[03:44] <ScottK> xnox: No need to change maintainer for a no change rebuild.
[04:15] <Mirv> mardy: sure. requires full testing but I'll schedule a slot for that patch.
[04:15] <Logan_> ScottK: I think it becomes kinda instinctual :P
[04:15] <Logan_> update-maintainer before debuild -s
[04:15] <Logan_> *S
[05:26] <Mirv> any core dev available for packaging ack of ubuntu-ui-toolkit (a doc file change it seems): http://162.213.34.102/job/landing-018-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-ui-toolkit_0.1.46+14.04.20140331-0ubuntu1.diff
[06:52] <dholbach> good morning
[08:15] <ogra_> slangasek, hmm, i dont get that, must be a false positive https://jenkins.qa.ubuntu.com/job/phablet-tools-trusty-amd64-ci/67/console says line 176 .... nothing suspicious in that line at http://bazaar.launchpad.net/~phablet-team/phablet-tools/trunk/view/head:/phablet-screenshot .... and checkbashisms agrees too http://paste.ubuntu.com/7188675/
[08:19] <zyga> good morning
[08:48] <pitti> barry: note your pyflakes sync is stuck in -proposed as it makes lintian4python uninstallable (Depends: pyflakes (< 0.7.3+))
[08:50] <seb128> mitya57, hey, what does "resubmit" means? should the mp be changed to workinprogress as well so get out of the sponsoring queue?
[08:51] <mitya57> seb128: Indeed, marked as WIP
[08:52] <seb128> mitya57, thanks
[08:52] <mitya57> pitti, barry: https://bitbucket.org/jwilk/lintian4python/commits/f2f7400ef33fcc08, I expect jwilk will upload it soon (he usually does).
[08:52]  * seb128 is looking at https://bugs.launchpad.net/ubuntu/+source/nautilus-share/+bug/1293177
[08:52] <seb128> which knows about samba/is the closest from a maintainer we have for it?
[08:52] <seb128> slangasek? ;-)
[08:52] <hyperair> me
[08:52] <hyperair> oh
[08:53] <hyperair> samba
[08:53] <seb128> lol
[08:53] <hyperair> :)
[08:53] <seb128> hyperair, thanks for commenting on that one, pointing it as a samba regression
[08:54] <hyperair> yeah well, i maintain nautilus-share
[08:54] <seb128> right
[08:54] <seb128> do you know what command can be called manually to reproduce the issue?
[08:54] <hyperair> hmm lemme check
[08:54] <seb128> thanks
[08:54] <hyperair> net usershare add sharename /path/to/sharename "comment" Everyone:R
[08:55] <pitti> mitya57: ah, nice
[08:55] <rbasak> While we're talking about samba, bug 1296289 bothers me too. Bug 1292548 is a possible dupe.
[08:57] <seb128> rbasak, ok; so more people with samba issue but still no sign of maintainer/somebody wanting to look at those, that doesn't help us much :/
[09:00] <rbasak> seb128: I'd like to look into this one. It's on my todo, but I feel a bit swamped by death of a thousand papercuts at the moment :-/
[09:01] <seb128> rbasak, yeah, that's a common issue around here...
[09:05] <seb128> zul, hey, maybe you can help with those samba issues ^ (would it be good to update to 4.1.5 before the LTS, that report claims it fixes the issue from our current version)
[09:06] <seb128> slangasek, ^
[09:09] <FourDollars> Hi, I made a patch on https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1300623. Could someone help me to review it? It is for precise.
[09:11] <seb128> FourDollars, hey, add it to the bug and subscribe ubuntu-sponsors to it
[09:11] <FourDollars> seb128: I have done it.
[09:12] <seb128> you can also try to ping cyphermox in a few hours when he starts his day, he usually look at bluetooth issues
[09:12] <FourDollars> Thanks for the information. :)
[09:12] <FourDollars> cyphermox: ping
[09:13] <seb128> FourDollars, he's in Canada and still sleeping at this time
[09:13] <FourDollars> seb128: haha. I see.
[09:27] <dholbach> mitya57, do you think we should get another ubuntu-packaging-guide uploaded?
[09:27] <Cimi> Laney, ev : I've been trying to hook up to diagnostics plugin for system settings to set whoopsie preferences
[09:28] <Cimi> I set up 'watch qdbus --system com.ubuntu.WhoopsiePreferences /com/ubuntu/WhoopsiePreferences org.freedesktop.DBus.Properties.GetAll com.ubuntu.WhoopsiePreference'
[09:28] <mitya57> dholbach: Oh, sorry, I promised that I'll update the autopkgtest article, but forgot to do that.
[09:28]  * mitya57 checks the changelog
[09:28] <Cimi> but I'm only getting ReportCrashes changing, not AutomaticallyReportCrashes
[09:29] <Laney> I don't think that automatically works
[09:29] <mitya57> dholbach: Maybe we should upload the current version, yes
[09:29] <dholbach> awesome
[09:30] <mitya57> Will you ping Andrew?
[09:31] <Laney> Cimi: I asked ev a similar question the other day, I think the setting is simply ignored
[09:31] <dholbach> mitya57, yes, will do
[09:31] <Laney> so don't worry about it (assuming I'm right)
[09:32] <dholbach> mitya57, I was just looking at the packaging guide to see if it could be used as a basis for the docs on developer.u.c :)
[09:33] <ev> Laney: automatic crash reporting is separate from automatically reporting crashed on failed login, confusingly enough
[09:33] <ev> automatic crash reporting is needed for the phone
[09:34] <ev> where we definitely definitely don't want to pop up a dialog when the application goes away
[09:34] <ev> automatically reporting crashes on failed login is only relevant for the desktop, and is not implemented yet
[09:34] <ev> automatic crash reporting on the phone is, however
[09:34] <Laney> oh right
[09:40] <Cimi> Laney, so we have a bug
[09:40] <Cimi> Laney, the property is false here
[09:40] <Laney> Cimi: yeah I see it too
[09:40] <Laney> infact if I call the dbus method I get a polkit denial
[09:41] <Laney> so it's a problem there
[09:41] <Laney> ah wait hang on maybe not
[09:48] <Laney> ev: whoopsie-preferences crashes when you perform this dbus call!
[09:48] <Laney> try it on your desktop: gdbus call -y -d com.ubuntu.WhoopsiePreferences -o /com/ubuntu/WhoopsiePreferences -m com.ubuntu.WhoopsiePreferences.SetAutomaticallyReportCrashes true
[09:49] <Laney> Cimi: indeed there is a bug, well spotted
[09:50] <apachelogger> pitti: ping bug 1267769 bug 1267771 bug 1267773
[09:52] <Riddell> pitti: better do it or else he'll get his pink unicorn onto you
[09:57] <ev> Laney: that's not good :)
[10:03] <seb128> does anyone know why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8 has e.g
[10:03] <seb128> "out of date on arm64: unity8 (from 7.84+14.04.20140327.1-0ubuntu1) "
[10:03] <seb128> when unity8 was already not available on that arch
[10:12] <didrocks> the fix for #271 Touch which doesn't start will be blocked (if unity8 is really blocked on that ^)
[10:15] <Laney> hopefully fixed for the next run
[10:17] <Laney> Cimi: ev: It's because nothing creates /var/lib/apport/ and the code doesn't check for this possibility
[10:21] <Laney> fixing it to create the directory
[10:24] <Dudytz> hi all .. I have my custom patch in a debian package (gnucash), and a custom preinst to divert a file of another package (a xml: /usr/share/xml/iso-codes/iso_4217.xml) and add a new line ... the line is added after the dpkg-divert via sed command ... this is a good approach or exist another "standard" way to do this?
[10:26] <seb128> Laney, "hopefully fixed for the next run" ... did you hint anything or are you just hopping it's a transient issue/going to be resolving itself with next publisher?
[10:26] <Laney> I fixed it, or at least I think I did
[10:32] <didrocks> yeah, it's not anymore, so should be published next time in the release pocket
[10:32] <seb128> Laney, what was the issue?
[10:32] <Laney> there's a faux package which needs to have its version in sync with the archive
[10:33] <Laney> I didn't follow why it exists, so don't ask me that :P
[10:35] <seb128> oh ok
[10:35] <seb128> thanks for fixing it in any case ;-)
[10:36] <ev> Laney: cheers
[10:54] <doko> Dimitri John Ledkov (xnox) tried to claim the Launchpad
[10:54] <doko> team named Debian GCC maintainers (debian-gcc) (which is
[10:54] <doko> associated with debian-gcc@lists.debian.org).
[10:54] <doko> To finish claiming that team, making Dimitri John Ledkov (xnox)
[10:54] <doko> its owner, just follow the link below.
[10:54] <doko>     https://launchpad.net/token/0VvKD6lckmM57V5Vpp2l
[10:54] <doko> tss, tss, tss ...
[11:03] <Laney> O_O
[11:13] <xnox> doko: Laney: just to protect mailing list from bogus person who tried to merge their launchpad account with the mailing list.
[11:13] <xnox> you can now forever ignore that team.
[11:14] <xnox> ScottK: yes and no, so debuild -S may fail if it's ubuntu2 -> ubuntu3 upload and e.g. previous ubuntu upload did not update the maintainer field (e.g. if doko was the TIL). Hence i always do it...
[11:33] <zul> seb128: rbasak has mentioned a work around
[11:35] <Cimi> seb128, so I discovered why my privacy page is not working on the phone
[11:35] <Cimi> seb128, I'm having authorisation failed
[11:35] <Cimi> seb128, whoopsie preferences and policykit
[11:35] <Cimi> how do I gather permissions?
[11:37] <seb128> Laney, ^ you looked at that more than me
[11:37] <Laney> Cimi: why do you think it doesn't work?
[11:37] <Laney> Did you see my conversation earlier in response to your question?
[11:37] <Cimi> Laney, because I get auth failed from my wizard
[11:37] <Laney> I found that there was a bug with automatic crash reporting
[11:37] <Cimi> Laney, I'm using the diagnostics plugin from the welcome wizard
[11:37] <Cimi> and on the phone I cannot change settings
[11:38] <Laney> Does it work if you launch it from system-settings?
[11:38] <Laney> (does here)
[11:38] <Cimi> I receive not authorized qdbus message
[11:38] <Cimi> Laney, yes
[11:38] <Laney> Shouldn't be a difference
[11:38] <Laney> how are you launching your stuff?
[11:38] <Cimi> Laney, MIR_SOCKET=/run/user/32011/mir_socket system-settings-wizard --desktop_file_hint=/usr/share/applications/webbrowser-app.desktop
[11:39] <Cimi> from console
[11:39] <ogra_> Cimi, are you the phablet user when doing that ?
[11:39] <Cimi> ogra_, yes
[11:39] <Laney> terminal on device?
[11:39] <Laney> or ssh?
[11:39] <Cimi> adb shell
[11:39] <Cimi> and ssh
[11:40] <Laney> you don't get the right permissions if you do that
[11:40] <Laney> try making a script and launching it from the terminal app
[11:40] <xnox> .... there is upstart-app-launch as well.
[11:40] <Laney> that works for pk?
[11:40] <xnox> did not try.
[11:41] <Laney> doesn't look like it to me
[11:43] <Laney> Cimi: ^^^
[11:46] <Cimi> Laney,
[11:46] <Cimi> Laney, yes
[11:46] <Cimi> works
[11:46] <Laney> great
[11:58]  * ogra_ notes that xnox doesnt like us phone people anymore ... i dont see you on #ubuntu-touch 
[11:58] <xnox> ogra_: hi, what can I do for you?
[11:59] <xnox> ogra_: i did a channel clean up, i idle on way too many channels anyway.
[11:59] <ogra_> well, seems initctl stopped working in the latest image
[11:59] <ogra_> for the root user
[12:00] <xnox> ogra_: in what way? does initctl --system list works?
[12:00] <ogra_> and i was wondering what actually happens after your adbd change ... i duppose /etc/profile gets processed now ?
[12:00] <ogra_> *suppose
[12:00] <xnox> ogra_: plus are you talking about root user as: sudo -i from the terminal app from within the phone, or via ssh, or via adb shell?
[12:00] <ogra_> .... we have hacks like http://paste.ubuntu.com/7189348/ in there
[12:00] <xnox> ogra_: "root user" is ambigious =)
[12:01] <ogra_> root user via adb shell i think
[12:01] <xnox> ogra_: root user talks to system upstart via socket and not via dbus.
[12:01] <ogra_> ah, k
[12:02] <ogra_> xnox, how about that one http://paste.ubuntu.com/7189358/
[12:03] <ogra_> (there is no /run/user/0 ... indeed)
[12:03] <xnox> ogra_: root user has no user sessions....
[12:03] <xnox> ogra_: and that snippet is wrong, as it shouldn't be in profile.d
[12:03] <ogra_> xnox, well, it would be nice if you coulld also see what is discussed in -touch
[12:03] <xnox> ogra_: i'll read irc logs =)
[12:04] <ogra_> heh
[12:04] <xnox> ogra_: again, does: initctl --system list
[12:04] <xnox> ogra_: work for you?
[12:04] <ogra_> so Saviq notes that UPSTART_SESSION is unset
[12:04] <xnox> root user does not have UPSTART_SESSION.
[12:04] <ogra_> right
[12:04] <xnox> ogra_: and root user never can talk to upstart user session.
[12:05] <xnox> ogra_: root user only ever needs to talk to system upstart.
[12:05] <ogra_> the initctl works on 270 ... i dont have 271 installed since thats completely broked
[12:05] <xnox> ogra_: hence i've asked you, does: initctl --system list
[12:05] <xnox> work
[12:05] <ogra_> (but 271 has your change)
[12:05] <ogra_> i.e. Saviq testing would be more helpful
[12:05] <xnox> ogra_: you still didn't tell me what's broken =) you only pasted pastebins of profile.d snippets =)
[12:05] <Saviq> me just flashes 271 again
[12:06] <ogra_> xnox, ask Saviq i'm just proxying
[12:06] <Saviq> xnox, initctl as root didn't work
[12:06] <Saviq> xnox, for the system init
[12:06] <xnox> Saviq: does initctl --system list, work?
[12:06] <Saviq> xnox, I'm reflashing right now, will get back to you in 3
[12:07] <xnox> Saviq: yeah, i dual boot so for me it takes longer to reflash.
[12:07] <doko> is this mvo's first work day?
[12:07] <xnox> doko: are you kidding me?! =)
[12:07] <Laney> APRIL FOOL!
[12:07] <Saviq> xnox, I dual boot, too, new dual boot app from ondra actually supports "sideloading" from the host
[12:08] <Saviq> xnox, https://chinstrap.canonical.com/~okubik/humpolec/refactor/
[12:08] <xnox> Saviq: hm, haven't upgraded to that one yet.
[12:08] <Saviq> not official yet, but it's purty ocol
[12:08] <Saviq> cool
[12:09] <Saviq> works with system-image downloads, too
[12:09] <Saviq> and deltas
[12:09] <xnox> Saviq: so if it works with "--system" then i'd upload updated profile.d snippet to be less crazy.
[12:09] <xnox> Saviq: yeah, i'd want delta updates \o/
[12:09] <ogra_> doko, yes
[12:09] <Saviq> xnox, k, reboots to ubuntu now
[12:10] <Saviq> xnox, yes, that works
[12:10] <Saviq> xnox, can I export something in the env so that initctl defaults to the system init?
[12:10] <xnox> Saviq: ok, can you pastebin me the output of "$ adb shell env" ?
[12:11] <Saviq> xnox, http://paste.ubuntu.com/7189396/
[12:11] <Saviq> lunch time...
[12:16] <mvo> doko: yes, first day today, at your service
[12:16] <doko> how many wishes do I have? ;-P
[12:17] <xnox> mvo: welcome back! =)))))))
[12:17] <mvo> xnox: thanks :)
[12:18] <doko> xnox, wait until he escapes again to do some app store thingy ...
[12:18] <ogra_> doko, yeah, the movie start career obviously didnt work out
[12:18] <xnox> Saviq: i think http://paste.ubuntu.com/7189418/ should solve it. Waiting for the download.
[12:20] <ogra_> doko, http://video.golem.de/politik-recht/12714/rohrpostsystem.html (forward to 0:47 sec)
[12:20] <ogra_> s/start/star/
[12:20] <ogra_> :)
[12:20] <ogra_> xnox, ++
[12:21] <ogra_> we would probably also want such a check in the dbus script
[12:21] <xnox> ogra_: and arguabily it's a bug in upstart as well, since empty UPSTART_SESSION variable, should be ignored.
[12:21] <xnox> ogra_: well just not export empty vars should be fine.
[12:22] <ogra_> xnox, note that ubuntu-touch-session is stuck in a silo atm though ...
[12:22] <xnox> ogra_: [ -n "$DBUS_SESSION_BUS_ADDRESS ] && export DBUS_SESSION_BUS_ADDRESS
[12:22] <ogra_> (luckily owned by Saviq so you should be able to upload there)
[12:22] <xnox> ogra_: which silo?
[12:22] <xnox> or i guess i can hunt down the silo number from spreadsheets.
[12:23] <ogra_> yeah, u-t-s also became a fulll branch now ... just make an MP
[12:24] <ogra_> (source packages work pretty bad on silos if there are multiple landings using the same package at different revisions)
[12:25] <xnox> ogra_: of course it's everything else that's a problem, rather than the silos =)))))))))))
[12:25] <xnox> ogra_: still downloading 271.
[12:25] <xnox> ogra_: will propose after checked it's all correct.
[12:26] <ogra_> it definitely looks correct
[12:27]  * ogra_ goes back to glare at http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-trusty-270.png 
[12:27]  * xnox ponders if mvo's comeback is for one-day only to stage the most ellaborate april's fools joke ever.
[12:28] <xnox> ogra_: i want a boot chart for emulator. How would i do that?
[12:28] <ogra_> xnox, i discussed that with rsalveti already ... its a bit more tricky since the initrd needs to be updated
[12:28] <mvo> xnox: I certainly hope its for more than 1 day :) hopefully at least as long as my pervious gig :)
[12:29] <Unit193> mvo: Poke.  Any updates? :)
[12:29] <xnox> ogra_: updating initrd is easy =) what needs changing?
[12:29] <ogra_> xnox, this is my ultra ugly bootchart script http://paste.ubuntu.com/7189452/ ... i'm working on transforming it into phablet-bootchart for phablet-tools
[12:29] <mvo> Unit193: uhhhhhh, no yet! sorry!
[12:29] <ogra_> (and on getting it into CI as a standard test this week)
[12:30] <Unit193> mvo: Hey, you remembered, better than nothing.  Thanks. :)
[12:30] <mvo> Unit193: but I will have to use my log file to find the bugnumber :)
[12:31] <ogra_> xnox, so after the bootchart package was installed, you want to grab the initrd from /boot inside the rootfs i guess ... that should be all (well, and boot with it on the next reboot)
[12:32] <xnox> ogra_: ack.
[12:33] <ogra_> (and you probably want to replace the network bringup hack with something sane too :) )
[12:41]  * ogra_ wonders why there is nothing between 3 and 10 seconds in his dmesg output at http://paste.ubuntu.com/7189485/
[12:41] <ogra_> i would really like to know whats going on in these 7 seconds
[12:48] <ivoks> ogra_: /var/log/upstart?
[12:48] <ivoks> ogra_: or is that even before upstart?
[12:49] <ogra_> ivoks, thats after initrd (teh swapon is the last thing that happens there) so yes, the first chunks of upstart processing ...
[12:49] <ogra_> i have a bootchart, i can see what processes ran when, i'm concerned that dmesg doesnt log anything
[12:49] <ivoks> well, dmesg is kernel only
[12:50] <ogra_> its init as well
[12:50] <ogra_> even the android init from the container that starts at 10.78 logs there
[12:52] <ogra_> ivoks, i think the console switches somewhere where it cant be logged for that time frame
[12:53] <xnox> Saviq: ogra_: initctl and dbus works with both adb shell as root user and as phablet user with https://code.launchpad.net/~xnox/ubuntu-touch-session/no-export-bogus-environment/+merge/213646 applied
[12:53] <xnox> Saviq: please reconfigure/land as appropriate.
[12:54] <ogra_> xnox, great !
[12:54] <Saviq> xnox, coolz
[12:55] <Saviq> ogra_, I could add this to the right edge landing, who should review?
[12:56] <ogra_> Saviq, done
[12:57] <Saviq> ogra_, building in silo 015
[12:58] <ogra_> Saviq, do you think you can land it today ? else i would like to push my lxc-android-config changes in the silo as well
[12:59] <Saviq> ogra_, yes, I really want to land it today
[12:59] <ogra_> ok
[12:59] <Saviq> ogra_, just building those and doing last round of testing
[12:59] <ogra_> (and i would prefer a separate landing :) )
[13:03] <ogra_> hmm, so even echoing to /dev/kmgs doesnt show up during that timeframe
[13:03] <ogra_> *kmsg
[13:35] <ogra_> hallyn, i see a bunch of http://paste.ubuntu.com/7189686/ during boot on the phones ... is there any kernel option we need ?
[13:36] <pitti> apachelogger, Riddell: travelling today, but these are simple, doing now
[13:36]  * pitti waves from Dublin airport
[13:36] <seb128> pitti, hey, what are you doing in Dublin? ;-)
[13:37]  * ogra_ was about to ask the same :)
[13:37] <pitti> seb128: waiting for my flight to IoM :)
[13:37] <seb128> pitti, oh, good to IoM? have fun there!
[13:38] <pitti> it's horribly difficult to get there -- 9 hours trip there, 10:30 hours back
[13:38] <seb128> :-(
[13:38] <pitti> seb128: yep, little sprint here
[13:41] <pitti> apachelogger: hm, the notificationhelper has been there for a long time already; if it doesn't work that needs some further research, can't do ATM
[13:41] <pitti> apachelogger: so queueing
[13:53] <sladen> pitti: yes it takes that long on the train+ferry to get to the IoM :)
[13:54] <ogra_> hrm ...
[13:54] <ogra_> so i wonder why it takes two seconds from run-init to starting mountall
[13:54] <Laney> that's why when you live there you have a private jet :-)
[13:55] <ogra_> /sbin/init cant be that slow
[13:55] <sladen> pitti: yes it takes _less than that_ on the train+ferry to get to the IoM :)  (8h30 hours Euston->Douglas)
[13:57] <pitti> cjwatson: what was the name of that little magic tool which would download apt indexes and let you simulate installs (to check installability problems, etc) as pure user without a full chroot?
[13:57] <wookey> cjwatson: man-db is failing test on arm64 in debian: https://paste.debian.net/90962/
[13:58] <wookey> any suggestions before I dig in. it's built OK on trusty in same version SFAICS
[13:58] <Laney> pitti: I think you're thinking of chdist
[13:58] <pitti> Laney: yes! that was it, thanks
[13:58] <pitti> cjwatson: unping
[14:00] <ogra_> xnox, jodh, so i added some "echo .... >>/dev/kmsg" right before run-init is executed in the initrd and right when mountall starts from upstart ... http://paste.ubuntu.com/7189757/ is what i get then ... any idea why it takes 2.5 sec for run-init to switch to upstart ? (or any idea how i could get more fine grained data)
[14:01] <jodh> ogra_: are you booting with --debug?
[14:01] <ogra_> jodh, nope, thats a phone, i cant fiddle easily with cmdline options
[14:02] <jodh> ogra_: well it would help significantly if you could :)
[14:02] <ogra_> this is a normal boot ... bootchart installed and these two echos added
[14:02] <ogra_> hmm
[14:03] <jodh> can't you modify the initramfs's init script?
[14:03] <cjwatson> wookey: I tried to reproduce that on real hw and couldn't
[14:03] <cjwatson> wookey: be my guest if you can see what's up
[14:03] <ogra_> jodh, ok, was easier than i thought ... trying a boot now
[14:04] <cjwatson> wookey: oh, that's a different error from the one I saw before, actually - https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5708181
[14:04] <cjwatson> wookey: not in remotely the same place either
[14:05] <cjwatson> wookey: that error's actually from groff
[14:07] <wookey> If it's not immediately obvious I'll report a bug including the logs, then take a look at what's up.
[14:07] <ogra_> jodh, bah, to much spam ... the earliest info i can get from dmesg or kern.log is at 8sec
[14:08] <cjwatson> wookey: suspect you'll need to run the test verbosely to get the actual groff command, use groff's -V option to get the formatting pipeline, apply gdb to troff and see what the values of the relevant variables around there are
[14:08]  * ogra_ creates an upstart job that makes dmesg snapshots 
[14:12] <doko> cjwatson, wookey: don't bother about that, this is the xgene optimizing compiler in the test rebuild
[14:12] <hallyn> ogra: pretty sure that's due to how the upstart jobs are designed.
[14:13] <seb128> zul, slangasek: comments/opinion on https://launchpadlibrarian.net/171463522/samba.diff
[14:13] <ogra_> hallyn, well, do i need cgproxy on a phone ?
[14:13] <seb128> zul, those changes got dropped in https://launchpad.net/ubuntu/+source/samba/2:4.0.10+dfsg-4ubuntu1 (your trusty samba4 merge), not sure if that was on purpose or an overlook/error
[14:13] <zul> seb128:  +1 from me
[14:13] <seb128> zul, thanks
[14:13] <hallyn> ogra: you might, if you were on a re-3.12 kernel
[14:14] <ogra_> lol
[14:14] <hallyn> pre-3.12 that is
[14:14] <ogra_> we are on 3.0 to 3.5
[14:15] <ogra_> (android kernels)
[14:15] <hallyn> actually that's not the version, but if /proc/pid/ns/pid does not exist then you need it
[14:15] <hallyn> but no, wiat
[14:15] <ogra_> it doesnt exist ... checked that already
[14:15] <hallyn> respawning.  something else is going on
[14:15] <ogra_> right
[14:15] <ogra_> root@ubuntu-phablet:/# ps ax|grep cgproxy
[14:15] <ogra_>   613 ?        Ss     0:00 /sbin/cgproxy
[14:16] <ogra_> it starts eventually
[14:16] <hallyn> well i expect it to start once and go away, then be started manually by the cgmanager job
[14:17] <hallyn> but what you're seeing is not what i'd expect.  can you start it under strace (in /etc/init/cgproxy.conf)?
[14:17] <jodh> ogra_: you could try --verbose which is slightly less spammy than --debug
[14:17] <ogra_> ok
[14:18] <hallyn> also add --debug to the cgproxy options :)
[14:18]  * hallyn biab
[14:19] <ogra_> heh, doing ten things at once here :)
[14:19] <ogra_> jodh, even with verbose i get the first line at 7.8sec
[14:19] <ogra_> i'll try to make the ringbuffer larger
[14:20] <cjwatson> doko: you mean the mandb segfault in the test rebuild?
[14:20] <cjwatson> doko: wookey's problem is not the same, now that I look at it, it's groff reporting overflows
[14:21] <hallyn> ogra: kids are still breakfasting, so ignore me for a few mins :)
[14:22] <doko> cjwatson, yes in the test rebuild only
[14:24] <ogra_> jodh, line 598 to 857 http://paste.ubuntu.com/7189889/
[14:24] <ogra_> we have the majority (but not all) plymouth jobs disabled on the phone
[14:25]  * ogra_ is surprised how much stuff is going on there 
[14:25] <pitti> Riddell, apachelogger: I'm afraid I need some heads-up here: KDE langpacks got dropped a while ago, what replaced them?
[14:25] <pitti> Riddell, apachelogger: are these kubuntu specific translations supposed to be in kde-l10n-* or are these teh upstream translations only?
[14:26] <apachelogger> pitti: kde-l10n is upstream only
[14:26] <Riddell> pitti: the generic langauge packs for the few kubuntu transations in main
[14:26] <apachelogger> ^ that's what we concluded last we talked about where to put them anyway ;)
[14:26] <pitti> aah
[14:26] <pitti> like /usr/share/locale-langpack/de/LC_MESSAGES/kubuntu-patched-l10n.mo ?
[14:26] <cjwatson> doko: ok, thanks
[14:27] <jodh> ogra_: can't we disable /etc/init/startpar-bridge.conf on Touch?
[14:27] <ogra_> jodh, what does it do ?
[14:27]  * ogra_ just noticed that disabling the unused ureadahed jobs gains him a good bunch 
[14:27] <xnox> jodh: if there are no initd scripts that depend on upstart jobs.
[14:28] <ogra_> i think that was it ...
[14:28] <ogra_> [    4.286860] run-init !!!
[14:28] <ogra_> [    4.594689] mountall !!!
[14:29] <ogra_> only .3 seconds now
[14:29]  * ogra_ cleans up the kernel cmdline and makes a bootchart 
[14:29] <jodh> ogra_: great. I thought you'd gone round the ureadahead-required-on-touch-or-not loop already? :)
[14:30] <ogra_> jodh, i had, it works great by just looping over the .pack files ... but i forgot to disable the default jobs :)
[14:33] <ogra_> wow !
[14:33] <ogra_> 2 seconds gained \o/
[14:38] <pitti> apachelogger: ok, added overrides to langpack-o-matic; next langpack update shold have it
[14:41] <apachelogger> pitti: danke. I'll put down a todo to verify :)
[14:57] <xnox> barry: i see strange failures, python-regex ftbfs due to test-suite errors with python2.7. Yet this was not present before, nor in the recent test rebuild....
[14:58] <barry> xnox: huh, interesting.  is this in the trusty version?
[14:58] <xnox> barry: yeap.
[14:59] <barry> xnox: looking
[15:07] <barry> xnox: test_getattr failure?
[15:07] <xnox> barry: yeap.
[15:07] <xnox> barry: the assert is simply checking that default flags are sane. And the flag value under test is insane =)
[15:11] <barry> >>> import regex
[15:11] <barry> >>> x = regex.compile('(?i)(a)(b)')
[15:11] <barry> >>> x.flags
[15:11] <barry> 8322
[15:11] <barry>  
[15:11] <barry> amd64 ^
[15:13] <barry> xnox: i386 looks sane too
[15:13] <barry> chroot
[15:15] <xnox> barry: true. and recompiled & installed .debs also work fine. I'm confused how come it fails in sbuild.
[15:15] <xnox> barry: i'll upload and hope for the best.
[15:20] <barry> xnox: sounds good.  if it fails there, the place to look is in Python2/_regex.c.  my best guess is that there's a bogus assumption about the size of the "flags" field in the PatternObject structure.  e.g. sizeof(RE_CODE) != PYSIZET
[15:23] <xnox> barry: failed on ppc64el https://launchpad.net/ubuntu/+source/python-regex/0.1.20140120-1build1
[15:23]  * xnox ponders if i'm accidently running ppc64el kernel on my amd64 machine..... nope, i'm not.
[15:24] <barry> xnox: i don't have time atm to dig into that, but see above.  i'm sure it's an upstream bug.  or file a bug and i can look at it soonish
[15:24] <xnox> barry: and that's  a regression cause ppc64el did build before.
[15:25] <xnox> barry: right, thanks! i'll see what i can dig out of above hint.
[15:25] <barry> xnox: hmm
[15:25] <barry> cool!
[15:34] <rbasak> Who runs +1 maint currently?
[15:35] <rbasak> I'd like to do another month rotation early next cycle, if that still happens. Though I need to run the schedule past my manager first.
[15:36] <slangasek> ogra_: right, checkbashisms likes it /now/ because a fix for it went in yesterday ;)
[15:36] <ogra_> lol
[15:37] <ogra_> slangasek, that checkbashisms run was on precise
[15:37] <ogra_> or do you mean the CI tool
[15:38] <slangasek> seb128: if you're asking for my general opinion, I'd say yes we should update samba to the latest 4.1.x version before the LTS; but someone else can go through the FFe process to show that it's safe :)
[15:39] <seb128> slangasek, that makes sense, thanks
[15:39] <slangasek> ogra_: ah, yeah, maybe you're seeing a difference in checkbashisms versions... I guess the changes are still in a silo
[15:39] <slangasek> seb128: Debian unstable is at 4.1.6 now fwiw
[15:39] <ogra_> slangasek, well, i meant the bastebin i sent you with the ping above
[15:39] <ogra_> *pastebin
[15:39] <ogra_> http://paste.ubuntu.com/7188675/
[15:39] <seb128> slangasek, I saw that
[15:40] <Laney> sounds like seb128 won a merge :-)
[15:40] <slangasek> ogra_: with the current checkbashisms?  Regardless, I pushed a change that both works and makes checkbashisms happy
[15:40] <ogra_> slangasek, i think whatever tool is used there to run the bashism verification should learn about single quotes :)
[15:40] <slangasek> ogra_: and drops the grep|sed pipe ;)
[15:40] <ogra_> yes, i saw your fix and it is nice
[15:41] <ogra_> but i think checkbashisms shouldnt have fallen over in the first place
[15:41] <seb128> slangasek, do we have somebody usually looking after samba?
[15:41] <seb128> Laney, nice try :p
[15:41] <slangasek> seb128: I'd say that's probably zul
[15:42] <zul> slangasek:  i would say thats rbasak
[15:42] <seb128> zul, hey, you wouldn't have spare cycles to merge/update samba to the current version before trusty by any chance? ;-)
[15:42] <seb128> haha
[15:42] <slangasek> oh, ok
[15:42] <Laney> hahaha
[15:42] <Laney> this potato seems pretty warm
[15:42] <seb128> rbasak hinted he would like to look at those issues but is too busy
[15:42] <zul> seb128:  sure i can do it then...debdiff?
[15:42] <ogra_> just make him stop doing that other stuff then :)
[15:43] <seb128> zul, debdiff of? the versions? ;-)
[15:43] <rbasak> Part busy, part too scared to touch it! Plus, I'd need sponsorship anyway.
[15:43] <zul> seb128:  debdiff
[15:43] <seb128> zul, dget https://launchpad.net/ubuntu/+archive/primary/+files/samba_4.1.3%2Bdfsg-2ubuntu4.dsc http://ftp.iut-bm.univ-fcomte.fr/debian/pool/main/s/samba/samba_4.1.6+dfsg-1.dsc; debdiff *.dsc
[15:44] <seb128> ? ;-)
[15:44] <zul> grr...ill have a look it this afternoon
[15:45] <seb128> zul, sorry if I didn't understand what you asked for ... you though somebody had it merged with a debdiff ready to sponsor?
[15:45] <ogra_> i think we should just check who touched samba last ... as usually that  person owns it forever :P
[15:45] <seb128> zul, I can try having a look at the merge if you want
[15:45] <stgraber> zul: if you do that, can you please fix bug 1268180 at the same time, should be trivial
[15:46] <zul> seb128: i thought it was merged already
[15:46] <zul> slangasek:  sure
[15:46] <doko> tkamppeter, what is blocking system-config-printer moving to Python3?
[15:46] <seb128> zul, oh ok, sorry about the confusion, no we were discussing if it's doable to update to the current point version before the LTS, and trying to find somebody with slots to do that
[15:47] <zul> seb128:  well i dont have slots but i can do it anyway
[15:47] <seb128> zul, let me know if you are too busy, I can try having a look at the merge (though I don't know enough about samba to properly test it)
[15:47] <seb128> zul, thanks
[15:54] <tkamppeter> doko, I did not try whether it actually works, was busy with making printing working for mobile, so I will ask Tim Waugh, the upstream author.
[16:08] <mdeslaur> tkamppeter: have you seen this? http://www.openwall.com/lists/oss-security/2014/04/01/4
[16:12] <stgraber> mdeslaur: that's slightly scary... broadcast some crap on the network and everyone runs it? (well, they have to print something, but still...)
[16:13] <mdeslaur> stgraber: yeah...good thing cups is protected by apparmor
[16:14] <ogra_> xnox, did you already do an android rebuild after uploading the touch initrd changes ?
[16:14] <ogra_> (i have a pending change here i would like to land if you didnt yet, so it gets pulled in alongside)
[16:16] <tkamppeter> mdeslaur, so we need to check the inserted strings (make/model, PDLs, ...) for illegal characters in cups-browsed?
[16:17] <mdeslaur> tkamppeter: yeah, I think that would be ok. or rather, a whitelist of valid characters
[16:20] <tkamppeter> mdeslaur, I will add that and issue it as 1.0.51.
[16:25] <xnox> ogra_: yeah, that's all landed ages ago with deb support
[16:26] <ogra_> xnox, i mean the fstab parsing change
[16:26] <ogra_> that only landed on the weekend, no ?
[16:27] <ogra_> oh, ignore me
[16:27]  * ogra_ was off by one week
[16:28]  * ogra_ blames DST !
[16:28] <xnox> ogra_: yeah, not sure about timings. But everything is in release pocket, so you are all clear for any android/initramfs changes.
[16:28] <ogra_> xnox, right, i was hoping you had not uploaded android yet :)
[16:30] <ogra_> xnox, OH !
[16:30] <ogra_> xnox, https://launchpad.net/ubuntu/trusty/+source/initramfs-tools-ubuntu-touch/0.70
[16:31] <ogra_> seems it took two weeks to migrate from proposed
[16:31]  * ogra_ was wonderign why apt-get source didnt give him 0.70
[16:39] <cjwatson> ogra_: it was manually blocked for some time by a bug
[16:39] <ogra_> ah, ok
[16:42] <xnox> wgrant: infinity: CI has a whole new meaning from now on =)
[16:43] <doanac> xnox: you have any suggestions/ideas how i can get the ubuntu-emulator to show up as an adb device?
[16:44] <mdeslaur> tkamppeter: thanks
[16:44] <ogra_> doanac, it just shows up as one once adbd is started (here at least)
[16:45] <ogra_> you just need the patience to wait til its booted after 20min :P
[16:45] <doanac> ogra_: hmm. i get the device to boot and have a log-in prompt in my shell. but it doesn't show up under adb
[16:45] <ogra_> doanac, do you have the UI yet ?
[16:45] <doanac> ogra_: its off now. let me power on so i can give more info
[16:45] <ogra_> adb only starts after the container nowadays
[16:46] <ogra_> so pretty late in the boot process
[16:46] <doanac> last night i had it to the touch intro, but no adb
[16:46] <ogra_> hmm, thats surely wrong
[16:46] <doanac> ack. i'll retry
[16:46] <doanac> hopefully user-error
[16:48] <xnox> mvo_: would you be able to kick off command-not-found data update based on trusty series? as far as i could trace it, it's still running by your cronjobs albeit still against precise (or some such).
[16:49] <mvo_> xnox: I certainly hope its not against precise, but probably saucy, but I will check
[16:49] <mvo_> xnox: now that I can login again :)
[16:50] <xnox> mvo_: well, I only tested against something that's new in trusty. E.g. "ubuntu-emulator" is not known to command-not-found =)
[17:18] <doanac> ogra_: so  my emulator is running. i'm at the edges intro, i've got a login prompt for ttyS2, but adb-devices shows nothing on my host pc
[17:18] <ogra_> weird
[17:18] <ogra_> (i havent run an emulator in a while, let me try)
[17:19] <doanac> thanks. i suspect its something easy to address. i just wasn't sure where to start
[17:20]  * ogra_ watches his laptop to start hovering over the desk
[17:27] <ogra_> doanac, so i see adbd running in the emulator, but you are right, no device seen on my laptop
[17:28] <ogra_> doanac, restarting the adb server on the laptop helped
[17:29] <ogra_> i assume adb waits for an USB event it doesnt get for noticing the connection
[17:29] <doanac> ogra_: that helped. mine is still offline though
[17:29] <doanac> it shows up as offline that is
[17:29] <ogra_> thats strange, i'm logged in
[17:30] <doanac> hmm. my emulator seems locked up.
[17:30] <ogra_> ogra@styx:~/Devel/packages/android-tools-4.2.2+git20130218/core/adbd$ adb devices
[17:30] <ogra_> List of devices attached
[17:30] <ogra_> emulator-5554	device
[17:30] <ogra_> and i can log in just fine
[17:30] <doanac> ogra_: let me retry this. if it just needs a restart, i can code around things for now
[17:30] <ogra_> k
[17:40] <doanac> ogra_: thanks. i think i've got a path forward now!
[17:40] <ogra_> awesome
[17:41] <zyga> doanac: hey
[17:41] <zyga> doanac: how are you? :)
[17:41] <doanac> zyga: not too bad. what's up?
[17:41] <ogra_> i would ask to open a bug for that but i have not even remotely a clue if thats a qemu issue or udev on the host ... or adb
[17:41] <zyga> doanac: good, thanks, busy week, eh?
[17:41] <doanac> zyga: yeah. they've all been pretty busy lately :)
[18:17] <cjwatson> psusi: I think the LVM regression here is because dev->loop is undefined on some paths.  Considering http://paste.ubuntu.com/7190835/ - what do you think?
[18:17] <cjwatson> psusi: the whole PedDevice.loop thing seems to be very awkward in terms of layering, because you need it when you only have a PedDevice in hand, but strictly speaking it's really a property of a PedDisk ...
[18:17] <psusi> cjwatson, I just noticed that I did make a booboo there... if you run parted and attempt to rm the fake partition, it pukes trying to remove the lv itself
[18:18] <cjwatson> Don't know if that's related
[18:18] <psusi> I just had to clear the loop flag temporarily and restore it after the remove partition step... but there seem to be a number of different weird things going on in partman
[18:18] <cjwatson> It's not that weird
[18:18] <cjwatson> partman is doing a ped_device_new_fresh
[18:18] <cjwatson> You only initialise dev->loop in ped_device_new
[18:18] <cjwatson> So it's random
[18:18] <cjwatson> (I think)
[18:18] <psusi> beacuse the first problem I run into, even after fixing that issue removing the fake partition, is that the first error in syslog is that /dev/ubuntu-vg can not be statted... well, no kidding, you didn't call pvcreate and vgcreate yet
[18:19] <psusi> it just created the partitions at that point
[18:19] <cjwatson> Sorry, s/ped_device_new/ped_disk_new/g in all that
[18:19] <cjwatson> That's all a consequence of the above, as far as I can tell
[18:19] <psusi> retrying the same step again lets it correctly create the lv/pv and proceed, after I fixed the issue with removing the fake partition
[18:19] <cjwatson> It tries to call pvcreate/vgcreate but it's very confused because the uninitialised PedDevice.loop causes it to get the wrong path to create the PV on
[18:20] <psusi> then  why does it work the second time?
[18:20] <cjwatson> Second time it'll be going through ped_disk_new which *does* initialise it
[18:20] <psusi> ohh, I see
[18:21] <psusi> do those changes fix it?
[18:21] <cjwatson> I'm trying to rig a test now
[18:21] <psusi> why did you remove the initialization from ped_disk_new?
[18:21] <cjwatson> Because ped_disk_new calls ped_disk_new_fresh
[18:21] <psusi> ohh, right
[18:22] <cjwatson> Presumably you're not allowed to ask a PedDevice for a partition path without going through ped_disk_new* first
[18:22] <cjwatson> Hopefully
[18:22] <cjwatson> Like I say, the layering is awkward
[18:23] <psusi> ok, in addition to those changes, you want to go disk_sync_part_table and around the call to remove_partition, add an int loop = disk->dev->loop; disk->dev->loop = 0;, then restore it after
[18:23] <cjwatson> I don't quite see why you didn't instead key off PED_DEVICE_FILE or some such
[18:23] <psusi> because a loop device isn't a PED_DEVICE_FILE
[18:24] <cjwatson> But this whole area of parted has always been a total mess
[18:24] <psusi> yea... it has... that's why I've been trying to fix it up
[18:24] <cjwatson> Well, it's still a conceptual mess :)
[18:24] <psusi> you can create a loop label on a normal scsi disk if you want
[18:24] <cjwatson> You now have ped_device behaviour that depends on what ped_disk has done on top of it ...
[18:25] <psusi> that's actually the use case I was working on in gparted when I found and tried to fix these bugs... you mkfs the whole scsi disk with no partition table
[18:25] <psusi> yea... the layering is a bit goofy
[18:26] <cjwatson> would you mind pastebinning me a patch for the disk_sync_part_table thing?  I have a rotten headache and not sure I'm coherent
[18:26] <psusi> come to think of it, maybe taht should have been just initialized in linux_new
[18:26] <cjwatson> it kinda sounds like hack upon hack
[18:27] <cjwatson> isn't it better to do it in the architecture-independent code?
[18:27] <psusi> well yea... the loop lable is kind of a hack... its basically pretending there is a partition table there when there isn't
[18:27] <cjwatson> oh, you only use it in linux.  why is it not in PedDevice.arch_specific then?
[18:27] <psusi> good point
[18:27] <psusi> hrm... it shouldn't be linux only
[18:29] <cjwatson> hack upon hack> what I mean is, why do we need the partition path with number appended in some situations but not others?
[18:29] <cjwatson> that seems to make only dubious sense
[18:30] <psusi> because partitions normally have a number appended
[18:30] <psusi> but not when you don't have a partition table ( i.e. loop label )
[18:31] <cjwatson> sure.  but why then do we suddenly need the number when removing partitions?
[18:31] <cjwatson> surely either we need it or we don't
[18:31] <psusi> say you initially do have a partition table with some partitions, and then mklabel loop over top of it
[18:31] <psusi> you want to remove the no longer needed partitions
[18:32] <cjwatson> oh, loop is set way before actually committing the removal, right
[18:32] <cjwatson> this is foul
[18:33] <cjwatson> I'd have thought then that we need to detect what the actual pre-removal state is, rather than just forcing it to zero ...
[18:33] <psusi> can't really and it doesn't matter
[18:33] <psusi> if the partitions are there, we remove them... if they aren't... then we don't care...
[18:34] <psusi> i.e. if we get back ENXIO trying to remove, we ignore it since it's already gone and that's what we wanted
[18:34] <cjwatson> well, it's potentially a name clash isn't it?
[18:34] <cjwatson> I agree it's relatively unlikely
[18:35] <cjwatson> with my patch, vg creation works, but I get a whinge about being unable to inform the kernel about the change to partition 1 of /dev/mapper/ubuntu--vg-root
[18:35] <cjwatson> maybe that's the removal issue you describe
[18:35] <psusi> cjwatson, http://paste.ubuntu.com/7190938/
[18:36] <psusi> bingo
[18:36] <psusi> what is potentially a name clash?
[18:37] <cjwatson> what if somebody makes an lv called root1
[18:38] <psusi> ahh, ick... and one called root, and then creates a partition on it?
[18:38] <cjwatson> I guess it would still have clashed before, just differently
[18:39] <psusi> yea
[18:40] <psusi> yea, there's just no good way out of that one
[18:40] <psusi> other than patching lvm to not allow you to create such names ;)
[18:41] <cjwatson> there is.  parted could know that vg-root wasn't previously non-loop-partitioned and never try to access vg-root1
[18:41] <cjwatson> like I say, by reading the previous state
[18:41] <psusi> well no, this doesn't have anythign to do with loop lables
[18:42] <psusi> if you just make a volume named root, and another named root1, then use parted to create a partition table and partition on loop, then it's going to clash with the root1 lv
[18:42] <psusi> s/loop/root
[18:42] <cjwatson> but if it's a loop table on root, then it should never need to hit root1
[18:43] <psusi> true... but at that layer of the code there is no "previous" state you can compare to... remember, the same stuff is called when you execute partprobe
[18:43] <psusi> which only knows what the current partition table says... has no idea about what, if anything, was there before
[18:43] <cjwatson> mm.  horrible.
[18:43] <psusi> so it just has to remove everything
[18:44] <psusi> well, it's a lot better than it was before when it was using BLKRRPRT ;)
[18:44] <psusi> also the name clash goes beyond parted
[18:44] <cjwatson> ok, same warning this time round
[18:45] <psusi> no tool or person can tell whether /dev/mapper/root1 is a partition or lv
[18:45] <psusi> you sure you got it applied and the updated package installed in your testing vm?
[18:45] <psusi> it fixed it for me
[18:45] <cjwatson> pretty sure
[18:45] <cjwatson> no doubt we're hitting different warnings
[18:45] <psusi> you rebooted the vm with a clean disk right?
[18:45] <cjwatson> yes
[18:46] <psusi> run parted by hand on the lv and try to rm 1
[18:46] <psusi> that's how I reproduced it and figured out what was really going on
[18:47] <cjwatson> "Warning: Partition /dev/mapper/ubuntu--vg-root is being used. Are you sure you want to continue?"
[18:47] <psusi> you have it mounted ;)
[18:47] <cjwatson> well yes, but that's basically the same error I was getting in the UI
[18:47] <psusi> well you can't remove a partition that's mounted
[18:48] <psusi> and the ui certainly shouldn't be trying to
[18:48] <cjwatson> this all worked before so something is broken.
[18:48] <cjwatson> I'm afraid I'm out of steam for today though
[18:48] <cjwatson> I'll pick it up again tomorrow and try to disentangle it
[18:48] <psusi> I'm positive it never tried to remove a mounted partition before ;)
[18:49] <cjwatson> I expect that this is a second-order effect
[18:49] <cjwatson> Something to do with this parted change is confusing it into trying to do so
[18:49] <psusi> if you didn't clear the disk when you rebooted the vm, then it probably found the existing swap partition and mounted that?
[18:49] <cjwatson> I cleared the disk
[18:49] <cjwatson> Stop it :P
[18:49] <psusi> hrm... weird
[18:49] <cjwatson> Obviously it isn't *intentionally* trying to remove a mounted partition device
[18:50] <cjwatson> That would be silly
[18:50] <psusi> by clear the disk you don't just mean blew away the partition table right?
[18:51] <cjwatson> I mean qemu-img create
[18:51] <psusi> yep, ok then...
[18:51] <cjwatson> The error is on ped_disk_commit
[18:52] <cjwatson> And OK, the error in the UI is actually different
[18:53] <cjwatson> "Partition(s) 1 on /dev/mapper/ubuntu--vg-root have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes."
[18:53] <cjwatson> Sorry for misleading
[18:53] <psusi> yea.. same thing
[18:54] <psusi> the question is how the hell can it be trying to (re)create the partition after mounting it
[18:54] <cjwatson> right, yeah, after I unmount, I get a stream of "device-mapper: remove ioctl on ubuntu--vg-root failed: Device or resource busy"
[18:54] <cjwatson> Then the above message
[18:54] <psusi> then you must not have my patch in there?
[18:54] <cjwatson> (from "rm 1" in "parted /dev/mapper/ubuntu--vg-root")
[18:54] <cjwatson> I sure do
[18:54] <cjwatson> Oh
[18:54] <psusi> that's exactly what I had before I applied that patch
[18:54] <cjwatson> Damnit, I lost my debian/changelog
[18:55] <cjwatson> So it built with the wrong version
[18:55] <psusi> heh
[18:55] <cjwatson> Sorry!

[19:00] <cjwatson> Right, that actually seems to work now
[19:00] <cjwatson> http://paste.ubuntu.com/7191088/ for the record
[19:00] <cjwatson> If that still looks sensible to me in the morning then I'll upload
[19:01] <cjwatson> Don't trust myself with dput right now :)
[19:01] <cjwatson> Thanks
[19:01] <psusi> looks sensible to me.... will see if I can find any other ways to break it
[19:02] <cjwatson> I'll actually fold that into fix-loop-labels.patch of course, no point having patch upon patch for the same thing
[19:03] <psusi> aye
[19:04] <psusi> and I'll upstream those changes
[19:04] <cjwatson> Thanks
[19:10] <bdmurray> hallyn: bug 1300927 sounds familiar but I don't recall the exact details
[19:12] <hallyn> bdmurray: yeh it does sound familiar.  but by now i thought we had procps not failing if it fails to write to something?
[19:13] <blkperl> cjwatson: I'm running into this issue, bug 1300943, any suggestions? I'm trying to get log files but mount is hanging when trying to connect my nfs server
[19:15] <psusi> cjwatson, come to think of it, disk.c shoudln't be touching loop at all... it should only need initialized once... in device.c just after it is created
[19:19] <hallyn> bdmurray: i'll follow that one, thanks
[19:19] <bdmurray> hallyn: cool, thank you
[19:34] <hallyn> if eth0 is defined both in /etc/network/interfaces and /etc/network/interfaces.d/eth0, which definition do we expect to be used?
[19:35] <stgraber> hallyn: short answer, "don't do that".
[19:35] <stgraber> in practice, I'd sort of expect the response to be "both" but I'd have to go look at the code to make sure
[19:35] <stgraber> ifupdown isn't very clever, it basically reads the /etc/network/interfaces and processes things as it finds them
[19:36] <stgraber> so I'd expect it to first parse and bring up the first one, then find the second one through the include and complain because it's already up
[19:38] <hallyn> stgraber: i'm not doing it, i'm looking at a system where it's the case... :)
[20:57] <mwhudson> infinity: eglibc is failing to build for me on arm64
[20:58] <infinity> mwhudson: In what way?
[20:58] <infinity> mwhudson: Also, the buildds would mostly disagree with you. ;)
[20:58] <mwhudson> infinity: have you seen anything like this? http://paste.ubuntu.com/7191580/
[20:58] <mwhudson> yes
[20:58] <mwhudson> i realize :)
[20:58] <infinity> mwhudson: A log and a debdiff of what you're abusing it with would help.
[20:59] <mwhudson> ok
[20:59] <infinity> mwhudson: I've never seen tst-tls5 fail, no.  That's either a regression from the patch you're testing, or a bug in the kernel you're building on.
[20:59] <mwhudson> hm
[20:59] <mwhudson> i bet the kernel
[20:59] <mwhudson> 3.13.0-19-generic
[21:00] <mwhudson> are the buildds still on 3.8?
[21:00] <infinity> Or a bug in the binutils patches from APM that doko accepted?
[21:00] <infinity> But I'm pretty sure I've built glibc in the archive since then.
[21:00] <infinity> mwhudson: The buildds are still on 3.8 until I can adequately test a distro kernel for sanity, yeah.
[21:00] <mwhudson> i guess binutils could do this too for sure
[21:01] <mwhudson> infinity: do you still want to see build log / debdiff?
[21:01] <infinity> So, binutils could absolutely do that, but the last eglibc upload to the archive was after the last binutils, by several days.
[21:01] <infinity> So it's probably not that.
[21:02] <infinity> mwhudson: Diff yes, log no, your snippet was enough.
[21:02] <mwhudson> infinity: http://paste.ubuntu.com/7191589/
[21:02] <infinity> mwhudson: Also, find the tst-tls5 invocation in your log and try running that massive line of goop by hand a few times to see if it's just racy/confused somehow.
[21:02] <mwhudson> i assume you don't just want to take my word for it and upload that to the archive? :)
[21:02] <infinity> Though that doesn't look racy.
[21:02] <mwhudson> it's failed the build twice
[21:03] <infinity> mwhudson: I'll throw your patch at a PPA and see how it fares on the distro builders too.
[21:03] <mwhudson> the first time i thought it might have been moving the time by 140 years during the test suite...
[21:03] <mwhudson> infinity: that would be great, thanks
[21:03] <infinity> mwhudson: Some headers in said patch that indicate origin and the like would be nice. :P
[21:04] <infinity> mwhudson: And maybe some prodding of Will to push harder to get it re-reviewed and committed.
[21:04] <mwhudson> infinity: heh, yes
[21:04] <mwhudson> does quilt refresh eat comments like that>?
[21:04] <mwhudson> i quilt import-ed the git format-patch version i think
[21:05] <mwhudson> and yes, i don't think will's reposted the patch yet
[21:22] <infinity> mwhudson: quilt refresh should ignore everything above the patch itself.
[21:24] <infinity> cjwatson: Hey, grub-probe has an FD leak, according to LVM.
[21:24] <infinity> (LVM, the best leak tracer EVER)
[21:25] <mwhudson> infinity: hm ok, i wonder what i did wrong then
[21:46] <bdmurray> stgraber: could you have a look at bug 1300516?
[21:48] <stgraber> bdmurray: looks reasonable to me
[21:49] <stgraber> I'd probably make it: [ ! -d "$HOME/.cache/upstart" ] && mkdir -p "$HOME/.cache/upstart"
[21:49] <stgraber> which is shorter and covers some corner cases (spaces and such)
[21:50] <bdmurray> stgraber: okay, do you want to apply / upload that or should I?
[21:51] <stgraber> bdmurray: I can do it
[21:53] <stgraber> bdmurray: uploaded
[21:54] <juliank> infinity: So, (Continuing here, rather than on #debian-devel) Does http://paste.debian.net/91079/ look sensible for trusty?
[21:56] <infinity> juliank: Why did get_ubuntu_mirrors go away?
[21:56] <juliank> bdmurray: In case you're bored, you're opinion is appreciated as well. If we can get that python-apt into trusty, I'll just upload it to Debian as 0.9.3.5 and we can sync. Otherwise, we'd need cherry-pick the python/tag.cc and possibly the debian/* changes.
[21:57] <juliank> infinity: Because we use a script get_ubuntu_mirrors_from_lp for a long time already.
[21:57] <juliank> The old one is unused and broken.
[21:57] <infinity> juliank: The python2.6 cleanups look fine to me to accept as-is.
[21:57] <infinity> juliank: Ahh, kay.
[21:58] <infinity> juliank: In that case, that all looks fine, assuming a changelog that explains it.
[22:09] <juliank> infinity: Now the only question is, should I follow APT into 1.0 land and name the release 1.0.0 or should I stick with 0.9.3.5, or should I use 0.9.4. That's an important question!
[22:10] <infinity> juliank: Whoa, apt went 1.0?
[22:10] <juliank> It's bug fix only, but hey super stability is a good reason for a 1.0
[22:10] <juliank> infinity: Yes, today.
[22:11] <xnox> juliank: i thought that was april's fools joke.
[22:11] <juliank> Or yesterday, depending on location (it's now yesterday here)
[22:11] <infinity> I don't know how to deal with this information.
[22:11] <xnox> bah, it did =) http://packages.qa.debian.org/a/apt/news/20140401T170442Z.html
[22:11] <infinity> Michael just broke my brain.
[22:12] <xnox> also, appears to use a very small key.
[22:12] <infinity> juliank: Anyhow, version it how you like.  But if you want to imply that "this is the python-apt you should use with apt 1.0", going for the version bump might make sense.
[22:12] <juliank> Meh, now python-apt FTBFS on Debian because of a new pyflakes version which complains about more things.
[22:13] <juliank> We're shadowing _ in a loop variable.
[23:09] <xnox> barry: i ponder if we'll manage to drop python2 from the desktop cd this cycle =)
[23:10] <xnox> barry: if we push printing stack it should be all tip-top.
[23:10] <Unit193> gstreamer0.10 is close.
[23:11] <xnox> that too.
[23:11] <xnox> cyphermox: any news on bluez-gstreamer?
[23:12] <xnox> cyphermox: i'm tempted to just drop it, and see if anything breaks.