[00:06] <mwhudson> there must be some way to translate a control file's build-depends line into a command to feed to apt-get?
[00:06] <mwhudson> actually maybe not
[00:10] <jtaylor> mk-build-deps -ir
[01:00] <mwhudson> jtaylor: ah thanks!
[01:00] <mwhudson> now for my next question
[01:01] <mwhudson> i have on my laptop some changes that i want to test build on a different machine
[01:01] <mwhudson> what's the most efficient way to get them onto that machine?
[01:01] <mwhudson> apt-get source on that machine and then scp a debdiff?
=== salem_ is now known as _salem
=== timrc is now known as timrc-afk
[05:27] <dholbach> good morning
[08:04] <pitti> stgraber: related to that, shold we merge criu 1.3.1-1 from sid for utopic, or are we fine with 1.3~rc1 that we have in utopic?
=== tvoss|food is now known as tvoss
[08:04] <pitti> infinity: fixed autopkgtest is  waiting in unapproved since this morning; ok to accept this?
[08:05] <pitti> infinity: (same version that's running in production)
[08:17] <infinity> pitti: Accept away if you haven't already.
[08:32] <infinity> pitti: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1381968
[08:32] <ubottu> Ubuntu bug 1381968 in linux (Ubuntu) "Fstrim destroys data on loopback device" [Critical,Confirmed]
[08:34] <pitti> infinity: opened in tab, will have a look soon; this works differently in utopic (fstrim --all), so hopefully it's not an issue in utopic too
[08:35] <infinity> pitti: I think it's your dm/md-check-skip feature that's at fault here.
[08:35] <infinity> pitti: Since that seems to imply that we trim *anything* behind dm/md, which can't be right...?
[08:41] <pitti> infinity: that was the idea, yes, as we can't run hdparm on a dm device; then if there's something behind it that fstrim can't deal with, fstrim will fail with an error
[08:42] <pitti> infinity: so for fstrim'ing dm devices we ignore the errors, while on real-iron block devices we do show errors (as we want to know if fstrim fails on devices where it really Should Work™)
[08:43] <pitti> so apparently fstrim wreaks havoc on loop devices, so we need to explicitly black list them (I haven't looked at the bug in detail yet)
=== vrruiz_ is now known as rvr
[08:56] <apw> pitti, i have been attempting to repro that on T and U and so far ... not so much
[08:59] <apw> pitti, oh i wonder if he has a device behind the loopback that is buggy ...
[09:00] <infinity> apw: That shouldn't matter, should it?  It's trying to trim the file, not the device?
[09:01] <infinity> (Or, so I'd assume)
[09:03] <apw> infinity, i would nope not indeed, then again it works fine for me
[09:03] <shadeslayer> dholbach: poke, re licensing stuff that was waiting on Canonical Legal, any updates on that
[09:04] <infinity> apw: I can see, in theory, how trying to trim a sparse file could explode, if you were mistakenly treating it as a real block device.
[09:04] <pitti> apw: it seems fstrim -v <mount point of my block device> actually does succeed
[09:04] <dholbach> shadeslayer, I'll send a mail, thanks for the reminder
[09:04] <shadeslayer> Cheers
[09:04] <infinity> apw: Were you testing sparse or complete?
[09:04] <shadeslayer> dholbach: this is going too slowly though :(
[09:05] <dholbach> shadeslayer, I'm not involved in the discussions and I don't know how complicated they are, so I can't comment
[09:05] <apw> infinity, i am using the ORs "reproduce it this way" script
[09:05] <shadeslayer> dholbach: roger
[09:06] <dholbach> shadeslayer, I'll ask for an update now
[09:08] <pitti> apw, infinity: so shuld we workaround this in fstrim-all, by either scanning the md to see if there's any loop device behind it and then not trim it? or make fstrim fail on loop devs?
[09:09] <pitti> I just fstrim'ed a non-sparse 1 GB loop file and that seems to work well, but I guess the issue is only with sparse files
[09:09] <infinity> pitti: Well, apw can't reproduce with sparse either.
[09:09] <infinity> pitti: So, I think it would be sane for us to sort out a way to actually reproduce it, so we can hunt down if utopic is also effected, etc.
[09:09] <infinity> (Or if the problem is local to the submitter's machine, for some reason)
[09:10] <infinity> pitti: But, yeah, assuming the issue is that fstrim and loop devices don't love each other, refusing it in fstrim itself (not the wrapper) makes more sense.
[09:11] <pitti> infinity: right, it's just not entirely trivial to determine that; you might have a an LVM where one PV is an MD device out of dm devices built from loop devs, and similarly funny things
[09:12] <pitti> infinity: if that's a problem, then I think a safer approach would be to stop trimming those "virtual" block devices at all and only trim "direct hardware" block devices like sdXX
[09:15] <infinity> pitti: I could get behind that solution, too.
[09:15] <infinity> pitti: But I'd like evidence of what the bug actually *is* first.  The fact that neither you or Andy can reproduce it smells a bit fishy.
[09:16] <pitti> infinity: yes, of course
[09:16] <pitti> (NB I'm just here with 1/4 of a brain/attention)
[09:16] <infinity> Join the club. ;)
[09:16] <pitti> infinity: I already destroyed my fs once this week, I'd rather do the second try at home when I have my backup USB right next to me :)
[09:17] <infinity> Not to fear, though, what's left of our brains will be killed off tonight.
[09:22] <infinity> mvo: Pokity poke poke.
[09:22] <infinity> mvo: Someone whose name I won't invoke publicly because he's on vacation mentioned that LP: #1381986 might be an apt-cdrom bug fixed in sid.  Do you know more?
[09:22] <ubottu> Launchpad bug 1381986 in debian-installer (Ubuntu) "base-installer: error: exiting on error base-installer/kernel/no-kernels-found in utopic server installs from 20141011" [Critical,Confirmed] https://launchpad.net/bugs/1381986
[09:24] <mvo> infinity: right, let me upload the, I'm very sorry for this
[09:30] <infinity> mvo: Bugs happen, but a quick fix would be nice. :)
[09:31] <mvo> infinity: already uploaded
[09:31] <infinity> mvo: My hero.
=== doko_ is now known as doko
[09:50] <dpm> hi cjwatson, I'm told you're the person to ask for this: would it be possible to sync myspell-ca from utopic to the rtm archive? I've got an MP to add a Catalan keyboard + predictive text + spellcheck, which depends on myspell-ca, but it's only available in the ubuntu archives
[11:02] <roaksoax> /wi/win 3
[11:17] <doko> pitti, autodep8 MIR missing (pulled in by autopkgtest)
[11:17] <stgraber> pitti: I think we need 1.3.1 to get things working, so if we care about having the feature in utopic, then a merge would be nice
[11:17] <stgraber> tych0: ^
=== infinity changed the topic of #ubuntu-devel to: Archive: Final Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[11:18] <tych0> stgraber: yes, 1.3.1 is the latest tagged release. whatever we do, we shouldn't include 1.3 :)
[11:19] <tych0> pitti: a merge would be much appreciated :)
[11:22] <israel> Hi, I have a question about pkexec.  I am building from a minimal base, how do I force pkexec to use a graphical dialog?
[11:31] <pitti> doko: ah, needs a MIR; I'll file one
[11:39] <pitti> doko: bug 1382524
[11:39] <ubottu> bug 1382524 in autodep8 (Ubuntu) "[MIR] autodep8" [Undecided,New] https://launchpad.net/bugs/1382524
=== MacSlow is now known as MacSlow|lunch
[12:11] <pitti> stgraber, tych0: I can probably squeeze it in somehow, but as this doesn't really fall into any final freeze category I'd rather have the release team's +1 first
[12:12] <pitti> or we make infinity do it as he introduced the first delta :)
=== _salem is now known as salem_
=== timrc-afk is now known as timrc
[12:35] <rbasak> Somebody probably needs to look at bug 1377813.
[12:35] <ubottu> bug 1377813 in tzdata (Ubuntu Trusty) "tzdata SRU to 2014f because of law changes in Russia" [Critical,Confirmed] https://launchpad.net/bugs/1377813
[12:35] <rbasak> Oh
[12:35] <rbasak> Somebody is.
[12:35] <rbasak> Never mind.
[12:40] <pitti> rbasak: socket activation! *cough*
[13:05] <Jon> greetings all. I'm trying to fix a bug in sssd in trusty; but I can't find where the source is kept. LP seems to be out of date; and trusty tags/branches aren't in the Debian VCS. Anyone any idea what's actually being used?
[13:08] <rbasak> Jon: https://launchpad.net/ubuntu/+source/sssd
[13:08] <rbasak> Jon: click on one of the versions there, and you can see the source downloads.
[13:09] <rbasak> Generally we use a tools "rmadison" and "pull-lp-source" for CLI equivalents of that.
[13:10] <rbasak> Jon: we appreciate all help in fixing bugs in Ubuntu. But note that a fix can't land in Trusty sssd without having been fixed in Utopic first (or now, Utopic+1 probably)
[13:10] <rbasak> Jon: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure has the steps you will need to follow once you have a fix ready.
[13:11] <rbasak> pitti: good point!
=== MacSlow|lunch is now known as MacSlow
[13:19] <pitti> rbasak: I meant wrt. your bug reply of having to find out the right dependencies in advance
[13:19] <rbasak> pitti: yeah I get it. I didn't think of socket activation as a way to solve this problem.
[13:19] <Jon> rbasak: thanks - so if I understand right, they've basically given up on using VCS for changes to sssd in trusty since 1.5.8-0ubuntu3 / 2011?
[13:20] <Jon> rbasak: re fix in utopic; my priority is to fix the bug for me in trusty, I'll at least report and file a diff, but I may not take it further myself (don't have any utopic systems anyway so I'd have to do quite a lot of work to fix it there)
[13:20] <rbasak> Jon: we never really used VCS for changes to sssd in the first place. What you see there is the importer importing into VCS for convenience, and that broke in 2011.
[13:20] <Jon> aah I see. mild-boggle but at least I understand now!
[13:21] <rbasak> (it's always been somewhat fundamentally broken; there are plenty of other packages that are also stuck like that)
[13:22] <rbasak> Jon: OK. We can't make you do anything, but if we fix it in Trusty but not in the development release, then users get a regression on upgrade, which is why we don't do it.
[13:22] <rbasak> Jon: if it helps, VMs and LXC are useful here, to test and reproduce on development releases. You probably want to have a reproducible test case anyway.
[13:23] <Jon> rbasak: oh no I totally understand why the process is that way; it's just I'm looking at this on salary
[13:24] <rbasak> Jon: sure, I understand. You still have a case for fixing the development release on salary though; not doing so time-limits your fix. You'll need to upgrade eventually.
[13:24] <Jon> nod, there is that
[13:25] <rbasak> And it's easier to deploy and manage if you are running a version published in the archive. Otherwrise you have to maintain your patched version.
[13:25] <rbasak> And sssd is in main in Trusty, so you get the benefit of Canonical's security team looking at the version in the archive for free, too, as opposed to your patched version.
[13:25] <rbasak> I'm just trying to give you some reasons for your manager :-P
[13:28] <Jon> btw which ubuntu version is the move-to-systemd one? (this bug is upstart-specific)
[13:29] <sarnold_> afaik not yet set in stone
[13:29] <Jon> sure
[13:29] <sarnold_> one hopes it'll be in two releases before an LTS release, but we might only get one..
[13:29] <Jon> sigh at some point I need to vote on the Debian systemd GR stuff... great fun
=== timrc is now known as timrc-afk
[14:21] <stgraber> pitti: +1
[14:21] <stgraber> pitti: if I don't do the work, I've got no conflict of interest in using my release team hat to +1 this :)
[14:21] <pitti> stgraber: for merging? I'll have a look in the train
[14:21] <pitti> stgraber: I haven't touched criu at all, but I was planning to look at it as it sounds awesome
[14:22] <pitti> stgraber: so I can test it while I'm at it
[14:22] <stgraber> yeah, and IIRC the current one is just completely broken, so it fits the "can't possibly be worse" category
[14:22] <pitti> oh, is that so
[14:22] <pitti> stgraber: thanks for the warning, so I won't scratch my head wondering if I did something wrong :)
[14:23] <pitti> on that note --- infinity: https://launchpad.net/ubuntu/+source/criu/1.3~rc1-1ubuntu1 -- qoui ?
[14:24] <pitti> infinity: that was to fix the FTBFS, right? or something else?
[14:26] <infinity> pitti: Yeah.
[14:26] <infinity> pitti: It was passing GCC arguments to ld.
[14:26] <infinity> pitti: ie: -Wl,--foo instead of --foo
[14:27] <infinity> pitti: My gross hack was the quickest path to sanity, cause fixing the upstream mess wasn't a high priority the day I uploaded that. :P
[14:27] <infinity> pitti: Obviously, the right answer is to convert the upstream makefiles to link with gcc instead of ld.
[14:34] <dholbach> happyaron, can you accept Jonas/Jack in the LP team of Ubuntu China User team? thanks
[14:35] <happyaron> dholbach: that's done already, 
[14:35] <dholbach> happyaron, excellent!
[14:35] <happyaron> :)
[15:07] <bdmurray> mvo__: will you have a look at bug 1380774?
[15:07] <ubottu> bug 1380774 in apt (Ubuntu Utopic) "debian-installer does not find kernel" [Critical,Triaged] https://launchpad.net/bugs/1380774
[15:34] <mvo__> bdmurray: is this still reproducable with apt 1.0.9.2ubuntu2 - I *hope* this upload fixes it
[15:34] <mvo__> (I'm actually pretty sure, but you never know)
[15:36] <bdmurray> mvo__: ah, I'd missed there was a new upload
[15:37] <mvo__> bdmurray: I uploaded it some hours ago, I think the bug referes to the 1.0.9.2ubuntu1 version but please let me know if I'm wrong
[15:38] <pfsmorigo> is there a way to avoid using ipv6 during ubuntu installation? It seems that aptinstall prefers ipv6 and the installation fails because I don't have ipv6 here.
[15:38] <bdmurray> mvo__: will do, thanks
[15:38] <pfsmorigo> using daily image from oct 10 for ppc64el
[15:56] <pitti> infinity: I'm asking as the current debian sid version builds just fine, and also has the b-dep fix
[15:56] <pitti> IOW, we can sync criu if we need it
[15:56] <pitti> stgraber: however, I tested the current utopic version and it's far from "completely broken"; it works more or less like advertised
[15:57] <pitti> stgraber: but I tested plain "criu dump"/"criu restore", not with lxc
[16:02] <pitti> stgraber: "sudo lxc-checkpoint -v -n systemd-tests -D /tmp/checkpoint" indeed fails, but with both versions (and no helpful output)
[16:03] <pitti> other than maybe "lxc_container: lxccontainer.c: criu_ok: 3671 lxc.tty must be 0"
[16:06] <pitti> stgraber: so, the final version works just as well as utopic's for a simple "yes" process, and lxc-checkpoint is broken with either; so I did a sync request which will get us rid of the delta and to the final versoin
[16:06] <pitti> stgraber: so accept/reject as you see fit :)
[16:08] <pitti> stgraber: oh, err, auto-accepted; not seeded, no reverse depends and such :) shouldn't lxc at least suggests: it?
=== timrc-afk is now known as timrc
[17:08] <smoser> ok. i have a file /var/crash/_usr_lib_unity_unity-panel-service.1000.crash
[17:09] <smoser> unity-panel-service is in a crash loop
[17:09] <smoser> segfaulting
[17:09] <smoser> given that i have .upload and .uploaded, does that mean those got uploaded ? and is there a bug
[17:30] <SpamapS> doko: FYI, I'm working on an SRU for python3.4 in trusty
[17:30] <SpamapS> doko: https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1382607
[17:30] <ubottu> Ubuntu bug 1382607 in python3.4 (Ubuntu Trusty) "[SRU] Backport python3.4 logging module backward incompatibility fix." [High,In progress]
[17:41] <smoser> ok. so going further on the above unity crash.
[17:41] <smoser> why doesn't this work:
[17:41] <doko> SpamapS, ok, but I hope I'll get my 3.4.2 backport approved next week
[17:41] <smoser>  sudo apport-cli /tmp/_usr_lib_unity_unity-panel-service.1000.crash
[17:41] <SpamapS> doko: OH
[17:41] <smoser> i hit 'S' (send report) and it immediately exits.
[17:41] <SpamapS> doko: but is that to trusty-backports ?
[17:41] <doko> no, -updates =)
[17:41] <SpamapS> doko: or trusty-updates ?
[17:41] <SpamapS> ohh sweeet lets just do that
[17:42] <doko> SpamapS, are you at the sprint?
[17:42] <SpamapS> doko: what sprint?
[17:42] <SpamapS> I am a ghost
[17:42]  * smoser misses SpamapS too
[17:43] <doko> SpamapS, if you want to test, see the ubuntu-toolchain-r/ppa PPA. survived a trusty main rebuild
[17:43] <SpamapS> doko: is there a trusty bug report I can point to?
[17:43] <SpamapS> smoser: I miss you all very mcuh. :)
[17:43] <doko> 1348954
[17:43] <doko> a bit empty
[17:43] <SpamapS> mcuh being the algonquien word for "some"
[17:44] <SpamapS> doko: thats fine, just want people to be able to track it.
[17:45] <SpamapS> doko: ah I didn't see that bug because it isn't linked to trusty series. :-P
[17:45] <SpamapS> doko: well anyway, I'll leave you be. :)
=== roadmr is now known as roadmr_afk
=== roadmr_afk is now known as roadmr
=== salem_ is now known as _salem