[00:26] <psusi> lifeless, I thought that rsync could deal with bytes being inserted or removed and shifting the position of the remaining bytes in the file, so you just needed to reset the encoder periodically without regard to the exact position in the output?
[00:26] <psusi> looking at the patch though, it seems to be trying to compute the rsync rolling checksum of the data and flushing only when it hits a particular value... which makes no sense to me whatsoever
[04:29] <pitti> Good morning
[04:32] <ion> morning
[05:26] <jk-> any upstart-o-nauts able to help with http://askubuntu.com/questions/162319/how-do-i-stop-all-processes-in-a-chroot ?
[06:31] <infinity> jk-: Answered.
[06:32] <jk-> the service in this restaurant is fantastic!
[06:33] <infinity> jk-: I cheated.  I cargo-culted from launchpad-buildd, with the theory that "if it's good enough for thousands of builds in a day during a test rebuild run, it's probably good enough for Jeremy's PC".
[06:34] <hrw> morning
[06:34] <hrw> can someone review patch in bug 824708?
[09:24] <jokerdino> seb128: i reported bug #1027584 earlier. please do take a look?
[09:25] <seb128> jokerdino, hey, thanks, I've added it to my todolist, I can confirm the issue
[09:26] <jokerdino> thanks much! i am not sure if we still have this bug in 12.04?
[09:27] <jokerdino> anyway, i be right back. just wanted to attract some attention to the bug.
[09:35] <seb128> jokerdino, it might be worth fixing in precise as well yes
[09:36] <Laney> easy fix, i just did it
[09:36] <seb128> Laney, for precise?
[09:36] <Laney> just sending upstream
[09:36] <Laney> you think it's worth SRU on its own?
[09:37] <seb128> Laney, it's probably not but good to include if we get to do a gedit upload for something else
[09:38] <Laney> ok
[09:38] <Laney> do we have a staging area for SRUs?
[09:39] <seb128> Laney, not really, I create ~ubuntu-desktop/source/precise vcs-es on the way as needed
[09:39] <seb128> Laney, we should probably do that for gedit
[09:39] <Laney> just as long as there is somewhere people will look
[09:39] <seb128> well nominate the bug for precise, that might help to spot it when somebody look at doing a SRU ;-)
[10:22] <Laney> is the sponsor queue really at 18?!?!?!?
[10:23] <jokerdino> hey Laney, as you are at it, may be reassign the bug to yourself? thanks!
[10:24] <Laney> jokerdino: feel free to do it
[10:24] <Laney> or just unassign since it's done
[10:24] <jokerdino> alrgiht. doing.
[10:24] <jokerdino> Laney: done. thanks.
[10:24] <seb128> Laney, shame it happens while dholbach is on holidays ;-)
[10:25] <Laney> heh
[10:25] <Laney> suspicious, eh?
[10:25] <jokerdino> so, he is not in holidays after all ;-)
[10:26] <jokerdino> probably remotely checking in the review queue
[10:27] <Laney> nah, he's travelling to every developer individually to force them to do reviews
[10:27] <jokerdino> that probably is what is happening.
[10:29]  * coolbhavi just sponsored a sync on the review queue
[10:33] <tumbleweed> or maybe everyone just gave up on ever getting sponsored? :)
[10:33]  * tumbleweed can't say he noticed a massive amount of sponsoring in -changes, but I don't read it *that* carefully...
[10:33] <tumbleweed> (clearly)
[10:34] <Laney> well, if you look at the graph there's a big drop
[10:34] <Laney> maybe it's a bug :P
[10:35] <tumbleweed> https://bugs.launchpad.net/~ubuntu-sponsors is fairly short
[10:35] <tumbleweed> dammit, we need the hall of fame, so we know who to applaud
[10:35] <Laney> maybe it was rejected merge proposals
[10:35] <coolbhavi> tumbleweed, IIRC few days back queue was around 80 now its the reverse i.e 18 :)
[10:36] <jokerdino> oh wait. is that why one of my proposed branches is in limbo?
[10:36] <jokerdino> i mean, i think i forgot to subscribe the sponsors
[10:36] <Laney> you don't need to do that for branches
[10:36] <Laney> if they're targetted correctly
[10:36] <tumbleweed> if it's in limbo, it was put there manually
[10:36] <jokerdino> bug #937334 it is.
[10:36] <Laney> is it on http://reports.qa.ubuntu.com/reports/sponsoring/index.html ?
[10:37] <Laney> oh, that is for unity not the distro
[10:37] <Laney> ask them :P
[10:37] <tumbleweed> that's targetted at lp:unity
[10:37] <jokerdino> hmm this stuff is confusing ;/
[10:37] <jokerdino> earlier, i proposed a branch against lp:gedit and asked to go away ;p
[10:37] <Laney> you can think of unity as an upstream project which is hosted on launchpad
[10:37] <tumbleweed> gedit isn't a LP projet
[10:37] <Laney> gedit is not, it is hosted on git.gnome.org
[10:38] <Laney> the ubuntu sponsors are for uploads to the ubuntu archive
[10:38] <jokerdino> well yes. i figured it out over time.
[10:40] <jokerdino> now that the gedit bug is fixed, i should get back to nagging the unity devs to fix that other bug :P
[14:23] <mterry> pitti, update-manager finally succeeded in jenkins!  yay  :)
[14:24] <pitti> mterry: indeed, thanks for fixing it! I uploaded your branch this morning
[14:24] <pitti> mterry: u-release-upgrader has a real issue, though
[14:24] <mterry> pitti, yeah, was about to mention that
[14:27] <mterry> pitti, I think the failure is "error from httplib: '<urlopen error [Errno 110] Connection timed out>'" when connecting to de.archive.ubuntu.com.  But I'm not sure why that would be true
[14:27] <pitti> jibel: ^ could it be because the jenkins environment can't access that?
[14:28] <pitti> only hosts in the DC perhaps?
[14:29] <jibel> pitti, ah, probably true. Will the test still be valid if the address is changed to archive.ubuntu.com or us.archive.ubuntu.com ?
[14:29] <pitti> I think archive.u.c. is the fallback if a mirror doesn't respoind
[14:29] <pitti> respond
[14:29] <pitti> we'd need a mirror within the DC
[14:30] <mvo> mterry: \o/
[14:30] <pitti> if us.archive is reachable, that ought to work
[14:30] <jibel> pitti, the machine has access to archive.ubuntu.com
[14:30] <pitti> yes, that part works
[14:31] <pitti> mterry: is there a separate test for correct fallback if a mirror isn't reachable?
[14:31] <pitti> if not, this test could perhaps turn into that :0
[14:31] <mterry> pitti, let me see
[14:31] <mterry> :)
[14:31] <xnox> pitti: mterry: i recall cjwatson was struggling with that test as well....
[14:31] <xnox> it was doing something special which mvo should know about?! =)
[14:32] <xnox> s/struggling/trying to understand what is it testing, how and why/
[14:34] <mterry> pitti, there is a test against archive.u.c, and then an identical test for de.archive.u.c to test mirror support
[14:34] <pitti> mterry: i. e. it could perhaps test with a mirror ubuntu.example.org and verify that it falls back to archive.u.c.
[14:34] <mterry> Yeah, I don't see one that tests fallback
[14:34] <pitti> mterry: of course testing with a working mirror would also be nice, but the test could check if the mirror works and skip itself if not?
[14:35] <pitti> mterry: test with archive.canonical.com ?
[14:35] <pitti> mterry: no, ignore me
[14:35] <pitti> mterry: so perhaps try with us.archive, as jibel said that might work
[14:36] <mterry> pitti, so at a minimum, this test should catch this timeout exception and skip the test gracefully if encountered.   But it might as well also be run against us.archive I guess, if that's available, so we get the benefit of the test
[14:36]  * mterry whips up a patch
[14:36] <pitti> mterry: cheers!
[14:39] <jibel> mterry, I confirm the machine has access to us.a.u.c
[14:39] <mterry> jibel, awesome, thanks
[14:41] <smoser> jodh, around?
[14:41] <jodh> smoser: yes!
[14:42] <smoser> mountall question
[14:42] <smoser> i'm under the impression that mountall kind of determines mount dependencies and then does them non-serially
[14:42] <smoser> is that correct?
[14:42] <smoser> and probably figures out that it has to mount /var/lib after /var ... and such like that.
[14:43] <smoser> is that true? (because the rest of my thoughts have no point if its not)
[14:43] <jodh> smoser: it orders the mounts by type - see http://upstart.ubuntu.com/cookbook/#mountall-event-summary. Just double-checking how clever it is...
[14:44] <stgraber> mountall knows about the relationship between mount points, yes (that /var is the parent of /var/lib for example)
[14:44] <stgraber> I'm not sure how clever it's about the ordering though
[14:44] <smoser> i was then wondering how mountall would handle an overlayfs mount.
[14:45] <stgraber> I believe it'd fail
[14:45] <smoser> where the lowerdir=/root/home,upperdir=/home
[14:45] <stgraber> as I added logic to mountall to never mount a filesystem that'd hide another one mounted at an upper level
[14:45] <smoser> it'd have ot know that 'uppperdir=/home' would have to block on /home
[14:46] <smoser> hm..
[14:46] <smoser> i'll try to write a fstab to show what i'm thinking
[14:54] <tkamppeter> Anyone knows how to make pbuilder not delete the build directory after building? I want to look into config.log.
[14:57] <mterry> tkamppeter, you could log into the chroot and build there?  I don't happen to know a switch to save the build artifacts.
[14:58] <mterry> cjwatson, didrocks: Could one of y'all reject the gigi source upload I made to quantal?  It's in NEW, but will not be needed after all.
[14:58] <cjwatson> mterry: done
[14:59] <mterry> cjwatson, thanks!
[14:59] <didrocks> cjwatson had the trigger under his finger it seems :)
[14:59] <ogra_> cyphermox, poke
[14:59] <tumbleweed> tkamppeter: do something like /usr/share/doc/pbuilder/examples/C10shell but in a B hook
[14:59] <cjwatson> tkamppeter: ln -s /usr/share/doc/pbuilder/examples/C10shell /etc/pbuilder/hooks.d/
[14:59] <cjwatson> and then it'll give you a shell after every failed build
[15:00] <cjwatson> (assuming this is a failed build, otherwise, what tumbleweed said)
[15:00] <smoser> stgraber, what does "never mount a filesystem that'd hide another one mounted at an upper level" mean ?
[15:01] <jamespage> anyone know whether quantal will ship eglibc 2.16? or are we sticking with 2.15?
[15:01] <cjwatson> jamespage: ask infinity when he's around
[15:01] <jamespage> cjwatson, ack
[15:01] <stgraber> smoser: if you have /mnt/test mounted before mountall runs, and have /mnt defined in /etc/fstab, mountall will skip /mnt as it'd hide the content of /mnt/test/
[15:02] <smoser> ah. ok.
[15:02] <smoser> stgraber, is there special handling of bind mounts?
[15:03] <stgraber> not that I can remember of (has been a while since I last looked at the code)
[15:03] <smoser> perhaps i could cheat here and use the fs_spec field (field 1) that is (I think) ignored by overlayfs
[15:03] <smoser> but if mountall supports bind mounts, it clearly has to support paying attention to that field.
[15:04] <smoser> otherwise binding /home into /another-home-location would be random
[15:06] <jodh> smoser: mountall doesn't support the "bind" mount option option currently, but it does bind mount if "showthrough" is specified.
[15:07] <sil2100> didrocks: hm, where is the nux precise branch located?
[15:07] <smoser> jodh, ok. so to do this right i probably would have to add some overlayfs knowledge to mountall
[15:08] <sil2100> didrocks: I mean, is there a special location like lp:ubuntu/nux for it?
[15:08] <smoser> not tested, but i thinkm the fstab would look something like example at http://paste.ubuntu.com/1106554/
[15:08] <sil2100> didrocks: or should I use the one from ~ubuntu-desktop ?
[15:09] <smoser> given that example, i suspect that mountall doesn't know that line 12 depends  on line 10 and that line 11 depends on line 9
[15:09] <didrocks> sil2100: lp:ubuntu/nux is trunk content, yeah
[15:09] <didrocks> ah precise
[15:10] <didrocks> sil2100: well, like all the other ones, for older branch, take ~ubuntu-desktop
[15:10] <didrocks> and add a /precise one if there is not any
[15:14] <jodh> smoser: yes, I think you're right. However, that example should actually work since mountall would run the mounts in order.
[15:15] <smoser> why would it do them in order, jodh ?
[15:19] <jodh> smoser: mountall reads its internal fstab and then /etc/fstab, adding each entry to a list. It then attempts to prune that list (removing already mounted entries, etc). But eventually -- and assuming no parent directory dependencies between entries -- it will run through the remaining list entries in order. Since your example doesn't have any directory/device dependencies between lines 9+11, 10+12, I think it should attempts the mounts
[15:19] <jodh> in lines 9-12 inclusive in that order.
[15:20] <smoser> jodh, ok. i'l work on that assumptio nthen.
[15:20] <tkamppeter> mterry, did login with the directory containing the source package bind mounted, and found the missing build dependency by that. Thank you very much.
[15:21] <mterry> tkamppeter, awesome  :)
[15:22] <jodh> smoser: let me know how it does. I think mountall could do with a little more commentary, so I'll attempt to add that. Also, it would be pretty useful to be run it in --dry-run mode so you could see the ordering it has chosen. Feel free to raise a bug on that.
[15:22] <jodh> smoser: ahem. how it *goes. :)
[15:30] <seb128> cjwatson, hey, could you have a look to http://pastebin.ubuntu.com/1106596/ please?
[15:31] <seb128> cjwatson, I'm a bit unsure about the postinst "clean empty dirs on upgrade" and the mainscript part so it would be nice if you could have a look for me before I upload
[15:31] <seb128> cjwatson, basically bash_completion.d got moved from /etc to /usr
[15:38] <cjwatson> seb128: would be nice to fix the syntax errors to start with ;)
[15:39] <cjwatson> (you need spaces before ])
[15:40] <seb128> cjwatson, ups, yes, I didn't test yet, I was more concerned about the idea, i.e is postinst the right place to do that?
[15:40] <cjwatson> seb128: I haven't reviewed the whole diff in context or anything.  maintscript is generally fine, though you can drop the unnecessary "bash-completion" at the end of every line.  I think the postinst changes are fine; maybe discard errors?
[15:41] <cjwatson> i.e. that'd be one of the cases where 2>/dev/null might be reasonable, since it isn't really an error if those directories are non-empty
[15:41] <cjwatson> seb128: consider adding a version guard to the added postinst code, though
[15:41] <seb128> right
[15:42] <seb128> cjwatson, thanks, I will fix those and send to debian,upload to quantal (after another round of testing)
[15:42] <cjwatson> ta
[15:48] <jdstrand> @pilot in
[16:09] <mterry> pitti, do you know if someone is porting update-notifier to udisks2 from gdu?
[16:14] <cjwatson> jamespage: tasksel is in bzr and has lots of automatic update scripts etc. - happy to help you if you need to change it in future
[16:14] <jamespage> cjwatson, argh - sorry - did I break alot?
[16:15] <cjwatson> I just had an upload conflict is all
[16:15] <cjwatson> Resolving now
[16:15] <jamespage> cjwatson, ack - not sure how I missed the VCS field - my bad
[16:16] <cjwatson> Ah well
[16:16] <cjwatson> The automatic update thing is that you can 'rm -r ubuntu-tasks; make ubuntu-tasks'
[16:17] <cjwatson> Should never be necessary or desirable to edit files under ubuntu-tasks by hand
[16:17] <cjwatson> And generally worth avoiding because if you do that it's susceptible to being overwritten by future changes (although that didn't happen here)
[16:19] <jamespage> cjwatson, so the ubuntu-tasks are created from the seeds?
[16:19] <cjwatson> jamespage: Yes
[16:20] <cjwatson> That's the reason we have those Task-* fields in the seeds
[16:20] <jamespage> cjwatson, right - I see
[16:24] <cyphermox> ogra_: hey
[16:24] <ogra_> cyphermox, you seem to be our bluetooth expert
[16:25] <cyphermox> ahahah
[16:25]  * ogra_ is struggling a bit trying to get that cool setup running you showed at UDS
[16:25] <cyphermox> shoot ;)
[16:25] <ogra_> i have a galaxy S2 and no idea what i need to do to debug the non working SMS stuff, i installed ofono and telepathy-ring ...
[16:26] <cyphermox> telepathy-ring doesn't do the SMS, I think
[16:26] <cyphermox> ogra_: but so far it sounds good
[16:26] <ogra_> oh, i thought that was what you installed during your talk
[16:26] <cyphermox> well it is
[16:27] <cyphermox> but I only played with phone calls, not SMS
[16:27] <ogra_> oh, indeed
[16:27] <cyphermox> at this point in quantal SMS might work directly with ModemManager, too
[16:27] <cyphermox> (using a 3g dongle, not a phone, though)
[16:27] <ogra_> ah, well, i have my phone paired via BT indeed
[16:27] <cyphermox> unless your phone can be tethered or uses BT DUN
[16:27] <cyphermox> ok
[16:28] <cyphermox> does ofono see your phone?
[16:28] <ogra_> i also tried gnome-phone-manager and i cant see DUN with sdptool
[16:28] <ogra_> Using device: /org/bluez/3806/hci0/dev_BC_85_1F_E1_F1_14, devaddr: BC:85:1F:E1:F1:14, adapter: 00:1B:DC:01:F0:4F
[16:28] <ogra_> looks like
[16:28] <cyphermox> awesome
[16:29] <ogra_> BC:85:1F:E1:F1:14 is it
[16:29] <cyphermox> is telepathy-ring saying it's connected? if it can't understand ofono or the phone, it will remain disconnected IIRC
[16:29] <ogra_> how would i see that ?
[16:30] <ogra_> all i get is a new tel and SMS protocol in the telepathy account dialog
[16:30] <cyphermox> best way I found was to disable all the other accounts, or check in the accounts dialogs
[16:30] <cyphermox> there's a slider thing for the account that would be on or off
[16:31] <ogra_> well, which protocol should i use ? tel or sms ?
[16:31] <ogra_> (neither seems to have any options)
[16:31] <cyphermox> neither will have any options
[16:31] <ogra_> well, selecting either of them gets me just a greyed out "accept" button
[16:32] <cyphermox> you want to receive SMS so I'd use sms; can you try to send yourself one to see if ofono sees something, and if telepathy-ring sees it?
[16:32] <ogra_> ah, no, tel doesnt but it gets me an immediate network failure message
[16:32] <cyphermox> ok
[16:32] <ogra_> sure
[16:32]  * ogra_ goes to abuse mup on the other server ;)
[16:33] <cyphermox> telepathy-ring is kind of really broken, I had a hard time starting it in the right order with ofono
[16:33] <cyphermox> and if the dbus API in ofono changed, it's probably even more broken now
[16:33] <ogra_> hmm, nothing in ofono
[16:34] <cyphermox> what about phone calls?
[16:35]  * ogra_ tries to find his landline phone
[16:36] <ogra_> nope, no reaction in ofono
[16:36]  * ogra_ wonders if there is an issue with the default setup for HFP
[16:36] <tkamppeter> tumbleweed, cjwatson, also thank you for your method, will try it in a later case.
[16:38] <tumbleweed> tkamppeter: if you set up the C10shell hook now, you'll be pleasently suprised the next time a build fails, and you can debug it :)
[16:41] <cyphermox> ogra_: there were no settings to change anywhere
[16:42] <cyphermox> I could try this out later, but for now I really should keep modemmanager on to be able to work on NM and properly test my stuff :)
[16:42] <ogra_> ok, i'll go on digging then
[16:43] <cyphermox> oh boy, ofono is ancient
[16:43] <ogra_> heh
[16:43] <ogra_> well'i'm not even sure i would need it at all
[16:44] <cyphermox> ok
[16:44] <ogra_> the bad thing is that any search i did on google yet only returns UoA results
[16:44] <ogra_> tons of them
[16:44] <cyphermox> UoA?
[16:44] <ogra_> err UfA
[16:45] <ogra_> ubuntu for android :)
[16:45] <cyphermox> oh
[16:45] <cyphermox> well for SMS ModemManager is supposed to work, but I know it works really a lot better with 3G dongles than with phones
[16:45] <cyphermox> or I just never figured out how to have it talk to my phone ;)
[16:46] <ogra_> haha
[16:46] <ogra_> so we have the same prob :)
[16:46] <cyphermox> that said, they're still working hard on the SMS stuff
[16:46] <ogra_> ogra@anubis:~$ sdptool browse BC:85:1F:E1:F1:14|grep SMS
[16:46] <ogra_> Service Name: Android SMS
[16:46] <cyphermox> whereas ofono should have good support already, but it's not any easier to make it work apparently
[16:46] <ogra_> well, apparently there is something i should be able to access
[16:46] <cyphermox> huh
[16:46] <cyphermox> yeah
[16:47] <ogra_> just not sure how
[16:50] <cyphermox> ogra_: there is probably no app on linux that does this yet :)
[16:52] <seb128> bug #1027665
[16:52] <seb128> does anyone if that's a gcc issue or what?
[16:52] <cyphermox> ogra_: I can't even see that profile on http://developer.bluetooth.org/KnowledgeCenter/TechnologyOverview/Pages/Profiles.aspx
[16:53] <ogra_> ah, seems i can force /dev/rfcomm0 to be used in gnome-phone-manager which results in a constant 30sec loop of password prompts on the phone
[16:54] <infinity> seb128: Erm, how do they not have libgcc1 installed?
[16:54] <seb128> infinity, libgcc1 1:4.7.1-5ubuntu1
[16:55] <seb128> https://launchpadlibrarian.net/110939701/Dependencies.txt
[16:55] <seb128> so not sure how they run into that issue
[16:55] <ogra_> cyphermox, http://paste.ubuntu.com/1106745/ ist intresting that "Service Class ID List" and "Profile Descriptor List" are just empty
[16:56] <ogra_> *it's
[16:56] <ogra_> so it might either be new or something "special" :)
[16:56] <cyphermox> yeah
[17:01] <infinity> seb128: libgcc_s.so.1 appears to still have the right symbols for glibc to not be throwing that assertion...
[17:02] <seb128> infinity, it's only one user and there were no recent gcc update so I'm not really concerned but the bug is weird
[17:05] <infinity> seb128: Well, it was an amd64 user, but that codepath should only be hit when using linuxthreads, which seems fishy all by itself.
[17:16] <seb128> infinity, slangasek, SRU team: what are the chances somebody can review unity's SRU today?
[17:16] <infinity> seb128: I will.
[17:16] <seb128> infinity, great, thank you!
[17:18] <infinity> seb128: You can send me some d'Affinois and a nice Merlot as compensation.
[17:20] <seb128> infinity, let's wait to see if you approve it first ;-)
[17:22] <infinity> seb128: If I don't, I'm sure I'll still provide cheese-worthy feedback.
[17:22] <seb128> infinity, I've no doubt about that!
[17:23] <jibel> given his region I'd rather ask for a Géromé with a pinot-gris ;)
[17:24] <infinity> jibel: His region still has d'Affinois a heck of a lot cheaper than I can get it here. :P
[17:24] <infinity> And by "his region", I mean "mainland Europe", in this case.
[17:24] <jibel> and Munster won't pass border control :P
[17:44] <infinity> seb128: libnet-dns-perl should have been merged, not synced.
[17:52] <infinity> seb128: Oh, hrm.  FSVO "merge" that means something entirely different.  Curious.
[18:22] <infinity> seb128: Yeah, I take it back entirely, the libnet-dns-perl failure is an entirely new one, and seen on Debian as well.
[18:40] <infinity> seb128: Hrm, the majority of that unity diff appears to have been someone building the source package in a non-UTF-8 locale (or somehow otherwise breaking the encoding of some changelogs).
[18:46]  * mterry is looking at libnet-dns-perl ftbfs; let me know if someone else is too
[18:47] <scientes> mterry, <infinity> seb128: libnet-dns-perl should have been merged, not synced.
[18:47]  * scientes guesses gcc-4.7 issues
[18:47] <mterry> scientes, thanks
[18:47] <mterry> oh also I see looking back "Yeah, I take it back entirely, the libnet-dns-perl failure is an entirely new one, and seen on Debian as well."
[19:04] <seb128> scientes, mterry: why should it be merged and not synced?
[19:04] <seb128> infinity, ^
[19:04] <mterry> seb128, I believe that opinion has been retracted
[19:04] <seb128> ok, good ;-)
[19:05] <seb128> the only diff it has was an year old issue that seems to be something like shouldn't apply to the current version
[19:05] <infinity> seb128: Well, it was a testsuite failure due to buildd network access, and so it the current one, so I knee-jerked.  But the new failure is, well, new.
[19:06] <infinity> s/so it/so is/
[19:06] <seb128> infinity, how come those issues happen on Ubuntu and not Debian, I though the debian buildds had the same network limitations?
[19:07] <infinity> seb128: No, most Debian buildds don't have network restrictions at all.
[19:07] <infinity> seb128: And it *did* fail on plenty of Debian arches the same way.
[19:07] <seb128> hum, k
[19:08] <seb128> infinity, unity> can I blame launchpad?
[19:08] <seb128> oh, no, local debdiff has the same issue
[19:08] <seb128> -x is your friend :p
[19:08] <infinity> seb128: Yeah, not LP's problem.  The upstream tarball is wrong.
[19:08] <infinity> seb128: But I'm going to just la la la over it, I guess, unless someone wants to fix it with a 5.14.0.1
[19:09] <seb128> hum, I like that lalala music ;-)
[19:09] <infinity> seb128: 6.0.0 is fine, so it's not like someone broke the changelogs upstream.
[19:09] <seb128> the changelog is autogenerated from bzr log
[19:09] <infinity> (Well, someone might have broken the 5.x branch, I didn't check bzr)
[19:09] <seb128> so I guess whoever rolled the tarball has a weird locale
[19:09] <infinity> Ahh, so it's.. Yeah.
[19:09] <infinity> Okay, that makes some sense.
[19:10] <infinity> Especially if it was Łukasz ...
[19:10] <seb128> he's the one ;-)
[19:10] <infinity> People with funny characters in their names seem to often have weird locales. :P
[19:10] <seb128> ;-)
[19:11] <infinity> (If there's a script or something that's used to make dist, it might be nice to commit a LANG=C.UTF-8 to that, for consistency)
[19:11] <seb128> right, I will check with the unity guys
[19:11] <infinity> But I'll overlook it for now.
[19:11] <seb128> thanks
[19:12] <infinity> Just make a mental note that their next upstream release will probably have the same diff in reverse, so someone will have to explain it again. :P
[19:15] <ScottK> filterdiff --no-weird-locale-diff
[19:16] <ScottK> The U/I design work is done, just up to implementation now.
[20:08] <jdstrand> @pilot out
[20:10] <infinity> arges: Can you reupload your nss-pam-ldapd oneiric SRU without the autotools regen mess?
[20:13] <infinity> arges: Actually, I guess I'll do that on your behalf. :P
[20:23] <infinity> arges: Alright, re-uploaded with cruft removed, and also fixed versioning for your natty and oneiric uploads so that natty wasn't > oneiric.
[20:28] <arges> infinity, hey just got back. sorry missed that
[20:28] <arges> infinity, ok thanks
[20:30] <infinity> arges: You might want to kill the natty MP, since I appear not to be able to. :P
[20:31] <arges> infinity, not sure what you mean by natty MP
[20:32] <infinity> arges: https://code.launchpad.net/~christopherarges/ubuntu/natty/nss-pam-ldapd/nss-pam-ldapd/+merge/115147
[20:33] <infinity> arges: I can't commit to the branch (only the importer can), so I can't close the merge proposal.
[20:33] <arges> infinity, ok. so mark the status of the merge to something eles?
[20:33] <infinity> arges: But you should be able to.
[20:33] <infinity> arges: merged would be fine.  Or some appropriate lie.  Whatever. ;)
[20:34] <arges> infinity, ok gotcha.
[20:34] <arges> infinity, done. thanks
[20:59] <bdrung> bryceh: thanks for triaging so many vlc bugs
[21:03] <seb128> bdrung, hey, speaking about vlc is there any plan to get 2.0.2 or .3 in precise?
[21:04] <stgraber> mdz: TB meeting?
[21:04] <bdrung> seb128: i plan to get a MRE for vlc and then upload 2.0.3 to precise
[21:04] <seb128> great
[21:05] <bryceh> bdrung, sure thing
[21:05] <seb128> bdrung, not sure how easy the MRE will be to get but you can maybe try to update to 2.0.2 or 2.0.3 without it?
[21:06] <bryceh> seb128, there's an SRU requesting it, but the diff from 2.0.1 to .2 is pretty big.  A provisional MRE seems the right way to go.
[21:06] <bdrung> seb128: quote from bryceh: The 2.0.2 release has a large number of changes over 2.0.1 (the website says over 500 commits), although from the NEWS file it does sound like this is almost entirely bug fixes.
[21:06] <Laney> the website doesn't give that impression
[21:07] <bdrung> the commits to the 2.0.x branch are mostly bug fixes
[21:07] <Laney> eg "Experimental support for BluRay discs"
[21:07] <seb128> bdrung, bryceh: I don't know enough about vlc to know if it justify a MRE (process, testing, etc)
[21:07] <Laney> or is that not the changes?
[21:07] <Laney> ah, it is not, /me scrolls further down
[21:08] <bdrung> their rules for commits in their maintanance branch seems to be more relaxed
[21:08] <bryceh> Laney, http://www.videolan.org/vlc/releases/2.0.2.html says "2.0.2 fixes a couple of hundreds of bugs, and adds more than 500 commits on top of 2.0.1."  I didn't verify that count but it looks likely
[21:08] <seb128> bdrung, usually the SRU team will be wanting to get a track of some successful SRUs to grant a MRE
[21:09] <Laney> Sounds like it'll be a tough sell :-)
[21:09] <bryceh> bug 1025713 lists 5 specific fixes that look like low hanging fruit worthy of SRU
[21:09] <mdz> stgraber, sorry, I'm late, had stuff going on at work
[21:10] <bryceh> however I have not yet linked any of those fixes to reported bugs (nor know how to repro)
[21:10] <bryceh> I'm looking through the reported bugs for any others that I can tie to fixes, but no luck so far
[21:11] <bryceh> anyone know if 2.0.3 is in debian?  at least we could up quantal to that version, which would be prereq to getting precise on 2.0.3.
[21:11] <kees> mdz: tech board?
[21:11] <mdz> kees, yes
[21:11] <mdz> #startmeeting
[21:12] <bdrung> bryceh: i just synced vlc 2.0.3-1 to quantal
[21:12] <mdz> cjwatson, soren, pitti, ping
[21:15] <bryceh> bdmurray, aha thanks
[21:15] <bdrung> mdz: https://wiki.ubuntu.com/TechnicalBoard says "You can submit an item or proposal for discussion by the Technical Board using the wiki page TechnicalBoardAgenda.", but the agenda says "If you have a question to raise with the Board, you can reach the Technical Board members directly by e-mailing technical-board@lists.ubuntu.com.". what's the preferred way?
[21:18] <stgraber> bdrung: either way is fine, including adding to agenda + sending an e-mail to the mailing-list to give more details.
[21:18] <stgraber> bdrung: mostly depends if you want it discussed during a meeting (should be on agenda) or offline (should be sent to the mailing-list)
[21:18] <bdrung> stgraber: i prefer the online discussion
[21:19] <mdz> bdrung, agreed, either is fine. email has a chance of a faster response, whereas agenda items wait until the next meeting
[21:20] <bdrung> mdz: i added the item to the agenda some minutes ago. so the response time should be very fast. ;)
[22:16] <mterry> infinity, I've got a lead on why the libnet-dns-perl test is failing, but I have to stop working very soon.  I'll finish up tomorrow.  Just wanted to let you know now, so you don't work on it in the interim
[22:16] <mterry> Has to do with ipv6 sockets not being able to be created
[22:17] <mterry> The test even has a check at the top to see if it can bind to a socket, and will skip the test if it can't.  But it only does that for ipv4
[22:17] <infinity> mterry: Curious.  But why only on some buildds (in the Debian case)?
[22:17] <infinity> And why none of ours?
[22:17]  * infinity shrugs.
[22:17] <mterry> infinity, not sure.  A local lockdown policy difference?  Like, some have ipv6 locked down and some don't?
[22:17] <infinity> I look forward to seeing your fix. :0
[22:18] <mterry> infinity, though, it seems like ours locks down only ipv6
[22:18] <mterry> which doesn't make much sense
[22:18] <infinity> mterry: That test is on localhost, which we don't lock down at all.
[22:18] <mterry> infinity, the test already has code to test if a socket is bindable.  I'll just add a stanza to also test ipv6
[22:18] <infinity> So, it miiiiight not relate to locked down networks in any way.
[22:18] <mterry> but this might point to some misconfiguration on the machines?
[22:19] <stgraber> I believe xnox hit a similar bug a few weeks back with another package
[22:19] <infinity> But adding the test will do anything, perhaps.  If that's definitely what's failing.  Do test in a PPA.
[22:19] <stgraber> same kind of problem, the test would try to listen on ::1 and would fail
[22:19] <mterry> infinity, I did
[22:19] <infinity> stgraber: Did you ever sort it out?
[22:19] <stgraber> infinity: I didn't. Not sure if xnox figured it out
[22:20] <infinity> stgraber: I vaguely recall him handing it to you and washing his hands of it.
[22:20] <mterry> I'll bug xnox if I see him tomorrow
[22:20] <stgraber> hmm, maybe it's on one of my long bug lists then ;)
[22:21] <stgraber> I vaguely remember it having to something to do with the way /etc/hosts was setup or something to do with the kernel version (as one of the usual suspects in these cases)
[22:21] <infinity> stgraber: There are precise kernels in play on most of these buildds now, so that shouldn't be an issue.
[22:21] <mterry> bye!  gotta run
[22:22] <infinity> stgraber: /etc/hosts could be weird in the chroot, but I thought xnox also tested with the lp chroot tarball.
[22:22] <infinity> Let me grab one.
[22:22] <infinity> stgraber: If it's something you can diagnose and pinpoint as a chroot issue, I can fix it right now.
[22:23] <infinity> Oh, this is curious.
[22:24] <stgraber> hmm, no /etc/hosts in there
[22:24] <infinity> My schroot chroot where the build works *doesn't* have correct ipv6 stuff in /etc/hosts
[22:24] <infinity> In fact, it has a blatant lie of:
[22:24] <infinity> 127.0.0.1       ip6-localhost ip6-loopback
[22:24] <stgraber> ouch, that's horribly wrong
[22:25] <infinity> And the lp buildd chroots have no /etc/hosts at all.
[22:25] <infinity> Which is probably differently wrong.
[22:25] <infinity> Though, neither case should cause problems binding to ::1, since it doesn't require resolution...
[22:26] <stgraber> for lxc containers we're using http://paste.ubuntu.com/1107257/ to setup /etc/hosts and /etc/resolv.conf (based on what netcfg uses)
[22:27] <infinity> Yeah, that's what my base system has.
[22:27] <infinity> And what many of the buildds would also have.
[22:27] <stgraber> yeah, that was the bit I didn't quite get and that's why having a minimal testcase would be awesome (vs running 3 hours build ;)) The only way I can see it going wrong is if the service does reverse + forward lookup for some weird reason
[22:27] <infinity> Well, libnet-dns-perl is certainly minimal.
[22:31] <bryceh> mdz, kees on topic of mesa mre, I've run piglit on three types of hardware (ati, nvidia, intel all with the foss/mesa drivers enabled), both without and with the proposed version, and verified the number of passed tests goes up in all cases.
[22:32] <bryceh> piglit is a combo conformance + regression test suite, so in normal operation not all  tests will pass as they're checking for unimplemented features too
[22:33] <stgraber> infinity: what's the test that's currently failing in libnet-dns-perl?
[22:33] <mdz> bryceh, sounds solid
[22:33] <infinity> stgraber: Hrm, I think mterry's test and fix might be a red herring in this case.  I see nowhere where it's actually doing INET6 in the testsuite.  But testing that inet6 is broken and then skipping the inet4 test sure "fixes" it. ;)
[22:34] <mdz> bryceh, as long as no tests go from green to red
[22:34] <infinity> stgraber: 13-udp-trunc.t is the test that breaks.
[22:35] <bryceh> mdz, kees results at http://people.canonical.com/~bryce/mesa803-piglit/
[22:35] <bryceh> mdz, right there were no new failures found
[22:38] <infinity> stgraber: Ah-ha, but lib/Net/DNS/Nameserver.pm tries to bind to "['::1' , '127.0.0.1' ]" if one doesn't override.
[22:38] <infinity> stgraber: Or, I'm tired and reading the docs, not the source. :P
[22:41] <infinity> stgraber: Yeah, this failure can't be INET6 related, I was right the first time.
[22:47] <bryceh> mdz, kees on the vlc front, I can help bdrung handle regressions.  I looked through the release notes and git history for 2.0.2/2.0.3 and it looks like they're taking care to keep them to sane bug fixes.  I've noticed they also appear active in our bug tracker so that's a good sign.
[22:59] <SpamapS> + mysql_install_db --no-defaults --user=buildd --datadir=/build/buildd/php5-5.4.4/mysql_db --rpm --force
[22:59] <SpamapS> A newer kernel is required to run this binary. (__kernel_cmpxchg64 helper)
[22:59] <SpamapS> �Aborted
[23:00] <SpamapS> some problem w/ mysql on armel?
[23:00] <SpamapS> Kernel version: 2.6.38-1209-omap4 #24-Ubuntu SMP PREEMPT Mon May 14 17:19:07 UTC 2012 armv7l
[23:01] <SpamapS> infinity: ^^ any ideas?
[23:03] <StevenK> Handy
[23:11] <infinity> SpamapS: Yeahp, we need to build it on caph or sigbin.
[23:12] <infinity> SpamapS: (Or, rather, need to "run it" on one of those machines, where it builds doesn't matter, but this tends to upset test suites)
[23:12] <infinity> stgraber: Hahaha.  I've come full circle.  It *is* an INET6 problem.
[23:13] <infinity> stgraber: If this module detects you have the INET6 module installed, it uses the shinier IO::Socket::INET6 instead of IO::Socket::INET, then explodes.
[23:13] <infinity> stgraber: If I force it to v4-only, it's fine.
[23:13] <infinity> stgraber: Which seems suboptimal. ;)
[23:14] <stgraber> infinity: fun ;) why is INET6 exploding?
[23:15] <stgraber> from what I remember of looking at that test, it's trying to bind 0.0.0.0, which with INET6 should be :: and with our default sysctl config, should bind both 0.0.0.0 and ::
[23:15] <ScottK> Speaking of IPv6 ...
[23:15] <infinity> stgraber: So, it's probably reproducible with a perl 2-liner or so of require IO::Socket::INET6; new IO::Socket::INET6 ( LocalAddr => "127.0.0.1", LocalPort => 5443, Proto => UDP );
[23:16] <infinity> stgraber: (Well, reproducible if I can figure out how to get an environment as sad as a buildd, but maybe I'll try)
[23:16] <StevenK> infinity: Remove large swathes of /etc, and then you're done?
[23:17] <ScottK> I noticed today that if I'm talking to a remove host that's down via IPv4, if the host has only an A record, I get connection refused.  If it also has an AAAA record because it's dual IPv4/6 I get connection unreachable (because there's no IPv6 path).
[23:17] <infinity> StevenK: And large chunks of the DC surrounding it.
[23:17] <infinity> ScottK: That seems like a feature.
[23:17] <StevenK> ScottK: network unreachable, rather?
[23:17] <ScottK> It seems suboptimal in this case to give the user the IPv6 error message (unreachable).
[23:17] <ScottK> StevenK: Yes.
[23:18] <ScottK> If the IPv6 network is unreachable, it should give the IPv4 error as that was actually useful.
[23:18] <ScottK> So what do I file a bug against?
[23:18] <StevenK> They are different causes
[23:18] <stgraber> ScottK: and you're getting the network unreachable error without a globally routable ipv6 address on an interface?
[23:19] <ScottK> Yes.
[23:19] <ScottK> It was with SSH.
[23:19] <StevenK> The buildd has a route, and so attemptes to make a connection, and gets stopped, which is ECONNREFUSED. It attempts via IPv6, and has no route at all, so the network is unreachable
[23:20] <ScottK> As soon as I ssh'ed to the IPv4 address directly, I got the connection refused.
[23:20] <ScottK> SSHing to the IPv6 address got the network unreachable.
[23:21] <infinity> ScottK: Oh, it's ssh that's giving you the return you think is unfriendly?
[23:21] <ScottK> The only IPv6 address I have locally is link-local: inet6 addr: fe80::224:d7ff:fea1:e8ec/64 Scope:Link
[23:21] <ScottK> Is it ssh or is ssh just parroting what it got from elsewhere?
[23:22] <infinity> ScottK: Well, those error messages come from elsewhere, but what order it tries to connect in, and what error it chooses to bubble up is entirely up to the client application.
[23:22] <infinity> ScottK: It doesn't say "just open me a random port on some IP identified by this hostname, and let's see how it works out".
[23:23] <ScottK> I think it's fundamentally a misfeature that applications need to care at all if a connection is IPv4 or IPv6, but I know I'm about 20 years late to the party on that one.
[23:24] <ScottK> I guess I'll file it against openssh and see what happens.
[23:24] <infinity> If IPv6 was nothing more than "just more address space", they'd have no reason to care, but when it's also "funky new features", some clients really do want to know.
[23:24] <infinity> (Others really couldn't care less)
[23:25] <ScottK> Unfortunately even ones that shouldn't need to care seem to end up doing so.
[23:27] <ScottK> Ironically, this is the same issue with the libnet-dns-perl test is stuck in.
[23:27] <ScottK> (it seems)
[23:29] <infinity> ScottK: Well, no.  It's falling back to a generic implementation (INET6 can handle both), which then fails because INET6 fails because out inet6 setup is confused somehow.  Or something.
[23:29] <infinity> It's doing what you think it should be doing (being generic), which we'd screwed up somehow. :P
[23:30] <infinity> If it instead did a "is 127.0.0.1 ipv4?" test and called INET functions explicitly, it would be fine.
[23:31] <ScottK> Right, I was thinking the situation, not the root cause.  It was ipv4 connection refused and ipv6 network unreachable.
[23:31] <infinity> ...
[23:31] <infinity> My.
[23:31] <infinity> God.
[23:31] <infinity> I just started a new Firefox window, and for NO REASON I CAN FATHOM, it's in a backwards language.
[23:32] <infinity> And now every new window is stuck in right-to-left squigglies.
[23:32] <infinity> Yay.
[23:39] <stgraber> infinity: is the whole page right-to-left or just the address bar (and maybe some other input boxes)?
[23:40] <RAOF> That's AWESOME!
[23:41]  * slangasek wants his browser windows to launch in boustrophedon
[23:41] <infinity> stgraber: Yeah, it wasn't firefox, it was the start page.
[23:42] <infinity> stgraber: Going to Google and forcing back to English magically fixed the start page too.
[23:42] <infinity> stgraber: And now I'm confused.
[23:42] <infinity> stgraber: But don't care.
[23:45] <ScottK> Sounds like the start of Alzheimer's.