[05:05] <xnox> vorlon:  d-i uploaded for another reason!
[05:06] <vorlon> xnox: cheers
[08:00] <seb128> vorlon, hey, so, libgphoto2 has a bit of a weird autopkgtest, it does autoreconf/configure/make check its source, which fails on i386 on configur not fiding ltdl
[08:00] <seb128> do you think it makes sense to try to cross compile or is it fine to just badtest that one on i386?
[08:02] <vorlon> seb128: I think a cross-compile would be better
[08:30] <seb128> vorlon, k, adding to the backlog of things we need to look at then (webkitgtk is high on that list, I will try to make progress today)
[08:40] <seb128> hum, autopkgtest, so http://autopkgtest.ubuntu.com/packages/s/sbd/focal/amd64 is often failing with
[08:40] <seb128> 'sudo: /tmp/autopkgtest-run-wrapper: command not found'
[08:41] <seb128> but sometime it success ... is that command supposed to be always available? or is it by luck on some images?
[08:45] <seb128> juliank, hey, do you know maybe about ^ ?
[10:12] <OxThiebaut> Hi! Any plans to port https://ubuntu.pkgs.org/18.04/ubuntu-universe-amd64/nfqueue-bindings-perl_0.6-1build2_amd64.deb.html to ubuntu 19? (Appologies if wrong channel)
[10:31] <ginggs> OxThiebaut: it's not recent Ubuntu because of release critical debian bug #906495
[10:33] <OxThiebaut> Thanks for the quick and precise response. Have a good day!
[10:57] <seb128> Laney, do yo maybe know about my question from earlier and 'autopkgtest-run-wrapper: command not found' errors and if they are sign on an image issue usually?
[10:58] <Laney> seb128: no, probably the real error is further up
[10:58] <Laney> that is just something which gets printed as part of dumping some logs on failure
[10:58] <seb128> that's what I was wondering, thanks
[14:14] <Bun> Is there any information available on how Ubuntu Base images are created?
[14:49] <Eickmeyer[m]> Do we have any progress on bug 1851346?
[15:21] <oSoMoN> vorlon, lp:ubuntu-themes isn't up-to-date with the contents of the archive, it's missing https://launchpadlibrarian.net/451540523/ubuntu-themes_19.04-0ubuntu1_19.04-0ubuntu2.diff.gz , would you mind pushing that change to the branch?
[17:13]  * ogra hugs sil2100 
[17:31] <seb128> hum, does anyone know what's the easiest way to 'simulate' an i386/focal autopkgtest environment?
[17:35] <Laney> seb128: Use amd64 and pass a --setup-command "dpkg --add-architecture i386; apt update" or something like that
[17:36] <Laney> Would be useful to add that to https://wiki.ubuntu.com/ProposedMigration/#autopkgtests if it works for you
[17:37] <seb128> Laney, I will try and update if it works, thanks
[17:39] <Laney> thanks to you!
[17:39] <Laney> I think I gave Steve a review comment on his MR upstream to make this automatic
[18:05] <ahasenack> kanashiro: so you want 1.3.0-5 in focal
[18:05] <ahasenack> plain 1.3.0-5? no ubuntu changes needed?
[18:06] <rafaeldtinoco> node-uglifyjs-webpack-plugin | 1.3.0-5         | unstable         | source, all
[18:06] <rafaeldtinoco> kanashiro: needs that package in focal
[18:06] <kanashiro> ahasenack, exactly
[18:06] <rafaeldtinoco> but im thinking about upgrade path
[18:06] <rafaeldtinoco> you cant sync to the same version in focal
[18:06] <ahasenack> ok, and that failed because this existed in focal before, and was removed
[18:06] <ahasenack> "Depends on node-webpack, removed in favor of node-acorn transition" <-- do you know what this means?
[18:07] <kanashiro> ahasenack, during node-acorn transition node-webpack FTBFS I think
[18:08] <kanashiro> but the current version of it in Debian unstable is fixed
[18:08] <ahasenack> node-webpack we have in focal-proposed
[18:08] <ahasenack> from you, actually
[18:08] <kanashiro> yes, with a delta
[18:08] <kanashiro> I want to drop the delta
[18:08] <kanashiro> and make it a sync
[18:09] <kanashiro> to do that I need node-uglifyjs-webpack-plugin
[18:09] <rafaeldtinoco> ahasenack: and im proposing to upload node-uglifyjs-webpack-plugin with versioning
[18:09] <rafaeldtinoco> so its not the same as eoan
[18:09] <ahasenack> you will need to make node-uglifyjs-webpack-plugin something like 1.3.0-5build1
[18:09] <rafaeldtinoco> and it allows eoan to upgrade (not that will upgrade)
[18:09] <rafaeldtinoco> 1.3.0-5build1 would be in eoans upgrade path
[18:10] <rafaeldtinoco> if it gets rebuilt
[18:10] <rafaeldtinoco> for whatever reasons
[18:10] <ahasenack> a "buildN" suffix also doesn't block future automatic syncs
[18:10] <rafaeldtinoco> hum I do a build1
[18:10] <ahasenack> use dch -R (iric) for the changelog
[18:10] <rafaeldtinoco> and then after its good
[18:10] <rafaeldtinoco> a sync again ?
[18:10] <ahasenack> no
[18:10] <ahasenack> you will have to grab the source
[18:11] <rafaeldtinoco> do a -R and upload
[18:11] <rafaeldtinoco> with build1 versioned
[18:11] <ahasenack> add a new d/changelog entry, call it 1.3.0-5build1
[18:11] <ahasenack> and upload
[18:11] <ahasenack> and that's it
[18:11] <rafaeldtinoco> yep.. my doubt
[18:11] <rafaeldtinoco> eoan has the same version
[18:11] <rafaeldtinoco> lets suppose SRU is done and a rebuild is needed in eoan
[18:11] <ahasenack> if debian releases 1.3.0-6, and the archive is open again (no FF), ubuntu will sync it automatically
[18:11] <rafaeldtinoco> build1 would be a version that eoan would also use
[18:11] <rafaeldtinoco> thats the main concern
[18:11] <ahasenack> then whoever is doing the sru to eoan has to come up with a version number that fits between 1.3.0-5 and 1.3.0-5build1
[18:11] <rafaeldtinoco> of everything we are saying
[18:12] <rafaeldtinoco> ahasenack: gotcha. works for me
[18:12] <rafaeldtinoco> thanks for checking this
[18:12] <ahasenack> according to https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation, that would be 1.3.0-5ubuntu0.1
[18:12] <rafaeldtinoco> yep
[18:12] <ahasenack> 2.0-2build1                   2.0-2ubuntu0.1
[18:12] <ahasenack> from their example
[18:12] <ahasenack> no, wait
[18:13] <ahasenack> that's for focal
[18:13] <rafaeldtinoco> yep i was almost putting 1.3.0-5ubuntu1 for focal
[18:13] <rafaeldtinoco> and letting eoan to have 1.3.0-5ubuntu0
[18:13] <ahasenack> some ~ might be involved
[18:13] <rafaeldtinoco> if ever needed
[18:13] <ahasenack> for an eoan sru
[18:13] <rafaeldtinoco> they could do 1.3.0-5~ubuntu1
[18:13] <rafaeldtinoco> etc.. if needed
[18:13] <ahasenack> 2.0-2 in two releases         2.0-2ubuntu0.11.10.1 and 2.0-2ubuntu0.12.04.1 <-- that case I think, if the sru affects focal as well
[18:13] <ahasenack> but it has a solution
[18:14] <rafaeldtinoco> ok.. i'll go with a build1
[18:14] <rafaeldtinoco> to keep things simple for now
[18:14] <ahasenack> it's correct for focal
[18:14] <rafaeldtinoco> cool thx!
[18:14] <rafaeldtinoco> kanashiro: ^
[18:28] <cjwatson> rafaeldtinoco: It would be up to a future hypothetical SRUer not to collide.  Just suffixing build1 is correct for the development series, indeed.
[18:28] <rafaeldtinoco> cjwatson: cool! thanks for clarifying
[19:29] <vorlon> oSoMoN: sorry, I'm out of office today, probably best if you can push the changes there yourself?