[05:22] <pitti> Good morning
[07:14] <dupondje> pitti: i'll check papyon somewhere today, something went wrong :(
[07:57] <dholbach> good morning
[09:15] <pitti> hm, yesterday's dailies grew by 7 MB, due to adding fonts-nanum
[09:32] <pitti> fixed seeds and uploading new -meta, that should do it
[09:36] <cjwatson> pitti: thanks
[09:40] <pitti> cjwatson: FYI, nanum is actually expected to be there, it just looked a bit weird because some ttf-* got renamed to fonts-*; but it replaced ttf-unfonts-core which is still on the imags
[09:47] <cjwatson> pitti: right, I knew about the ttf-* -> fonts-* renaming
[09:47] <cjwatson> still need to process some removals for that
[09:55] <bdrung> broder: debug-symbols-directly-in-usr-lib-debug?
[10:58] <cjwatson> pitti: https://launchpad.net/ubuntu/+source/eog/3.2.1-0ubuntu2 - could you please use libjpeg-dev rather than libjpeg8-dev for such changes, per http://lists.debian.org/debian-devel-announce/2010/02/msg00006.html ?
[10:58] <pitti> cjwatson: ah, ok; I used 8-dev | -dev
[10:58] <pitti> cjwatson: I thought the first alternative should always be preferred
[10:59] <cjwatson> That will make future transitions require a source change
[10:59] <pitti> cjwatson: pushed to bzr
[10:59] <cjwatson> For this library we're just having only one provider to make it easier to transition
[10:59] <pitti> cjwatson: do you want me to upload that now to satisfy some report scripts, or is it not that urgent?
[10:59] <cjwatson> thanks
[10:59] <cjwatson> it's not urgent
[11:00] <cjwatson> I just wanted to catch it quickly in case you were making the same change to lots of packages
[11:00] <pitti> I only really caught it because I was using it for testing the new scour
[11:00] <pitti> but good to know for other cases
[11:35] <Daviey> cjwatson: Does anyone on your team have prior experience with bonding interfaces?
[11:36] <Daviey> cjwatson: trying to work out if bug 889423 would be better worked on my server or foundations.
[11:36] <cjwatson> not that I know of for certain, although I wouldn't put it past Stéphane
[11:37] <Daviey> I have /some/ experience, but don't claim to be an expert.
[11:37] <Daviey> stgraber: When you see this, can you chime in please? :)
[11:39] <cjwatson> there were some ordering changes in ifupdown 0.7~beta2 (not yet in precise) although I don't know if they're relevant here
[11:39] <cjwatson> (just saw Debian mail about that yesterday)
[11:50] <Daviey> cjwatson: thanks
[13:10] <djszapi> Hi! Where can I find the source of the kdeedu 4.7 package ?
[13:50] <Riddell> djszapi: launchpad.net/ubuntu/+source/kdeedu
[13:51] <djszapi> Riddell: I do not see 4.7 there.
[14:03] <stgraber> Daviey: this looks a lot like a potential SRU regression we currently have on lucid, sadly I can't easily reproduce the bug here (need to setup all the hardware, reinstall, ... first)
[14:04] <iceroot> cjwatson: hi, you have a minute? (imo you are a patch-pilot)
[14:04] <stgraber> Daviey: bug 823366 is the potential SRU regression on 10.04.3 (the SRU in 10.04.3 is based on what we had in natty/oneiric IIRC)
[14:05] <Daviey> stgraber: ah, i thought it might have been a regression of bug 482419
[14:05] <Daviey> FWIW, Debian experimental package without ubuntu delta also has the bug.
[14:07] <stgraber> Daviey: right, bug 823366 has been filed as a potential regression of the bugfix from bug 482419
[14:07] <cjwatson> iceroot: patch-piloting is a one-morning-a-month duty for me; I'm not patch-piloting at the moment
[14:07] <cjwatson> there should be another pilot along in a bit, announced in the channel topic ...
[14:08] <iceroot> cjwatson: ok :)
[14:08] <stgraber> the problem being that the fix got taken as-is from a more recent version of ifupdown, so it's not totally clear how we should fix it. Pulling the SRU in lucid will get us back to the previous not-always-working state, keeping the current one is a different kind of not-always-working AFAICT
[14:09] <Daviey> stgraber: We've been discussing it in #ubuntu-server, one user suggested that gets 10% success rate, and modprobing (!) gave him reliable setup
[14:10] <Riddell> sladen: where do I report uses of the old ubuntu logo?
[14:11] <stgraber> Daviey: that could be explained by the fact that all of /proc/sys/net/ipv4/*/bond* only appears once the module is loaded (same with /sys/class/net/bonding*)
[14:11] <sladen> Riddell: http://launchpad.net/ubuntu-branding/+filebug?field.title=XYZ+uses+pre-2010+Ubuntu+logo
[14:11] <stgraber> Daviey: so we may have some kind of race condition between ifupdown/ifenslave and the kernel module being loaded
[14:14] <Daviey> stgraber: I've been given access to an env where we can reproduce it, do you want me to try and get you access?
[14:14] <stgraber> Daviey: that'd be great
[14:23] <stgraber> Daviey: so if you add "bonding" to /etc/modules, does it then work reliably?
[14:23] <stgraber> (trying to figure out a quick test/workaround for the guy who reported the SRU regression so we can confirm it's the same issue and "fix" his setup for now)
[14:27] <smoser> pitti, you touched libtasn1-3, right?
[14:29] <pitti> smoser: yes, I debugged this weird NEWS.gz issue this morning a bit
[14:29] <smoser> pitti, sorry. i was going to say it didn't seem to fix it for me
[14:30] <smoser> but it was user error downloading wrong deb from launchpad (mirror doesn't have it yet for me)
[14:30] <smoser> all better now it seems.
[14:30] <pitti> smoser: you need ubuntu1, not build1
[14:30] <smoser> right.
[14:30] <pitti> build1 was more or less a check whether it still happens
[14:30] <pitti> it seems to happen consistently on ubuntu buildds
[14:30] <smoser> but then when i downloaded that, i accidently downloaded the wrong thing
[14:30] <smoser> and it didn't help
[14:30] <smoser> :)
[14:30] <pitti> but not anywhere else
[14:30] <smoser> now i'm square. yeah, a gzip bug is a bit strange.
[14:31] <cjwatson> pitti: I was working through a gdb session on that over the weekend
[14:31] <pitti> cjwatson: oh, you have a way to reproduce it locally?
[14:31] <cjwatson> will be getting back to it this week ...
[14:32] <pitti> I tried local builds, chroots, porter boxes, PPAs, all deliver the "correct" checksum
[14:32] <cjwatson> pitti: not as such but the difference is in alignment slack near the end of the file, so I'm prepared to bet that it's uninitialised data somewhere and I think I may be able to track it even without being able to reproduce it directly
[14:34] <pitti> cjwatson: ah, so perhaps the ubuntu buildds do use a different fs than ext4 for /build ?
[14:35] <cjwatson> I wouldn't have jumped to the filesystem being at fault
[14:35] <cjwatson> but I haven't ruled out anything in particular
[14:35] <pitti> not necessarily "at fault", I just can't think of any other significant difference
[14:35] <pitti> more like "triggers this bug"
[14:35] <pitti> perhaps truncate() zeroing vs. not, or something
[14:35] <cjwatson> could also be kernel differences
[14:36] <pitti> as the kernel, chroot, architecture shoudl more or less match
[14:36] <cjwatson> not in distro build chroots
[14:36] <cjwatson> the kernel is often several releases older than the chroot, and the degree of difference itself differs across architectures and also isn't necessarily the same as (virtualised) PPAs
[14:37] <cjwatson> personally I think that's the most likely cause, although I don't have a particular mechanism in mind and it probably amounts to a gzip bug anyway
[14:38] <pitti> cjwatson: ah, I had assumed that the buildds run lucid kernel
[14:38] <cjwatson> definitely not true across the board
[14:38] <pitti> ok, that's another possibility then
[14:38] <cjwatson> in fact I think lots of them are still on hardy, since they still need to build hardy-security packages
[14:38] <pitti> I tried precise on lucid kernel, but not precise on hardy or so
[14:39] <cjwatson> some are newer since hardy didn't support the relevant machine
[15:16] <ct529> hi! I am trying to compile the kernel, but 1) I am not certain about the numbering of the ubuntu kernel: does it follow the numbering of the kernel? 2) is it possible to compile the kernel by using the output of cpuid, or /proc/cpuinfo?
[15:39] <cjwatson> pitti: https://launchpad.net/ubuntu/+source/haskell-dummy/1:6/+build/2906774 looks like a pkgbinarymangler bug to me.  Shouldn't pkgstriptranslations only walk over the list of control files once, no matter how many times it's called for a given package?
[15:40] <cjwatson> pitti: I suspect this isn't doing kernel builds any favours in terms of performance either
[15:40] <cjwatson> (I'm not sure why it's exiting 1 in the haskell-dummy case; perhaps a lockfile timeout)
[16:11] <bdmurray> dobey: any idea what happend to the fix for bug 791927?
[16:13] <dobey> bdmurray: looks like it was fixed in upstream, but maybe the packaging didn't get updated to actually include it?
[16:14] <dobey> bdmurray: i can fix that after lunch probably
[16:15] <bdmurray> dobey: okay, thanks for looking at it
[16:15] <dobey> bdmurray: should we SRU it, or just put it in precise?
[16:17] <bdmurray> dobey: I'd think SRU'ing it makes sense but I'm don't know how many bugs desktopcouch gets ...
[16:20] <dobey> bdmurray: ok. will do then
[16:42] <asac> smoser: I remember that our lucid cloud images had issues to boot on high mem amazon instances. do you know if was that fixed at some point or are better off sticking to maverick still?
[16:43] <smoser> asac, i think it is fixed, but dont know for sure the exact bug.
[16:45] <asac> thanks. we might try :)
[16:45] <asac> will let you know if folks can spare some time testing this
[16:45] <smoser> do you remember the bug ?
[17:26] <dobey> bdmurray: https://code.launchpad.net/~dobey/ubuntu/oneiric/desktopcouch/include-apport/+merge/82197
[18:34] <zul> slangasek: Ping what do you think of bug #873423 is it a good idea?
[18:35] <slangasek> zul: all libraries should be converted for multiarch
[18:35] <zul> slangasek: so yes :)
[18:36] <cjwatson> not after feature freeze; but it's open season at the moment
[18:36] <slangasek> zul: certainly - that one's low priority from my POV though, since it's not part of the replace-ia32-libs critical path
[18:36] <zul> slangasek: gotcha thanks
[18:37] <roadmr> SRU-related question, are string changes SRUable? Our trunk has updated strings having to do with Unity and g-c-c changes and we'd like to have those changes in 11.10 as well
[18:46] <broder> bdrung: I'm looking at our outstanding lintian diff and trying to understand the "Drop debug-symbols-directly-in-usr-lib-debug from binaries-general." change you made
[18:56] <slangasek> roadmr: generally not, since this would result in a worse user experience for those who aren't using English rather than a better one
[18:57] <roadmr> slangasek: ok, so unless it's a major snafu on the string it's not likely to be accepted right?
[18:57] <slangasek> yes
[18:58] <roadmr> slangasek: ok, thanks! exactly what I wanted to know :)
[18:58] <slangasek> no prob
[19:01] <slangasek> debfx: bug #889475> you know you can use syncpackage to sync mozc yourself these days, it doesn't need to go through an archive admin?
[19:01] <slangasek> (and indeed, syncpackage is recommended )
[19:09] <stgraber> slangasek: hey, I just noticed http://packages.qa.debian.org/i/ifenslave-2.6/news/20111114T104742Z.html in Debian, which looks a lot like our current ifenslave bug. bug 823366, bug 482419 and bug 889423
[19:09] <stgraber> I'm tempted to just try a merge in a PPA and test on the server that Daviey and I are using for testing
[19:10] <stgraber> slangasek: I noticed you're the touched-it-last, is there anything weird with merging that one from Debian or should I just go ahead and do it myself?
[19:16] <slangasek> stgraber: feel free to take it, though I doubt Debian actually has a fix for any of this since these are mostly issues specific to event-driven boot
[19:18] <slangasek> maybe some of the code has been streamlined to reduce the need for duplicating information
[19:36] <hallyn> SpamapS, do you mind pulling the libvirt-bin from lucid-proposed?  (it failed to build, I marked bug 863629 wontfix for lucid)
[19:54] <stgraber> slangasek: yeah, looking at it, the change in Debian is basically what was pushed as an SRU in lucid (and then lost a bit later on in Ubuntu for some unknown reason)
[19:54] <stgraber> slangasek: basically just re-ordering the lines at the bottom of the pre-up script
[19:56] <stgraber> slangasek: doing a few tests now, my guess is that we should have the upstart job do nothing at all if an interface is in a bonding setup as bond0 will bring up the interfaces anyway
[19:58] <SpamapS> hallyn: hmmm?
[19:59] <SpamapS> hallyn: heading to lunch, do you mean revert it or try it out?
[19:59] <SpamapS> hallyn: or is it just in queue ?
[19:59] <hallyn> SpamapS, i mean pull it out of the -proposed queue
[19:59] <slangasek> stgraber: "lost a bit later on"?
[19:59] <slangasek> grr
[20:00] <SpamapS> hallyn: "The unapproved queue is empty"
[20:01] <SpamapS> hallyn: figure out what you need me to do, I'll be back online in about 45 min
[20:01] <stgraber> slangasek: yeah, the SRU for lucid basically looks like what has been uploaded in Debian this morning. So it looks like we thought changing the ordering was a good idea, got that as an SRU but didn't apply it to later versions of Ubuntu.
[20:02] <stgraber> I'll look at that once I have something that works and push the needed SRUs
[20:02] <slangasek> stgraber: that's not what I see in the current version of ifenslave-2.6 in precise
[20:02] <slangasek> add_master
[20:02] <slangasek> early_setup_master
[20:02] <slangasek> enslave_slaves
[20:02] <slangasek> setup_master
[20:02] <slangasek> that's what we currently have... which is intuitively correct
[20:02] <hallyn> SpamapS, it was approved for -proposed.  It should be pulled out of -proposed.
[20:03] <hallyn> "figure out what I want" depends on what 'revert it' means.  it's not in -updates yet, so I didn't think revert would have applied.  But if revert means pull it from proposed, then yes.
[20:03] <stgraber> slangasek: right, lucid has:
[20:03] <stgraber> add_master
[20:03] <stgraber> setup_master
[20:03] <stgraber> enslave_slaves
[20:03] <SpamapS> hallyn: if it has already been pushed out to mirrors, its better to upload a new package with the change reverted
[20:03] <hallyn> SpamapS, huh?  for something only in -proposed?
[20:03] <SpamapS> hallyn: no if it hit -proposed users will be affected
[20:04] <slangasek> stgraber: yes; that's different not because precise doesn't include the fix, but because precise includes a *further* fix to split setup_master into setup_master + early_setup_master
[20:04] <SpamapS> hallyn: many devs (myself included) run with -proposed enabled all the time.
[20:04] <hallyn> SpamapS, it didn't build, so users won't be affected
[20:04] <slangasek> because presumably some bits need to be done before enslavement, and some after
[20:04] <SpamapS> hallyn: ahh if it FTBFS then just upload a new one with the fix.
[20:05] <stgraber> slangasek: -19 to -20 in Debian is: http://paste.ubuntu.com/738533/
[20:05] <hallyn> i thought things got pulled from -proposed all the time when verification wasn't done by anyone, or failed.
[20:06] <slangasek> stgraber: that looks to me like the maintainer is flip-flopping; I don't believe that's going to be a correct fix
[20:06] <SpamapS> hallyn: they do, but I don't believe I can do that as I don't have direct "cocoplum" access.
[20:07] <slangasek> stgraber: I think this needs more investigation rather than just a simple merge
[20:07] <hallyn> ok, thx
[20:07] <slangasek> because it will probably reintroduce the other bugs that led to the early/setup split to begin with
[20:07] <SpamapS> hallyn: I'm no help at all I know. :-P
[20:07] <stgraber> slangasek: yeah, agreed on that point (once I actually saw what the change was in Debian). Looking at tweaking the upstart job to not run ifup when the interface is in a bond
[20:08] <stgraber> which means only bond0 will be brought up and it should then bring up the interfaces, making everything work (hopefully)
[20:08] <slangasek> stgraber: I think we need a clearer statement of what problem you're actually trying to fix.  That also sounds like a wrong change to me
[20:08] <hallyn> and i'm just a cranky jerk who hates mondays.  i think i'm less fun to be around.
[20:08] <slangasek> bond0 will not be brought up correctly
[20:08] <slangasek> don't do that :)
[20:09] <slangasek> the bonding bring-up *must* be initialized starting from the physical interfaces
[20:09] <slangasek> because those are the only things we get events for
[20:10] <slangasek> we need to properly handle hot-adding of interfaces to an already-up bonding interface, and we need the bonding interface to be brought up when the first physical interface is brought up; there's no other way to do it reliably
[20:13] <stgraber> ok, let me start a clean precise install on a machine that uses bonding and that's not in Montreal (the one I'm currently working on had way too many changes done to it to still be trusted :))
[20:14] <slangasek> ok
[20:14] <slangasek> fwiw, with a complete config here, I'm not reproducing any of these issues
[20:18] <stgraber> slangasek: that machine in Montreal is failing at every boot but I'd like to see it happen on a perfectly clean system
[20:20] <slangasek> stgraber: can I see your /e/n/i?
[20:25] <Daviey> stgraber: that is a volatile machine that can be re-installed if you need it to be?
[20:28] <stgraber> slangasek: http://paste.ubuntu.com/738559
[20:28] <cjwatson> slangasek,debfx: syncpackage doesn't support sponsorship yet, though, so the requestor wouldn't get credited; that's one situation where the old-style workflow is still recommended
[20:28] <slangasek> cjwatson: ah
[20:30] <slangasek> stgraber: right, so, the design of the current code is such that you need to reproduce the 'bond-mode' and 'bond-miimon' options in the stanzas for each of the physical interfaces, or else they don't get picked up
[20:31] <slangasek> stgraber: I expect that if you copy those down, the interface will come up reliably
[20:31] <slangasek> and it's a design defect of the script that this is required
[20:33] <Daviey> cjwatson: sync bugs don't exactly work well, when they bake in the queue and another developer comes along and does a sync whilst waiting for the bug based sync, so the reporter gets credit.
[20:34] <cjwatson> Daviey: I'm not saying they're ideal - they aren't.  But syncpackage has no way to assign credit to somebody else right now, so it's a difference between some chance and no chance.
[20:34] <slangasek> stgraber: /etc/network/if-pre-up.d/ifenslave-2.6 probably needs to use 'ifquery' to extract the details for the bonding interface; this is inelegant, but ifup is obviously not going to know to inject variables from a different interface (bond0) when bringing up the physical interface, so the script would have to do the work
[20:35] <stgraber> slangasek: rebooting now, I also think I reverted most of the changes that happened to that machine (thanks to debsums)
[20:35] <slangasek> ifquery also being Ubuntu-specific for the moment
[20:35] <cjwatson> (Of course the availability of syncpackage has meant that there's less general pressure to process the bug queue regularly ...)
[20:36] <cjwatson> I'd do it now while thinking about it but I'm being called away
[20:37] <stgraber> slangasek: machine just finished rebooting, still not working
[20:37] <slangasek> stgraber: hmm, ok
[20:39] <stgraber> back to installing a clean precise server :)
[20:48] <SpamapS> slangasek: think you will have time to upload from the mysql-5.5 svn tree again today?
[20:48] <Daviey> cjwatson: ack
[20:48] <SpamapS> slangasek: 5.5.17-3 implements Multi-Arch: foreign for libmysqlclient18
[20:49] <slangasek> SpamapS: not sure if I'm going to get to it today; if not today, then tomorrow
[20:50] <SpamapS> slangasek: ok thats great. I am also preparing an upload to make 5.1 stop building libmysqlclient-dev, libmysqld-dev, libmysqld-pic, mysql-common, mysql-server, and mysql-client
[21:10] <bdrung> broder: that's needed to work around bug #808767
[21:10] <bdrung> broder: i would be happy, if you can find a fix for it
[21:26] <broder> bdrung: ...huh. that is *bizarre*
[21:32] <stgraber> slangasek: same problem with a clean precise install
[21:32] <slangasek> stgraber: phooey
[21:32] <stgraber> slangasek: /etc/network/interfaces => http://paste.ubuntu.com/738619/
[21:33] <stgraber> slangasek: dmesg => http://paste.ubuntu.com/738620/
[21:33] <stgraber> lots of complaining going on in dmesg
[21:34] <stgraber> including some complaints (also visible when doing ifup eth0/eth1) that bond-mode can't be changed from an interface definition (as it can only be set when the bond is down)
[21:35] <slangasek> stgraber: hmm.  so results may be driver-dependent
[21:35] <slangasek> it's possible that my own testing in kvm is inadequate :P
[21:35] <stgraber> in that dmesg (50.) is roughly the time where I fix stuff manually
[21:35] <stgraber> yeah, test environment here and in Montreal is using e1000 + cisco/hp switches doing actual LACP
[21:36]  * slangasek nods
[21:37] <slangasek> well, I know it's working for me because my interface is dhcp-configured and successfully gets an IP, and I can route traffic out
[21:37] <Fusionite> Hey all
[21:37] <slangasek> but I'm not using bonding mode 802.3ad
[21:48] <stgraber> slangasek: ok, so I tried something very ugly but that seems to work pretty well. Added "ifup bond0 || true" to /etc/init/network-interface.conf (before the ifup call)
[21:48] <slangasek> strange
[21:48] <slangasek> oh, network-interface, not networking
[21:48] <slangasek> less strange, just ugly :)
[21:49] <bdrung> broder: yes, it's a weird i386 bug
[21:49] <stgraber> yeah, at least that confirms the theory that we need to make sure we always bring up the bond before the slaves
[21:49] <stgraber> now to find the right place to do it
[21:49] <slangasek> I'm not sure it does that
[21:49] <broder> bdrung: does that mean that all i386 dbgsym packages are statically linked?
[21:50] <slangasek> because /etc/network/if-pre-up.d/ifenslave-2.6 would trigger in both cases
[21:50] <slangasek> just with different environment variables set
[21:50] <bdrung> broder: IIRC not all, only that specific file
[21:52] <stgraber> slangasek: oh, also something that's wrong in most configs I've seen so far, bond-primary only applies to active-backup mode, not to 802.3ad or any of the other bonding modes
[21:55] <slangasek> ah
[21:55] <stgraber> slangasek: so that seems to be a minimal valid 802.3ad config: http://paste.ubuntu.com/738645/
[21:56] <stgraber> at least it works fine (with that hack in the upstart job) and I don't see anything weird in dmesg anymore
[21:56]  * stgraber just finished reading http://www.kernel.org/doc/Documentation/networking/bonding.txt again
[22:08] <bdrung> tumbleweed: question.py doesn't seam to be the right place for class EditFile
[22:10] <tumbleweed> bdrung: it seemed about right to me. Better suggestions?
[22:10] <bdrung> tumbleweed: where is it used?
[22:10] <tumbleweed> bdrung: submittodebian, and in the subclass EditBugReport
[22:11] <tumbleweed> (which is used by requestsync, requestbackport)
[22:11] <bdrung> tumbleweed: maybe put those two classes into a separate pyfile
[22:17] <stgraber> slangasek: I'm starting to think these scripts should be split between bond and slaves. Then have the code for the slaves check if the bond exists and if it doesn't call ifup on it so we go through the usual stack instead of bypassing half of it
[22:36] <YokoZar> I have concluded that the proper way to stop regular kernel panics is to install the kernel-crashdump package
[22:37] <stgraber> YokoZar: I noticed a similar fix for apache a while ago, if you want it to stop crashing, just turn on debugging
[22:38] <YokoZar> stgraber: maybe we should put the debug packages in the default install then
[22:38] <broder> and, of course, the best way to fix race conditions is to have a debugger attached :)
[22:41] <hallyn> SpamapS, looking at bug 625882 - we are at 0.8.4 of libdbi, does that mean that anything compiled against libdbi can go back to being build-depends on libdbi0-dev instead of libdbi-dev ?
[22:42] <SpamapS> hallyn: no, libdbi0-dev is deprecated, it needs to be libdbi-dev
[22:42] <SpamapS> hallyn: if its coming in as a merge from Debian, then there needs to be a bug opened against the debian package.
[22:43] <hallyn> SpamapS, with rationale 'libdbi0-dev is deprecated'?
[22:44] <SpamapS> hallyn: I assume the intention of the maintainer is to drop the provides after a time...  in 0.8.4-1 " Renamed libdbi0-dev to libdbi-dev"
[22:44] <hallyn> SpamapS, d'oh, nm, i was misreading anyway.  it has 'libdbi0-dev | libdbi-dev'
[22:45] <SpamapS> hallyn: then in 0.8.4-2 he did 'Adds a Provides: libdbi0-dev' presumably because the API was still compatible
[22:57] <stgraber> slangasek: I have a working hack on top of ifenslave's pre-up script that seems to work great here (except for the part where both interfaces come up at the exact same time, that I worked around with a sleep for now :))
[22:58] <slangasek> stgraber: heh, right - plenty of race conditions to be watched after here
[22:58] <slangasek> stgraber: also, what's the right behavior if one of the interfaces is unavailable (never comes up at boot)?
[23:00] <stgraber> slangasek: http://pastebin.com/irAA6erR
[23:01] <stgraber> slangasek: with that code, only the first interface will be added to the bond, which should still work fine
[23:02] <stgraber> going back home now, will look at backlog later
[23:12] <bdrung> tumbleweed: bug #890464
[23:18] <Laney> that diff does more than the changelog says
[23:19] <slangasek> bryceh: ping re: bug #889226
[23:19] <tumbleweed> bdrung: right, that was on my queue, but nobody was verifying distro-info SRUs
[23:19] <tumbleweed> err udt
[23:20] <tumbleweed> bdrung: please go ahead. Also, we should come up with a long-term solution to this before precise freezes.
[23:21] <bdrung> tumbleweed: SRUing distro-info should be easier to SRUing ubuntu-dev-tools
[23:21] <broder> stgraber: is there a ppa or something with a new version of arkose? i want to play with some of the dbus filtering stuff :)
[23:24] <tumbleweed> bdrung: I suppose that works for tzinfo...
[23:25] <bdrung> tumbleweed: there are some weeks between the announcement and the release, so we should have enough time for the SRUs
[23:26] <tumbleweed> usually, the last one was a bit tight
[23:30] <stgraber> broder: yes, ppa:arkose-devel/stable
[23:32] <bryceh> slangasek, yeah
[23:34] <slangasek> bryceh: hey; followed up on the bug, if you want to debug this I suggest we do so in realtime
[23:34] <slangasek> as this is a one-off situation that happened *during* an X session that was previously fine
[23:34] <slangasek> and I don't expect it to be reproducible if I restart the X server
[23:34] <bryceh> slangasek, I'm reading up on Cypress TetraHub
[23:34] <slangasek> why?
[23:34] <slangasek> it's just a USB hub
[23:34] <slangasek> I can see the kernel events just fine
[23:34] <slangasek> the devices are there
[23:34] <slangasek> it's only X that's confused
[23:35] <stgraber> slangasek: so, I think that the diff I pasted earlier should work and seems to do the right thing. Only thing that needs fixing is the code bringing up the bond interface if it's not there.
[23:36] <bryceh> slangasek, I won't argue that X may not be doing something stupid, however we've not yet updated the X stack in precise, so what you're running right now should be pretty similar to what you were running in oneiric.
[23:36] <stgraber> basically whatever is the first slave coming up needs to do the ifup on the bond, any other interface needs to wait for the bond to be up, then add itself to the list of slaves
[23:37] <slangasek> bryceh: sure; so it could be a latent bug in the oneiric stack, or it could be related to the kernel in some unidentified fashion
[23:37] <bryceh> slangasek, also there appear to be a lot of usb subsystem error messages in your dmesg; possibly unrelated but also make me wonder at kernel problems
[23:37] <slangasek> stgraber: my understanding was that the ifup on the bond was already being done by the previous code
[23:37] <bryceh> slangasek, also I've found a linux-usb thread discussing this particular USB hub and issues with devices not detecting properly
[23:38] <slangasek> bryceh: heh; I've been using it for a couple of years now with no such problems
[23:38] <bryceh> the hub appears to have some usb 2.0 / 3.0 switching behaviors that I gather confused the kernel in the case being described in this thread
[23:38] <bryceh> slangasek, yeah the thread is very recent (nov 12)
[23:38] <slangasek> ah
[23:39] <bryceh> http://www.spinics.net/lists/linux-usb/msg54013.html
[23:39] <bryceh> not sure if it's relevant though.
[23:39] <stgraber> slangasek: kind of, the previous code was creating the bond and doing all the sysctl configuration, but never actually doing an ifup on it (so you'd have to wait till the ifup -a at the end of the boot to get an IP and run the other post-up scripts)
[23:40] <slangasek> stgraber: no, you shouldn't have to wait for ifup -a; creating the device causes a udev event for bond0
[23:40] <slangasek> which (asynchronously) triggers /etc/init/network-interface for bond0
[23:40] <bryceh> slangasek, last paragraph on this email suggests some known issues exist with this hw - http://www.spinics.net/lists/linux-usb/msg54377.html
[23:41] <slangasek> stgraber: maybe instead of calling ifup explicitly, we can just cause the interface to be created?
[23:41] <slangasek> (which I think would probably be cleaner)
[23:42] <slangasek> bryceh: checking to see what happens if I plug the mouse in directly
[23:43] <slangasek> stgraber: I guess it depends whether there's additional setup that needs to be done on the slave interface after ifup is called on the master
[23:44] <slangasek> bryceh: same problem when I plug the mouse in directly
[23:44] <slangasek> device shows up in lsusb, lsinput, input-events shows the events are being received, nothing useful out of X
[23:44] <stgraber> slangasek: I need a way of waiting for bond0 to be done initalizing because only then the other interfaces can be added as slaves to that bond
[23:45] <slangasek> stgraber: I don't think it's very clear what "done initializing" means in all cases
[23:45] <stgraber> slangasek: currently what's creating bond0 is the pre-up script for bond0, so not sure how to trigger the udev event without running the whole pre-up script
[23:46] <stgraber> slangasek: I need to have the bonding module loaded, have the bond interface created, have it's mode set and the interface up so /sys/class/net/bond0/bonding/slaves is writable
[23:47] <bryceh> slangasek, let's pop over to #ubuntu-x
[23:57] <slangasek> stgraber: oh; I was mistaken, there apparently *aren't* any udev events for bonding interfaces
[23:57] <slangasek> stgraber: arguably a bug, but I guess we shouldn't design to rely on it
[23:58] <stgraber> I don't think calling ifup on the master interface is a big problem, as long as we can be sure never to do it twice at the same time because of some race condition
[23:59] <slangasek> no, ifup itself guards against that