[00:41] <doko> rbasak, jamespage: please could you give some advice on libapache2-mod-python ? do we need a python3 package in parallel, or can we drop the python2 package?
[00:45] <doko> rbasak, cpaelzer: is there a need for platform.bionic/supported-misc-servers: * graphviz ?
[06:00] <cpaelzer> doko: rbasak: graphviz was added long before my time, as far as I can see it is in since the beginning
[06:01] <cpaelzer> I looked around in bugs and bzr but found no statement why it was added
[06:01] <cpaelzer> rbasak: do you have more history of this in your memory?
[06:03] <cpaelzer> it is back from http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.hardy/revision/125
[06:03] <cpaelzer> and moved several times due to restructures since then
[06:05] <cpaelzer> it was back then added to Desktop => other
[06:05] <cpaelzer> I'd assume it was moved incorrectly since then
[06:06] <cpaelzer> doko: rbasak: your opinion what to do now?
[07:23] <LocutusOfBorg> doko, ehm... context? graphviz?
[07:29] <doko> LocutusOfBorg: what else, that was part of the original message here
[07:30] <LocutusOfBorg>     - Build without gts support since the library is still in universe
[07:30] <LocutusOfBorg>     - Don't build-depend on libann-dev since it's in universe
[07:30] <LocutusOfBorg> you mean this, right?
[07:31] <doko> yes
[07:32] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/graphviz/2.38.0-15ubuntu1
[07:32] <LocutusOfBorg> this is the first time gts has been disabled
[07:32] <LocutusOfBorg> and this the first time libann-dev has been disabled https://launchpad.net/ubuntu/+source/graphviz/2.38.0-16ubuntu1
[07:32] <LocutusOfBorg> both are jbicha ^^
[07:43] <doko> ahh, ok, then the question goes to somebody else ...
[07:43] <doko> cpaelzer: my assumption is that the seed wasn't reviewed after we don't require b-d's in main anymore ...
[08:16] <cpaelzer> doko: sounds reasonable
[08:30] <cpaelzer> of the current b-d's to graphvis the following are in main and might have been the old reason it was added apt, corosync, doxygen, dpkg, gcc, imagemagick, pacemaker, schroot
[08:31] <cpaelzer> none has it as real depends or recommends
[08:31] <cpaelzer> I'd guess it can be reomved, but then of you rbasak and me I'm clearly the least experienced
[08:32] <cpaelzer> rbasak: your opinion on the graphviz question by doko?
[09:07] <JEBjames> Is there an eta on the 18.04 daily server getting fixed (tar extract bug fails install)?
[09:09] <JEBjames> I have a script I run that can manually work around it when the install errors out but it's kind of a pain.
[09:55] <jibel> could someone have a look at bug 1723198 ? it's breaking the upgrade from 14.04 to 16.04
[10:42] <eoli3n> Hi
[10:43] <eoli3n> when using kickstart with netboot of 16.04, it's not possible to use sfdisk in %pre section
[10:44] <eoli3n> if i understand well, problem is that busybox for netboot install have not be compiled with parted fdisk or sfdisk. Problem is that thoses tools are installed by debian-installer before proceding installation.
[10:44] <eoli3n> So when %pre is executed, debian-installer has not run yet
[10:45] <cjwatson> you can't do that sort of thing in %pre, indeed, but you could do it by using the 'preseed' extension directive to set partman/early_command to the text of a script that calls sfdisk
[10:45] <eoli3n> and sfdisk, etc are not present. is there any way to get sfdisk working in %pre section of a kickstart installation ?
[10:46] <eoli3n> cjwatson: i did
[10:46] <cjwatson> since partman/early_command runs somewhat later, just before the partitioner starts
[10:46] <eoli3n> ahhhh EARLY !
[10:46] <eoli3n> i didn't found it, lets try
[10:47] <eoli3n> lets try : http://sprunge.us/eRHH
[10:49] <cjwatson> I am not sure that a file name will work there.
[10:49] <cjwatson> Checking.
[10:49] <eoli3n> cjwatson: you're a god... i'm fighting with kickstart since 5 days...
[10:49] <eoli3n> it worked
[10:50] <cjwatson> Oh, yeah, I guess it will, it'll be passed to sh -c and that'll exec it.
[10:50] <cjwatson> Excellent
[10:50] <eoli3n> i did set shebang in script
[10:51] <eoli3n> lets go eating, maybe i will come get a bit more help later
[10:51] <eoli3n> thx a lot cjwatson
[10:51] <cjwatson> np
[11:50] <sil2100> coreycb: hey! Could you make sure LP: #1731595 is verified? I guess the artful openstack stack would be good to release 'all together', but this one neutron bug is not verified
[12:16] <eoli3n> so cjwatson
[12:16] <eoli3n> here is my kickstart file : https://ptpb.pw/2fun
[12:16] <eoli3n> the early partman command works
[12:16] <eoli3n> problem is that installer still prompting for manual partitionning
[12:17] <eoli3n> i removed clearpart
[12:17] <eoli3n> it seems that when no clearpart --all is set, it keeps prompting
[12:20] <cjwatson> eoli3n: I'm not sure I sufficiently understand what your sfdisk thing is for - you're trying to override some limited bit of the installer's partitioning code, I think?
[12:25] <eoli3n> cjwatson: i need sfdisk to overwrite the partition table, and let partman use first partition as a windows one, without erasing it
[12:25] <eoli3n> it that case
[12:25] <eoli3n> if windows is already there, its not broken
[12:25] <eoli3n> and if not, partition is initialized
[12:26] <eoli3n> is there anyway to perform an automatic installation without setting clearpart --all ?
[12:26] <eoli3n> clearpart --linux dont work too
[12:26] <eoli3n> doesnt
[12:26] <cjwatson> clearpart --all basically just turns into preseeding partman-auto/disk, and without that the automatic partitioner won't run
[12:27] <eoli3n> problem is that it initialize a fake partition table to be sure to destroy all datas
[12:27] <eoli3n> in redhat documentation
[12:27] <cjwatson> I think you need --onpart or --usepart to be implemented in our Kickstart implementation, but they're not
[12:28] <eoli3n> ah ok !
[12:28] <eoli3n> it is
[12:28] <eoli3n> but i can't mix --onpart, and part
[12:28] <eoli3n> maybe
[12:28] <cjwatson>                         --onpart|--usepart|--ondisk|--ondrive|--start|--end)
[12:28] <cjwatson> the RH documentation is not necessarily accurate for Ubuntu; we've implemented a compatibility layer
[12:28] <cjwatson>                                 # TODO: --ondisk/--ondrive supported with LVM
[12:28] <cjwatson>                                 warn "unsupported restriction '$1'"
[12:28] <eoli3n> hm, so your point for now, is that i need to write all partition table with sfdiks
[12:28] <eoli3n> sfdisk
[12:28] <cjwatson> https://help.ubuntu.com/lts/installation-guide/amd64/ch04s06.html#kickstart documents the differences
[12:29] <cjwatson> no, I don't think that would work either
[12:29] <eoli3n> and use only --onpart
[12:29] <cjwatson> no
[12:29] <eoli3n> hm
[12:29] <cjwatson> --onpart is unimplemented
[12:29] <eoli3n> ah !
[12:29] <eoli3n> should i use preseed commands here ?
[12:29] <cjwatson> right, I think you'll need to do that
[12:30] <cjwatson> figure out the necessary partitioning recipe in preseeding language, and drop down to that
[12:30] <eoli3n> cjwatson: where can i read that ubuntu kickstart implementation does not support --onpart ?
[12:30] <cjwatson> mm, it's possible the documentation doesn't say that.  I implemented all this to start with but I no longer work on it ...
[12:31] <eoli3n> ah so i found the right dev, good point
[12:31] <cjwatson> I looked it up in the code to refresh my memory
[12:31] <eoli3n> i don't know how works preseed, it seems a bit harder
[12:31] <eoli3n> ok so lets preseed
[12:31] <cjwatson> https://help.ubuntu.com/lts/installation-guide/amd64/apb.html
[12:31] <cjwatson> in particular https://help.ubuntu.com/lts/installation-guide/amd64/apbs04.html#preseed-partman
[12:31] <eoli3n> oh thx
[12:32] <cjwatson> and you may need to refer to https://anonscm.debian.org/gitweb/?p=d-i/debian-installer.git;a=blob;f=doc/devel/partman-auto-recipe.txt;h=bc8b541c59b319147db652f8db01f5c4f427b249;hb=HEAD for detailed recipe syntax
[12:33] <cjwatson> I probably can't help very much more.  If you still run into trouble you may be able to find other people in #ubuntu-installer who are more current
[12:33] <coreycb> sil2100: all set i've marked that bug as verified for artful
[12:56] <eoli3n> cjwatson: just something to clarify, if i use partman preseed, must 'clearpart --all' be set for an automatic install ?
[13:04] <cjwatson> eoli3n: not if you separately preseed partman-auto/disk
[13:22] <michael-vb> Afternoon.
[13:23] <michael-vb> apw: I believe that you are in charge of the vbox* guest modules in the Ubuntu kernel packages?
[13:24] <michael-vb> I am wondering how easy it would be for you to update the versions in supported Ubuntu distributions.  The newer the better of course, but the versions in the current mainline kernel would do too.  We had an ABI break after 5.1.
[13:24] <cjwatson> eoli3n: oh and also partman-auto/method will probably need to be preseeded to 'regular'
[13:24] <cjwatson> sorry, forgot about that bit
[13:25] <eoli3n> cj i just did, i'm searching for a way to set vars with dialog installer, then get my recipe string
[13:25] <michael-vb> Of course, our upstream/out-of-tree versions might make your life easier, as the code is intended to build on older kernels.  They carefully stripped that out of the mainline ones.
[13:25] <eoli3n> cjwatson:
[13:25] <cjwatson> I don't know what you mean by "set vars with dialog installer"
[13:25] <eoli3n> install manually with keyboard
[13:25] <cjwatson> please note that you cannot use the interactive installer to work out a recipe
[13:25] <eoli3n> not writing the recipe
[13:25] <eoli3n> ah
[13:26] <eoli3n> sad :/
[13:26] <cjwatson> it is a bit unfortunate, but there you go
[13:27] <eoli3n> thx for information
[13:35] <jbicha> LocutusOfBorg: vbox discussion ^
[13:37] <michael-vb> jbicha: he knows.
[13:37] <michael-vb> Thanks.
[13:37] <michael-vb> It was follow-up from #vbox-dev.
[13:39] <eoli3n> cjwatson: its a bit tricky with generators but it still prompt, it should not : https://ptpb.pw/B40N
[13:39] <eoli3n> cjwatson: oh wait
[13:40] <eoli3n> sorry for that, didn't read doc until end :/
[13:42] <cjwatson> gonna have to redirect you to other people in #ubuntu-installer for anything more, I'm afraid
[13:45] <eoli3n> huhu ok, thx a lot for your help
[13:48] <cjwatson> (not sure whether anyone else is around at the moment, but should be eventually ...)
[14:38] <doko> xnox: none of the URL's in amd64-microcode's copyright file are working. are you aware of working links?
[14:39] <xnox> ha
[15:15] <michael-vb> apw: have to go.  Would you be able to e-mail regarding the above?  michael dot thayer at oracle.  Thanks!
[16:00] <coreycb> sil2100: would you have a chance to look at releasing bug 1734990 today? it has some critical fixes, including CVEs.
[16:06] <sil2100> coreycb: thanks! Yeah, if it's marked as ready then let me release that in a moment
[16:10] <Laney> apt resolver question...
[16:10] <Laney> ...given this https://paste.ubuntu.com/26183841/ preferences file (generated by autopkgtest)
[16:11] <Laney> would you expect to be able to install python3-distutils from bionic + bionic-proposed atm?
[16:11] <Laney> The following packages have unmet dependencies: python3-distutils : Depends: python3 (>= 3.6.3-2) but 3.6.3-0ubuntu2 is to be installed
[16:11] <Laney> i.e. it doesn't want to select bionic-proposed's python3
[16:12] <doko> rbasak: do you agree about dropping graphviz from the seeds?
[16:12] <coreycb> sil2100: thanks!
[16:13] <doko> Laney: yes, I would expect that
[16:13] <Laney> I can install it if I add python3/bionic-proposed explicitly
[16:13] <Laney> basically, halp
[16:16] <doko> if it helps, I can lower the python3-distutils : Depends: python3 (>= 3.6.3-2) requirement
[16:22] <Laney> I suppose it would, or we can queue with an extra trigger on python3-defaults
[16:23] <Laney> Would like to understand why apt doesn't want to select -proposed's python3 though
[16:23] <Laney> Broken python3-distutils:amd64 Depends on python3:amd64 < none -> 3.6.3-0ubuntu2 @un puN > (>= 3.6.3-2) Considering python3:amd64 10003 as a solution to python3-distutils:amd64 10004
[16:26]  * Laney will requeue the tests
[16:30] <rbasak> dpb1, kirkland: ^ can we drop graphviz from the seeds?
[16:31] <doko> ok, afk now, maybe upload yourself when needed. it should be safe (tm) ...
[16:34] <doko> RAOF: are you uploading things for the mir transition?
[16:36] <jbicha> doko: btw, it looks like you'll need to drop some imagemagick -dev pkgs to universe in order to demote src:graphviz
[16:40] <doko> jbicha: hmm, where is the dependency?
[16:40] <doko> I only see it in B-D-I
[16:42] <rbasak> doko: FTR, I'm fine with dropping graphviz if kirkland and dpb1 are happy.
[16:43] <doko> ok, let's wait
[16:46] <jbicha> doko: libmagickcore-6.q16-dev depends on libgraphviz-dev for instance but there are a few more related ones
[16:47] <doko> wondering why ... I'll have a look. there are no b-d's ...
[16:47] <dpb1> rbasak: What does it gain in dropping?
[16:48] <dpb1> doko: any idea why it was in the seed to begin with?  seems like a very odd package to be installed by default
[16:48] <doko> # libgraphviz-dev, incompatible license against fftw
[16:48] <doko> dpb1: no, as others noticed, it's a very old seed
[16:50] <rbasak> dpb1: I can only defer that question to doko really. doko: what does it gain in dropping?
[16:50] <rbasak> ~ubuntu-server wouldn't have to maintain it once demoted, but I presume there's another reason you're asking?
[16:51] <dpb1> so, take it out of the seed *and* out of main, I guess you are asking
[16:52] <jbicha> doko: cool, obsolete dependency then :)
[16:52] <rbasak> dpb1: that's correct. Though in theory our team declares what we want to explicitly keep in main as part of our product via the seeds. So from our perspective it's both. Do we need it in our product as a top level item?
[16:53] <rbasak> From my POV that's what doko is asking us.
[16:54] <jbicha> graphviz showed up in our gtk2 demotion list, also we diverge from Debian because a few graphviz features require universe deps
[16:56] <doko> rbasak, dpb1: we still need it as a b-d for packages in main, so if things fail we have to fix it anyway. but we don't officially support it. yes, and one more step towards GTK2 demotion
[16:57] <dpb1> ok, that goal I agree with
[16:58] <dpb1> doko: +1
[16:58] <dpb1> doko: kirkland is traveling, might be best to email him so this isn't lost
[19:19] <sil2100> cpaelzer: hey! Do you plan on merging exim4 in the nearest days again?
[19:21] <sil2100> cpaelzer: asking since I saw you did the last merge, and the new version in Debian removes the lynx-cur dependency that is needed to get rid of an NBS
[19:21] <sil2100> It's always best to just fix this with a merge to have two birds with one stone
[19:37] <mdeslaur> so what's the latest with debug packages? If I have a package that has a delta to generate a -dbg, do I drop that and do the --dbgsym-migration ?
[19:39] <mdeslaur> or do I just carry the delta and keep the -dbg?
[20:06] <slashd> slangasek, infinity o/ I've been told you might be able to help or at least get me started on how to approach the following bug : LP: #1733018. (dpkg: cycle found while processing triggers:) thanks in advance.
[20:07] <slashd> sorry ^ LP: #1723198
[20:08] <slangasek> slashd: infinity is out.  I can give you general pointers wrt trigger cycles, but I don't know what all we have or haven't done to resolve this in later releases - for that, best to look at the history of the relevant packages, or ask doko or tdaitx
[20:09] <slangasek> slashd: basically the main change that fixes trigger cycles is to change them into noawait triggers; those keywords should be enough to let you find details e.g. how to implement in a package, minimum version of dpkg required in order to support them
[20:10] <slashd> slangasek, ack will look at this, thanks much it definitely unblock my troubleshoot
[20:12] <slangasek> slashd: I would also suggest investigating why ca-certificates-java is being removed on upgrade, considering it was manually installed
[20:12] <slashd> slangasek, ack
[20:12] <slashd> slashd, much appreciated thank you
[20:13] <slashd> slangasek, ^
[20:13] <slangasek> n/p
[20:15] <slashd> slangasek, yeah I see that 1.16 should suffice to have the implementation (considering nothing after is needed) I'll look at this too thanks  "cf6b98d dpkg: implement "interest-noawait" and "activate-noawait" trigger commands"
[20:22] <slangasek> slashd: ok, I couldn't resist digging a little more.  the root cause of the removal is ca-certificates-java in xenial Depends: openjdk-7-jre-headless (>= 7~u3-2.1.1~pre1-1) | java7-runtime-headless; java7-runtime-headless is provided by openjdk-8-jre-headless, but this will not cause apt to install openjdk-8-jre-headless on upgrade when openjdk-7-jre-headless is already installed;
[20:22] <slangasek> openjdk-7-jre-headless is only available in trusty, and has a dependency chain on an obsolete version of tzdata, so apt forces removal of tzdata-java -> openjdk-7-jre-headless -> ca-certificates-java
[20:22] <slangasek> slashd: sruing ca-certificates-java in xenial to explicitly prefer openjdk-8-jre-headless as the first alternative may be sufficient hint to the package manager for this upgrade to work correctly
[20:23] <slangasek> the circular trigger dep will still be there, but side-stepped
[20:23] <slashd> slangasek, looking
[20:27] <slashd> slashd, I see what you mean
[20:27] <slashd> x/ca-certificates-java-20160321/debian/rules:				-Vjre:Depends="openjdk-7-jre-headless (>= 7~u3-2.1.1~pre1-1)"
[20:27] <slashd> x/ca-certificates-java-20160321/debian/rules:				-Vjre:Depends="openjdk-7-jre-headless"
[20:29] <slashd> slashd, I check and test that, thanks a lot
[20:29] <slashd> slangasek, I check and test that, thanks a lot
[20:42] <RAOF> doko: Ooof. I forgot that we had rdepends 🙄. Thanks for the ping!
[20:54] <ahasenack> hm, I'm looking at a PR in github that splits a big shell script into submodules (https://github.com/CanonicalLtd/ubuntu-advantage-script/pull/92#discussion_r157047936 FTR)
[20:54] <ahasenack> and I made a comment about this change:
[20:54] <ahasenack> +modules/* usr/share/ubuntu-advantage/modules
[20:54] <ahasenack> the package name (deb) is ubuntu-advantage-tools
[20:54] <ahasenack> I asked if that directory should be named ubuntu-advantage-tools instead of just ubuntu-advantage as in the PR
[20:54] <ahasenack> is there a policy about this?
[21:12] <rbasak> ahasenack: that's an archive admin question really. I'd say that you should stick to /usr/share/<binary package name> to avoid conflicts.
[21:13] <rbasak> Though if it's /usr/share/<ubuntu something> then I suppose there's very low likelyhood of a conflict with any other project we're likely to package
[21:14] <ahasenack> rbasak: did you see his reasoning in the reply?
[21:34] <JEBjames> is there an ETA on fixing Ubuntu 18.04 server/Lubuntu-alternate (re: busybox/tar glitch since November 30th breaks install)
[21:35] <JEBjames> I have a work around but it's pretty cludgy and breaks my auto-install testing.
[21:37] <sarnold> JEBjames: that sounds like https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1737662
[21:38] <rbasak> ahasenack: I answered there to save splitting the conversation
[21:38] <JEBjames> sarnold: That sounds great!
[21:58] <JEBjames> I'll retest again tomorrow.  Thank you.
[22:27] <RAOF> doko: Hm. *What* Mir transition? As far as I can tell we no longer have any rdepends?
[22:29] <RAOF> And it has happily migrated out of proposed...