[03:29] <hallyn> pitti: mind you i think it's a shame :)
[06:52] <pitti> Good morning
[06:52] <didrocks> good morning pitti
[06:52] <pitti> bonjour didrocks !
[08:22] <brainwash> pitti: hi. does pkexec work for you? running "pkexec whoami" gives me:
[08:23] <brainwash>  polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
[08:30] <brainwash> bug 1288786
[08:30] <brainwash> same error message in comment #7
[08:57] <mwhudson> doko: ping, did you see https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1586872
[09:20] <mapreri> cjwatson: really not totally sure how this could be possible, but indeed using -O2 instead of -O3 (at least, that's the only relevant change I see) made cowdancer build on pcc64el.
[09:20] <mapreri> https://volatile.mapreri.org/2016-06-02/d177d0ca47a32d7e2a8a05675de28948/0.80_0.80u1.html — if you are fancy looking the diff of the 2 logs and figure it out :|
[09:29] <mapreri> Thank you very much for the precious hint!
[09:38] <cjwatson> np
[10:18] <Odd_Bloke> What package creates/manages /etc/nsswitch.conf?  (And how can I work this out for myself in future?)
[10:22] <brainwash> Odd_Bloke: try  dpkg -S /etc/nsswitch.conf
[10:22] <rbasak> Odd_Bloke: failing that (which it will as it isn't a conffile), "grep nsswitch.conf /var/lib/dpkg/info/*" is a quick hack to find maintainer scripts on your system that reference it.
[10:22] <rbasak> Odd_Bloke: looks like the answer is base-files.
[10:23] <Odd_Bloke> brainwash: rbasak: Thanks! :)
[10:24] <Unit193> rbasak: Don't forget apt-file 'nsswitch.conf'
[10:40] <ubuntu577> Hello all,  need help  .. how to rebuild the ppa to another architecture.
[10:42] <ubuntu577> sorry .. I mean  how to build  Archives  to another architecture  through ppa
[10:42] <cjwatson> ubuntu577: PPAs automatically build packages for all architectures they're configured to build for, but you can enable some additional architectures that aren't enabled by default using the "Change details" page on the PPA
[11:18] <xnox> ogra_, do you have time at all to look into initrafs-ubuntu-touch thing? it has not been rebuild for a while. I've tried dropping adbd (apperantely doesn't work and not available on arm64) and enable arm64 build and no dice.
[11:18] <xnox> it build locally, but fails in a launchpad ppa.
[11:19] <xnox> ogra_, https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+build/9844912
[11:25] <ogra_> xnox, hmm
[11:25] <ogra_> + fakechroot chroot ./build apt update
[11:25] <ogra_> /usr/sbin/chroot: failed to run command ‘apt’: No such file or directory
[11:26] <ogra_> why would it not run apt-get
[11:26] <zander> I'm trying to upload a packaged version of my software to launchpad. It gives me "rejected" with no useful error message. Is there anyone that can help out?
[11:27] <xnox> ogra_, it did run apt-get before, and resulted in similar error messages "apt-get not found" changed to apt, no dice.
[11:27] <xnox> ogra_, somehow debootstrap log shows loads of errors too.
[11:27] <xnox> locally it builds fine.
[11:27] <cjwatson> zander: Can you provide your dput command line?
[11:27] <ogra_> weird
[11:28] <zander> cjwatson: dput ppa:bitcoinclassic/bitcoinclassic  bitcoinclassic_0.12.1-trusty1_sources.changes
[11:29] <cjwatson> zander: Are you sure you didn't get a useful error message?  Our logs show that we sent you one indicating that dpkg-source failed to extract the source package
[11:30] <cjwatson> starting with "dpkg-source failed for bitcoinclassic_0.12.1-trusty1.dsc [return: 2]"
[11:30] <cjwatson> it's slightly cryptic I'll grant ...
[11:31] <zander> The full text is http://paste.ubuntu.com/16918003/
[11:31] <zander> I can't find the actual error.
[11:31] <zander> Nothing I can use to fix it, anyway.
[11:32] <cjwatson> zander: So one thing that this can sometimes be is that our production systems (unfortunately) still run on precise, and it's occasionally possible to construct a source package that precise's dpkg-source obscurely fails to unpack like this.
[11:32] <cjwatson> zander: Can you put the source package somewhere I can see?  I recognise most of the usual causes of this by now
[11:32] <zander> sure
[11:34] <ogra_> xnox, i think the deboostrap.log looks fine though (the pre-dep moaning is notmal IIRC)
[11:34] <ogra_> *normal
[11:36] <zander> cjwatson: http://thomaszander.se/foo/
[11:38] <cjwatson> zander: Right, the problem is that debian/patches/series lists a patch that doesn't exist.  In fact dpkg-source in xenial fails to unpack the package in a similar way.
[11:39] <zander> isn't series supposed to list the release? Trusty in this case?
[11:40] <cjwatson> No.
[11:40] <cjwatson> Not even a little bit :)
[11:40] <cjwatson> It's a quilt patch series.
[11:40] <zander> ok, I guess I misread a tutorial somewhere :)
[11:41] <zander> My intention was to host several 'versions'. For the different ubunutu releases.
[11:41] <cjwatson> You could probably just delete debian/patches/ entirely, as it is.  But if you need patches in future, then each line in debian/patches/series should be a file in debian/patches/ which is a patch file applied to the upstream source code.  You'd normally manage those with quilt or with some more sophisticated tooling around it.
[11:44] <zander> Since I develop on debian, I would just change the actual sourcetree. I'll delete the dir.
[11:49] <zander> cjwatson: its building now \o/
[11:49] <zander> So, how can I get it build for more than one version of ubuntu?
[11:52] <cjwatson> zander: Often it's entirely unnecessary to have multiple builds, and you can just upload to the oldest series you want to support and then copy it forward to all the other ones using "Copy packages" in your PPA and telling it to copy existing binaries.
[11:52] <zander> ah
[11:53] <cjwatson> zander: But if you really need to build separately for different Ubuntu series, then you can just build source packages with different versions (usually just changing the bit after the last "-") and a different target in the top entry in debian/changelog.
[11:54] <zander> That makes sense. thanks
[12:27] <zander> Another question. Is there a simple way to append the filelist to the .dsc file?  I now manually run things like sha1sum.
[13:08] <pete-woods> pitti: thought it had been a while since I nagged about python-dbusmock, so here's a little PR for you (https://github.com/martinpitt/python-dbusmock/pull/21)
[13:29] <cjwatson> zander: Err, you should never have to edit the .dsc by hand.  What are you finding that you need to add to it?
[13:30] <zander> cjwatson: 'add to it'... I need to *create* it.  Since I have not found any tool to do so for me.
[13:30] <cjwatson> zander: debuild -S
[13:31] <cjwatson> zander: really really do not write the .dsc by hand :-)
[13:32] <cjwatson> debuild is a wrapper around dpkg-buildpackage, and you can use that too, but debuild is a little more convenient
[13:33] <zander> I tried to run that a couple of times. Never got any useful output from it.  For instance; http://paste.ubuntu.com/16919442/
[13:33] <cjwatson> zander: Was that before or after you removed the nonsense debian/patches ?
[13:34] <zander> thats just now. I removed the patches dir.
[13:34] <cjwatson> zander: can you post 'find -ls' from there so that we can orient ourselves?
[13:35] <cjwatson> debuild -S is what basically everyone else uses so you have some weird corner case here
[13:36] <cjwatson> zander: It sounds like perhaps you have "debian" as a symlink, which isn't allowed
[13:37] <zander> http://paste.ubuntu.com/16919488/
[13:37] <zander> Hmm, I'll move the debian dir...
[13:38] <cjwatson> Right, the debian directory must always be at the top level of the package's ordinary source tree, and not a symlink
[13:39] <zander> but its Ok to not have it inside the .orig.tgz ?
[13:39] <cjwatson> Indeed, it's normal not to have it in the orig.
[13:39] <zander> Well, i guess I got bitten by lots of little rules :)
[13:40] <zander> But it seems to work now. Which makes me quite happy.
[13:40] <cjwatson> Excellent
[13:42] <mgedmin> would be nice to improve the error message about 'debian' not being a directory
[13:43] <mgedmin> e.g. "add_directory() only handles directories at /usr/share/perl5/Dpkg/Source/Package/V2.pm line 556." doesn't even mention what the not-directory was
[13:51] <pitti> xnox, infinity, tinoco: aupkg02 (10.100.0.13) is still down (since yesterday), could one of you please torture it with the right stick?
[13:59] <xnox> pitti, it has a stalled task on the CPUs
[14:00] <xnox> with kthreads starved for 17227361 jiffies
[14:00] <xnox> force poweroff, rebooting
[14:00] <xnox> pitti, booted
[14:01] <tuxinator> hi all, since some time (only have time to investigate now, my mirror does not sync from cdimage.ubuntu.com::cdimage/
[14:01] <pitti> xnox: cheers!
[14:01] <tuxinator> the error message is only  change_dir "/daily/current" (in cdimage) failed: No such file or directory (2)
[14:01] <tuxinator> at my site the directorys exist
[15:31] <arges> bdmurray: can you sru-review kpatch/xenial today? Thanks
[15:34] <bdmurray> arges: sure
[16:19] <nacc> rbasak: so i had to remove one of our optimizations from the algorithm -- the one that looks for launchpad versions 'greater than' the tip's version when doing an import to an existing repository. Because of the case of versions going backwards potentially ... so i'm now using the publishing date and asking for published history after a committed date (this also minimizes our lp traffic). Does that
[16:20] <nacc> seem sane? I'm thinking I may fudge it a little bit to make sure we don't 'miss' any publishes (still considering corner cases)
[16:21] <rbasak> nacc: I think going by publishing date is fine. That's what I thought we were doing already!
[16:23] <nacc> rbasak: launchpad_revs_greater_than(debian, last_debian_version) (and similar for ubuntu)
[16:23] <nacc> rbasak: so we were (in my old undrstanding) using the versions, not the dates
[16:24] <rbasak> nacc: fair enough. We've changed plans so many times I lost track, sorry. I think publishing dates is fine as long as it doesn't interfere with import ordering in some unexpected way.
[16:24] <rbasak> (I don't see why it would).
[16:24] <rbasak> And in fact, going by publishing date is probably more accurate for the pocket parent in this new world order.
[16:25] <nacc> rbasak: ack, that's what i'm thinking too -- i just need to make sure we're capturing and passing the date properly as far as the JSON goes (so we don't miss stuff published, e.g., the same day let's say)
[16:36] <nacc> rbasak: a new interesting case, python-pip (https://launchpad.net/ubuntu/+source/python-pip/+publishinghistory?batch=75) -- 8.1.2-1 was in debian/sid (first seen there) then yakkety-proposed then yakkety-release. Our history indicates the version from debian/sid was copied to yakkety-proposed and yakkety, as opposed from debian/sid to yakkety-proposed and then from yakkety-proposed to yakkety-release.
[16:36] <nacc> This turns out to be true based upon the publishing logs (both indicate copies from debian/sid). But is that always the case?
[16:43] <nacc> ogasawara_: is there a reason there aren't xenial directories in http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D ? Apologies in advance if you're not the right person to ask :)
[16:46] <rbasak> nacc: I'm not sure why that happened. Something to do with archive opening perhaps? It'll create some slightly different history in our import but is otherwise OK, right?
[16:47] <nacc> rbasak: yeah, i'm not 100% either -- to clarify, the algorithm as written now, for a version that has already been imported previously, will mark as the 'changelog parent' the commit corresponding to the first import of that version. I'm just trying to think if that is correct or not :)
[16:48] <rbasak> nacc: if it does affect us then I'd have to ask someone like Colin to explain.
[16:49] <rbasak> nacc: would a parent minimisation function help us here? If the commit has two parents A and B, and A is an ancestor of B, then eliminate A.
[16:50] <rbasak> I'm not sure if that makes sense or not for us. Not thought it through.
[16:55] <nacc> rbasak: we probably should add something liek that, but i don't think it applies to this particular case. The two parents are distinct (the pocket parent is the old yakkety release version, correctly)
[16:57] <nacc> rbasak: from a code content perspective our algorithm is correct; i'm just not sure we have enough information from any source to know where something gets copied from, let me see if launchpadlib says
[17:00] <ogasawara_> nacc: I see we have xenial for 4.4.9, .10, .11, and .12...is there a specific version you were hoping to find?  I don't believe we have anything earlier than that because xenial hadn't been officially released until end of april, so build after that would use xenial's config.
[17:04] <nacc> ogasawara_: i might just be misunderstanding hte layout of the directories, but there is a 4.6-rc6-wily, but not a 4.6-rc6-xenial ?
[17:04] <nacc> ogasawara_: in fact those 4 you found are the only xenial, but there are many more for wily and (now) yakkety
[17:05] <nacc> ogasawara_: someone in #ubuntu was asking how to test mainline on xenial for a bug report, and i wasn't sure if we'd normally advise them to just use latest-yakkety (and if that would work properly, i'd worry about deps)
[17:05] <rbasak> nacc: do we need to know where the code was copied from? Since the trees are identical and a previous uploader (or archive admin) could have copied from a different pocket (but the same version), then from a source package perspective, is it fundementally part of the data we're trying to capture at all?
[17:07] <nacc> rbasak: no, we probably don't. But I want to make sure we don't accidentally lose some publishing information. So let's say that in this case, the yakkety version had gone debian -> y-proposed -> y-release. There would be no link in our git tree from the y-release commit to y-proposed, because the first import was in debian and that's where we'd point the 'publish parent' commit to.
[17:11] <rbasak> nacc: I understand how that loses some information about publication ordering, but my initial feeling is that it's OK. We're interested in the history of the code, and the code hasn't changed. One might consider all of the commits sharing a version to be bundled together, and as a whole the graph edges to and from the bundle would be correct.
[17:11] <nacc> rbasak: yep, absolutely
[17:11] <nacc> and in theory, the one in any other pocket *did* come from the first one, by definition, aiui
[17:12] <nacc> so we're bsaically doing a bit of optimized parent following :)
[17:12] <rbasak> Yeah. Sort of like git and renames again :)
[17:13] <ogasawara_> nacc: I'm reaching out to apw for clarification as I actually was only expecting to see 4.6-rc# builds against yakkety
[17:17] <nacc> ogasawara_: ack, thanks! yeah, i think that's what is confusing the user (and me) :)
[17:18] <cjwatson> nacc: the copy-from information in fact tells you where it was originally uploaded to, not the previous hop in the chain; so what you're seeing is expected.
[17:21] <nacc> cjwatson: ah ok, thanks for clarifying -- that makes me happy that our algorithm will match that :)
[17:21] <nacc> cjwatson: even if accidentally...
[17:35] <RobertDupont> hello guys
[17:36] <RobertDupont> I found a bug in an iptables module and I was wondering if I have to report it to iptables or kernel
[17:36] <RobertDupont> rule is inserting just fine
[17:36] <RobertDupont> it is just not matching when it should be on 16.04 (works fine on 14.04)
[17:52] <RobertDupont> does anybody know
[17:52] <RobertDupont> or you're just not interested in bug reports?
[17:53] <cjwatson> People aren't very likely to respond to bug reports on IRC, especially if they're a bit ambiguous or difficult to diagnose immediately.  Just report it to wherever you think most sensible, that's better than nothing
[17:54] <RobertDupont> I'm just asking which package I should file it to
[17:54] <cjwatson> (I don't know the answer to exactly where it belongs, though I'd suspect the kernel.  But I reject your false dichotomy that either somebody here knows or nobody is interested in bug reports)
[17:55] <RobertDupont> well, I've filed a couple of reproductible bug reports and nobody has fixed them
[17:55] <RobertDupont> some bugs have been present since 2008 and haven't been fixed
[17:56] <cjwatson> Sure, but also lots of bugs are fixed all the time.  Human effort is sadly finite
[17:56] <cjwatson> Speaking of which, end of day and dinnertime
[17:57] <RobertDupont> apparmor, snort and a few other big ones
[18:08] <Logan> nacc: hey, have you been working on the phpunit-mock-object merge? phpunit is still uninstallable because it depends on phpunit-mock-object >= 3.1, and we have 3.0.6-1+ubuntu1
[18:11] <nacc> Logan: let me do that right now
[18:12] <Logan> thanks!
[18:15] <nacc> barry: https://code.launchpad.net/~usd-import-team/ubuntu/+source/python-pip/+git/python-pip
[18:23] <barry> nacc: cool!
[18:24] <nacc> barry: i took a quick look, it seems correct, and didn't provide any warnings, errors, etc., but do please take a look when you can and let me know if anything looks odd
[18:31] <barry> nacc: will do
[18:31] <nacc> barry: thanks! also just uploaded the helper script for merges at https://code.launchpad.net/~usd-import-team/usd-importer/+git/usd-importer
[18:32] <nacc> and that's the current importer's code too (same repository)
[18:32]  * barry nods
[18:34] <rbasak> nacc: looking at usd-import-reconstruct-merge, it looks good, just a couple of comments.
[18:35] <rbasak> Only from a quick read of the code, so maybe I've got it wrong.
[18:35] <nacc> rbasak: ack, it might need some love, i just cobbled it together last night
[18:35] <rbasak> 1) dsc_commit_tag looks like it might match too much, for example ubuntu1.1 when ubuntu1 is being looked for.
[18:36] <nacc> rbasak: ah you're right, i'll anchor it
[18:36] <rbasak> 2) Never mind, I missed something. Looks good :)
[18:36] <nacc> rbasak: or i could just use -F right?
[18:36] <nacc> oh but that would still need anchoring
[18:37] <nacc> i guess `grep -F -w` ?
[18:37] <nacc> or -x, not sure, i'll read :)
[18:38] <rbasak> I'd use a regexp. Because you're looking for /^(import|upload)\/<version>$/, right?
[18:40] <rbasak> nacc: BTW, we should probably pull together my ubuntu-git-tools repo with the usd-importer repo at some point. No point having them separate.
[18:40] <nacc> rbasak: ack, you're right, becauseall i have is the version, sorry
[18:41] <nacc> rbasak: yep, they are starting to be more related
[18:50] <hallyn> smb: hrmph.  you're telling me my libvirt upgrade/transition stuff was wrong?
[18:52] <smb> hallyn, no, in the end the problem is that we upgraded before it was done completely, so was not executed. I just finishing up some upload that is more persistent
[18:52] <bdmurray> happyaron: How is bug 1297849 related to the network-manager-openconnect upload in xenial-proposed?
[18:55] <smb> hallyn, That systemd suddenly got more picky about a still lingering /etc/systemd/system/libvirtd.service alias to libvirt-bin might be another problem. I decided that I just check and if found remove various files which may still be present when doing 1.3.4 to 1.3.4 upgrades (or fresh install but then its unlikely to find anything)
[18:59] <hallyn> smb: my ego thanks you :)
[18:59] <smb> hallyn, :D
[18:59] <hallyn> makes sense too
[19:00] <hallyn> \o
[19:01] <nacc> rbasak: smoser: pushed updates, thanks to you both!
[19:02] <nacc> caribou: corosync imported, and the helper script dtrt, i think, as far as building you a reconstruct/<version> commit
[19:02] <nacc> rbasak: so the bash script *could* tag the commit too, would that be useful? as I can get the version out of dpkg-parsechangelog given the commit, apply the renaming rules to it, etc.
[19:10] <rbasak> nacc: yeah, that'd probably be useful. Maybe tag it reconstruct/<version> unless that tag already exists, in which case warn?
[19:32] <nacc> rbasak: yep, will work on that now
[19:33] <nacc> rbasak: i probably could dig and find it, but i didn't see a good way of doing cherry-pick without checking out first
[19:35] <rbasak> nacc: you need a working tree I think. The only way to not clobber the user's tree would be to do it like git-dsc-commit and use a temporary directory for the tree I think.
[19:35] <nacc> rbasak: yeah, i was hoping to avoid that route
[19:36] <nacc> rbasak: i think it's "ok" as-is? if someone hates it, we can modify it
[19:39] <nacc> rbasak: and git-tag already does that detection and will emit an appropriate warning, i think
[19:40] <rbasak> nacc: yeah I think it's fine as-is and we can change it later if it's an issue. Generally the user will want to check it out anyway I think, or at least have a clean tree before doing so.
[19:41] <nacc> rbasak: yep
[19:41] <nacc> rbasak: that's a good point, i should probably handle the error case on checkout
[19:42] <rbasak> nacc: perhaps just insist on a clean tree first. I think git-dsc-commit does that.
[19:42] <nacc> rbasak: yep
[19:45] <nacc> rbasak: pushed
[19:45] <nacc> caribou: --^ so the helper script for corosync should generate the reconstruct tag for you now
[19:54] <nacc> rbasak: I really appreciate all the feedback so far! Thanks!
[20:03] <elbrus> rbasak: would you recommend me to try for MOTU (or even ubuntu developer as I'd like to help with my own package dbconfig-common which is in main)
[20:03] <elbrus> and would you endorse my application
[20:03] <elbrus> ?
[20:07] <pitti> infinity: I'm confused about https://launchpadlibrarian.net/262897168/buildlog_ubuntu-yakkety-amd64.autopkgtest_3.20.8_BUILDING.txt.gz -- don't buildd chroots have "deb-src" apt sources?
[20:08] <pitti> (builds fine in my sid and yakkety schroots)
[20:14] <pitti> I can reproduce it if I drop deb-src, but that seems strange for a buildd chroot
[20:19]  * pitti will add a @skipUnless() if there are no deb-src, not much that I can do then
[20:22] <cjwatson> pitti: The default setup for buildd chroots doesn't much matter, since Launchpad blats out its own preferred sources.list anyway
[20:23] <cjwatson> (doesn't matter for builds, that is)
[20:25] <cjwatson> pitti: So in this case it's the one that Launchpad blats out that matters, not what's in the chroot; and Launchpad doesn't write out deb-src lines, because buildds fetch the source straight from the librarian
[20:25] <cjwatson> (except in the private PPA case which currently does a somewhat weird thing, but even that doesn't rely on deb-src)