[01:15] <xcyclist> I have been using https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel, and for instance it says I should see 3 .deb files instead of dozens of files.
[01:16] <xcyclist> Ubuntu kernel builds appear to put out a bunch of stuff, .deb files, .udeb files, and a .tar.gz file, that I don't see specified in a document accurately.  Is there a document I SHOULD  be reading, or can I help updating one that is old?
[01:16] <xcyclist> Please advise how I can be most helpful in either asking a question, reading other documents, or updating inaccuracies.
[01:19] <tsimonq2> xcyclist: Your question's good enough to me, you're just asking in the wrong place. ;)
[01:19] <tsimonq2> xcyclist: Try #ubuntu or #ubuntu-kernel.
[01:20] <xcyclist> Ok.
[01:21] <xcyclist> Thank you.
[01:22] <tsimonq2> You're welcome. Have a good day.
[08:34] <cjwatson> enyc: thanks
[09:24] <juliank> mvo: command-not-found feedback: it is not particularly helpful if I accidentally type lsa. It tells me there are 17 similar ones and to try apt install <deb name>, but not which packages. http://paste.ubuntu.com/p/v5zsTgyYpP/
[09:24] <juliank> with lsx I get a list of commands and packages
[09:28] <mvo> juliank: oh, that is a bug
[09:29] <mvo> juliank: will fix
[09:29] <mvo> juliank: thank you!
[10:04] <cpaelzer> doko: I already had retriggered the ruby-libvirt test for libvirt with the right triggers (needs all proposed for the ruby things to work)
[10:05] <cpaelzer> doko: I see you later on triggerd one as-is (which will fail)
[10:05] <cpaelzer> doko: is there a way to cancel your test request from the queue?
[10:06] <cpaelzer> good: ruby-libvirt {"all-proposed": "1", "requester": "paelzer", "triggers": ["libvirt/4.0.0-1ubuntu5"]}
[10:06] <cpaelzer> bad: ruby-libvirt {"requester": "doko", "triggers": ["libvirt/4.0.0-1ubuntu5"]}
[10:07] <cpaelzer> the second being about 7 pages below the former entry on http://autopkgtest.ubuntu.com/running
[10:20] <cpaelzer> anyone else knowing if/how one can cancel test retires?
[10:20] <cpaelzer> pitti: ^^ ping for being a subject matter expert
[10:23] <pitti> cpaelzer: https://git.launchpad.net/autopkgtest-cloud/tree/tools/filter-amqp
[10:23] <pitti> cpaelzer: but it needs to be run on the infra, i. e. only Laney, infinity, and a few others have access (not me any more)
[10:24] <pitti> there's no public API for it
[10:24] <cpaelzer> ok thanks pitti
[10:24] <pitti> it's usually not a biggie, just some wasted electrons
[10:24] <pitti> this makes more sense when one needs to remove a hundred wrong test requests
[10:24] <cpaelzer> I thought I've had cases where the second (bad) test will again make it not migrate
[10:25] <pitti> cpaelzer: I thought it wrote it so that "any pass wins", not "the latest result counts"
[10:25] <cpaelzer> ok, if that is true I feel better
[10:25] <pitti> but this is becoming a bit blurry, I'm afraid
[10:25] <cpaelzer> in the current case it is the last missing bit, so I assume it will be migrated before it gets to the second test anyway
[10:26] <Laney> I think that's right
[10:27] <pitti> on second look at https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/tree/britney2/policies/autopkgtest.py#n165 , maybe I'm wrong
[10:28] <pitti> but in the worst case, just re-trigger your's again
[10:28] <pitti> uh, the queue is quite long right now
[10:29] <pitti> kde update ho
[10:31] <Laney> I'll just kill it out to be safe
[10:45] <rbasak> enyc: metadata_csum is enabled in Debian stretch I think?
=== Sigyn` is now known as Sigyn
=== Sigyn is now known as Sigyn`
=== Sigyn` is now known as Sigyn
[14:15] <doko> xnox: does xe-guest-utilities need a MIR?
[14:15] <doko> in supported-cloud seed
[14:16] <xnox> doko, it does
[14:16] <xnox> doko, i've started to fill one out, but it is incomplete.
[14:57] <ricotz> mdeslaur, hi, why is clamav depending on llvm3.9 while it ships an internal copy?
[15:00] <mdeslaur> ricotz: which release?
[15:01] <mdeslaur> debian typically strips out the internal llvm and uses the system one
[15:01] <ricotz> 0.99.4+addedllvm-*
[15:01] <mdeslaur> but when we backport for our earlier releases, the system llvm is sometimes too old, so we use the internal one
[15:02] <ricotz> mdeslaur, afaics this is a special ubuntu repack?
[15:02] <mdeslaur> yes, it's a special repack for our old stable releaes
[15:02] <ricotz> it used llvm3.9 on bionic which seems odd
[15:02] <mdeslaur> and I used it for bionic because debian is currently using a pre-release version
[15:02] <ricotz> is uses *
[15:03] <mdeslaur> only trusty actually uses the built-in llvm
[15:04] <mdeslaur> xenial and later use the system llvm
[15:05] <ricotz> I see, the version somehow suggested this is not conditional
[15:05] <mdeslaur> when we released 0.99.4, debian didn't have a tarball yet
[15:05] <mdeslaur> so I just used the same one I prepared for trusty, even though later releases didn't need the internal llvm
[15:07] <mdeslaur> looks like debian has a 0.99.4 tarball in stretch, would could use that for bionic, but meh
[15:07] <ricotz> ok, I also assumed this is a step to get rid of libllvm3.9 which is only used by libclamav7 in bionic
[15:11] <mdeslaur> I hadn't considered that
[15:44] <geofft> cyphermox: are there netplan packages for Debian? (or would you expect the dsc to build on Debian?)
[16:46] <cyphermox> geofft: I expect it would build on Debian fine, the only issue might be version numbers for Depends
[16:47] <cyphermox> I have yet to file a ITP for netplan.io in Debian.
[17:13] <nacc> Odd_Bloke: are you working on any ruby packages right now?
[17:28] <Odd_Bloke> nacc: Other than keeping an eye on autopkgtests to request retries, no.
[17:30] <nacc> Odd_Bloke: ok, i'll start trawling
[21:29] <nacc> slangasek: not urgent by any means, but samba 2:3.6.5-2ubuntu1 is unable to be extracted (dpkg-source -x) in modern Ubuntu, which means we can't get to a patches-applied state (cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850843). Do you have any ideas of what we might do there? We could simply not import that patches-applied version, and I think it would have no impact to our new algorithm.
[21:29] <ubottu> Debian bug 850843 in dpkg-dev "dpkg-source in stretch cannot extract samba_3.6.5-2.dsc" [Important,Fixed]
[21:29] <nacc> But it would mean this one publishing event (or anything like it) isn't in our Git repo
[21:33] <slangasek> nacc: my empty stomach is suggesting options to me that may not be constructive ;)
[21:38] <nacc> slangasek: :)
[21:38] <nacc> slangasek: like i said not urgent, just something to mull over when/if you have time
[21:41] <nacc> slangasek: it doesn't *really* affect us, because we don't treat patches-applied imports as full failures (we figure it's a tooling thing and will get fixed by future fixes to dpkg/etc). However, in this case, there hasn't been much movement (possibly won't ever be) and it might make sense to provide some mechanism to deal with it. I think I'd be "ok" with a blacklist of source package, version tuples
[21:41] <nacc> that we know don't work
[21:41] <slangasek> nacc: yeah, that's probably reasonable in this case
[21:42] <slangasek> it's sort of like, yes this version number exists, but it's associated with a thing that's not actually a source package :P
[21:42] <nacc> slangasek: right
[21:42] <nacc> i'll file a bug to document the idea, at least
[21:44] <nacc> slangasek: and, since the patches-unapplied import does exist, it's possible to at least get the source package in Git and probably munge the patch so that it applies by hand
[21:45] <slangasek> yep, the main problem is that it doesn't tell you which way to munge it is the correct way
[21:45] <nacc> slangasek: yeah, in my mind the 'right' way would be to spin up precise, i guess and do it there :)
[23:02] <nacc> mdeslaur: fyi, LP: #1744148 updated, i've assigned the two security tasks to you and uploaded the php7.2 update to bionic
[23:02] <ubottu> Launchpad bug 1744148 in php7.0 (Ubuntu Xenial) "[MRE] Please update to latest upstream release 7.0.28 / 7.1.15 / 7.2.3" [Wishlist,In progress] https://launchpad.net/bugs/1744148
[23:04] <nacc> xnox: have you already fixed rails? Odd_Bloke mentioned you were working on it
[23:05] <xnox> nacc, rails is fixed; but fixed rails showed that ruby-spring is broke; just now fixed ruby-spring https://launchpad.net/ubuntu/+source/ruby-spring/1.3.6-2ubuntu1
[23:05] <xnox> nacc, then need to rerun rails (and rails-like) with all-proposed, to see if this ruby-spring fixes everything
[23:06] <nacc> xnox: ack, i was just leafing through ruby-defaults and there are a few *rails* pacakges with failures; i assume you'll retry?
[23:09] <nacc> xnox: ruby-turbolinks is agreat one, calls ruby2.3 explicitly  in it's dep8 test :)
[23:10] <nacc> xnox: ah Odd_Bloke already fixed that one, just nees a retrigger
[23:10] <nacc> it's a bit annoying that before the fixes were all in place, another ruby-defaults was uploaded
[23:10] <xnox> yeah, but oh well, doko didn't know we were actively looking and manually re-triggering half of the things with the right triggers.
[23:11] <nacc> yeah, it happens :)
[23:11] <xnox> and were hoping to migrate current ruby-defaults; before merging in a bug fix.
[23:12] <nacc> fun, ruby-turbolinks looks to just have raced (it's migrated already now acc'g to rmadison) the test rerun, so i'd let that settle and it can be retriggered without any extra flags
[23:13] <nacc> ruby-sexp-processor looks ugly... "[BUG] Stack consistency error"
[23:14] <nacc> ah fixed in debian, will sync
[23:14] <nacc> already synced, nm
[23:48] <mdeslaur> nacc: thanks! I'll work on them tomorrow
[23:49] <nacc> mdeslaur: thank you, let me know if you need anything