[08:44] <dholbach> good morning
[09:49] <lool> Are build failure handled in all cases by buildd admins or should I do something about them?
[09:49] <dholbach> MOTU Q&A session in #ubuntu-classroom in 10 minutes
[05:39] <bspencer> ping debian package masters
[05:39] <bspencer> I want to create a symbolic link in my rules file
[05:39] <bspencer> is there a "right" way?
[05:40] <seb128> do you need it in the rules file?
[05:40] <bspencer> uh
[05:40] <seb128> you can use a package.links
[05:41] <seb128> if that's for a file which gets installed
[05:41] <bspencer> yes it is
[05:41] <bspencer> package.links is a new file that gets placed in debian dir
[05:41] <seb128> yes
[05:41] <seb128> where package in the name of the binary package shipping the file
[05:42] <seb128> and the .links contains 
[05:43] <seb128> real_file_path symlink_file_path
[05:44] <bspencer> ok.  I'll play with that.  I need to know the final location of the installed package  (e.g. /usr/share/<pkg>/<some folder>
[08:47] <asac> Mithrandir: there?
[08:47] <asac> Mithrandir: we have some strange buildd issues... for instance xulrunner-1.9 build was finished, then hanged there and was killed after 150 minutes of inactivity
[08:47] <asac> Mithrandir: however it was uploaded to NEW
[08:47] <asac> Mithrandir: same appears to happen with i386 as well now
[08:48] <asac> Mithrandir: its finished and just sits there ... most likely blocking the buildd
[09:09] <agoliveira> kwwii: Hi. You're there?
[11:08] <rustyl> Anyone notice how libgtk2.0-0 is broken?  Attempting to install will fail with:
[11:08] <rustyl> libgtk2.0-0: Depends: libgtk2.0-common (= 2.12.0-1ubuntu3) but 2.12.0-1ubuntu2 is to be installed
[11:09] <rustyl> maybe a new version of gtk is in the process of being uploaded?
[11:09] <rustyl> or half of the related packages were uploaded and one of the packages failed to upload, leaving something like a log jam?
[11:10] <rustyl> The result is you can not build a new image, so expect the UME nightly to fail
[11:10] <rustyl> well... unless this is just a transient problem (like a few packages are in-flight into the apt repository)
[12:29] <rustyl> amitk, should the linux-ubuntu-modules-2.6.22-13-lpiacompat_2.6.22-13.33_lpia.deb package be running a depmod?  The reason the initramfs images are not pulling in the squashfs and unionfs images is because modprobe doesn't know about them (i.e. we are lacking a depmod)
[12:45] <rustyl> either way... i just fix a bug in image-creator where we are now correctly calling depmod on the target filesystem before creating the install images.  We had a bug that nobody noticed until this new package stopped depmoding.
[12:49] <amitk> rustyl: Yeah.. it should call depmod in postinst
[12:50] <amitk> could you run depmod on the target manually, and update-initramfs -u
[12:53] <rustyl> amitk, after manually running depmod, mkinitramfs correctly creates the initramfs 
[12:54] <amitk> and that gives you a working system?
[12:54] <rustyl> yes, i can not boot a usb image and have a workable system (well... other then a gtk package that has a problem)
[12:55] <amitk> cool
[12:56] <rustyl> and i just pushed a fix the moblin-image-creator that works around the depmod issue... we intend to always do a depmod (for good measure) before creating a USB image, but we were calling it on the project filesystem instead of the target filestem.  Nobody noticed before because the kernel packages always called depmod in the postinstall
[12:58] <amitk> rustyl: and they should always call depmod. I am wondering if this happened because I created a single package for lpia, instead of running the mega command that spits out L-U-M for all flavours of Ubuntu
[12:59] <amitk> I'll check up on that on Monday... late here now.
[01:00] <rustyl> l8r
[01:01] <rustyl> for anyone that is following the gtk failures... the new version of libgtk2.0-0 that was breaking new image creation (because libgtk2.0-common depended on it) appears to now be in the apt repository