[00:34] <smoser> psusi, hey. uploaded your util-linux
[00:34] <smoser> was going to ask you if it would work for gpt. i didn't think it would, but it seems to.
[00:34] <psusi> smoser, ahh, cool... I don't remember if kpartx speaks gpt or not
[00:35] <psusi> err, partx
[00:35] <slangasek> from what I've seen, it doesn't
[00:36] <slangasek> but maybe I was doing it wrong
[00:36] <psusi> smoser, I've got patches for upsteam parted to add a resizepart command to use the new ioctl to sync the new, larger patition size as well, so you can just run parted -s /dev/sda resizepart 1 100%
[00:39] <smoser> slangasek, psusi well, what i did is shown at https://bugs.launchpad.net/cloud-utils/+bug/1087526
[00:39] <smoser> it seemed like the kernel/udev could get confused easily (see comment 4), but it *did* work.
[00:40] <smoser> psusi, that'd be pretty nice.
[00:40] <smoser> for now, growpart does basically the same thing
[00:40] <smoser> growpart /dev/sda 1
[00:40] <smoser> will work for gpt or msdos
[00:41] <smoser> (as of today)
[00:41] <smoser> it uses sgdisk or sfdisk
[00:43] <smoser> but it (growpart) does not do the partx call yet. i plan to make an option to it.
[00:51] <psusi> smoser, why make it an option?  if sfdisk or sgdisk complain about BLKRRPART failing, may as well go ahead and run partx -u
[00:51] <smoser> psusi, yeah, i considered that.
[00:52] <smoser> the only reason to not have it just do it is that it "just didn't" before
[00:52] <psusi> well, before it was run in the initramfs so it wouldn't run into that error, right?
[00:52] <psusi> so now it does the same thing, just is no longer restricted to running in the initramfs
[00:53] <psusi> are there any other outstanding issues to dropping the initramfs from cloud images?
[01:09] <lifeless> psusi: wait, what ?
[01:21] <psusi> lifeless, at UDS... what was it, october before last?  in Orlando, we discussed dropping the initramfs as a requirement for simple configs that don't really need it
[01:22] <psusi> lifeless, cloud image boot time is apparently significantly impacted by the initramfs, and iirc, the one hangup for getting rid of it was growpart
[01:25] <lifeless> psusi: so what would an image look like then?
[01:25] <lifeless> psusi: FWIW cloud images boot in 5-6 seconds for us with the initramfs.
[01:25] <psusi> lifeless, just the kernel, no initramfs
[01:26] <lifeless> psusi: this worries me, because the initramfs provides an excellent debugging facility when things go wrong
[01:26] <lifeless> psusi: will it be easy to revert for folk building on the cloud images?
[01:27] <psusi> about the only thing that can go wrong in the initramfs with a simple disk config is can't find the root fs
[01:27] <psusi> yea.. the plan was to make it optional, and most configs have no need for it, so, faster boot
[01:27] <lifeless> psusi: we're using the cloud images to boot bare metal :0
[01:28] <smoser> i really doubt the initramfs is a significant speed issue for cloud images. it might be. but it'd shave a second or two at most i'd think.
[01:28] <smoser> clearly non-zero
[01:28] <psusi> the idea was also to have regular installs initramfs scripts detect whether or not an initramfs is actually required ( i.e. you are using lvm ) and disable it unless overridden
[01:29] <smoser> right. this is really a uber-fast desktop boot thing.
[01:29] <psusi> ohh, maybe it was the arm guys that were driving it because for them it was a big time sink
[01:29] <smoser> it was/is a time sync.
[01:29] <smoser> and it is not insignificant.
[01:29] <psusi> something about grub being very slow at IO on arm
[01:29] <smoser> loading 10M-ish, decompressing, runnign a bunch of scripts ...
[01:30] <smoser> well, bios load is generally slow (which is what grub is using)
[01:30] <smoser> so its not going to be the fastest thing in the world, for sure.
[01:30] <psusi> iirc, arm has no bios so grub was using its own disk module there, which was supposedly very slow
[01:30] <smoser> right.
[01:31] <psusi> but it does add a not insignificant time to boot on your average pc desktop and cloud images too
[01:31] <smoser> anyway... during that "lets get rid of initramfs" discussion, i raised that i like initramfs , and this was one of the reasons why.
[01:31] <smoser> but then psusi fixed *that* the right way, and now we dont need initramfs for it anymore. which is really cool.
[01:32] <smoser> but doesn't mean we'll drop initramfs. just one less thing to prevent it being dropped.
[01:32] <lifeless> ok
[01:33] <lifeless> well, let me know what we need to do to keep it on, so the ops guys doing run around gibbering
[01:33] <lifeless> :)
[01:33] <psusi> what benefit does it provide when you are using a simple disk config?
[01:34] <psusi> it's whole purpose is to locate the root fs, so if the kernel can do that on its own...
[01:34] <psusi> did the kernel uuid finding patches ever get applied?
[01:35] <lifeless> psusi: so - for example - the HP public cloud has two block devices
[01:35] <lifeless> psusi: and there may be LVM particularly if you are using boot from volume.
[01:36] <psusi> yea, lvm still would require an initramfs
[01:36] <lifeless> psusi: bare metal cloud will often have more complex setups too.
[01:36] <psusi> well, if / is on lvm anyhow
[01:36] <smoser> lifeless, you dont have to worry.
[01:36] <lifeless> psusi: MAAS is moving to using cloud images; nova bare metal uses cloud images.
[01:36] <smoser> its not going away.
[01:36] <lifeless> smoser: yeah, I'm not:)
[01:36] <smoser> it would be going away in places where its not needed
[01:37] <smoser> but you're listing places where it *is* needed.
[01:37] <lifeless> smoser: that was estalished above; I'm answering psusi's question about where it may be needed.
[01:37] <lifeless> smoser: I may have misparsed that question, of course :>
[01:37] <psusi> right, the question  was where is it needed, other than when / is on lvm ;)
[01:37] <smoser> when / is crypto
[01:37] <psusi> or that ;)
[01:37] <lifeless> or when / has died and you want to poke around
[01:37] <smoser> when / is iscsi
[01:38] <smoser> lifeless, when / has died and yrou initramfs was on /
[01:38] <smoser> you're kind of dead
[01:38] <lifeless> smoser: well, PXE booting initramfs+kernel
[01:38] <psusi> that's grub fallback time
[01:38] <lifeless> smoser: / can die, can still examine :)
[01:38] <smoser> well, its not goingt away in pxe boot either!
[01:39] <lifeless> indeed!
[01:39] <psusi> yea... the idea was for simple disk configs.. i.e. root is on a regular disk partition
[01:39] <smoser> and smart people were even discussing ways where grub would fall back automatically to initramfs if no-initramfs seemingly failed.
[01:40] <lifeless> nice
[01:40] <smoser> just ask yourself, do you think that OS that runs on your devices from apple have an initramfs ?
[01:40] <smoser> (not that they boot fast... but probably not necessary )
[01:41] <lifeless> smoser: what devices from apple? :)
[01:41] <smoser> your kids devices, lifeless
[01:41] <smoser> :)
[01:41] <smoser> yeah, thats why i have one.
[01:41] <smoser> kids.
[01:41] <lifeless> You have a kid to get apple devices?
[01:42] <lifeless> Seems expensive :>
[01:42] <smoser> its not significantly more than the price of the device.
[01:42] <smoser> and easier to justify to employer
[01:42] <lifeless> rotfl
[01:49] <smoser> can someone else confirm for me ...
[01:49] <smoser> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1015339
[01:49] <smoser> that doesn't look like an installer issue to me, but a driver issue.
[01:50] <smoser> (as in lack of pci-ids or some other reason it wouldn't load automatically)
[01:52] <lifeless> smoser: hi
[01:52] <lifeless> smoser: so thats our hardware config; the driver is in a separate kernel package
[01:53] <smoser> separate kernel package, as in ...
[01:53] <lifeless> smoser: linux-image-extra
[01:55] <smoser> ah. well, that is installed by linux-server -> linux-generic -> linux-image-generic -> linux-image-extra-3.8.0-4-generic
[01:55] <lifeless> does the server image build include that by default?
[01:55] <smoser> ie, it was not just missing driver in initrd.gz (at least per the reporter).
[01:56] <lifeless> hi
[01:56] <lifeless> smoser: EntropyWorks is the reporter
[01:56] <EntropyWorks> Hi
[01:56] <lifeless> EntropyWorks: I'll just pastebin the discussion so far
[01:56] <smoser> oh. there, you're right. it does not include it.
[01:56] <smoser> at least per report
[01:56] <lifeless> EntropyWorks: http://paste.ubuntu.com/1610977/
[01:56] <smoser> so you're right. thats strange.
[01:57] <smoser> but EntropyWorks it seems that just having it in the intiramfs is not enoguh to make it work, right?
[01:57] <smoser> yo uahve to load it manually?
[01:57] <smoser> at least that goo.gl link there seems to imply that (as does another report to me)
[01:58] <lifeless> so there may be two bugs :)
[01:58] <EntropyWorks> let me dig up my notes on this.
[01:58] <lifeless> A) Where is my driver!
[01:58] <lifeless> B) Why driver not load?!
[01:59] <smoser> right.
[01:59] <smoser> but "where is my driver" is not (i dont think) related to "my driver is in -extra"
[01:59] <smoser> so yeah, "where is my driver" i san installer/installer build process bug.
[02:00] <smoser> "why my driver no load" is a driver/udev/kernel bug i think.
[02:00] <smoser> EntropyWorks, so why did you do this udev rule business for modprobing?
[02:01] <lifeless> smoser: right, being in -extra isn't an intrinsic bug (but if -extra isn't in the installer default initramfs...)
[02:01] <smoser> nah. most every thing is 'extra' from that perspective
[02:02] <smoser> i think
[02:02] <EntropyWorks> I eventually did something slightly different after getting fustrated.
[02:02] <smoser> but maybe your'e right. i could be wrong.
[02:04] <EntropyWorks> I went and downloaded the http://us.archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/initrd.gz and unpacked it...
[02:04] <smoser> EntropyWorks, it seems to me what you did with that udev rule should have been equivalent to adding the item to /conf/modules in the intiramfs.
[02:05] <smoser> ie, by putting it in /conf/modules, you're doing what would happen if you had put it in /etc/initramfs-tools/modules during the initramfs build process.
[02:06] <EntropyWorks> I added a 80-mellanox-drivers.rules to /etc/udev/rules.d
[02:07] <smoser> right. but why/where did you come up with that?
[02:08] <smoser> it would seem to me that you're essentially loading mlx4_en every time a "net" device was found.
[02:08] <smoser> i could be missing something.
[02:08] <EntropyWorks> its been a while since I repackaged this initrd.gz for the netboot so forgive me while I try to remember. I think I may have just borrowed it from somewhere else. to be honest.
[02:09] <smoser> EntropyWorks, thats fine. i was just trying to see if i was missing something.
[02:09] <lifeless> EntropyWorks: thats whats in the diskimage-builder rules
[02:09] <EntropyWorks> before i was doing this.. echo "modprobe mlx4_en ; # Move this line up" >> init
[02:09] <smoser> :)
[02:09] <lifeless> EntropyWorks: we have both the modprobe and the udev rule
[02:09] <smoser> you clearly should not need both.
[02:10] <smoser> right?
[02:10] <lifeless> https://github.com/stackforge/diskimage-builder/tree/master/elements/mellanox
[02:10] <EntropyWorks> right
[02:10] <smoser> and the udev rule is wierd, an I right?
[02:10] <smoser> you're loading that module every time a net device is seen
[02:10] <smoser> (but then, i'm kind of confused as to how linux knew it was a net device since clearly the driver didn't completely recognize it)
[02:11] <smoser> EntropyWorks, just so we're clear, i'm grateful for your help, i'm just trying to figure out if you were doing stuff for a reason, so that i can make sure we take that into account.
[02:13] <smoser> lifeless, where does 'init' from mellanox/init end up? hnow does that get rendered ?
[02:14] <lifeless> smoser: it gets attached to the deploy ramdisk init script
[02:14] <lifeless> smoser: the deploy ramdisk is a special special creature
[02:16] <smoser> lifeless, thanks.
[02:18] <EntropyWorks> I think this covers how I have been fixing my initrd.gz at the moment
[02:18] <EntropyWorks> http://paste.ubuntu.com/1611008/
[02:19] <EntropyWorks> I may have added etc/udev/rules.d/010_net-hotplug.rules but I don't think I did.
[02:22] <EntropyWorks> smoser: honestly its been awhile and if there is anything confusing I can build another initrd.gz from scratch if you need it
[06:22] <pitti> Good morning
[06:28] <shadeslayer> hi pitti
[07:04] <infinity> siretart: Hey, handbrake (in both experimental and raring) seems to be implicitly declaring a few functions that exist nowhere in the source, and I can't find reference to them in libav headers either.
[07:05] <infinity> siretart: You might want to grep build logs for "implicit", and figure out where those missing functions went. :P
[07:06] <infinity> siretart: (Maybe it's depending on either an old feature that was removed from libav, or a new feature that's not yet in the Debian packages?)
[07:56] <tjaalton> cjwatson: um, nvidia-173 isn't in -proposed yet?
[07:56] <tjaalton> cjwatson: for .2
[08:00] <tjaalton> oh it's nvidia-173-updates
[08:01] <tjaalton> jockey doesn't suggest any drivers for my gf8600gt
[08:01] <tjaalton> the window is empty
[08:12] <tjaalton> should there be a jockey launcher in system settings?
[08:12] <tjaalton> on 12.10
[08:12] <dholbach> good morning
[08:14] <tjaalton> ..behind software sources it seems
[08:22] <pitti> tjaalton: it's not jockey any more; right, software-properties supersedes it
[08:22] <pitti> admittedly hard to discover
[08:26] <tjaalton> yeah
[08:32] <tjaalton> it should shout out tho that the system needs to be rebooted once the driver has been changed.. just logging out will end up in a crash and a bug report..
[08:32] <tjaalton> a confusing one too
[09:46] <dholbach> @pilot in
[09:46] <seb128> @pilot in
[09:47] <seb128> dholbach, alter! in what order do you go through the sponsoring list? I will try to help you a bit, I missed my shift while I was in SF
[09:47]  * dholbach hugs seb128
[09:47]  * seb128 hugs dholbach
[09:47] <dholbach> I don't care which way we go - maybe we just say what we're looking at?
[09:47] <seb128> dholbach, ok
[09:47] <seb128> dholbach, I will try to grab what is desktopish first
[09:48] <dholbach> seb128, I'll do cliff-tablib
[09:49] <seb128> dholbach, doing alacarte nautilus language-selector xorg-gtest
[09:49] <dholbach> woohoo
[09:49] <seb128> ;-)
[09:52] <dholbach> seb128, taking a look at ubuntukylin-theme
[09:52] <seb128> Riddell, hey, do you have any comment on https://code.launchpad.net/~gunnarhj/ubuntu/raring/language-selector/help-update/+merge/145491 (dropping language-selector-kde)?
[09:53] <Riddell> seb128: I'm not currently expecting to go back to using language-selector so I guess it's fine
[09:53] <seb128> Riddell, ok, thanks, we can still bring it back some way if really needed
[09:54] <seb128> pitti, ^ I'm sponsoring l-s then
[09:54] <pitti> seb128: merci
[09:54] <seb128> pitti, or did you want to do it/had it ready?
[09:54] <seb128> pitti, de rien ;-)
[09:54] <pitti> no, I didn't
[09:54] <seb128> good
[09:57] <cjwatson> tjaalton: my mistake, sorry
[09:58] <cjwatson> tjaalton: I noticed the missing task and my eyes tend to pass over existing invalid tasks ...
[10:03] <tjaalton> cjwatson: heh, yeah
[10:07] <dholbach> seb128, taking a look at ktorrent
[10:08] <seb128> dholbach, looking at telepathy-logger-qt
[10:13] <dholbach> seb128, looking at ubuntu-sounds
[10:15] <Esokrates> howto apply ubuntu settings to compiz compiled from source?
[10:16] <Esokrates> I have compiled and installed compiz but when I login the only thing I get to see is the wallpaper
[10:17] <Esokrates> so I change to a VT and start compiz using: env DISPLAY=:0 compiz –replace composite opengl move resize decor compiztoolbox mousepoll wall expo animation switcher unityshell
[10:21] <seb128> Esokrates, try asking on #ubuntu-unity but the compiz package ships a profile, export COMPIZ_CONFIG_PROFILE="ubuntu"
[10:21] <seb128> Esokrates, not sure how you can get the profile and apply it from a source build
[10:22] <Esokrates> @seb128 thank you
[10:22] <udevbot> Error: "seb128" is not a valid command.
[10:23] <seb128> dholbach, looking at sphinxbase
[10:38] <seb128> dholbach, commented on the python-tz from stokachu, seems like a possible direct sync
[10:38] <seb128> stokachu, ^
[10:40] <jibel> doko, python2.7 2.7.3-15ubuntu1 broke the testsuite of bzr, I filed bug 1116079
[10:40] <jibel> doko, it's probably caused by this change "Issue #1159051: GzipFile now raises EOFError when reading a corrupted file with truncated header or footer.", could you have a look
[10:40] <jibel> ?
[10:42] <dholbach> seb128, cool
[10:46] <seb128> dholbach, looking to vino
[10:47] <dholbach> wow, you're quick :)
[10:52] <seb128> dholbach, french efficiency my german friend :p
[10:52] <dholbach> haha
[10:54] <dholbach> tjaalton, Sarvatt: do we have someone we can ping upstream about bug 985202? :)
[10:56] <tjaalton> dholbach: sure
[10:56] <seb128> pitti, hey, can you set https://code.launchpad.net/~baltix/ubuntu/precise/ubuntu-defaults-builder/remove-quotes-from-firefox-bookmarks-titles/+merge/137107 as needs work/work in progress/whatever status is available to indicate it needs the comments to be addressed before being ready for sponsoring?
[10:56] <dholbach> tjaalton, and a bit more recently bug 1112147
[10:59] <tjaalton> hmm, could be that they'd have better success via the list(s)
[11:00] <tjaalton> although the mesa-dev list does get all the bugmail too
[11:01] <seb128> pitti, can you set those as merged (they are in the unapproved queues for SRU):
[11:01] <seb128> https://code.launchpad.net/~arges/ubuntu/precise/iptables/fix-lp982961/+merge/145941
[11:01] <seb128> https://code.launchpad.net/~arges/ubuntu/quantal/iptables/fix-lp982961/+merge/145942
[11:06] <tjaalton> dholbach: got a rev-by for the libxrandr patch, I'll upload it
[11:06]  * dholbach hugs tjaalton!
[11:07] <tjaalton> the mesa patch doesn't apply as-is to the version we're preparing, will investigate further..
[11:12] <dholbach> seb128, looking at the raring part of firebird2.5
[11:17] <seb128> dholbach, looking to bind9
[11:23] <seb128> lamont, hey
[11:24] <seb128> lamont, I'm looking at https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1090593 , e.g https://launchpadlibrarian.net/130013535/quantal.debdiff ... those debdiffs only change the ip, I saw that your version adds a "D.ROOT-SERVERS.NET.	 3600000      AAAA  2001:500:2D::D" ipv6 entry as well (in addition of autotools noise)
[11:24] <seb128> lamont, should the ipv6 entry be added in those SRUs or are the current debdiffs with only the ip change fine for upload?
[11:28] <dholbach> for security uploads to the current devel release - is it normal to use a *ubuntu0.13.04... version number?
[11:31] <seb128> xnox, hey, is there still anything blocking https://bugs.launchpad.net/ubuntu/+source/player/+bug/979841 to be uploaded (you mentioned python issues)? you can probably fix the bug number/target and upload rather than just to block on the submitter to fix those typos
[11:33] <xnox> seb128: let me check if python multiarch hacks got uploaded or not.
[11:39] <cjwatson> dholbach: I wouldn't bother, just increment the version as usual
[11:40] <dholbach> cjwatson, my question was the other way around (the suggested patch had 13.04 in it) and I thought it looked weird :)
[11:41] <cjwatson> Yeah, I know.  It's not forbidden but I agree it's weird.  If I were sponsoring that I would just amend the patch and tell the contributor I'd done so (if it were otherwise OK)
[11:41] <dholbach> cjwatson, since I have you here... do you have any feelings about bug 1102107? (I just saw that an earlier request in Debian was not acted on yet: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676533)
[11:41] <dholbach> yeah, I changed it to ubuntu1 :)
[11:41] <cjwatson> those bugs are quite different - arm != arm64
[11:41] <cjwatson> I'll review 1102107, thanks
[11:43] <cjwatson> dholbach: (And BTW 676533 was already applied in Ubuntu)
[11:43] <seb128> xnox, I'm unsubscribing sponsors from https://bugs.launchpad.net/ubuntu/+source/libsemanage/+bug/1103271 btw, your comment indicates that the patch will need to be reworked if it's still needed at all, right?
[11:43] <seb128> xnox, oh, you already did that, ignore me ;-)
[11:44] <dholbach> cjwatson, yes, I saw that - I just thought that if the request for arm wasn't replied to after half a year, we probably shouldn't block on debian for arm64
[11:45] <dholbach> thanks a lot for having a look at it!
[11:46] <cjwatson> Eh, it's really not that related - that's arm optimisation, not arm enablement
[11:46] <cjwatson> Enablement rightly normally jumps the queue
[11:47] <dholbach> oh ok
[11:48] <cjwatson> dholbach: I'm going to have to look around as I'm not convinced the second patch is correct either - it doesn't seem to agree with my reading of the arm64 abi
[11:49] <dholbach> thanks a lot
[11:52] <seb128> @pilot out
[11:52] <seb128> dholbach, ok, if/when pitti is around and mark the merge requests I pointed before as needs work/merge we should be < 35 in the queue
[11:52] <seb128> dholbach, time to get some lunch ;-)
[11:53]  * dholbach hugs seb128
[11:53] <dholbach> good work
[11:53]  * seb128 hugs dholbach
[11:53] <seb128> thanks, you too
[11:55] <jamespage> @pilot in
[11:55] <jamespage> dholbach: how low can we go :-)
[11:55] <dholbach> yes yes yes! :)
[11:56]  * dholbach hugs jamespage
[11:56] <dholbach> piloting party :)
[11:56] <dholbach> jamespage, looking at 'player' right now
[11:56] <jamespage> dholbach: OK _ I'll look at the bind SRU
[11:57] <dholbach> jamespage, if you check the backlog - seb128 pinged lamont about something related to bind earlier
[11:57] <dholbach> not sure if it's the same issue
[11:58] <seb128> jamespage, I looked at bind9, I wanted to know if we should add the ipv6 record lamont added in his ppa and debian or not
[12:01] <jamespage> seb128: right-oh
[12:25] <marga> o/
[12:25] <marga> I just uploaded two debdiffs to https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1100587
[12:26] <marga> I was wondering if this could be considered for an SRU or not.
[12:37] <seb128> marga, hey, that debdiff seems fine to me, I will sponsor it today
[12:38] <marga> seb128, tnx
[12:41] <seb128> marga, yw, was there any other bug/patch that you want review on? (asking because some might be lost in email backlog from our side)
[12:43] <pitti> seb128: sorry, missed your pings! doing now
[12:43] <seb128> pitti, hey, danke!
[12:44] <marga> seb128, I need to discuss the dropbear patch with vorlon
[12:44] <marga> But I'm guessing I still need to wait a few hours for him to be around.
[12:44] <seb128> yeah
[12:44] <seb128> I will let non desktopish ones to Steve ;-)
[12:44] <marga> Aside from that, I think I don't have anything else pending.
[12:45] <seb128> ok, good
[13:05] <lamont> seb128: "my version" is the current-n-correct file, not some patch applied to some randomly old file. :D
[13:05] <lamont> seb128: my ppa has some bits sitting in it - though I suspect I'll have even-newer for raring
[13:06] <lamont> seb128: so yes, the answer is we should have all of the entries in the file...
[13:09] <seb128> lamont, hey
[13:09] <seb128> lamont, well the only difference between "current-n-correct file" and "some randomly old file" is a one line ipv6 record ;-)
[13:10] <seb128> lamont, your version also has some autotools noise, not sure how much the SRU team like that
[13:10] <lamont> hrm
[13:10] <seb128> lamont, I saw you uploaded those fix to Debian and to your ppa, any plan to deal with the SRUs for Ubuntu as well? ;-)
[13:10]  * lamont was hoping to avoid learning the SRU process
[13:11] <lamont> s/learning/being reminded about/
[13:11] <seb128> lol
[13:11] <seb128> lamont, the bug is SRU ready, you just need to get sources uploaded targetting the right series
[13:11] <seb128> lamont, with the changelog having a reference to the launchpad bug, and without the autotools noise if possible
[13:12] <lamont> ah, that's not so bad
[13:12] <lamont> I think I might be talked into that
[13:12] <lamont> is tomorrow soon enough? tuesdays tend to be crazy
[13:13] <dholbach> seb128, jamespage: I'll do some more sponsoring tomorrow - now need to get some other things done first :)
[13:14] <dholbach> @pilot out
[13:14] <dholbach> and: we're at 31!
[13:15] <marga> seb128, thanks again :)
[13:15] <seb128> dholbach, great work!
[13:15] <seb128> marga, yw ;-)
[13:15] <seb128> lamont, yeah, no hurry, I was going to upload the version of the guy who took the time to contribute the debdiffs but as I said he didn't include your ipv6 extra entry ... anyway if you want to take care of it this week great, I will just get it off the sponsoring queue and assign to you ;-)
[13:17] <lamont> sounds good
[13:17] <rbasak> seb128, lamont: that was me. My understanding is that SRUs need to be minimal
[13:19] <seb128> rbasak, hey, they do, but if the ipv6 entry (which is a one liner) is considered useful there is no reason to do 2 uploads for a 1 liner each, we can as well include both changes in that update
[13:21] <rbasak> Sure, I understand. I suppose this comes down to my original philosophy that it barely matters anyway. bind will immediately bootstrap the ipv6 entry from any of the other addresses listed, so I saw the SRU as merely fixing the soon-to-be-broken entry rather than anything else
[13:22] <seb128> rbasak, I think what you did is right, but if lamont (who is the bind maintainer) wants to include the ipv6 change as well I will not stop him
[13:24] <lamont> rbasak: by your logic, we don't need to update the ipv4 address either - 1 time in 13 the startup will be delayed by a few seconds.  So yeah, fixed is better
[13:25] <lamont> so yeah, keeping that file current is a good thing
[13:34]  * jamespage gets the feeling he's now just following dholbach through bugs...
[13:54] <Riddell> kirkland: anerd has binary files in the .orig.tar.gz, should I reject to let you fix that?
[14:16] <jamespage> @pilot out
[14:25] <tjaalton> doko: hey, so about llvm.. would it be possible to include a snapshot of the r600-branch just for mesa?
[14:25] <tjaalton> doko: as a new package
[14:26] <tjaalton> doko: upstream says the branch will stabilize tomorrow, since mesa 9.1 was branched last week
[14:27] <kirkland> Riddell: sure, you bet
[14:27] <kirkland> Riddell: sorry about that :-/
[14:31] <mjt> hallyn: telling the truth, i didn't understand anything in your lxc reply... :)
[14:33] <Riddell> kirkland: voila
[14:51] <tomreyn> hi, according to apport i'm affected by https://bugs.launchpad.net/bugs/925545 but this bug is hidden. can you tell me whether there is a known workaround, though?
[14:57] <barry> seb128, stokachu shall i just sync python-tz now?
[15:04] <hallyn> mjt: heh, sorry, rant :)
[15:25] <jamespage> doko: did you see this? http://lists.debian.org/debian-java/2013/02/msg00005.html
[15:46] <dholbach> highvoltage, stgraber: ready for in 45m? :)
[15:47] <jbicha> cjwatson: could you add clutter-1.0, clutter-gst, clutter-gtk, cogl, gnome-bluetooth, gnome-icon-theme-symbolic, and vte3 to the ubuntu-desktop set?
[15:48] <jbicha> I already sent https://lists.ubuntu.com/archives/devel-permissions/2013-January/000440.html for all but gnome-bluetooth
[15:50] <stgraber> dholbach: yep
[15:50] <dholbach> stgraber, greta
[15:50] <dholbach> great
[15:56] <kirkland> Riddell: can you give her another look?  cheers!
[16:00] <Riddell> kirkland: accepted!
[16:00] <kirkland> Riddell: cheers, bud, thanks
[16:01] <smoser> cjwatson, ping
[16:01] <smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1015339
[16:02] <cjwatson> smoser: yes?  I followed up this morning and made that bug not my problem :)
[16:02] <smoser> there seem 2 issues there.  1 (as you stated) the network driver does not get into the initrd.gz.
[16:02] <smoser> 2. the modules dont get auto-loaded
[16:02] <smoser> i dont think this is "your problem"
[16:02] <cjwatson> there was a horribly confused pile of stuff involving manually created initrds
[16:02] <smoser> but can you verify for me, that they should "just get loaded"
[16:02] <cjwatson> I decided it was unlikely to be diagnosable until we had something more sane
[16:03] <smoser> if they're present, based on udev and pci-ids built in.
[16:03] <cjwatson> smoser: that is generally up to the modalias tables in the kernel
[16:03] <smoser> right
[16:03] <cjwatson> smoser: if the ids are correct then they will be auto-loaded, yes
[16:03] <cjwatson> and usually if they aren't then the driver won't bind to the device anyway
[16:03] <smoser> k. so it would appear to me that those need updating also.
[16:03] <smoser> in this case at least, manual 'modprobe' gets them functional.
[16:04] <smoser> thanks, cjwatson . as you said "not your problem" :)
[16:04] <cjwatson> there's a big list of ids in the driver; certainly possible it's missing one or two
[16:04] <cjwatson> can't tell from the bug since it doesn't quote any ids
[16:05] <cjwatson> and I would say that any id update should be regarded as a separate bug
[16:10] <stokachu> barry: should i remove that MP since im going to do a sync ?
[16:11] <barry> stokachu: probably not delete it.  what status options do you have?  (probably different than me since it's your mp)
[16:11] <stokachu> barry: i got WIP, needs review and merged
[16:11] <barry> stokachu: hmm
[16:12] <barry> stokachu: yeah, i guess delete it then
[16:13] <stokachu> ok
[16:13] <ogra> hmm, so diggin into the udevd issues on the nexus7(i now end up with 26 daemons on boot), stracing shows that only two of them are actually active, the rest just sits and gives no output via strace
[16:21] <Quintasan> \o
[16:23] <cjwatson> tumbleweed: Your mk-sbuild change to improve naming of cross-building chroots doesn't align with what Adam committed to upstream sbuild; your version has an extra "-cross" in the output name.  Would you mind if I removed that extra "-cross", since it hasn't been uploaded yet anyway?
[16:24] <cjwatson> I don't think it's necessary - SERIES-BUILD-HOST should be clear enough
[16:24] <stokachu> barry: pad.lv/1116418
[16:24] <stokachu> i did a brief explanation about most of it being in debian, and i didnt notice any other Ubuntu specific changes
[16:32] <barry> stokachu: looks good, thanks.  i'll do the sync momentarily
[16:34] <stokachu> barry: awesome! :D
[16:34] <stokachu> barry: since its a request sync do i get any credit for it? (mainly for when i apply for core-dev)
[16:36] <barry> stokachu: if i run syncpackage correctly, you should ;)
[16:36] <stokachu> lol ok cool, thanks man for your help
[16:37] <barry> stokachu: thanks for working so hard on this package.  it's always fun when you think you've got an easy one and it turns out to be "interesting" :)
[16:37] <stokachu> barry: yea no kidding, i was like hmm python-tz should be easy its just timezones :X
[16:37] <cjwatson> pitti: Do you think we're good to go with language-pack-* for precise-updates?
[16:48] <marga> slangasek, I'm hoping you'll be around soon.
[16:49] <marga> slangasek, I'd like to discuss the fix for https://bugs.launchpad.net/ubuntu/+source/dropbear/+bug/834174
[16:56] <slangasek> marga: hey there
[16:56] <slangasek> marga: otp, but I have a couple spare brain cycles
[16:56]  * marga tries to expand "otp"
[16:57] <slangasek> "on the phone" :-)
[16:57] <marga> Anyway, the thing is, do you want me to prepare a new upload without the "echo 'passwd: compat'" line? Or do you want a completely different patch?
[16:57] <slangasek> marga: I think it needs to be changed to be "echo 'passwd: files'".
[16:58] <marga> Alright.  Next question, what version should this package be? Because the one with the bad patch is in precise-updates
[16:58] <slangasek> marga: the current hook is buggy if plymouth isn't already pulled into the initramfs
[16:58] <ogra> slangasek, oh its not "out to pee" ? and i was wondering about the weak blatter of all our managers :P
[16:58] <slangasek> hmm?  how did it get into precise-updates?
[16:58] <marga> oh, maybe I'm wrong
[16:59] <marga> I thought I had had this sponsored
[16:59] <slangasek> marga: I was reviewing it prior to accepting it into the archive
[16:59] <slangasek> marga: sponsorship just gets you to the queue, then you have to pass the SRU team gauntlet ;)
[16:59] <marga> ah, precise-proposed, not updates
[16:59] <marga> I always mix them, sorry.
[16:59] <slangasek> and I was the SRU gauntlet here
[16:59] <marga> alright.
[16:59] <marga> So, same version number or different?
[16:59] <slangasek> same
[17:00] <marga> ok.  Will have it there for you tomorrow.
[17:00] <marga> (with chekcing that it works and that)
[17:00] <slangasek> sounds good, thanks!
[17:01] <pitti> cjwatson: yes, from my side
[17:02] <cjwatson> pitti: excellent, I'll get going on that then
[17:07] <xnox> slangasek: marga: don't we need an upload into raring to diverge with "s/compat/files"
[17:07] <xnox> ?
[17:08] <slangasek> xnox, marga: yes, this should also get fixed in raring - or at least have a bug opened against dropbear in Debian about the use of 'compat' being buggy
[17:08] <cjwatson> pitti: I can get the list easily enough; we just hand an enormous list to sru-release, right?
[17:08] <pitti> cjwatson: I usually use sru-release -p language-pack-
[17:08] <pitti> cjwatson: (--pattern)
[17:09] <pitti> cjwatson: http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/view/head:/doc/operator-guide.txt
[17:09] <pitti> cjwatson: "Releasing -proposed packages to -updates
[17:09] <cjwatson> oho
[17:11] <infinity> ev: *poke*... whoopsie that builds? :)
[17:11] <ev> oh yeah
[17:11] <ev> on it now
[17:11] <pitti> cjwatson: yeah, documentation -- scary, isn't it?
[17:14] <infinity> ev: Thanks.
[17:18] <ev> infinity: done
[17:20] <arges> is there anyway pad.lv/1052038, can be sponsored, then SRUed for Precise? thanks
[17:21] <infinity> Laney: Not that I disagree that C++ symbols files are a pain, but why not just feed all the maliit-framework build logs to pkgkde-symbolshelper batchpatch, and be done with it, instead of dropping the symbols file entirely?
[17:22] <Laney> infinity: I tried, but the tool kept refusing to apply patches and also applied some in a way that broke other arches. So in the end I saw red.
[17:22] <Laney> Hopefully I have enough state to file bugs
[17:23] <Laney> s/refusing to apply/ignoring/, perhaps
[17:23] <infinity> Laney: Sounds like you were trying to apply each arch individually.
[17:23] <infinity> Laney: Hence "batchpatch".  If you take -0ubuntu1, grab ALL the build logs, and feed them all in at once, it tends to DTRT.
[17:24] <Laney> I was doing that - that was when it didn't apply all of the hunks and still FTBFSed
[17:24] <ev> ughhhhhhh
[17:24] <infinity> Hrm.  Weird.
[17:25] <Laney> then I tried some other permutations and that was when it undid some other correct arch annotations
[17:25] <Laney> which I agree is because I was using it wrong at that point
[17:25] <infinity> ev: I've heard good things about test building. :)
[17:25] <ev> I did! (just not in raring)
[17:26] <ev> fixing, throwing it at sbuild, shouting angry things, etc
[17:27] <infinity> Heh.
[17:39] <smoser> cjwatson, can i make the installer load modules via the kernel cmdline ?
[17:39] <smoser> ie, as if they were in /conf/modules or something.
[17:42] <cjwatson> smoser: I don't think s
[17:42] <cjwatson> o
[17:42] <infinity> smoser: There's a general assumption that udev actually works correctly these days.  How is this failing you?
[17:42] <infinity> smoser: (You can blacklist modules from the commandline, but not the other way around)
[17:44] <smoser> infinity, its failing by design on this issue.
[17:44] <smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1115710
[17:45] <smoser> infinity, its not loaded here becaujes the thing that gets automatically loaded is mlx4_core , not mlx4_en .
[17:45] <smoser> that is how it is designed by upsream as ethernet or infiniband usage is somewhat "configruration"
[17:45] <cjwatson> eh, if something isn't autoloaded by design then the design is wrong
[17:46] <infinity> smoser: Yeah, uhm.  Fix the kernel bug?
[17:46] <cjwatson> there are several other modules like this that we've dealt with in various ways
[17:46] <cjwatson> unfortunately I don't currently remember their names ...
[17:47] <smoser> its not necessarily a kernel bug.
[17:47] <infinity> smoser: This will be just as broken on the installed system as in an installer initrd, so I don't see how it's not a bug.
[17:47] <smoser> correct. and the user will configure the device to act as infiniband or as ethernet
[17:47] <infinity> smoser: (Unless we're to assume this driver is a unique snowflake that needs to be manually loaded on installed systems too, which pretty much anyone will tell you is exactly how this isn't supposed to work)
[17:47] <cjwatson> there are ways to deal with this kind of thing in installer code - but we haven't had to add any new examples of those in years and I don't want to do so ever again
[17:48] <smoser> so it wont "just work" because you codn't know which "just work" is right.
[17:48] <cjwatson> you *could* have a udev rule that interrogates the device for whether it's in ethernet or infiniband mode and loads the right other module
[17:48] <cjwatson> but if udev can do that, so can the kernel
[17:48] <infinity> Exactly.
[17:48] <cjwatson> and either is more appropriate than adding configuration to the initramfs or to the installed system
[17:49] <smoser> i'm in agreement with that.
[17:49] <cjwatson> hardware upstreams are generally terrible at this kind of thing; there is no reason you should trust their design decisions implicitly
[17:49] <smoser> but as it is here, upstream kernel isn't going to magically load, and just saying "make the ethernet driver load" is not the right solution either.
[17:49] <cjwatson> Linux has plenty of history with overriding foolish decisions made by hardware vendors
[17:49] <infinity> Dear god, you referenced a 211 page PDF in the bug.
[17:50] <smoser> well, search for mlx4_en in it, infinity
[17:50] <infinity> smoser: Last I checked, we build those kernels, we don't trust upstreams or mainline blindly.
[17:50] <cjwatson> smoser: fixing the driver isn't necessarily that hard; if it's important, find a kernel team victim to help.  This shouldn't be unfamiliar territory for our kernel team.
[17:50] <cjwatson> It's the sort of thing we do.
[17:51] <infinity> smoser: The other curious question is if all the drivers can be loaded together.
[17:51] <smb> says the one defining the SEP
[17:51] <smoser> well, i did find one. its just not as simple as we'd like.
[17:51] <smoser> infinity, i'm not sure. i wondered that too.
[17:51] <infinity> smoser: What happens if one modprobes mlx4_ib mlx4_en and mlx4_fc?
[17:52] <smoser> but i dont know why youd' have your softwar stack have configuration for whic hone to load if they loaded at the same time with no fallout.
[17:52] <cjwatson> smb: Well, yes :-)  But it's simple truth that you guys have done this kind of thing before
[17:52] <infinity> smoser: If it's a tiny waste of RAM, but they all load and the "right" one works, the simple solution could be to just build it statically.
[17:52] <cjwatson> And fixing it in the installer is definitely the wrong place
[17:52] <infinity> smoser: If they all refuse to bind except the "right" one, that's a simple udev rule (or a kernel fix).
[17:52] <cjwatson> smoser: Don't assume that the driver authors had the same priorities as we do
[17:53] <cjwatson> They might have thought that saving a tiny bit of kernel memory was more important than anything else
[17:53] <infinity> mlx4_core
[17:53] <infinity> Handles low-level functions like device initiali
[17:53] <infinity> zation and firmware commands processing. Also
[17:53] <infinity> controls resource allocation so th
[17:53] <infinity> at the InfiniBand and Ethernet
[17:53] <smb> cjwatson, Some kind but not really assuming "cannot be hard" without knowing the hw design which sometimes is hard
[17:53] <infinity> functions can share the device
[17:53] <smoser> cjwatson, alright. i'll try to figure that out.
[17:53] <infinity> without interferin
[17:53] <infinity> g with each other.
[17:54] <infinity> Okay, ignore the bad line breaks.  But this doc implies that the driver is designed specifically to "do it all at once".
[17:54] <smb> infinity, But I would think the same. That in theory the ports can be mixed, so could be both modules needed
[17:54] <cjwatson> smb: It's an Ubuntu design principle to automatically probe hardware, and if the probing is possible in userspace then it's just as possible in kernelspace
[17:54] <infinity> So, the simple first-try workaround is a udev rule that loads all the sub-modules when core is loaded.
[17:55] <cjwatson> And (at its crudest) a bunch of "load this other module" calls is AIUI quite doable in the kernel
[17:55] <cjwatson> Not saying that's necessarily the best option
[17:55] <infinity> cjwatson: I could see one argument for keeping it a udev rule, which is just that some people may care deeply about upstream's attempt to save 25kB of kernel memory. :P
[17:55] <cjwatson> Sure
[17:55] <infinity> But, yeah.  First pass should just be "load everything and see".
[17:55] <arges> jdstrand: ping
[17:55] <infinity> And the docs here imply that should work.
[17:56] <jdstrand> arges: hey
[17:56] <arges> jdstrand: hey I see you uploaded for pad.lv/1052038, did precise also get uploaded as well?
[17:56] <stokachu> arges: https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=ecrypt
[17:56] <smoser> infinity, cjwatson what you. testing to see if they seem to live together.
[17:56] <stokachu> if thats the correct one it just needs sru
[17:56] <infinity> smoser: If "load everything" works, a udev rule to do the same it almost certainly your path of least resistance.
[17:56] <infinity> s/it/is/
[17:56] <smoser> yep
[17:57] <smb> infinity, Could even be a modprobe.conf thing. There is something about softdep
[17:57] <cjwatson> Let's not add to modprobe.conf
[17:57] <cjwatson> I have a feeling that is somewhat painful with d-i
[17:58] <cjwatson> udev is probably better for this kind of thing
[17:58] <infinity> d-i's initrd has a properly populated /etc/modprobe.d, I believe.
[17:58] <smb> ok, no strong preference there
[17:58] <infinity> But it's more about where you're shipping that file, and if it's there at build time. :P
[17:58] <jdstrand> arges: yes - https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=ecryptfs-utils
[17:58] <infinity> (Which is true of the udev rule too)
[17:58] <stokachu> jdstrand: could we get that one approved?
[17:58] <stokachu> so sru can take a look at it
[17:59] <infinity> stokachu: Hrm?
[17:59] <stokachu> infinity: hai!
[17:59] <infinity> stokachu: How does Jamie factor into this?
[17:59] <jdstrand> stokachu: ubuntu-sru needs to look at it (I am not on that team)
[17:59] <infinity> I think I may have intentionally not accepted it while the bug was in flux.
[18:00] <stokachu> ok
[18:00] <jdstrand> (besides I did the sponsored upload, so someone else would need to do the approval anyway)
[18:00] <arges> infinity: the fix should be settled now
[18:00] <infinity> I'll look at it in a sec.
[18:00] <arges> thanks
[18:00] <infinity> arges: Yeah, I see that.
[18:00] <stokachu> the bug still has sponsors subscribed to it
[18:00] <infinity> (Don't expect it to make .2, unless you make a really good case for it, it'll probably stay in -proposed until after 12.04.2 release)
[18:01] <infinity> But that gives you plenty of time to test very thoroughly. :P
[18:01] <tyhicks> Hmm... I think arges did need it in 12.04.2
[18:01] <arges> let me check
[18:02] <cjwatson> I thought I'd asked what else you guys needed in .2 a while back :-(
[18:02] <infinity> I can certainly see an argument for it being in .2 but, then again, I can see an argument for it being in .0, which it clearly wasn't. :P
[18:02] <arges> so whats the ETA then if not in .2?
[18:02] <stokachu> cjwatson: i think we just glanced over this one
[18:02] <infinity> Anyhow.  I'll quickly review and accept, you can argue promotion after.
[18:02] <arges> thanks
[18:02] <cjwatson> Any reason it has to be tied to a particular release?
[18:02] <infinity> arges: If it passes all verification, etc, and we don't intentionally target it for .2, it would hit -updates right after release.
[18:03] <infinity> arges: If there's no reason it MUST be on installation media, that's perfectly fine.  If the old version can cause such horrific problems that we don't want it on an ISO, speak up.
[18:04] <arges> infinity: ok this should work, I don't think it is necessary to be on media.I'll make sure
[18:04] <cjwatson> pitti: language packs copied
[18:05] <cjwatson> that should make sru-report run rather more quickly ...
[18:05] <stokachu> infinity: thanks for looking at it so quick
[18:05] <arges> infinity: indeed. thanks,
[18:05] <cjwatson> (well, after the removal pass, which I'll take care of once the report lists them)
[18:12] <smoser> what package would i put such a udev rule in? infinity ?
[18:13] <infinity> smoser: If the goal is for this to be in d-i images, and every base system, it would probably have to be in udev itself, not some leaf package.
[18:13] <smoser> thats what i thought too
[18:14] <infinity> smoser: That said, after testing the udev rules option, the proper solution is probably in the kernel, as Colin argues.
[18:15] <infinity> smoser: One could add an "auto_load=[yes,no]" option to the _core module, defaulting to "yes" in our kernels, so users who really want to old behaviour can change the module load parameters, but the default Just Works.
[18:24] <smoser> infinity, so.. the ude rule.
[18:24] <smoser> DRIVER=="mlx4_core", RUN+="/sbin/modprobe -bv mlx4_en", RUN+="/sbin/modprobe -bv mlx4_ib"
[18:25] <infinity> smoser: Was the -v just for testing?
[18:26] <smoser> no.
[18:26] <smoser> becausae i didn't test :)
[18:26] <smoser> i just ocpied from entry in /lib/udev/rules.d/80-drivers.rules
[18:26] <infinity> Oh, -bv seems to be the standard in other rules.  I guess for logging.
[18:27] <infinity> smoser: Anyhow, I'm no udev wizard, but if that works, it seems plausibly correct. :P
[18:27] <smoser> right. you're in the same place as me then
[18:27] <infinity> smoser: Testing on actual hardware would be sane.
[18:27] <smoser> i seem to be somewhat limited in access to such.
[18:28] <infinity> I'm assuming from agy's input on the bug that we have this hardware in the DC somewhere?
[18:28] <infinity> Surely, you can get a sysadmin to help.
[18:28] <infinity> (If you intend to SRU this back to precise, you'll need some hardware access to verify anyway)
[18:48] <siretart> infinity: did you observer run-time errors, or are you "just" concerned about the build logs?
[18:49] <siretart> -r
[18:49] <infinity> siretart: There's no just about it, it's broken if anything actually calls into that.
[18:50] <infinity> siretart: (In Ubuntu, we hard fail on implicit pointer conversions on 64-bit arches, so it's also a build failure, but the root cause is the implicit declaration, which is entirely a real problem here when you're calling into something that doesn't exist in the code you link to)
[18:52] <siretart> I guess it's a missing #include. the three functions refer to the audioconvert API, which we do have in libavcodec
[18:52] <infinity> siretart: A missing include of what?  I couldn't find those functions referenced in /usr/include at all.
[18:52] <infinity> siretart: Which is why I pinged you instead of just fixing it.
[18:52] <siretart> avcodec/audioconvert.h
[18:53] <siretart> HA, that's a private, non-installed header. fun
[18:53] <infinity> Ah-ha.  There you go.
[18:53] <siretart> yeah, that's upstream (ab)using private headers. bad upstream
[18:54] <infinity> So, you can either tell them to stop that, or include those prototypes in the handbrake source as a stub.
[18:54] <infinity> Linking against private symbols is generally considered a Bad Thing, but whatever. :P
[18:55] <infinity> Most of ffmpeg/libav scares me enough as it is, I can't see how this would make it worse.
[18:58] <mlankhorst> ... famous last words
[18:58] <siretart> thanks for notifing me about this. it seems that handbrake upstream is also hanging around in #libav-devel, where I'm trying to clarify what we can do about this.
[19:03] <cyphermox> @pilot in
[19:05] <siretart> infinity: okay, the situation is this: the audioconvert API was work in progress, never made public, never finished, and is scheduled for removal for the next libav release
[19:05] <infinity> siretart: Thanks for looking into it.
[19:05] <siretart> infinity: yet, handbrake is still using it. which is bad
[19:05] <infinity> siretart: Ahh, so handbrake just needs to be fixed to stop using it. :P
[19:05] <siretart> infinity: the replacement for this is libavresample, which is already part of libav 9, which I really would like to see in raring but am desperatly seeking for help to fix the remaining packages. (but that's another story)
[19:06] <siretart> infinity: it seems that handbrake has already been ported to libavresample in git, but there is no release for that yet.
[19:07] <infinity> siretart: Okay.  So, the way forward is new libav, and git pulls to handbrake?
[19:07] <siretart> infinity: yes
[19:07] <siretart> btw, help is desperately needed at https://launchpad.net/~motumedia/+archive/libav9-raring/ - I've added all relevant links to the PPA description
[19:08] <siretart> otherwise we'll have to defer for raring+1, which would be really, really sad :(
[19:11] <infinity> siretart: Are those 7 open FTBFS bugs the entirety of what needs fixing?
[19:12] <siretart> infinity: AFAIUI, the raring release process requires all FTBFS in https://launchpad.net/~motumedia/+archive/libav9-raring/+packages to be fixed. if we can shortcut this, I'm all for it :-)
[19:13] <siretart> afk (dinner)
[19:13] <infinity> siretart: I'd certainly prefer they all be fixed, yes.  That's a bit longer than the 7 bugs filed. :P
[19:13] <infinity> siretart: Probably entirely doable, though.
[19:33] <tumbleweed> cjwatson: not at all, please do so
[19:44] <siretart> infinity: some of the packages seem rather abandoned upstream. i'd suggest to just phase out such packages
[19:45] <cjwatson> tumbleweed: OK, done, thanks.  I didn't bother with a changelog entry since this is all new since the last upload
[19:45] <cjwatson> Unable to obtain lock  held by laney@bazaar.launchpad.net on taotie (process #13112), acquired 483 hours, 50 minutes ago.
[19:45] <cjwatson> Laney: ^- I figured it was OK to break that on ubuntu-dev-tools :-)
[19:46] <cjwatson> Probably isn't actually an epic 20-day commit
[19:46] <tumbleweed> heh
[19:50] <infinity> siretart: If you want to "phase them out", get them removed from Debian.
[19:50] <infinity> siretart: But I'm betting most of the porting is fairly trivial, and I'm not a fan of shafting users.
[19:59] <robru> barry, ping
[20:04] <smoser> infinity, smb would using MODALIAS be any better or worse than udev rule ?
[20:04] <smoser> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/286977
[20:05] <slangasek> for anything that /can/ be expressed as a modalias, you should be using a modalias and not a udev rule
[20:06] <barry> robru: pong
[20:07] <smoser> slangasek, bug 1115710
[20:07] <smoser> forgive ignorance, is that something that could be done as modalias?
[20:08] <infinity> smoser: That seems like a plausible solution to the problem.
[20:09] <infinity> smoser: Patch the kernel and find out? :P
[20:14] <slangasek> smoser: do you have a more precise pointer to the rationale for not autoloading the module, than a 212 page driver user manual?
[20:15] <slangasek> smoser: ah, I see your comment 9 explains what you meant, ignore me
[20:16] <smoser> slangasek, "upstream does not do it, and smoser is largely ignorant about this hardware"
[20:16] <slangasek> so the one problem is that you can only load one module per device, AIUI
[20:16] <slangasek> so if you have to pick between autoloading the ethernet module, and autoloading the infiniband module, then what?
[20:16] <smoser> slangasek, that seems like it was invalid logic
[20:17] <slangasek> what was?
[20:17] <smoser> at least  at the moment we're under hte impression that we can load both at the same time.
[20:17] <smoser> and at the expense of wasting kernel memory :)
[20:17] <slangasek> sure, you can load them but you can't make the kernel /autoload/ them via modalias
[20:17] <smoser> ah.
[20:17] <slangasek> unless you have two different device identifiers that you can associate each driver with
[20:18] <slangasek> still, rather than a udev rule, I would use a modprobe rule
[20:19] <smoser> slangasek, any reason why?
[20:19] <slangasek> because udev isn't really meant to be used that way, and I'm not sure it'll work
[20:19] <slangasek> sometimes the reentrancy of udev is suspect
[20:20] <smoser> slangasek, what package would you suggest this rule to be delivered in ?
[20:20] <slangasek> /etc/modprobe.d/alsa-base.conf shows the kind of thing you want
[20:20] <slangasek> smoser: er, what package delivers the driver?
[20:21] <smoser> linux
[20:21] <slangasek> hmm
[20:22] <slangasek> there isn't really a common package for the kernel, then
[20:22] <slangasek> is there any runtime package associated with these drivers?  Probably not?
[20:22] <slangasek> if not, then I'd say use the kmod package for it
[20:23] <smoser> no.
[20:24] <smoser> and then that should get packaged all the way into installer initramfs and any other initramfs , right?
[20:26] <siretart> infinity: yes, that's my plan, but surely not before wheezy release, which will not happen before raring's feature freeze
[20:28] <infinity> siretart: Which is your plan?  Removing all the packages that don't build with the new libav? :/
[20:28] <infinity> siretart: See above, re: shafting users.  If the porting is trivial, we should JFDI.
[20:28] <infinity> siretart: (We don't remove everything that fails to build with a new GCC even if upstream isn't fixing it, this should be no different)
[20:29] <siretart> infinity: most of them should be rather easy to port. there are some harder ones, which I've bugged upstream about, and from a few others, upstream seesm to be defact dead (e.g., dvbcut)
[20:30] <siretart> infinity: packages that don't build with newer gcc does not hinder gcc from passing britney. unlike what she would do with libav9
[20:30] <infinity> smoser: If it's in kmod (or module-init-tools, in older releases), it'll make it into initrds and d-i and such, yes.
[20:30] <infinity> siretart: No, but it still makes all those packages RC-buggy.  The fact that britney can't detect that is a process flaw, not a free pass. :P
[20:31] <smoser> ok. so now i'm being dense again.
[20:31] <smoser> install mlx4_core /sbin/modprobe --ignore-install mlx4_en; /sbin/modprobe --ignore-install mlx4_ib
[20:31] <smoser> that line causes recursion
[20:31] <siretart> infinity: ;-)
[20:33] <smoser> ok. here, this seems right now:
[20:33] <smoser> softdep mlx4_core post: mlx4_en mlx4_ib
[20:34] <smoser> slangasek, ^ that make sense ?
[21:31] <tjaalton> bdmurray: hey, could you accept the precise-proposed upload as well for bug 1095052?
[21:53] <bdmurray> tjaalton: I wasn't sure about that with the point release being imminent
[21:53] <bdmurray> infinity: ?
[22:17] <cjwatson> bdmurray,tjaalton: I'd prefer that to wait until after 12.04.2
[22:19] <tjaalton> cjwatson: ok
[22:48] <Laney> cjwatson: hah, no idea how that happened
[23:38] <slangasek> smoser: I've never seen/used softdep before; I was thinking of this: install mlx4_core /sbin/modprobe --ignore-install mlx4_core; /sbin/modprobe mlx4_en; /sbin/modprobe mlx4_ib
[23:47] <dobey> slangasek: hey, got a second? just wondering if this dependency makes sense to you: https://code.launchpad.net/~dobey/software-center/oc-lesser/+merge/146749