dkg is currently certified at Master level.

Name: Daniel Kahn Gillmor
Member since: 2009-01-05 21:31:28
Last Login: 2009-01-06 19:54:49

FOAF RDF Share This

Homepage: http://cmrg.fifthhorseman.net/wiki/dkg

Notes:

I'm a free software developer and technology advisor for activist groups, educational groups, and non-profits. I'm a debian maintainer, and in the queue toward becoming a debian developer (though i have no illusions about that being a speedy process). I contribute to a range of projects, but my focus these days is on sorting out cryptographic infrastructure, and PKI in particular. I'd like to see the global network be a place that encourages end-to-end communication (where people are both producers and consumers of culture, ideas, and tools), rather than a system that traps people into mechanisms of centralized control. Without a reasonable *and* intuitive PKI, the hope of empowering the end user to be in full control of their communication will fade in the face of the power of the entities that control the networks themselves. Because this goal is for wide-spread user adoption, i also have a strong interest in usability, though my skills need work there. Good usability is actually much harder than good cryptography, i think. Some interesting projects that i'm a significant contributor to:

  • monkeysphere, an OpenPGP-based PKI for SSH
  • debirf, a project to run a full debian distribution entirely from RAM
I do minor contributions and security audits on a range of tools, including GnuTLS, Trac and OpenSSH. I maintain about a half-dozen packages for debian. My OpenPGP key is 0xD21739E9 (fingerprint .0EE5 BE97 9282 D80B 9F75 40F1 CCD2 ED94 D217 39E9)

Projects

Recent blog entries by dkg

Syndication: RSS 2.0

Challenge: one reproducible package a week

I encourage anyone interested in debian development to get involved with the Reproducible Builds project. My own project is to try to diagnose (and hopefully provide patches for) two unreproducible packages a week. Maybe you can do one package a week?

Reproducible Builds is another example of the kind of audacious project that I celebrated in my last blog post.

It's a fun way to learn a little bit about different parts of the archive, and to help on an incrementally-improving process. My workflow below is meant to encourage folks to join in. The documentation on the wiki is certainly more authoritative (and will be more up-to-date in the future).

My usual workflow is this:

  • Visit the list of unreproducible packages "with no notes" -- these are packages that are known to not build reproducibly, but no one else has diagnosed.
  • Click on a package basically at random (but if you notice one that you are familiar with in that list, go ahead and pick it!)
  • That will take you to a page showing the debbindiff (difference between binary packages) of the two builds. Sometimes, this shows an obvious difference, like the difference for cloc, which shows that the man page embeds the build time.
    • If you have a guess about what's wrong, but don't feel sure, pop over to the #debian-reproducible IRC channel on irc.oftc.net -- usually there are friendly people there who will discuss it with you.
    • If you find a debbindiff that is completely indecipherable, go back and pick another package
  • Fetch the package source. I like to use debcheckout from the devscripts package, so that i can work with the maintainer's revision control system of choice. With cloc above, i'd do:
    debcheckout cloc
    If that failed for some reason, I would use:
    apt-get source clock
  • Change into the source directory you just unpacked and use your preferred tools (i like good old grep and find) to figure out where the affected file is created, and how it derives its variance. You might want to look through the list of known causes of unreproducibility to see if there are any similar suggestions there.
  • If you can fix the variance, make a patch!
  • File a bug report with your diagnosis (and with your patch if you have one). I write my bug reports as a simple e-mail, with the subject line describing what i found, and with a header referring it to the r-b project, like this:
    Source: packagename
    Version: packageversion
    Tags: patch
    Severity: wishlist
    User: reproducible-builds@lists.alioth.debian.org
    Usertags: closest-usertag
    X-Debbugs-CC: reproducible-builds@lists.alioth.debian.org
    
    When choosing the closest usertag, i look at the "Usertagged bugs" block on the R-B continuous integration dashboard or the wiki documentation to see what makes sense.
  • If you find that this is an example of one of the known issues, you can also note it in the notes.git repository, or just mailing a description of what you found to the reproducible-builds mailing list.

The information at the R-B wiki page is quite detailed if you want more info.

Finally, many many thanks to all of the people involved in the project, and particularly to h01ger and Lunar^, who have both contributed a ton of work, and have also made it easy to plug in and help as a less-involved contributor. The nice automatically-updated statistics provided by the team's continuous integration work makes it a fun game to help out.

Tags: challenge, reproducible builds

Syndicated 2015-06-04 02:31:00 from Weblogs for dkg

Cheers to audacity!

When paultag recently announced a project to try to move debian infrastructure to python3, my first thought was how large that undertaking would likely be. It seems like a classic engineering task, full of work and nit-picky details to get right, useful/necessary in the long-term, painful in the short-term, and if you manage to pull it off successfully, the best you can usually hope for is that no one will notice that it was done at all.

I always find that kind of task a little off-putting and difficult to tackle, but I was happy to see someone driving the project, since it does need to get done. Debian is potentially also in a position to help the upstream python community, because we have a pretty good view of what things are being used, at least within our own ecosystem.

I'm happy to say that i also missed one of the other great benefits of paultag's audacious proposal, which is how it has engaged people who already knew about debian but who aren't yet involved. Evidence of this engagement is already visible on the py3porters-devel mailing list. But if that wasn't enough, I ran into a friend recently who told me, "Hey, I found a way to contribute to debian finally!" and pointed me to the py3-porters project. People want to contribute to the project, and are looking for ways in.

So cheers to the people who propose audacious projects and make them inviting to everyone, newcomers included. And cheers to the people who step up to potentially daunting work, stake out a task, roll up their sleeves, and pitch in. Even if the py3porters project doesn't move all of debian's python infrastructure to pyt3 as fast as paultag wants it to, i think it's already a win for the project as a whole. I am looking forward to seeing what comes out of it (and it's reminding me i need to port some of my own python work, too!)

The next time you stumble over something big that needs doing in debian, even something that might seem impossible, please make it inviting, and dive in. The rest of the project will grow and improve from the attempt.

Tags: py3-porters

Syndicated 2015-05-08 18:43:00 from Weblogs for dkg

Preferred Packaging Practices

I just took a few minutes to write up my preferred Debian packaging practices.

The basic jist is that i like to use git-buildpackage (gbp) with the upstream source included in the repo, both as tarballs (with pristine-tar branches) and including upstream's native VCS history (Joey's arguments about syncing with upstream git are worth reading if you're not already convinced this is a good idea).

I also started using gbp-pq recently -- the patch-queue feature is really useful for at least three things:

  • rebasing your debian/patches/ files when a new version comes out upstream -- you can use all your normal git rebase habits! and
  • facilitating sending patches upstream, hopefully reducing the divergence, and
  • cherry-picking new as-yet-unreleased upstream bugfix patches into a debian release.

My preferred packaging practices document is a work in progress. I'd love to improve it. If you have suggestions, please let me know.

Also, if you've written up your own preferred packaging practices, send me a link! I'm hoping to share and learn tips and tricks around this kind of workflow at debconf 15 this year.

Syndicated 2015-05-01 19:41:00 from Weblogs for dkg

Bootable grub USB stick (EFI and BIOS for Intel)

I'm using grub version 2.02~beta2-2.

I want to make a USB stick that's capable of booting Intel architecture EFI machines, both 64-bit (x86_64) and 32-bit (ia32). I'm starting from a USB stick which is attached to a running debian system as /dev/sdX. I have nothing that i care about on that USB stick, and all data on it will be destroyed by this process.

I'm also going to try to make it bootable for traditional Intel BIOS machines, since that seems handy.

I'm documenting what I did here, in case it's useful to other people.

Set up the USB stick's partition table:

parted /dev/sdX -- mktable gpt
parted /dev/sdX -- mkpart biosgrub fat32 1MiB 4MiB
parted /dev/sdX -- mkpart efi fat32 4MiB -1
parted /dev/sdX -- set 1 bios_grub on
parted /dev/sdX -- set 2 esp on
After this, my 1GiB USB stick looks like:
0 root@foo:~# parted /dev/sdX -- print
Model:  USB FLASH DRIVE (scsi)
Disk /dev/sdX: 1032MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name      Flags
 1      1049kB  4194kB  3146kB  fat32        biosgrub  bios_grub
 2      4194kB  1031MB  1027MB               efi       boot, esp

0 root@foo:~# 
make a filesystem and mount it temporarily at /mnt:
mkfs -t vfat -n GRUB /dev/sdX2
mount /dev/sdX2 /mnt
ensure we have the binaries needed, and add three grub targets for the different platforms:
apt install grub-efi-ia32-bin grub-efi-amd64-bin grub-pc-bin grub2-common

grub-install --removable --no-nvram --no-uefi-secure-boot \
     --efi-directory=/mnt --boot-directory=/mnt \
     --target=i386-efi

grub-install --removable --no-nvram --no-uefi-secure-boot \
     --efi-directory=/mnt --boot-directory=/mnt \
     --target=x86_64-efi

grub-install --removable --boot-directory=/mnt \
     --target=i386-pc /dev/sdX
At this point, you should add anything else you want to /mnt here! For example: And don't forget to cleanup:
umount /mnt
sync

Tags: bios, efi, grub, tip

Syndicated 2015-03-16 23:12:00 from Weblogs for dkg

a10n for l10n

The abbreviated title above means "Appreciation for Localization" :)

I wanted to say a word of thanks for the awesome work done by debian localization teams. I speak English, and my other language skills are weak. I'm lucky: most software I use is written by default in a language that I can already understand.

The debian localization teams do great work in making sure that packages in debian gets translated into many other languages, so that many more people around the world can take advantage of free software.

I was reminded of this work recently (again) with the great patches submitted to GnuPG and related packages. The changes were made by many different people, and coordinated with the debian GnuPG packaging team by David Prévot.

This work doesn't just help debian and its users. These localizations make their way back upstream to the original projects, which in turn are available to many other people.

If you use debian, and you speak a language other than english, and you want to give back to the community, please consider joining one of the localization teams. They are a great way to help out our project's top priorities: our users and free software.

Thank you to all the localizers!

(this post was inspired by gregoa's debian advent calendar. i won't be posting public words of thanks as frequently or as diligently as he does, any more than i'll be fixing the number of RC bugs that he fixes. This are just two of the ways that gregoa consistently leads the community by example. He's an inspiration, even if living up to his example is a daunting challenge.)

Syndicated 2014-12-12 23:00:00 from Weblogs for dkg

82 older entries...

 

dkg certified others as follows:

  • dkg certified skx as Master

Others have certified dkg as follows:

  • skx certified dkg as Master

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page