[00:25] <micahg> slangasek: why was the aptitude multiarch issue marked won't fix?  are you sure the patch will be so scary it can't be SRUd?
[01:10] <slangasek> micahg: ambiguity over the proper way to handle release-tracked bugs; I'll un-wont-fix it
[01:11] <micahg> slangasek: thanks
[01:44] <YokoZar> slangasek: Can I add depends:libllvm1 to ia32-libs-multiarch to make the nonproprietary drivers work?
[02:05] <ScottK> YokoZar: Go for it.
[02:05] <YokoZar> ScottK: What about adding /usr/lib32/dri to the library path in that package?
[02:06] <YokoZar> err not that package
[02:06]  * ScottK looks at slangasek.
[02:06] <YokoZar> but somewhere
[02:06] <YokoZar> since if it's not somewhere we'll have to have environment variables on launching any 32 bit 3d program :/
[02:09] <slangasek> you have to do that anyway
[02:09] <slangasek> you should not add any of the 32-bit libGL to the system path
[02:09] <slangasek> because it's a halfway measure that's going to break the other cases harder
[02:11] <slangasek> YokoZar: libllvm1 doesn't seem to exist as a package?
[02:11] <Sarvatt> can't believe 11.10 is shipping without libgl1-mesa-dri:i386 being installable, darn libpciaccess :(
[02:12] <Sarvatt> multiarch libpciaccess is in ppa:ubuntu-x-swat/x-updates at least
[02:13] <slangasek> Sarvatt: fwiw, with only 6 reverse-build-deps, it would've been doable for somebody-who-isn't-me to prove that we wouldn't regress and get an FFe for the sync... but now it's too late :/
[02:14] <YokoZar> slangasek: *libllvm2.9
[02:14] <slangasek> YokoZar: ah yes
[02:14] <Sarvatt> slangasek: argh, I've been using it for 2 months and bringing it up for weeks and have been told it was too crazy to do past final freeze when it finally got uploaded to debian
[02:14] <slangasek> Sarvatt: hmm
[02:15] <YokoZar> Are we worried about breaking the rdeps?
[02:15] <YokoZar> because they'd have to be some pretty serious rdeps for their breakage to be worse than libgl1-mesa-dri not being installable...
[02:15] <Sarvatt> no accelerated GL on open source drivers is insane to ship with
[02:16] <Sarvatt> (for 32 bit apps on amd64, sorry)
[02:16] <slangasek> we care about not breaking *any* reverse-deps when doing freeze exceptions
[02:16] <Sarvatt> not to mention flash is one of the things that uses libgl1-mesa-dri:i386 if its available
[02:16] <Sarvatt> well not anymore with 64 bit flash
[02:18] <slangasek> Sarvatt: have you verified that all the reverse-depends of libpciaccess build against the multiarched version?
[02:18] <slangasek> if that's confirmed, we might still talk skaet into it if there's a window
[02:19] <YokoZar> slangasek: Sarvatt: quick way to test that is to upload them all to a PPA
[02:19] <YokoZar> (this also helps you prove it ;) )
[02:19] <Sarvatt> seriously? no I haven't but thats definitely something worth the time and effort vs. shipping 11.10 without wine/google-earth/32 bit flash working properly on open source drivers
[02:22] <slangasek> FWIW, it's news to me that flash wants libgl1-mesa-dri... there's nothing in the depends/recommends to indicate this, and it's been working here forever
[02:23] <slangasek> Sarvatt: anyway, how quickly do you think you could test the revdeps and get bug #864123 turned into an FFe?
[02:24] <slangasek> (and a local build is probably faster than a ppa if you're set up for it, since you don't have to wait for libpciaccess to be published in your ppa before building against it...)
[02:24] <YokoZar> I'll get on the PPA
[02:25] <YokoZar> If you can point me to the libpciaccess0 package to sync
[02:25] <YokoZar> err
[02:26] <YokoZar> is the package in ppa:ubuntu-x-swat/x-updates  just synced from debian?
[02:27] <Sarvatt> flash uses GL if its available for rendering, libgl1-mesa-dri has the accelerated drivers in it that makes it work fast, its not required or anything and uses software if not. libgl1-mesa-glx just has libGL in it but not DRI drivers that are required to actually use the GPU
[02:28] <slangasek> Sarvatt: yes, there's no mention of libgl1 in the flashplugin-downloader package's recommends - and there ought to be
[02:29] <Sarvatt> libpciaccess 0.12.1-2 is in debian testing
[02:29] <Sarvatt> (and multiarched)
[02:30] <Sarvatt> libgl1-mesa-dri depends on libdrm-intel1 which depends on libpciaccess0 (which isn't multiarched in oneiric making libgl1-mesa-dri uninstallable)
[03:00] <YokoZar> PPA builds are in progress btw
[03:17] <skyblaster> there seems to be a regression between beta1 and beta2 on the tg3 driver. I'm getting "eth0: link is not ready" when trying to bring up the interface (BCM57785). Link LED is on after issuing "ifconfig eth0 down" and extinguishes when trying to bring it back up. Anyone here able to help diagnose. I don't see any open tickets on this issue
[03:27] <RAOF> YokoZar: If you need a hand with pciaccess I can help / take over if you run out of time.
[03:27] <YokoZar> RAOF: slangasek: Sarvatt: half way done, PPA here: https://launchpad.net/~scottritchie/+archive/build-tests/+packages?field.name_filter=&field.status_filter=&field.series_filter=oneiric
[03:28] <lamont> infinity: is the bbg3/beagle3xm manualness your doing?
[03:28] <slangasek> YokoZar: I am confused by the set of packages I see in that ppa
[03:28] <infinity> lamont: Yes.
[03:28] <lamont> cool
[03:29] <infinity> lamont: If we have an emergency built for release, I want it to hit a panda.
[03:29] <lamont> yep
[03:29] <infinity> s/built/build/
[03:29] <YokoZar> slangasek: are you looking at the 2 deleted ones?
[03:29] <slangasek> YokoZar: the relevant set of reverse-deps is intel-gpu-tools, libdrm, libvirt, radeontool, xorg-server, and xserver-xorg-video-intel
[03:30] <YokoZar> slangasek: yes those are in progress uploading atm
[03:30] <slangasek> YokoZar: ah, ok
[03:30] <slangasek> also, libhbalinux
[03:31] <YokoZar> libhbalinux?
[03:35] <slangasek> YokoZar: nah, ignore that one, it's FTBFS in universe anyway
[03:36] <skyblaster> Forget my earlier question, there is a bug, but not with tg3. As soon as Additional Drivers scanned for new hardware, eth0 came up :-)
[03:37] <slangasek> skyblaster: glad to hear you got it sorted
[03:39] <skyblaster> slangasek: You're telling me. Just got this new Acer AS5750-9851 yesterday. Broadcom wireless and Broadcom GigE <barf>. Thought I was in quite the predicament with neither working.
[03:42] <slangasek> YokoZar: xserver-xorg-video-ati built before libpciaccess was published; please re-test that build
[03:42] <YokoZar> slangasek: Yeah I just noticed that, reuploaded
[03:42] <slangasek> thanks
[03:42] <YokoZar> all packages are uploaded, ball is in launchpad'
[03:42] <YokoZar> launchpad's court now ;)
[03:43] <slangasek> yep
[03:45] <slangasek> Sarvatt, RAOF: we have RM approval for this to go in today/tomorrow, provided the diff stands up to my scrutiny and the rebuild test clears it
[03:46] <RAOF> slangasek: Ok, thanks.  I don't expect there to be any rebuild problems, and obviously because I did the multiarching the diff will be perfect ?.
[03:46] <slangasek> :)
[03:47] <slangasek> there are other changes in that upload though
[03:49] <YokoZar> Assuming this works as planned, can I then put libgl1-mesa-dri  into ia32-libs-multiarch's list?
[03:52]  * YokoZar wonders what the implications of removing it from ia32-libs entirely would be since everything using it seems to be broken...
[03:54] <RAOF> Yes, that would be right.  Although you shouldn't need to, because libgl1-mesa-glx:i386 Recommends libgl1-mesa-dri:i386
[03:56] <YokoZar> RAOF: true, but will apt install it on update if it was previously uninstallable when its status as recommends is unchanged?
[03:56] <RAOF> ?I don't think so, actually, no.
[03:57] <RAOF> So it'd work for upgrades from Natty, but not people who updated from, say, Beta 2.  Which isn't particularly welcoming :)
[03:57] <YokoZar> I'll sneak it in then, as we'll need a final ia32-libs upload anyway to make sure every package is fresh
[04:10] <YokoZar> slangasek: all builds complete in PPA
[04:50] <RAOF> yokozar, slangasek: Anything I can do to help this along?  It seems like the next step is to hit the button and get the diff reviewed, right?
[04:50] <slangasek> RAOF: I'm a-reviewin'
[04:51] <YokoZar> This is probably the bug to post in: https://bugs.launchpad.net/ubuntu/+source/libpciaccess/+bug/864123
[04:54] <pitti> Good morning
[04:55]  * slangasek waves
[04:56] <YokoZar> Ahh good morning to the European crew.  Still working on multiarch/ia32-libs issues :/
[04:59] <slangasek> RAOF, YokoZar: libpciaccess accepted
[04:59] <RAOF> slangasek: Rocking.  Thanks muchly. +1 beer for UDS.
[05:00] <slangasek> RAOF: I assume that beer is transferrable in the case something blows up from this and I owe a beer to skaet ;)
[05:00] <RAOF> Of course! :)
[05:01] <slangasek> hallyn_: ping
[05:01] <YokoZar> If beer is transferable, then I should forward all those beers I got offered over the window controls blog post a year ago...
[05:02]  * Sarvatt owes infinite beers, thank you guys so much for that
[05:04] <Sarvatt> wasn't going to be fun explaning to my ubuntu convert friends that they needed to use a PPA to use wine in 11.10 otherwise :)
[05:04] <YokoZar> funny you mention that
[05:04] <YokoZar> the version in oneiric is one before the complete sound rework :D
[05:05] <ajmitch> Sarvatt: what game were you wanting to play? ;)
[05:20] <pitti> apw, ogasawara:
[05:20] <pitti> The following packages have unmet dependencies:
[05:20] <pitti>  linux-image-extra-3.0.0-12-virtual : Depends: linux-image-3.0.0-12-virtual (= 3.0.0) but 3.0.0-12.19 is to be installed
[05:20] <pitti> seems something went wrong with the dependency generation?
[05:20] <pitti> "= 3.0.0" looks very wrong
[05:26] <ScottK> So I'm assuming the PPA versioning on the udev upload wasn't on purpose ...
[05:26]  * ScottK eyballs slangasek.
[05:26] <slangasek> nope
[05:27] <slangasek> rather, the versioning was and the upload wasn't
[05:27] <slangasek> apparently the order of the arguments to 'dput' is significant!
[05:27] <slangasek> who knew?
[05:27] <slangasek> self-rejected now
[05:27] <ScottK> OK.
[05:28] <pitti> slangasek: do you mind to commit to the Vcs-Bzr: branch, too?
[05:28] <slangasek> pitti: for something that's not supposed to have been uploaded? yes, I do mind :)
[05:28] <pitti> ah, ok :)
[05:29] <pitti> I misunderstood the error the other way round
[05:35] <pitti> slangasek: FYI, https://github.com/kaysievers/udev is the current tree (temporary location)
[05:35] <pitti> but I didn't see anything related to --exit
[05:35] <slangasek> pitti: ah, good to know
[06:39] <dholbach> good morning
[07:25] <micahg> pitti: can you set https://code.launchpad.net/~rye/ubuntu/natty/bindwood/update-firefox-6-compat-fix/+merge/76055 to rejected please?
[07:26] <pitti> micahg: I can't, sorry
[07:26] <didrocks> @pilot in
[07:27] <pitti> I'm not currently a member of ~techboard
[07:27] <pitti> sabdfl needs to put us all back in
[07:27] <micahg> pitti: oh, I thought the TB could...
[07:27] <micahg> ah, right
[07:27] <pitti> we timed out
[07:27] <pitti> sabdfl: oh, you're online
[07:27] <pitti> sabdfl: how are you?
[07:27] <pitti> sabdfl: any chance that you can re-populate https://launchpad.net/~techboard ?
[07:43] <lifeless> pitti: a sysadmin could fix it too
[07:44] <pitti> ah, I guess so
[07:44]  * lifeless speculates should ~techboard be owned by ~council or something (or whatever the team is)
[08:08] <Galantus> hello world
[08:08] <Galantus> am i in the cave of developers
[08:10] <apw> Galantus, yes, if you have a question on ubuntu development this is the place
[08:11] <Galantus> uhh awesome:P
[08:12] <Galantus> ill start with a bold one
[08:12] <Galantus> where do i start?
[08:13] <apw> https://wiki.ubuntu.com/UbuntuDevelopment
[08:14] <Galantus> yes ive already been referred there on ubuntu-il
[08:14] <Galantus> but im not very experienced you know?
[08:14] <Galantus> where would you advice me to start coding?
[08:15] <apw> with something that interests you i guess
[08:16] <RAOF> It's also important to note that we don't do a huge amount of *coding*.
[08:16] <Galantus> you dont?
[08:17] <RAOF> At least, not in Ubuntu.  When we code, it generally goes to the upstream project.
[08:18] <RAOF> Sometimes the upstream project is driven by Canonical; Unity, for example.  Mostly it's not, like the kernel or the GNOME apps, or KDE, etc.
[08:18] <Galantus> ohh
[08:18] <Galantus> so where do you guys code?
[08:18] <Galantus> like where should i hahaha
[08:19] <RAOF> Like apw said: wherever you're interested in.  Most open source developers start by scratching their own itch.
[08:20] <Galantus> i heard other devels fire that line before
[08:20] <Galantus> but what if i dont have an itch lol
[08:21] <diwic> I have never used harvest myself, but maybe that would be interesting if you want to find bugs to fix
[08:22] <diwic> Galantus, http://harvest.ubuntu.com/
[08:22] <Galantus> thanks man ill start looking around:)
[08:23] <Galantus> so what other projects do you guys code for?
[08:23] <Galantus> just curiosity haha:P
[08:24] <diwic> Galantus, I'm doing audio stuff, so mostly in the kernel drivers and PulseAudio. But a lot of time is also communicating, triaging bugs etc.
[08:26] <Galantus> shit that sounds really interesting
[08:26] <Galantus> in what language do you work?
[08:26] <diwic> Galantus, mostly C
[08:26] <OdyX> .oO(English)
[08:26] <diwic> (kernel and PulseAudio are both written in C)
[08:28] <Galantus> cool ill check that out:)
[09:39] <didrocks> jhunt: I think you are in charge of mountall as well, isn't it? In that case can you look at some typo fixes: https://code.launchpad.net/~cldunlap1/ubuntu/natty/mountall/fix2-for-805509/+merge/78135 ?
[09:41] <jhunt> didrocks: looking...
[09:46] <jhunt> didrocks: I've now commented.
[09:47] <didrocks> jhunt: thanks a lot!
[09:57] <damg> what should I do with https://bugs.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/725248 ? the user reported that in 11.04 the problem got fixed. Simply put on fix commited w/o verification?
[09:59] <seb128> damg, set it fix released
[10:01] <damg> ok, thanks
[10:02] <seb128> damg, thank you for triaging ;-)
[10:02] <damg> as of  11.10, it looks like I'll return to launchpad :)
[10:14] <brendand> i've got a weird issue with an application i'm maintaining - basically it uses a GtkWindow for a dialog to indicate that a script is running, but what seems to happen is that if too many of them are instantiated in a short period of time then the whole application gets hidden to the launcher
[10:15] <brendand> if i introduce a small delay into the code the problem stops occuring
[10:26] <brendand> could be something to do with hide() being called to many times actually, because if i never hide the dialog then the problem doesn't occur
[10:28] <damg> dou your windows get a focus? maybe it is a matter of timing and the window manager executes hide on the wrong object.
[10:29] <damg> s/dou/do
[10:32] <pitti> jdstrand: there are two remaining WIs on https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-lightdm which sound related to your team: "Check two-factor works well", and "Perform security review"; right now they are owned by Robert, but especially the latter would make more sense for security?
[10:33] <pitti> jdstrand: I reassigned the second one to you, please feel free to delegate further; not sure who would be able to test two-factor?
[10:42] <didrocks> @pilot out
[10:49] <brendand> damg - that's what i'm thinking. should i check if they have focus before hiding them?
[10:49] <damg> I would take a look at that
[10:49] <brendand> damg - though i just tried checking if they were mapped, which should be as good - but it didn't help
[10:52] <damg> hm
[10:55] <damg> brendand, are those windows hidding from different threads?
[10:56] <damg> s/hidding/being hidden/  I should talk more English and put oni my glasses :)
[10:56] <brendand> damg - i don't think so. pretty sure this application is single threaded
[10:57] <brendand> damg - well, seems like it is multi-threaded
[10:57] <brendand> damg - problems with calling hide from different threads?
[10:58] <damg> possible. for example if the pointer to the window is static.
[10:58] <brendand> damg - btw, app is python based
[10:58] <damg> you could put a mutex around those critical sections and see whether it works
[10:59] <damg> hm, ok
[10:59] <damg> is it an opensource one? I could take a look, too
[10:59] <brendand> damg - lp:checkbox
[11:00] <brendand> damg - the hide is happening in checkbox_gtk/gtk_interface.py:242
[11:00] <damg> okay, I'll take a look in a few minutes (this VM is not the fastest :) )
[11:05] <artfwo> hi
[11:06] <artfwo> a main package (libffado) is suffering a severe regression, which renders the package unusable: debian bug 643024
[11:07] <artfwo> debian has a fix - can the fix be synced/merged into ubuntu at this development stage? (ubuntu version has changes)
[11:15] <damg> brendand, which tests produce such a fault?
[12:05] <mdeslaur> pitti: there's a small two factor test pam module I've wrote here: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/files/head:/utilities/pam_twofraktor/
[12:06] <mdeslaur> (If someone wants to run it against lightdm)
[12:10] <brendand> damg - oh, that's a tricky one. run it using 'bin/checkbox-gtk -W data/whitelists/default.whitelist' and follow the prompts. you can skip tests, when you get to the one about USB audio, then pressing Next should make it happen
[12:25] <damg> brendand, hm, interesting, I can't reproduce it in a virtual machine. You could try to send call to show_progress_pulse() directly after show_progress_start() in checkbox/user_interface.py:84 as it does some gtk event processing in gtk's pulse method
[12:29] <jdstrand> pitti: re security review> ack. I was unaware of that work item, but it was on my todo list. I can't guarantee it will happen in time for release
[12:29] <pitti> jdstrand: thanks
[12:29]  * jdstrand is not really here today btw
[12:36] <hallyn_> slangasek: I'm here if you still wanted to chat
[13:01] <smoser> bug 863629
[13:29] <kenvandine> @pilot in
[14:15] <jamespage> jhunt: hows udev feeling today?
[14:19] <sabdfl_> pitti,  i made the CC the owner of TB, so others can admin it too
[14:19] <sabdfl_> will update it now
[14:30]  * dholbach hugs kenvandine
[14:31]  * kenvandine hugs dholbach
[14:31] <kenvandine> dholbach, todays list has quite a few old things with open questions still
[14:31] <pitti> sabdfl_: splendid, thank you!
[14:32] <dholbach> kenvandine, I noticed that the bug bot resubscribed the sponsors team in a couple of cases
[14:32] <dholbach> is that it?
[14:32] <lamont> so if I can't use ctl-X, HTF do I get nano to exit?
[14:32] <kenvandine> maybe...
[14:33] <kenvandine> but things like the ubuntustudio lightdm theme, you had asked if it needed a dep
[14:33] <kenvandine> but it is still in confirmed
[14:33] <kenvandine> i am going through the list looking :)
[14:33]  * lamont figures out his path to happiness
[14:45] <artfwo> i don't want to spam the channel, but i'm still not sure about what can be done with libffado regression, related to debian bug 643024
[14:48] <artfwo> should i request a merge or a sync? debian version seems to have similar changes
[14:48] <artfwo> also, would a merge be acceptable at this stage of development?
[15:13] <diwic> artfwo, it seems definitely SRUable at least
[15:14] <diwic> artfwo, have you verified it is a problem, in what Ubuntu versions?
[15:14] <cjwatson> it probably ought to be a cherry-pick rather than a merge though
[15:15] <diwic> cjwatson, agreed
[15:15] <artfwo> diwic, cjwatson, yes, libffado worked in oneiric for me, but the latest upload broke it - i cannot start jackd anymore, symptoms are the same as in debian bug above
[15:16] <artfwo> diwic, cjwatson, i built the latest debian version locally and the problem is gone
[15:16] <diwic> artfwo, latest upload of libffado2 or jackd?
[15:17] <artfwo> diwic, libffado - jackd has a linked ffado backend
[15:20] <artfwo> there is also bug 855438, which is fixed both upstream and in debian, so a merge may be of double benefit, but i'm not sure
[15:36] <doko> diwic, can you handle the libffado issue?
[15:36] <diwic> doko, as an SRU or earlier than that?
[15:38] <doko> diwic, either. it was just a rebuild. I assume libffado makes some bad assumptions about constructors/destructors
[15:39] <diwic> doko, hmm, if a rebuild is all what's needed, and I don't have upload rights, there's not much I can do...?
[15:42] <doko> diwic, no, apparently the rebuild did introduce the regression. what is needed is a sync, or just applying the fix
[15:45] <diwic> doko, rebuild of libffado 2.0.99+svn1985-2 => libffado 2.0.99+svn1985-2ubuntu1 ?
[15:45] <cjwatson> it wasn't a no-changes rebuild, but there were no changes relevant to x86
[15:58] <doko> barry, ScottK:
[15:58] <doko> Setting up python3 (3.2.2-0ubuntu2) ...
[15:58] <doko> running python rtupdate hooks for python3.2...
[15:58] <doko> running python post-rtupdate hooks for python3.2...
[15:58] <doko> why? mixed up version numbers?
[15:59] <barry> doko: ScottK needed an urgent merge for python3-defaults a few days ago
[15:59] <doko> barry, but why run the rtupdate hooks?
[16:03] <barry> doko: afaict from python3.postinst.in, they always run
[16:04] <barry> (on configure)
[16:04] <doko> barry, they only should when a new runtime is added, removed, or the default changes
[16:06] <barry> doko: i'm just reading the file.  i guess POX would be able to answer definitively
[16:19] <Daviey> wow, devscripts already targets P-Series.
[16:23] <pitti> Daviey: s/wow/eww/
[16:29] <pitti> cjwatson: does that look ok to you? http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/529
[16:30] <Daviey> pitti: yeah, kinda suprised me.
[16:31] <Daviey> Anyone happen to know what sets, apt-config shell UpdateInterval APT::Periodic::Update-Package-Lists <-- in livebuild?
[16:34] <cjwatson> pitti: yes, that looks fine; you need an RT ticket to land the change though
[16:34] <cjwatson> pitti: they prefer you to attach the modified script to the ticket IME
[16:34] <pitti> cjwatson: ok, thanks; uploaded, filing RT now
[16:34] <cjwatson> pitti: bah, and the reason I couldn't find it in my tree was that I had staged the same change locally but not committed it :-/
[16:34] <pitti> well, I'll file it once it's through unapproved
[16:34] <slangasek> hallyn_: I guess when you say "/run is still mounted" you mean it's *not* mounted?
[16:34] <pitti> cjwatson: heh
[16:39] <hallyn_> slangasek: uh, no, disregard that comment :)  I thought /run/initramfs was supposed to get moved to /dev/.initramfs, but i ssee (on my laptop) it persists
[16:39] <YokoZar> Any library updates currently in the queue for oneiric?  I'm about to roll the final ia32-libs package
[16:40] <slangasek> hallyn_: ah; the intended behavior is 'mount -n -o move /run ${rootmnt}/run'
[16:40] <slangasek> YokoZar: any library updates in the queue will be shot on sight
[16:40] <YokoZar> slangasek: I suppose things like dependency changes wouldn't matter in this case
[16:46] <pitti> ogasawara: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt still has some linuxy stuff that wants to to go universe; I suppose we just seed the extra metapackages?
[16:47] <pitti> ogasawara: it would tremendously ease our countless SRUs if all binaries are in main
[16:48] <pitti> ogasawara: oh, our oneiric seeds still say "-natty", fixing
[16:50] <pitti> ogasawara: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.oneiric/revision/1654
[16:50] <pitti> will check c-m again tomorrow morning to verify
[16:50] <pitti> I took care of nova-compute-xen and openoffice.org-gcj
[16:50] <Daviey> mvo: Are you still running the upgrade testing?
[16:50] <Daviey> pitti: did you, i thought i did?
[16:51] <ogasawara> pitti: looks good to me
[16:51] <pitti> Daviey: removed NBS openoffice.org-gcj, demoted nova-compute-xen
[16:52] <Daviey> ah, thanks
[16:57] <kenvandine> @pilot out
[16:57] <kenvandine> but i'll be back :)
[17:06] <Daviey> lynxman: Was the udev issue you had solved with adam_g's sleep patch?
[17:06] <Daviey> (and that was the same hardware Trellis was using?)
[17:54] <herton> pitti: around?
[18:09] <kenvandine> @pilot in
[18:40] <Daviey> Does anyone have an oneiric fresh install handy?
[18:40] <Daviey> fresh-ish.
[18:47] <mvo> Daviey: yeah, the auto-upgrade tester is still running
[18:59] <YokoZar> Ok, making final ia32-libs-upload.  Hopefully it's the last one ever.
[19:01] <Daviey> Hi, can a few people please give me the output of: $ apt-config shell AutoAptEnable APT::Periodic::Enable && echo $?
[19:03] <ScottK> barry and doko: Did you get python3-defaults sorted?  I was AFK.
[19:04] <jamespage> Daviey: 0
[19:05] <Daviey> jamespage: What is your system, and it's history?
[19:05] <jamespage> Daviey: oneiric desktop; upgraded from natty about 1 month ago - natty was a fresh install
[19:06] <Daviey> interesting.
[19:10] <stgraber> Daviey: 0 here too on a fairly recent clean Oneiric installed from netinstall
[19:11] <jamespage> Daviey: 0 on a fresh oneiric server install from this morning
[19:13] <Daviey> jamespage / stgraber: apt-config shell AutoAptEnable APT::Periodic::Update-Package-Lists , rather
[19:13] <stgraber> AutoAptEnable='1'
[19:14] <jamespage> Daviey: 0 on the server
[19:14] <barry> ScottK: i think was left hanging (and i got distracted with other stuff)
[19:14] <jamespage> Daviey: AutoAptEnable='1'
[19:14] <jamespage> 0
[19:14] <jamespage> on the desktop
[19:14] <Daviey> jamespage: So I have a natty server here which shows AutoAptEnable='1'
[19:15] <jamespage> Daviey: double checked on the server - just a 0 - no  AutoAptEnable='1'
[19:16] <jamespage> Daviey: ah - but that was off preseed with - d-i pkgsel/update-policy select none
[19:16] <jamespage> that might make a difference
[19:16] <Daviey> heh
[19:16] <jamespage> Daviey: hmm can't get my natty iscsi root install to boot - lots of io errors
[19:17]  * jamespage thinks this seems familiar
[19:17] <Daviey> *awesome*
[19:17] <Daviey> This day started so well.
[19:17] <jamespage> lol
[19:22] <Daviey> jamespage: can you throw that in a bug and link it on the tracker?
[19:23] <jamespage> Daviey: the natty iscsi root install?
[19:23] <jamespage> it looks like the same issue that we had in oneiric
[19:23] <Daviey> Oh, you are seeing this on natty still?
[19:24] <jamespage> stgraber: I can't remember - did you see the iscsi root issue that you fixed this release in natty?
[19:24] <jamespage> then one where the open-iscsi daemon post initrd tramples the one that started first
[19:24] <jamespage> Daviey: yes - thats what is confusing me
[19:24] <stgraber> jamespage: nope, it's limited to Oneiric as a bug in upstart in Natty makes open-iscsi start before network is up
[19:25] <stgraber> jamespage: so in Natty open-iscsi either does nothing or just exists
[19:25] <stgraber> *exits
[19:25] <jamespage> stgraber: then I'm not sure what I'm seeing then
[19:25] <jamespage> it looks symptomatically like the oneiric issue
[19:25] <stgraber> jamespage: that part of the boot may be racy or someone "fixed" natty and so introduced the bug there too ;)
[19:25] <jamespage> I hacked the open-iscsi init script to just exit 0 rather than do anything and it boots just fine
[19:25] <Daviey> for giggles, lets blame udev.
[19:25] <stgraber> jamespage: my test system was a stock natty without updates IIRC
[19:26] <jamespage> OK - this is a stock with updates
[19:26] <stgraber> can you check if someone backported some of the upstart fixes that broke it in Oneiric?
[19:26] <Daviey> stgraber: is there a bug on this?
[19:27] <jamespage> Daviey; however I was able to confirm that when open-iscsi is not breaking stuff I don't get a long boot - but I do get a manual eth0 entry
[19:27] <jamespage> Daviey: so technically I am seeing a regression
[19:27] <stgraber> Daviey: the "hangs at boot time" bug was marked Fix released with the upload in Oneiric and I filed another one to track the "open-iscsi disconnects everything when we have / already on iscsi"
[19:28] <stgraber> bug 850960 is the new bug and bug 838809 is the one I "fixed"
[19:29] <stgraber> jamespage tracked it down to a change that happened in upstart 1.3-0ubuntu6 in Oneiric
[19:30]  * Daviey formally invites stgraber to the Ubuntu Server Teams weekly meeting.
[19:31]  * Daviey nees to go awol for a bit.
[19:32] <ScottK> barry: I've got no time today to even think about it, so please work it out.
[19:43] <barry> ScottK: maybe doko should file a bug
[19:47] <falktx> hey there
[19:55] <falktx_> I saw the latest kernel released went into -proposed
[19:56] <bkerensa> k
[19:56] <bkerensa> No RC?
[19:56] <bkerensa> https://wiki.ubuntu.com/OneiricReleaseSchedule
[19:57] <ScottK> RC isn't a formal milestone.
[19:58] <ScottK> RC means we have images we think we might want to release.
[19:58] <ScottK> We're starting to work on those, but there's a bit more to do.
[19:58] <falktx_> hm, it was due to yesterday
[19:58] <ScottK> No.  There is nothing due.
[19:59] <ScottK> That's when you start working on potential release candidates.
[19:59] <falktx_> oh, got it
[19:59] <ScottK> You don't KNOW you have one until you release.
[19:59] <bkerensa> kk
[19:59] <ScottK> What we used to call RC is now called beta2 because it seems wrong to call something an RC that we know wasn't what we were going to release.
[20:26] <slangasek> hallyn_: still around?
[20:29] <hallyn_> slangasek: yes
[21:04] <kenvandine> @pilot out
[21:10] <slangasek> hallyn_: sorry - how about now :)
[21:11] <hallyn_> a bit distracted, but here
[21:11] <slangasek> hallyn_: wondering about getting combined logs from a failed boot... a ps at the end of init-bottom/udev, plus udevadm monitor -e output from the whole run
[21:11] <slangasek> hallyn_: should I prepare a package that includes these mods?
[21:11] <hallyn_> slangasek: that would be best, so we can have reliable reproducible results from
[21:11] <hallyn_>  more than just me
[21:12] <hallyn_> but again, a ps aat end of init-bottom/udev was not getting done
[21:12] <hallyn_> well, that or fs tree was funky, and i should do it into kmsg
[21:13] <slangasek> I noticed that the earlier outputting to kmsg showed things a bit scrambled
[21:13] <slangasek> I think it's probably best to dump to stdout and capture the console output
[21:13] <slangasek> anyway, I'll do up a test package then
[21:14] <hallyn_> slangasek: great, thanks
[21:36] <slangasek> hallyn_: btw, "is the scripts/init-bottom/udev file itself being killed?" - absolutely - the script is set -e!
[21:36] <slangasek> so anything you try to do after the mount call will fail :)
[21:36] <slangasek> or not be called, I mean
[21:47] <Tecuhtli> I'm not sure if this is the correct place to ask but here it goes: is there any usage documentation for python-ftdi package?
[21:47] <Tecuhtli> I have only found one page but its information refers to libftdi API
[21:48] <slangasek> Tecuhtli: I don't think anyone here is likely to be familiar with it; the package is inherited without changes from Debian
[21:48] <hallyn_> slangasek: d'oh.  of course
[21:49] <Tecuhtli> thanks slangasek
[21:49] <Tecuhtli> I will search there then
[22:31] <hallyn_> slangasek: (I intend to test with your ppa later tonight)
[22:31] <slangasek> hallyn_: cheers
[22:32] <slangasek> hallyn_: hey, how do I use vm-new?  I get an error message about wanting a non-existent config file (~/.uqt-vm-tools.conf)
[22:32] <slangasek> this seems contrary to the goal of having an easy-to-use wrapper for creating vms :)
[22:33] <hallyn_> slangasek: yeah...  there's some initial setup involved.  see https://wiki.ubuntu.com/SecurityTeam/TestingEnvironment
[22:33] <hallyn_> it looks worse than it is :)
[22:33] <hallyn_> once it's set up, you can trivially create a set of new vms with 'vm-clone -c o1 o2'
[22:34] <hallyn_> i noticed this afternoon, trying to create a lucid one from scratch, there seem to be trouble with some of the lucid archives or installers...
[22:34] <hallyn_> at least the mini lucid iso installer fails
[22:34] <hallyn_> will have to pursue that
[22:34]  * hallyn_ curses the new alt-tab behavior one more time
[22:34] <slangasek> hallyn_: ok; so these are the same steps you followed?  I'm trying to make sure the vm I wind up with matches yours
[22:36] <hallyn_> slangasek: I followed those steps, but then used http://people.canonical.com/~serge/vm-new in place of that vm-new
[22:36] <slangasek> ok
[22:36] <hallyn_> (much smaller download).  and using apt-cacher-ng locally, though that shouldn't matter
[22:48] <krutoileshii> Need help compiling rocket raid 2640 divider under Ubuntu 11.10. Fails to compile saying only supports 2.4 2.6 $ series
[22:48] <krutoileshii> Does not compile under 3.0
[23:08] <bdrung> Laney: you are haskell hacker?
[23:44] <krutoileshii> (krutoileshii) (krutoileshii) Need help compiling rocket raid 2640 divider under Ubuntu 11.10. Fails to compile saying only supports 2.4 2.6 series
[23:49] <cjwatson> I guess you'll have to find where it complains about that and fix it to handle 3.x
[23:50] <cjwatson> and preferably to do a proper version check, or these days to drop the check altogether
[23:50] <krutoileshii> Makefile.def
[23:51] <krutoileshii> There are differences between the way 2.4 and.2.6 and up are compiled so there needs to be a check for that.
[23:52] <cjwatson> well, if anyone cares about 2.4 any more ...
[23:52] <krutoileshii> Not me, i'm in Mt phone right now, but I'd loved some help with modifying it.
[23:53] <cjwatson> I mean, 2.6.0 was released almost eight years ago
[23:53] <krutoileshii> I know the section approximately but not sure How to fix it
[23:53] <krutoileshii> I know.
[23:53] <cjwatson> really the maintainer of this out-of-tree driver should be fixing it
[23:53] <directhex> it's closed.
[23:54] <directhex> highpoint rocketraid ships a binary .o, which it munges into the C parts which are built against the target kernel
[23:54] <krutoileshii> Maintainer is highpoint, i've contacted them, but haven't heard anything yet.
[23:54] <directhex> it's as prone to breakage as you think
[23:54] <cjwatson> right.  we really can't in general help with that kind of thing.
[23:54] <krutoileshii> That part is not what's broken actually
[23:55] <cjwatson> sounds like if you bypass the version check (which is probably straightforward, just hack it out) it may just explode your kernel later.
[23:55] <krutoileshii> I've gotten it to compile and and run before under 2.8
[23:55] <cjwatson> there has never been a 2.8 kernel
[23:56] <directhex> highpoint aren't shipping a usable driver, and i'd be dubious about claims that the device is a real raid card, too
[23:56] <krutoileshii> I'll take a look at that. Thanks. I meant 2.6.28 (it didn't originally)
[23:57] <directhex> if there's magic they feel is worth protecting, then there's magic in the .o - and if there's amgic in the .o, it's doing things on your CPU rather than on your raid controller's io processor
[23:57] <krutoileshii> Its not a real raid card. I use it for extra sata
[23:57] <cjwatson> mm, 2.6.28 was quite a long time ago in kernel terms though
[23:57] <cjwatson> who knows what kernel interfaces it's using that may or may not have changed ...
[23:57] <krutoileshii> I'll post back on the progress.
[23:58] <directhex> probably describes itself as GPL in the c wrapper, to avoid the limited exported symbols issue
[23:58] <directhex> which was around 2.6.30something iirc
[23:58] <krutoileshii> I had it working in 11.04
[23:59] <directhex> 2.6.38 iirc
[23:59] <directhex> should be close enough to 3.whatever