[00:17] <tassadar_> hmm, a bit offtopic, but does "losetup /dev/loop2 image.img" create /dev/loop2 file, or does it have to be there already?
[09:38] <pritesh> hey please tell me, how can i change my kernel on BeagleBoard-XM. it showing me 3-4 kernels in /lib/modules/* and  by uname -r other version.
[09:38] <pritesh> how can i change it. there is no grub in it
[09:40] <siretart> pritesh: have a look at http://processors.wiki.ti.com/index.php/Boot_Sequence to understand how the BeagleBoard-XM boots
[09:41] <pritesh> ok
[09:55] <pritesh> siretart ok i got it, but how can i boot on other kernel Version in u-boot
[10:06] <siretart> pritesh: you need to install to the partition where uboot can reach it. AFAIUI, this needs to be done manually, but I may also be missing something
[12:44] <doomlord> can ubuntu-arm run on the Ouya :)
[12:45] <ogra_> no, but very likely ubuntu touch can
[12:45] <ogra_> well, the ubuntu arm userspace surely can though
[13:56] <kulve> I'm kind of hoping that Ouya can run ubuntu as easily as nexus7 can
[13:57] <kulve> and that ubuntu's normal desktop would suite Ouya's HDMI + usb mouse/keyboard better than what it's on nexus7 with touchscreen
[13:59] <ogra_> it likely will
[13:59] <ogra_> but based on ubuntu-touch first ...
[13:59] <kulve> I've ordered one and hoping to get it in April
[14:00] <ogra_> (once the convergence mode is available you should be able to just run ubuntu/desktop)
[14:00] <kulve> well, I'm going to take the nexus7 rootfs and modify it to Ouya
[14:00]  * ogra_ hasnt yet ... still pondering
[14:00] <kulve> I don't like that "running ubuntu on top of android" approach. Even though in some cases it's handy
[14:01] <kulve> bbl
[16:21] <doomlord> ubuntu-arm desktop on ouya would be awesome i think
[16:22] <ogra_> would need drivers etc
[16:36] <ogra_> whats the ouya using ? tegra4 ?
[16:37] <tassadar_> tegra 3
[16:37] <tassadar_> and 1gb of ram
[16:37] <ogra_> ah, that should be a no brainer indeed
[16:37] <tassadar_> pretty much nexus 7
[16:37] <ogra_> i thought i saw them raving about tegra4
[16:38] <tassadar_> I think they wouldn't fit into $99 with tegra4
[16:38] <ogra_> though afaik nvidia doesnt have a single manufacturer using it yet
[16:40] <tassadar_> hah, each of the 4 buttons on the controller is labeled with one of the letters from word ouya
[16:40] <tassadar_> that's cute)
[16:40] <ogra_> until microsoft sues them because thats patented :P
[16:41] <ogra_> "four buttons on a controller arrranged in the shape of a cross labelled with letters"
[16:42] <ogra_> (as opposed to snys patent: "four buttons on a controller arrranged in the shape of a cross labelled with things that look like letters but arent")
[16:42] <ogra_> *g*
[16:42] <ogra_> *sonys
[16:43] <tassadar_> well, the arrangement is exactly the same as on xbox controller
[16:43] <ogra_> yeah, thats what i was referring to ...
[16:44] <ogra_> americans allow such weird patents
[16:44] <tassadar_> no, I mean the little joysticks
[16:44] <ogra_> ah
[16:44] <tassadar_> nvidia at least switched those on their shield-thingy)
[17:03] <doomlord> wouldn't nintendo hold that patent...
[20:56] <angs> is there any instruction that explains how to compile a kernel for beagleboard (omap3) that I can follow?


[06:09] <hikiko> hi
[06:29] <duflu> Morning hikiko
[06:29] <duflu> Afternoon for others
[06:29] <duflu> Autumn for some :)
[08:52] <b4n> hi!
[08:52] <b4n> andyrock: re. a11y shortcuts:
[08:53] <b4n> if using XI2 "normally" doesn't really work, would we have another, possibly transitional, solution?
[08:54] <b4n> a separate plugin providing shortcuts handling for a11y tools, based off AT-SPI (meh, the API doesn't look good), or XI2 (maybe in another process)?
[08:54] <b4n> or maybe allow Actions to be triggered remotely through a socket/DBus/whataver API, so a separate app could take care of the event handling and control Compiz?
[08:55] <b4n> for specific things obviously
[08:56] <b4n> I kinda like the idea of remote control, but it might raise a question on how to avoid bad interaction between Compiz's normal handling and remote commands if they happen roughly at the same time.  But it cuold ismply not be handled specially and the setup should make sure not to trigger the same thing that compiz already does
[08:59] <davmor2> Morning all
[09:02] <Laney> parump pump pump
[09:05] <willcooke> morning all
[09:07] <seb128> hey willcooke Laney davmor2
[09:07] <seb128> how is u.k today?
[09:07] <seb128> enjoyed the pancakes?
[09:07] <davmor2> seb128: still full of pancake
[09:07] <andyrock> b4n, that could work but hard to implment
[09:07] <andyrock> *implement
[09:07] <seb128> hey andyrock
[09:07] <andyrock> and hey all
[09:07] <andyrock> :D
[09:07] <b4n> hey andyrock
[09:08] <b4n> andyrock: do you have any acceptable idea that would work and be reasonable to implement?
[09:08]  * willcooke checks the time
[09:08]  * willcooke . . o O (Hmm. Before noon)
[09:09] <willcooke> Hey andyrock :DD
[09:09] <seb128> willcooke, it's tea time!
[09:09] <willcooke> seb128, \o/
[09:09] <seb128> but that's not saying a lot for you right?
[09:09] <willcooke> lol
[09:09] <seb128> it's always tea time in the u.k
[09:09] <seb128> :-)
[09:09] <seb128> but yeah, what's up with italians being awake in the morning?!
[09:09] <seb128> next Trevinho is going to say hello?
[09:10] <andyrock> ahahaahah
[09:10] <seb128> :-)
[09:11] <andyrock> b4n: I would suggest you to understand why xi2 with CompScreen::dpy() does not work
[09:12] <b4n> andyrock: hum, okay.  i'm afraid i'll have to learn a lot about all that before I can start to understand anything, but well ^^
[09:12] <Trevinho> hi seb128 :-D
[09:12] <seb128> see! what's going on here?!
[09:12] <seb128> hey Trevinho :-)
[09:12] <willcooke> WHHAAAAAAAAA
[09:13] <Trevinho> ahah..
[09:13] <b4n> andyrock: but then, it's theoretically possible to get both X and XI2 events together in the same loop without conflicts?
[09:13] <andyrock> yep
[09:13] <Trevinho> It's just that we're not morning speakers :_D
[09:13] <andyrock> i still need to get my coffee
[09:14] <davmor2> seb128: no tea time is afternoon/evening not morning, Morning is Elevensies
[09:14] <davmor2> willcooke: Elevensies time :D
[09:14] <b4n> andyrock: okay.  I'll try and look into that, but no promises given my current X event expertise ^^
[09:14] <willcooke> davmor2, I'm still washing down the Marmite
[09:15] <davmor2> willcooke: oh you're one of those are you ;)
[09:15] <Trevinho> Laney: about that unity7.service, you want also uss in wants?
[09:15] <willcooke> davmor2, is this the start of a civil war?
[09:15] <Trevinho> Laney: I mean, I thought it not being there causing more serious problems, but... well, at leas something is there
[09:16] <willcooke> davmor2, look at the state of this:  http://imgur.com/a/klgo9
[09:16] <Trevinho> probably the one that is making unity the less usable is anyway BAMF
[09:16] <Laney> hey seb128 willcooke andyrock davmor2 Trevinho
[09:16] <Trevinho> willcooke: Oh... I want the store to sell them again!!!
[09:16] <Laney> Trevinho: It's alright if it crashes and restarts isn't it?
[09:16] <willcooke> Trevinho, yeah! The only sell the grey ones now :(((((
[09:16] <Laney> better than crashing the session anyway
[09:16] <Laney> or?
[09:16] <Trevinho> willcooke: Mine is still in pretty good state (lovely washed with hands for years)...
[09:17] <Trevinho> but I'm always worried that someone could break it
[09:17] <willcooke> Trevinho, wise!  I chuck mine in the dishwasher every day :)  Plus my wife broke my grey one :/
[09:20] <Trevinho> willcooke: oh, I didn't want to be her in that moment :-D
[09:21] <Trevinho> Laney: well, no it's not better... I loved the idea that unity didn't start if these prereq were not there
[09:21] <Trevinho> so that we couldn't give a broken state
[09:21] <Trevinho> but, it seems we can't have both cases (i.e. if a component then crashes, the everything follows)
[09:22] <Trevinho> Damn, I knew I should have gone to ski this morning... http://imgur.com/a/rHgPF :|
[09:22] <davmor2> willcooke: https://drive.google.com/file/d/1AoE68cz63OUescCRiR9W4QG4I9aORLVrig/view?usp=sharing My mug is more evil than yours :D
[09:23] <willcooke> LD
[09:23] <willcooke> :D
[09:23] <Laney> Trevinho: Not better?
[09:23] <Laney> Right, well, if you think that crashing the session is better then Requires is what you want...
[09:24] <Trevinho> Laney: it's not better... it was a trade off.... I wanted to make start unity7 to ensure it starts all the rest, but that leads us to this situation, where something crashing, causes the world to explode
[09:24] <Trevinho> so.... I agree it's just better to move everything
[09:24] <Laney> mmm
[09:24] <Laney> maybe there's some way to achieve that
[09:25] <Laney> but then you get: ups has a crash bug on startup -> can't start the session
[09:26] <Trevinho> Laney: which, for ups is also.. okeish... you're just going to miss indicators, but bamf or uss, it would just bring something that you can't work with
[09:27] <Trevinho> Laney: anwyay, I've pushed the wants-only version, so if you're fine with that. please give your coin
[09:27] <Laney> mmmmmmmmmmmmmmmmmmmm
[09:27] <Laney> usd is probably different, you're right
[09:27] <Laney> it's not really a working session without that
[09:27] <Laney> but I don't know how to achieve this
[09:28] <Laney> unless we give it an OnFailure= that does something nice maybe
[09:28] <Laney> something to think about
[09:28] <Laney> thanks for pushing! can you give me the link again please?
[09:28] <Trevinho> Laney: I instead wanted to make the session to crash when unity in locked state and unity crashes
[09:29] <Trevinho> Laney: https://code.launchpad.net/~3v1n0/unity/unity7-wants-ups
[09:29] <Laney> that would be good too
[09:31] <Laney> maybe something with BindsTo and the target could help there
[09:31] <Laney> not sure atm
[09:32] <Laney> Trevinho: should be RequiredBy=ubuntu-session.target, no?
[09:32] <Laney> the session itself isn't valid without unity7, but unity7 is (arguably) valid without those other things
[09:33]  * Laney approved, feel free to fix that as you like
[09:33] <Trevinho> Laney: yeah, we discussed with pitti too... the idea was to define a unity-locked target and that would cause to change the relationship with th esession
[11:08] <Laney> Trevinho: If you didn't get far on the zeitgeist diff, I can do it quickly
[11:08]  * Laney wants to upload this
[11:34] <Trevinho> Laney: I can do it after lunch...
[11:35] <Laney> nah, don't worry about it
[11:35] <Trevinho> Laney: as you prefer... you also move to 1.0?
[11:35] <Laney> yeah
[11:35] <Trevinho> good
[11:35] <Laney> I take the other diff and apply your fix
[11:35] <Trevinho> Laney: jbicha one?
[11:36] <Laney> yeah
[11:36] <Trevinho> good...
[11:36] <Laney> wonder what work they're having done next door
[11:36] <Laney> lot of banging
[12:05] <davmor2> Laney: You're assuming it is work, they might just enjoy annoying you with banging
[12:06]  * Laney sniggers
[12:16] <Laney> fnrrrrr
[15:42] <Trevinho> Laney: nice work with that
[15:43] <Trevinho> (not speaking of your neighbours :-D, but of zeitgeist)
[15:43] <Laney> heh
[15:43]  * Laney hugs Trevinho
[15:43] <Laney> thanks for the debate
[15:43] <Laney> :P
[15:44] <Trevinho> Laney: you should get involved in Politics too :-D
[15:45] <Laney> heheh
[15:45] <Laney> close enough to that with bike stuff sometimes
[15:46] <Laney> anyway it was hard to test the iso in a clean state
[15:46] <Laney> but i think it worked, will know for sure tomorrow
[15:50] <seb128> bah, "issue of the day" today, can't switch between sessions without getting my gpu locked/graphical corruption or my user session being closed for some $reason :-/
[15:50] <seb128> it's not specific to today, just happened to try to test a bug on the greeter
[15:51] <seb128> intel support of that old gen quite regressed over years :-(
[15:52] <Laney> :(
[16:13] <b4n> andyrock: do you have an embryonic patch that adds the non-working XI2?  It would probably save me some initial research
[16:20] <Trevinho> seb128: now that libappindicator3-1 SRU is in xenial, you can use that as stage-package in the gnomeruntime...
[16:42] <seb128> Trevinho, great, thanks!
[16:43] <Trevinho> seb128: still using the remote part will save you to use "prime:" to clean the unneeded files though ;-)
[16:44] <seb128> Trevinho, you are quite insistant on that :p
[16:44] <seb128> Trevinho, convince Didier, he's the one maintaining the helper
[16:45] <seb128> oh, that would be in the runtime
[16:45] <Trevinho> seb128: ahah, well, he was fine for the helper actually (and two PRs got merged, and then reverted because of troubles)... But snapcraft has some issues with remote of remotes... not for the runtime though
[16:47] <seb128> k
[16:47] <seb128> well I still think we should bundle too much, we can revisit if there is user demand or if we see it's creating issue
[16:47] <seb128> but there was no sign of that so far
[17:04] <jbicha> qengho: is there a particular reason why Ubuntu's Chromium sets use_gconf=true instead of false like Debian?
[18:20] <Laney> night!
[18:24] <willcooke> night laney
[18:24] <willcooke> and night from me o/
[18:26] <seb128> night Laney
[18:26] <seb128> & desktop
[18:26] <seb128> see you tomorrow!
[18:37] <qengho> jbicha: as I recall, it's to get access to display-density information in settings.
[18:40] <jbicha> qengho: do you want me to file a bug? I'd like to not have gconf installed on my computer any more


[00:15] <kim0> niemeyer: notes applied .. thanks
[00:47] <niemeyer> kim0: np!
[00:48] <kim0> I hope I can read up more on bitcoin this weekend :)
[01:58] <_mup_> ensemble/expose-open-ports-node r232 committed by<EMAIL_ADDRESS>[01:58] <_mup_> Addressed review comments
[02:02] <_mup_> ensemble/expose-open-ports-node r233 committed by<EMAIL_ADDRESS>[02:02] <_mup_> Use immutable tuple instead of list
[02:17] <_mup_> ensemble/trunk r228 committed by<EMAIL_ADDRESS>[02:17] <_mup_> merged expose-open-ports-node [r=niemeyer][f=785352]
[02:17] <_mup_> Implements support for managing the open ports for a service unit.
[03:09] <_mup_> ensemble/expose-machine-service-units r232 committed by<EMAIL_ADDRESS>[03:09] <_mup_> Use topology to retrieve service name, unit sequence instead of private method
[03:17] <_mup_> ensemble/expose-machine-service-units r233 committed by<EMAIL_ADDRESS>[03:17] <_mup_> Reworked naming and add helper method (add_service) to avoid having to split lines in tests
[04:09] <_mup_> ensemble/expose-service-watch r231 committed by<EMAIL_ADDRESS>[04:09] <_mup_> Addressed review points
[04:27] <_mup_> ensemble/expose-service-watch r232 committed by<EMAIL_ADDRESS>[04:27] <_mup_> Removed inadvertent fix for watch_exposed_flag


[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 <IP_ADDRESS>
[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<EMAIL_ADDRESS>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> <IP_ADDRESS>       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' , '<IP_ADDRESS>' ]" 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 <IP_ADDRESS>, which with INET6 should be :: and with our default sysctl config, should bind both <IP_ADDRESS> 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 => "<IP_ADDRESS>", 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.   :P
[23:30] <infinity> If it instead did a "is <IP_ADDRESS> 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.


[11:03] <psivaa> infinity: cjwatson: curious if we could re-enable daily precise iso's ?
[11:47] <cjwatson> psivaa: I guess that's reasonable.  Done
[11:48] <psivaa> cjwatson: ack, thanks :)
[11:59] <ScottK> Queue bot doesn't seem to show trusty SRUs.
[12:08] <cjwatson> ScottK: Probably because it's not here
[12:09] <cjwatson> stgraber: queuebot needs to be resurrected
[12:10] <ScottK> That'd do it.
[13:30] <stgraber> cjwatson: done
[13:31] <cjwatson> thanks
[14:00] <ypwong> could someone from SRU team kindly please take a look at bug 1314471?
[16:20] <doko> jibel, pitti: please restart the python-numpy autopkg test (sorry, didn't setup my vpn yet)
[16:22] <pitti> doko: already done
[16:23] <pitti> the dreaded "hash sum mismatch" again
[16:23] <pitti> darn, python3.4 amd64 still failed
[16:24] <pitti> FAIL: test_no_args_respects_force_flag (test.test_compileall.CommandLineTests)
[16:24] <pitti> AssertionError: Process return code is 1, stderr follows:
[16:24] <pitti> (nothing)
[16:24] <pitti> doko: that was one of the tests you reenabled, right?
[17:31] <slangasek> bdmurray: sru-review seems unwilling to accept libreoffice from the precise-proposed queue... I don't want to have to accept through the web ui and write bug comments by hand.  any suggestions?
[17:32] <bdmurray> slangasek: it's acceptable? if so I'll give it a try
[17:32] <bdmurray> slangasek: and what revision are you on?
[17:32] <slangasek> bdmurray: oh, this time it went through
[17:32] <slangasek> so n/m :)
[17:33] <slangasek> I tried twice before and LP was sassing me
[17:33] <bdmurray> I've been seeing more lp timeouts recently
[18:17] <xnox> how ofter are Contents-arch.gz files updated? amd64 appears to be last modified on 29th of april and i386 on 3rd of May
[18:18] <cjwatson> Daily, but the update process is buggy and sometimes races with the now-much-more-frequent publisher.
[18:18] <cjwatson> It looks as though nowadays it loses the race more often than not.
[18:18] <infinity> Definitely could use some TLC.
[18:21] <cjwatson> Basically the problem is that it installs the updated Contents files in the normal dists/ directory, but the publisher rsyncs dists to a working location at the start of its work and moves it into place at the end.
[18:21] <infinity> We could attempt to copy to dists.in-progress, and then fall back to dists.
[18:21] <cjwatson> Perhaps one option would be for generate-contents-files not to try to install the updated files at all, but for the publisher to check a known (and atomically-updated) location for updates that it should copy in.
[18:22] <infinity> Or that.
[18:22] <apw> that sounds much saner
[18:22] <cjwatson> I did think of your option but I think I prefer mine.
[18:22] <apw> let the publisher, like, publish it :)
[18:22] <infinity> Yeah, I prefer yours too.
[18:22] <infinity> I'd prefer even more if contents generation could actually happen from the main a-f run, but...
[18:23] <cjwatson> But I'm maxed out on LP work right now.  Hey, xnox, you seemed to want to do a bit of LP stuff ... :-)
[18:23]  * xnox slowly backs away =)))))))))
[18:23] <infinity> This barely qualifies as LP work.
[18:24] <infinity> Your solution could be sorted with a tiny LP patch and a new publisher-parts snippet.
[18:24] <xnox> infinity: well i've never run soyuz portion of the launchpad dev environment.
[18:24]  * infinity goes poking at the former.
[18:24] <cjwatson> I'd prefer it to be in LP since generate-contents-files is
[18:24] <cjwatson> All in LP proper I mean
[18:24] <cjwatson> And then it could be unit-tested fairly easily
[18:25] <infinity> Sure, so tack the contents copy on right before the dists move.
[18:25] <cjwatson> xnox: You don't need to set up the whole publisher for this (and IMO doing so would be a waste of time); the relevant bits are amenable to unit-testing.
[19:37] <stokachu> cjwatson: if you have a few seconds would you mind looking over bug 1311274
[19:37] <stokachu> its basically the same thing you did for me in london but for the cloud seed
[19:41] <cjwatson> stokachu: I'm fine with it and have approved the MP, but don't have time to do more than that at the moment
[19:41] <stokachu> cjwatson: no worries just needed a nod, thanks :)
[19:42] <cjwatson> python-six isn't a particular problem, says the maintainer ;-)
[19:42] <cjwatson> Though this is actually python3-six, right?
[19:42] <stokachu> cjwatson: yea
[20:33] <doko> pitti, yes, applied your work-around
[23:07] <rsalveti> slangasek: ^ in case you got some time to help reviewing and accepting them
[23:08] <rsalveti> after them get accepted I just need to update the meta package
[23:11] <rsalveti> will get some food, bbl
[23:15] <slangasek> rsalveti: why does qtbase-opensource-src-gles build-depend on the libs from the non-gles build?
[23:16] <rsalveti> slangasek: otherwise some of the libraries will fail when linking
[23:17] <rsalveti> we're not duplicating every package
[23:17] <slangasek> but a build-dep on libqt5gui5?  Surely it should use the internal copy that it's building
[23:17] <rsalveti> indeed, that one might not be needed, let me remove that and check


[06:52] <amitk> apw: smb: can you remind me again how we deal with ABIs? Why Ubuntu-3.5.0-21.32 is actually a 3.5.7 kernel?
[08:04] <ppisati> moin
[08:16] <smb> ppisati, moin moin
[08:17] <smb> amitk, Not exactly related to ABI :) That is the -21. in the version
[08:18] <smb> We never reflected the upstream stable number in our version. So that remains always 0
[08:45] <amitk> smb: That is where I was confused. I was thinking of the -21 as the ABI, but I couldn't remember where the .0 came from
[08:46] <amitk> smb: so we never change the .0, correct?
[08:46] <smb> amitk, Right
[08:46] <amitk> smb: thanks
[08:47] <smb> amitk, I think that is actually consistent with the orig.tar we use. Which is always the upstream release tarball (except for the accidental version in Hardy which luckily will go away soon)
[08:50] <amitk> smb: ok, makes sense when thinking of it in relation to the upstream release tarball and diffs
[09:37] <apw> we would have liked to make it 3.8-21 style, but userspace very commonly looks at the kerel version string and asumes it can pull 3*int off the front of it, bad userspace
[09:37] <amitk> apw: ack, that discussion is coming back to me now...
[10:30] <caribou> smb: did you notice that the SRU request for the latest crash version got turned down ?
[10:30] <caribou> smb: https://bugs.launchpad.net/bugs/1064475
[10:30] <ubot2> Launchpad bug 1064475 in crash (Ubuntu Quantal) "crash version is outdated. Needs to import Debian version of the package" [Medium,In progress]
[10:31] <smb> caribou, Yes, I saw it yesterday and was just reading through it again right now and thinking about a response
[10:32] <caribou> smb: ok, just wanted to be sure you were aware of it
[10:32] <smb> caribou, Yeah, thanks. I am. :)
[12:52] <ogra_> rtg, gah, seems the config change wasnt enough ... ureadahead still cant find /sys/kernel/debug/tracing/events/fs/do_sys_open (and in fact it isnt there)
[12:53] <rtg> ogra_, hmm, lemme check into it.
[12:53] <ogra_> i thought that option would be enough
[12:55] <ogra_> do we carry any ureadahead specific patch in our main kernel the nexus one could be missing ?
[12:57] <rtg> ogra_, I don't think so, but I need to check that all the required options are enabled in the N7 kernel. First I have to research what they are :)
[12:57] <ogra_> heh
[12:57] <ogra_> k
[12:57] <ogra_> i'll go on digging here as well
[13:08] <rtg> apw, do you recall what is required for ureadahead ? AFAICT its just CONFIG_DEBUG_FS=y and CONFIG_FTRACE=y
[13:10] <ogra_> ENABLE_DEFAULT_TRACERS ?
[13:12] <apw> rtg, i think so, we might be carrying a patch for a tracepoint
[13:12] <ogra_> (intrestingly not available on my precise x86 )
[13:13] <rtg> apw, I was just trying to find if we are carrying a ureadahead patch. if so, its not got ureadahead in the description.
[13:14] <rtg> apw, likely it was just a tracepoint, right ?
[13:14] <apw> it was a tracepoint, and i think it was going upstream
[13:14] <apw>     UBUNTU: SAUCE: trace: add trace events for open(), exec() and uselib()
[13:14] <apw>     UBUNTU: SAUCE: (no-up) trace: add trace events for open(), exec() and uselib
[13:14] <rtg> apw, is that raring ?
[13:15] <apw> (lucid, precise)
[13:15] <apw>     UBUNTU: SAUCE: (no-up) trace: add trace events for open(), exec() and uselib
[13:15] <apw> quantal
[13:15] <rtg> ok, then the N7 kernel would need it
[13:15] <apw> same in raring
[13:15] <apw> so there it is
[13:16] <apw> from the description i suspect that upstart should be being fixed to no longer need it
[13:16] <rtg> ogra_, ok, looks like the N7 kernel needs another patch,
[13:16] <apw> assuming the "syscall trace events whenever that gets merged"
[13:16] <apw> comment is accurate
[13:16] <ogra_> yeah
[13:17] <apw> jodh, hey ... do you look after ureadahead now ?
[13:19] <apw> rtg, might be steve actually
[13:20] <rtg> apw, well, I'm pretty sure that patch is needed for N7 regardless.
[13:20] <apw> rtg, yep i would say so indeed
[13:20] <ogra_> ...
[13:20] <ogra_> openat(3, "events/fs/do_sys_open/enable", O_RDWR|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[13:20] <ogra_> ...
[13:21] <ogra_> whatever gets me that file in sysfs will do ;)
[13:21] <rtg> ogra_, if memory serves, ureadahead did its own mounting internally in the program.
[13:21] <ogra_> ah
[13:21] <apw> yeah cause it is very very early
[13:22] <apw> but those may only exist if the trace points exist
[13:22] <apw> which brings us back to the patch
[13:22] <ogra_> so it mounts the whole fs subdir ?
[13:22] <ogra_> (since all of that is missing here)
[13:22] <apw> well i think it mounts sysfs doesn't it?
[13:22] <rtg> it mounts the debugfs file system
[13:23] <ogra_> k
[13:23] <apw> debugfs, what he said
[13:23] <apw> but i suspect the hierachy is made by declaring the tracepoints
[13:24] <rtg> ogra_, I have an N7 I can test on before I upload again.
[13:24] <ogra_> ok
[13:24] <ogra_> you need to drop quiet and splash to see the ureadahead error
[13:24] <ogra_> though a manual trace from userspace should help as well for testing
[13:25] <apw> rtg, ogra_, yeah the trace point name match the only ones in fs on my system
[13:25] <rtg> ogra_, it'll take me a bit since mine is still on Quantal.
[13:25] <ogra_> great !
[13:25] <ogra_> rtg, well, i'm up to date, probably uploading it somewhere and me pulling it is faster
[13:26] <rtg> ogra_, ok, gimme a bit.
[13:26] <ogra_> no hurry :)
[13:26] <apw> rtg, by the looks of it this generic framework for syscalls may have made it in
[13:26] <apw> see /sys/kernel/debug/tracing/events/syscalls#
[13:27] <apw> we probabally could switch to that and drop the patches
[13:27] <rtg> apw, perhaps stick that on a blueprint as a work item so we don't forget ?
[13:27] <apw> ack
[13:28] <apw> done
[13:34] <ogra_> rtg, while you're at it, i only ran into the ureadahead issue because i was trying to get plymouth working ... it seemingly has an issue somewhere between fbcon and font handling (running console-setup before plymouth kiks in fixes it apparently) ... comparing the kernel configs, i see 8x8 enabled on x86 while only 8x16 is enabled on the nexus, could you also add 8x8 (in the hope that magically fixes plymouth)
[13:37] <rtg> ogra_, um, which config option is that exactly ?
[13:37] <ogra_> oh ...
[13:37] <ogra_> the option would be CONFIG_FONT_8x8=y
[13:37] <ogra_> but i just see there is another difference
[13:37] <rtg> ah, font. I was looking for FB_*
[13:38] <ogra_> ogra@nexus7:~$ grep FONT /boot/config-3.1.10-8-nexus7
[13:38] <ogra_> CONFIG_FONTS=y
[13:38] <ogra_> gra@anubis:~/Desktop/nexus/kerneltree/nexus7$ grep FONT /boot/config-3.2.0-35-generic
[13:38] <ogra_> # CONFIG_FONTS is not set
[13:38] <ogra_> thats intresting
[13:38] <rtg> ogra_, I have CONFIG_FONTS=y, CONFIG_FONT_8x16=y
[13:39] <ogra_> yep, same here
[13:39] <ogra_> but x86 has:
[13:39] <ogra_> # CONFIG_FONTS is not set
[13:39] <ogra_> CONFIG_FONT_8x8=y
[13:39] <ogra_> CONFIG_FONT_8x16=y
[13:39] <ogra_> i dont really get how CONFIG_FONTS can be unset but the single fonts are still available
[13:40] <rtg> ogra_, I don't know what that option does. lemme read up on it
[13:40] <rtg> ogra_, Say Y here if you would like to use fonts other than the default
[13:40] <rtg>           your frame buffer console usually use.
[13:41] <ogra_> yeah, reading that too here
[13:41] <rtg> so 8X8 and 8X16 would be the defaults
[13:41] <ogra_> ah, k
[13:41] <rtg> or 8X16 at least. 8X8 isn't enabled on the N7
[13:41] <ogra_>  yeah, if i enable it they are preselected
[13:41] <ogra_> 8x8 isnt enabled because it was explicitly disabled then
[13:42] <ogra_> i dont see any reason why
[13:42] <rtg> probably
[13:42] <rtg> ogra_, do you think its impacting plymouth ?
[13:43] <ogra_> not sure, plymouth hardlocks if i dont cann console-setup first ... or at least setfont
[13:43] <ogra_> very hard to debug since i cant get any crash info, but setting the fonts in userspace seems to work
[13:44] <ogra_> s/cann/run/
[13:44] <ogra_> weird typo ...
[13:44] <apw> henrix, remind me, when i do a derivative with tracking bug, what do i change when i have uploaded it, i did it all wrong last time
[13:45] <rtg> well, I can turn on 8X8....
[13:45] <ogra_> in any case setting CONFIG_FONTS and not having 8x8 and 8x16 is a difference to our x86 kernel
[13:45] <rtg> I'll make them hogeneous
[13:45] <ogra_> thx
[13:45] <ogra_> i'll see if that helps ... else i still need to do additional userspace hackery
[13:46] <ogra_> it at least roules out one potential issue
[13:46] <ogra_> -o
[13:46] <apw> henrix, my reading of the wiki is i should just make the prepare-*'s in_progress and then upload them
[13:46] <henrix> apw: not sure i understand you're question, but usually you need to set the prepare-package-* tasks to 'in progress'
[13:47] <henrix> apw: correct
[13:47] <apw> and will shankbot handle the world from there
[13:47] <henrix> apw: yep, the bot will monitor the progress
[13:47] <apw> ok great
[13:47] <henrix> apw: once the builds are ready, it will set the prepare tasks to 'fix released' and will set the 'promote-to-proposed' to 'in progress'
[13:48] <apw> ok great
[13:54] <henrix> apw: oh! i guess you we're talking about the lowlatency kernel... in this case, i believe the process is slightly different because you have the 'upload-to-ppa' task
[13:55] <henrix> apw: in this case you'll need to set the prepare-package-* tasks manually to 'fix released' and the 'upload-to-ppa' to 'in progress'
[13:55] <henrix> apw: and then the bot will take over.  it will set the 'upload-to-ppa' to 'fix released' once the packages are built
[13:58] <apw> henrix, ok
[13:59] <apw> yep presumably that is so 'they' can make the package, and 'we' can shove them in the PPA
[14:00] <henrix> apw: although i guess that 'they' and 'we' is actually the same person :)
[14:00] <apw> well no in this case it won't be eventually, this cycle they made the git bit and i am spinning from there
[14:00] <apw> next time they will make the packages, i hope
[14:01] <henrix> cool
[14:03] <herton> apw, henrix, note that you set only prepare-package to 'fix released', and upload-to-ppa to 'in progress', prepare-package-meta can be left to 'in progress' and the bot will take care of it
[14:03] <herton> it's confusing right now, I have plans to change that, on my todo
[14:03] <herton> as well as it make "smarter", so if the bug has not the correct states it can try to fix itself
[14:04] <herton> or prepare-package-meta to 'invalid', if there was no abi bump
[14:15] <apw> herton, that is a mind-bending semantic indeed
[14:29] <rtg> ogra_, http://kernel.ubuntu.com/~rtg/Ubuntu-3.1.10-8.21.1
[14:30] <rtg> it has the font changes as well as the trace point patch for ureadahead
[14:30]  * ogra_ downloads
[14:30]  * rtg -> biab
[14:41] <apw> herton, one for your long-term-todo list for shankbot ... change the title from <to be filled> to a valid version once the packages appear
[14:45] <apw> herton, and did you as you change the lowlatency task, or you as shankbot
[14:45] <ogra_> rtg, ureadahead works fine, thanks a lot !
[14:45] <herton> apw, noted, should be possible to do it. No, I just changed it, that should be in progress
[14:45] <ogra_> the font changes at least didnt cause any regression, havent tested more yet
[14:45] <rtg> ogra_, excellent.
[14:46] <rtg> I'll upload this version then
[14:46] <apw> herton, i suspect shankbot could fix those too
[14:46] <herton> apw, yep, I plan to make it able to fix these
[14:47] <apw> it is quite opaque even with the wiki, i am bound to get this wrong time and time again :)
[14:47] <apw> herton, and ... that is lowlatency in the pipe for Q and R
[14:56] <ppisati> apw: UBUNTU: [Config] highbank -- disable DTB install" -- why?
[14:57] <ogra_> to confuse you :)
[14:57] <ppisati> indeed
[14:57] <apw> ppisati, we don't make a highbank kernel anyhow and that bit stopped working
[14:57] <apw> so i wacked it on the head
[14:57] <ppisati> ah ok
[14:57] <apw> bitrot setting in, we won't be able to get it back for much longer
[15:45]  * ogasawara back in 20
[15:52] <jsalisbury> **
[15:52] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:52] <jsalisbury> **
[16:55] <ogasawara> bjf: http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-r-tracking-bug-tasks.html
[17:01] <jsalisbury> ##
[17:01] <jsalisbury> ## Meeting starting now
[17:01] <jsalisbury> ##
[17:25] <philwyett> Can Toshiba laptop owners have some love and have bug 1048631 looked at and the patch in 3.8 put in raring and precise. Thanks :-)
[17:25] <ubot2> Launchpad bug 1048631 in linux (Ubuntu) "If electrical cable is plugged in then Toshiba Satellite C855-10M reboots instead of shoutdown " [Medium,Confirmed] https://launchpad.net/bugs/1048631
[17:49] <jwi> philwyett: if there's a patch upstream that fixes the bug, you probably want a kernel SRU. see https://wiki.ubuntu.com/StableReleaseUpdates#Kernel
[17:49] <philwyett> jwi: Ok, will look. Thanks
[18:21] <apw> philwyett, if you add the sha1 of the patch you think fixes it, then we can spin you test kernel with it on to confirm, and go from there
[18:21] <apw> jsalisbury, ^^
[18:22] <jsalisbury> apw, ack.  philwyett I'll update the bug and spin up a test kernel.
[18:23] <apw> henrix, did i just hear we are respinning some of the kernels ?
[18:23] <henrix> apw: yep, we need to respin P and Q
[18:23] <apw> balls
[18:24] <henrix> right, you need to respin lowlatency as well... :-/
[18:24] <bjf> apw, why?
[18:24] <bjf> oh
[18:24] <apw> bjf, cause i just got them to spin lowlatency, and reviewed and sponsored them
[18:24] <philwyett> apw, jsalisbury: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1048631/comments/48
[18:24] <ubot2> Launchpad bug 1048631 in linux (Ubuntu) "If AC electrical cable is plugged in then certain model Toshiba laptops reboot instead of shutdown" [Medium,Confirmed]
[18:25] <bjf> apw, well, the good news is that we are skipping the next cycle
[18:25] <bjf> apw, we are just going to make this one really, really painful :-P
[18:25] <apw> heh
[18:26] <henrix> apw: its a pita to sync with everyone prep'ing kernels: stable team, lowlatency (you), armadaxp (ike), ...
[18:26] <jsalisbury> philwyett, thats great.  so this should be automatically fixed in Raring when we rebase to v3.8.  I'll look and see if it will be queued for upstream stable and see how easy a backport would be.
[18:26] <henrix> apw: ah, and the testing team, as they may start testing ahead
[18:26] <apw> yeah, i wonder if we are asking too early to prep them, hmmm
[18:27] <jsalisbury> philwyett, can you test v3.8-rc2 to confirm the bug is fixed: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc2-raring/
[18:27] <jsalisbury> philwyett, if it is, please update the bug.
[18:27] <jsalisbury> philwyett, we can then look at getting in into stable releases
[18:27] <apw> jsalisbury, thanks
[18:27] <philwyett> jsalisbury: Thanks will do and adjust bug as necessary.
[18:28] <jsalisbury> philwyett, great, thanks!
[18:28] <jsalisbury> apw, anytime ;-)
[18:32]  * rtg -> lunch
[18:56] <bjf> rtg, i did get raring and the 3.8 rc2 kernel installed on my intel box. nouveau is working just fine right now.
[18:57] <bjf> rtg, i'll be able to do more testing when the dkms pkg is ready
[18:59] <rtg> bjf, tseliot says it won't be ready until tomorrow
[18:59] <bjf> rtg, that's ok with me
[19:04] <philwyett> jsalisbury: Updated bug report. 3.8.0-rc2 mainline worked fine. Laptop shutdown correctly.
[19:23] <jsalisbury> philwyett, great.  I'll see if it's already been submitted for stable and update the bug.
[19:23] <philwyett> jsalisbury: Superb.  Many thanks.
[19:24] <jsalisbury> philwyett, np.  thanks for testing.  I may have a stable kernel for you to test if that's ok.  I'll update the bug if it's needed.
[19:25] <philwyett> jsalisbury: That's fine. Anythinng to help.
[19:26] <jsalisbury> philwyett, thanks
[19:28] <bjf> rtg, 3.8-rc8 kernel works fine on macbook-air
[19:28] <rtg> bjf, cool
[19:29] <rtg> bjf, its actually -rc2
[19:29] <bjf> finger-bug
[19:35] <jsalisbury> philwyett, it looks like commit b7e3830 wasn't cc'd to stable.  The commit applied cleanly to Precise.  I'll build a Precise test kernel and post a link to it in the bug.  If all goes well I'll send a request upstream for inclusion in 3.2.
[19:38] <philwyett> jsalisbury: Will you also build the lts-quantal kernel? I can test 3.2 of course but I use the lts-quanttal kernel due too bug 1088829
[19:38] <ubot2> Launchpad bug 1088829 in linux (Ubuntu) "USB devices not detected in USB 3.0 ports" [Medium,Incomplete] https://launchpad.net/bugs/1088829
[19:39] <jsalisbury> philwyett, I can also build a Quantal kernel for testing.
[19:39] <philwyett> jsalisbury: Nice one.
[19:39] <jsalisbury> philwyett, are you using amd64 or i386?
[19:39] <philwyett> amd64
[19:40] <jsalisbury> philwyett, great.  I'll post links to the bug shortly.
[19:40] <philwyett> jsalisbury: Thanks.
[21:01]  * rtg -> EOD


[07:57] <kalikiana> _salem: bfiller_ Would one of youse be so kind and file a bug for the organizationName regression? I'll be looking into the fix, so feel free to assign it to me right away
[08:58] <cult-> hello, i would like to raise awereness of a broken library in ubuntu repository, i contacted the maintainer in email but he hasn't responded. what should I do?
[09:05] <cult-> ubuntu-bug libodb-dev for xenial 16.04, more info: http://www.codesynthesis.com/pipermail/odb-users/2016-May/003280.html
[09:22] <cult-> https://bugs.launchpad.net/ubuntu/+source/libodb/+bug/1588330
[12:05] <salem_> kalikiana, sure, just filed one: https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1662868
[15:24] <mzanetti> zsombi, kalikiana: is there a context menu in the uitk already? I found some bug reports for that but they seem to be open still
[15:24] <zsombi> mzanetti: none atm...
[15:25] <mzanetti> zsombi, what would you suggest? just doing it all by mysel of is there something that would help in the uitk?
[15:25] <zsombi> mzanetti: the Menu was suppose dto work as ContextMenu, not sure the rendering is available in QPA theme or not...
[15:26] <zsombi> mzanetti: if not, ActionSelectionPopover could substitute it for now, but that has an ugly layout...
[15:32] <kalikiana> What's the state of the Menu* API in terms of the QPA then?
[15:33] <kalikiana> We can't really have a ContentMenu until we have both sides of it.
[15:39] <oSoMoN> kalikiana, thanks for driving bug #1576282, I hadn’t followed the discussion but your experiments and the conclusion are very interesting
[15:40] <bfiller> kalikiana, salem_ : was there any resolution to issue salem_ reported yesterday about the organization being blank? or do you need more information
[15:42] <kalikiana> bfiller: Not just yet, but I'll push an MR soon
[15:43] <kalikiana> I know what the problem is
[15:43] <bfiller> kalikiana, ok thank you
[17:29] <shashank__> xampp installation issue in ubuntu 16.04 xenial
[17:29] <shashank__> need help?
[17:30] <shashank__> localhost and phpmyadmin not starting
[17:31] <shashank__> although have followed all the instructions as given on the ubuntu forums.
[17:32] <kalikiana> shashank__: This may not be the best place for you to be asking. See the topic of the channel.
[17:33] <kalikiana> We're mostly talking about QML and click/ snappy here.


[18:36] <OvenWerks> Eickmeyer[k]: which kernel will be in .next? Linux kernel v5.14 has alsa fw stack improvements/fixes
[18:36] <Eickmeyer> OvenWerks: 21.10 is frozen at 5.13.
[18:36] <OvenWerks> Eickmeyer[k]: ok
[18:36] <Eickmeyer> 5.14 (minimum) is likely for 22.04.
[18:37] <OvenWerks> I may look at one of the "off brand" kernels for testing :P
[18:37] <Eickmeyer> OvenWerks: I might have a pull request for Autojack: it needs to do a "systemctl --user restart pulseaudio" upon login or the bridges fail.
[18:38] <Eickmeyer> We can make it noop by throwing a "|| true" at the end of that.
[18:38] <OvenWerks> Eickmeyer: if it works for you, feel free to put it in
[18:38] <Eickmeyer> Ok
[18:39] <OvenWerks> that will probably make Cadence work too ;)
[18:39] <OvenWerks> or to put it another way... Cadence may already be broken by the code that requires that.
[18:41] <OvenWerks> It will be at least another day before I really start working on things though. I have a boat to unload of anything that will go bad first.
[18:47] <OvenWerks> I also seem to have hurt myself grabbing an outboard as it fell off the boat. I don't know if I managed to save it from injesting water or not :P
[18:48] <Eickmeyer> OvenWerks: Ouch. Take care of yourse.f!
[18:49] <Eickmeyer> *yourself