| 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:15 |
|---|---|---|
| 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:16 |
| 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:19 |
| xcyclist | Ok. | 01:20 |
| xcyclist | Thank you. | 01:21 |
| tsimonq2 | You're welcome. Have a good day. | 01:22 |
| cjwatson | enyc: thanks | 08:34 |
| 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:24 |
| mvo | juliank: oh, that is a bug | 09:28 |
| mvo | juliank: will fix | 09:29 |
| mvo | juliank: thank you! | 09:29 |
| 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:04 |
| 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:05 |
| 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:06 |
| cpaelzer | the second being about 7 pages below the former entry on http://autopkgtest.ubuntu.com/running | 10:07 |
| cpaelzer | anyone else knowing if/how one can cancel test retires? | 10:20 |
| cpaelzer | pitti: ^^ ping for being a subject matter expert | 10:20 |
| 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:23 |
| 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:24 |
| 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:25 |
| Laney | I think that's right | 10:26 |
| 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:27 |
| pitti | but in the worst case, just re-trigger your's again | 10:28 |
| pitti | uh, the queue is quite long right now | 10:28 |
| pitti | kde update ho | 10:29 |
| Laney | I'll just kill it out to be safe | 10:31 |
| rbasak | enyc: metadata_csum is enabled in Debian stretch I think? | 10:45 |
| === Sigyn` is now known as Sigyn | ||
| === Sigyn is now known as Sigyn` | ||
| === Sigyn` is now known as Sigyn | ||
| doko | xnox: does xe-guest-utilities need a MIR? | 14:15 |
| doko | in supported-cloud seed | 14:15 |
| xnox | doko, it does | 14:16 |
| xnox | doko, i've started to fill one out, but it is incomplete. | 14:16 |
| ricotz | mdeslaur, hi, why is clamav depending on llvm3.9 while it ships an internal copy? | 14:57 |
| mdeslaur | ricotz: which release? | 15:00 |
| 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:01 |
| 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:02 |
| mdeslaur | only trusty actually uses the built-in llvm | 15:03 |
| mdeslaur | xenial and later use the system llvm | 15:04 |
| 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:05 |
| 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:07 |
| mdeslaur | I hadn't considered that | 15:11 |
| geofft | cyphermox: are there netplan packages for Debian? (or would you expect the dsc to build on Debian?) | 15:44 |
| cyphermox | geofft: I expect it would build on Debian fine, the only issue might be version numbers for Depends | 16:46 |
| cyphermox | I have yet to file a ITP for netplan.io in Debian. | 16:47 |
| nacc | Odd_Bloke: are you working on any ruby packages right now? | 17:13 |
| Odd_Bloke | nacc: Other than keeping an eye on autopkgtests to request retries, no. | 17:28 |
| nacc | Odd_Bloke: ok, i'll start trawling | 17:30 |
| 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:29 |
| slangasek | nacc: my empty stomach is suggesting options to me that may not be constructive ;) | 21:33 |
| nacc | slangasek: :) | 21:38 |
| nacc | slangasek: like i said not urgent, just something to mull over when/if you have time | 21:38 |
| 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:41 |
| 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:42 |
| 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:44 |
| 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 :) | 21:45 |
| 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:02 |
| nacc | xnox: have you already fixed rails? Odd_Bloke mentioned you were working on it | 23:04 |
| 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:05 |
| 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:06 |
| nacc | xnox: ruby-turbolinks is agreat one, calls ruby2.3 explicitly in it's dep8 test :) | 23:09 |
| 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:10 |
| nacc | yeah, it happens :) | 23:11 |
| xnox | and were hoping to migrate current ruby-defaults; before merging in a bug fix. | 23:11 |
| 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:12 |
| nacc | ruby-sexp-processor looks ugly... "[BUG] Stack consistency error" | 23:13 |
| nacc | ah fixed in debian, will sync | 23:14 |
| nacc | already synced, nm | 23:14 |
| mdeslaur | nacc: thanks! I'll work on them tomorrow | 23:48 |
| nacc | mdeslaur: thank you, let me know if you need anything | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!