[00:09] pitti, there are no color escape code processing on LPAR & z/VM, instead one sees the color escape codes verbantim and one has to read it like matrix. [00:09] https://github.com/systemd/systemd/pull/3025/files [00:11] Why isn't that a terminfo thing? [00:12] I mean if you say TERM=dumb systemctl status blah.service then you don't get colour escape codes, for instance. [00:15] Maybe bits of systemd should be terminfoing harder, but that patch seems pretty wrong :) [00:26] cjwatson, hm, that's about log messages pid 1 prints to console, and it defaults to LogColor=yes unconditionally irrespective of terminfo [00:26] there is no terminfo when pid1 starts, or is there already inherited from initramfs? [00:27] at the moment it really just does LogColor=yes all the time to whatever is boot messages console. [00:27] this is not about systemctl [00:30] slangasek, yeah, there is definitely a race in that code, but it should only end up being a double-add [00:31] ie, if it checks with grep and then before appending the entry is there, then it could add it twice. or two things racing on open writes, but i dont think i'm hitting that. [00:31] i'm hitting the file being written and then truncated. [00:32] smoser: erm, ifupdown does atomic replaces of that file [00:33] hhm.. [00:34] so do you have thoughts on how open-iscsi could add a record there. to indicate that the interface that holds the root filesystem is already up? [00:34] im' sure there are better ways to do what its trying to do, but the intent is 2 fold [00:34] a.) get mark the interface up so ifup doesnt try to bring it up and fail [00:35] b.) populate resolvconf with stuff from initramfs [01:35] slangasek, so how does ifupdown know that it is the "first" ? [01:35] i'm pretty certain i'm writing that file before any interfaces are brought up. because i'm writing it through udev, which would bring said interfaaces up. === alexisb-afk is now known as alexisb [01:47] TheMuso: hey, not sure if you're done with the fixes you were making in ubiquity, but if you weren't, you'll want to pull again, I did an upload for more translations and vt switching. [01:49] fudge. [01:49] good night. [02:06] cyphermox: I personally was done with ubiquity last week, was just helping out Mirv get some stuff in. Thanks anyway. [02:07] ok, well thanks for the changes :) [02:11] np === shuduo-afk is now known as shuduo [04:25] smoser: mm. it's the first because the file doesn't exist yet [04:39] infinity, I have take2 of the casper fix (inject systemd unit) on bug 1561302 if you have time to have a look [04:39] bug 1561302 in casper (Ubuntu) "gdm won't allow passwordless login" [Critical,Triaged] https://launchpad.net/bugs/1561302 [05:07] TheMuso: cyphermox: thanks a lot, both for ubiquity and to cyphermox for u + u-s-u translations update [05:09] good morning [05:25] Mirv: np [06:03] Good morning [06:05] smoser: you mean ifupdown removes an existing /run/network/ifstate on boot that o-iscsi wrote in the initramfs? [06:07] i discovered ifupdown2 last week, I need to investigate that with more enthusiasm. otherwise systemd-networkd needs a lot of work. [06:07] smoser: it's handled in main.c, and I only see it being opened in "r" or "a+" mode (when it removes an entry) [06:07] smoser: perhaps better file a bug to collect information, easier to read than a smeared-out IRC conversation? [06:08] xnox: saw your PR, thanks [06:08] xnox: I suppose that's something which could land in an SRU? [08:17] pitti, yeah, if it's merged upstream. Or like if we upload systemd for any other reason it would be nice to pick that thing up too. it is mostly cosmetic. [08:18] xnox: yeah, as soon as it lands I'll cherry-pick it into the Debian tree (which I merge from, we are up to date in xenial) [08:20] xnox: I'm seeing multiple ICE:s on s390x only despite multiple retries on qtdeclarative + qtbase autopkgtests: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtdeclarative-opensource-src [08:20] pitti: ^ those are also the only reason the two packages are stuck in proposed now [08:21] ah, I just retried a few s390x tests [08:21] (and this morning too) [08:22] Mirv: I figure we don't care that much about Qt on s390x, so I'm okay with force-skiptesting Qt [08:22] pitti: here are url:s to four successive icing rocs builds for example http://pastebin.ubuntu.com/15805849/ [08:22] pitti: well I know xnox cares, he enabled it :) [08:23] oh, ok [08:23] but maybe mostly build wise [08:23] and not like running phone on his mainframes [08:23] Mirv: so, if these aren't too urgent, we can keep them for a while for xnox/doko to investigate, I don't mind either way [08:23] and these new compiler crashes are unlikely due to Qt changes and more likely due to gcc... [08:24] but I guess it'd be enough to file a bug with the URL to the build log and let them pass [08:24] pitti, yeah forcing should be fine. but compiler shouldn't ICE either. [08:24] can someome file a gcc bug? [08:24] pitti: either is fine for me too, as long as they eventually get in [08:24] filing [08:24] pitti, well i'm guessing Mirv doesn't have easy s390x access =) trying to reproduce rocs ICE [08:25] Mirv, s390x-linux-gnu-g++: internal compiler error: Killed (program cc1plus) [08:25] hmm, I did a mistake on my vsftpd upload, it went to Wily instead of xenial so it is waiting in Unaproved Wily's queue [08:25] looks like you're running out of memory. maybe half the parallelism? [08:26] what needs to be done to have it removed ? [08:26] caribou, ping anybody in #ubuntu-release to reject it. [08:26] xnox: thanks! [08:26] xnox: doko: you can make this bug #1569750 prettier [08:26] bug 1569750 in gcc-5 (Ubuntu) "s390x new ICEs" [Undecided,New] https://launchpad.net/bugs/1569750 [08:27] caribou: rejected [08:27] pitti: thanks ! didn't even have time to ask ! [08:27] (in #ubuntu-release I mean) :) [08:27] caribou: de rien :) [08:27] that's what happens when you do that type of work during training [08:28] caribou: même pas mal -- that's why we have unapproved queues :) [08:28] caribou, also we know suspect you are not running xenial =) [08:28] yeah, I still hate that [08:31] Mirv, did you read what I wrote? [08:33] doko: now I did. xnox can look into it if he can reproduce it. it hasn't happened earlier (previous qtbase landing last week) so it's a bit suspicious regarding what has changed. [08:33] ok [08:34] Mirv, well the autopkgtests on s390x run in lxd containers so share resources. not reproducible on a standalone zvm. [08:35] Mirv, the rules file looks crazy [08:35] LXCs have a memory limit of 1.8 GB (for ages), and the whole box has 4 GiB, so they shouldn't stomp on each other's feet much [08:35] i have no idea how to disable parallel build. [08:36] pitti, right, and the whole zvm shares memory with other zvms, I have totally seen performance fluctuations. [08:36] xnox, strip parallel=% from DEB_BUILD_OPTIONS, and explicitly append parallel=1 [08:36] sorry, they have 26 GB in total, and 8 parallel runners (the above was armhf) [08:36] xnox: oh, this is overcommitted? [08:37] anyway, there wasn't anything running this morning when I retried [08:37] horum, weird. [08:38] doko, but this is autopkgtest.... or does the autopkgtest set redicious parallel= setting? [08:38] ginggs, https://launchpad.net/ubuntu/+source/gdcm/2.6.3-3ubuntu2 are you aware of anything that changed in b-d's? [08:39] xnox, well, it's building the package first [08:40] pitti, but yes, autopkg tests maybe should print out the value of DEB_BUILD_OPTIONS, and maybe available memory, swap and cpu's [08:41] ahh, dh_auto_build '--buildsystem=kf5' --parallel [08:41] make -j8 [08:41] dh_auto_build '--buildsystem=kf5' --parallel [08:41] make -j8 [08:41] yesh [08:41] but from an autopkgtest i don't see that it compiles the whole thing. [08:41] pitti, Mirv - why is rocs doing a full build? and with -j8? [08:41] doko: going to have a look [08:41] xnox: I think that's what most kde packages do in their autopkgtests [08:42] xnox: but I'm not familiar with rocs [08:42] Restrictions: build-needed [08:42] however, no idea where -j8 is coming from then. [08:43] adt itself? [08:43] export DEB_BUILD_OPTIONS=parallel=$(grep -c ^processor /proc/cpuinfo | sed 's/^0$/1/') [08:43] yes [08:43] (from bug 1399177) [08:43] pitti, do you know about $ nproc ? [08:43] bug 1399177 in autopkgtest (Ubuntu) "adt-run should parallelize builds as necessary by default" [Wishlist,Fix released] https://launchpad.net/bugs/1399177 [08:43] nproc! [08:44] high five [08:44] xnox: yes, but only after I added that :) [08:44] not sure where I stole that from [08:46] pitti, right but 3.25GB of ram is not enough for -j8 of c++ code [08:47] pitti, because it's 8 cores in all runners, should be divided by number of runners or some such. Can you half that number somehow? when using lxc/lxd runners? [08:48] xnox: yes, I'll think about how to do that; most preferably, by only giving one or two CPUs to each container [08:48] pitti, right that would work too. [08:49] I adjusted bug 1569750 accordingly [08:49] bug 1569750 in Auto Package Testing "s390x new ICEs" [Undecided,New] https://launchpad.net/bugs/1569750 [08:52] that probably also explains why we had test failures for mariadb-10.0 which disapparead after disabling the parallel build [08:52] does this also do a package build in its autopkgtest? [08:53] it's already expensive enough for all those KDE packages [08:54] anybody familiar with gbp? [08:56] I'm using it quite regularly [09:10] pitti: You stole that grep/sed from launchpad-buildd, because it had to work on series' before nproc(1) existed. ;) [09:10] ah, that was probably it :) [09:10] but it exists on precise, so we should be okay [09:19] doko: the main thing with gdb is to use import-orig and nothing else [09:19] doko: :-) [09:20] er [09:20] gbp [09:20] gbp buildpackage is kinda the main point, gbp clone is nice, and gbp pq rather useful [09:20] mwhudson, pitti: I now just synced sparkleshare, there was no delta left ... [09:21] was just wondering about the ubuntu diff [09:21] oh right, pq sounds nice, i've never really used it in anger [09:23] doko: yeah, if the appindicator bits went to Debian and we synced, having an ubuntu branch is also obsolete [09:25] pitti, looking at our initramfs: ${recovery:+--startup-event=recovery} -> surely that's upstartism that does not work with systemd. [09:26] xnox: right, that would just be "recovery" [09:26] as per friendly-recovery.service [09:27] pitti, and i take it the phone/touch stuff cannot really boot into upstart recovery, can it? [09:27] xnox: I'm not entirely sure, but it's rather hard to set boot params there and -ENOKEYBOARD either [09:28] xnox: so I'd say "no" is a pretty safe answer indeed [09:29] jamespage, could you have a look at the openstack test rebuild ftbfs at https://launchpad.net/ubuntu/+archive/test-rebuild-20160401/+build/9502328 ? [09:30] doko, going to point that to coreycb > https://launchpad.net/ubuntu/+archive/test-rebuild-20160401/+build/9502328 [09:32] xnox: systemd's works fine because it just reads cmdline. [09:32] xnox: If you're suggesting tearing out the upstartism, don't. [09:38] ok [09:39] pitti: did bzoltan ping you about one armhf "Test in progress" https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-016/excuses.html that doesn't seem to be really running (has been there for 18 hours at least) [09:40] Mirv: I am not sure if pitti has seen my lines on the ci-eng [09:41] bzoltan: he's not on the channel so I doubt it [09:41] Mirv: possible... I used the android client what did not show [09:42] bzoltan: you used _what_ client! :D [09:42] Mirv: shame on me, shame on me... [09:42] Mirv: I wish to have a quassel client for ubuntu touch === pitti` is now known as pitti === Bluefoxicy_ is now known as Bluefoxicy === funkyHat_ is now known as funkyHat [09:59] xnox: What are the odds I can talk you into moving all those new s390-tools perl utilities into an s390-tools-perl package or something? Alternately, not shipping s390-tools in minimal. [10:00] xnox: (It's trying to yank perl and all its deps to priority:important, which isn't ideal) [10:00] Normally, I'd just set an ignore override in priority-mismatches, but perl's a bit of an oddball to ignore. [10:00] Is this the correct channel to contact release-team as documented at https://wiki.ubuntu.com/FreezeExceptionProcess#Milestone_Freeze ? [10:01] otto_: -> #ubuntu-release [10:03] infinity, i'll be happy with that, if none of the essential tools are written in perl (i don't think any are) [10:03] infinity, also note the sysconfig upload (and the auto-accepted s390-sysconfig-writer) packages =) you may want to review it [10:04] xnox: I skimmed, but I'm not really awake enough to be on the hook for reviewing. [10:04] infinity, in general - purge a tonne of bash scripts that were imported from debian that were imported from suse; instead use the tool written in C to generate and use minimalistic udev rules, which use builtins only. [10:05] and the generated udev rules are simply stored in /etc/udev/rules.d like one would normally expect. [10:06] xnox: For bonus points, making s390-tools mawk-compatible and dropping the gawk dep would be awesome, but meh. [10:06] the problem is old hwup/hwdown stuff, relied on WAIT_FOR_SYS= in udev rules to wait for devices to be fully there, and then fork to loads of bash. But systemd-udev has removed support for that, so things are really broken when one has many devices, and on typical mainframes one does have a lot of devices. [10:07] infinity, to be honest we don't need s390-tools in minimal per-se. [10:07] howerver IBM will wine if it's not there. [10:07] it only needs to be there on full installs, and is mostly uterly useless in e.g. containers [10:07] so, ubuntu-standard then? [10:08] yeah. [10:08] speaking of which, we still put ureadahead into minimal [10:08] Yeah, if I had my way, it would be standard. And zipl would be packaged separately and actually installed in the target by zipl-installer. [10:08] it should really move to ubuntu-desktop and perhaps ubuntu-server, but we so much don't want it in containers and stuff [10:08] Which currently isn't an installer at all. :P [10:08] infinity, i'm totally for moving s390-tools to standard, but let me check. E.g. i'll need to check that e.g. sysconfig stays in minimal, and doesn't pull s390-tools back in. [10:09] infinity, quite. [10:09] infinity, and then i want to have something generate /etc/zipl.conf similar to e.g. update-grub, with all installed kernels getting a stanza, and having something to control all the kernel parameters, etc. [10:10] xnox: That'd be nice, but perhaps a bit ambitious for the next week. [10:10] Though, given it's a simple yaboot/silo config style, it's much easier to write than grub.cfg. [10:11] I wish grub were that readable. [10:11] infinity, so we need zipl + sysconfig-hardware packages on bare metal installs, and i think something in the installer already tries to install sysconfig-hardware on the system, thus e.g. splitting zipl into standalone package and have sysconfig-hardware depend on it should do just the right thing. [10:11] and then we can drop s390-tools into standard. [10:12] xnox: Don't think sysconfig-hardware should depend on zipl. We should just follow the example we follow for all bootloaders and install it out-of-band. [10:12] ok [10:12] xnox: So, for d-i, zipl-installer should install it in the target before setting it up. [10:12] right [10:12] xnox: And for cloud images, we'll just add it to the install list. Easy peasy. [10:13] barry, are you looking at https://launchpad.net/ubuntu/+archive/test-rebuild-20160401/+build/9500466 and https://launchpad.net/ubuntu/+archive/test-rebuild-20160401/+build/9501296 ? [10:13] That won't actually fix my perl woes, mind you (perl is optional, not standard), but it would still look less ugly. :P [10:13] Splitting the perl utils out would probably still be nice. [10:14] * xnox ponders where perl is used [10:14] sower@z13-028:~$ dpkg -L s390-tools | xargs grep bin/perl 2>/dev/null [10:14] /lib/s390-tools/zipl_helper.device-mapper:#!/usr/bin/perl -w [10:14] /lib/s390-tools/cpumf_helper:#!/usr/bin/perl -W [10:14] /usr/sbin/chcpumf:#!/usr/bin/perl -W [10:14] /usr/sbin/ziorep_config:#!/usr/bin/perl [10:14] /usr/sbin/chmem:#!/usr/bin/perl [10:14] /usr/sbin/ziomon_fcpconf:#!/usr/bin/perl [10:14] /usr/sbin/ip_watcher.pl:#!/usr/bin/perl -w [10:14] /usr/sbin/lsmem:#!/usr/bin/perl [10:14] /usr/sbin/lsluns:#!/usr/bin/perl [10:14] /usr/bin/ts-shell:#! /usr/bin/perl -W [10:14] /usr/bin/lscpumf:#!/usr/bin/perl -W [10:14] /sbin/zfcpdbf:#!/usr/bin/perl [10:14] /lib/s390-tools/chreipl_helper.device-mapper:#!/usr/bin/perl -w [10:14] There. :P [10:15] mvo: goget-ubuntu-touch build deps on three NBS packages (http://people.canonical.com/~ubuntu-archive/nbs.html); is that still on your list, or on Sergio's, or someone else's? [10:15] right. and i am not re-writing zipl/chreipl_helper from perl this week and those are needed to generate/install the right zipl to boot with device mapper [10:16] other bits are optional-ish [10:16] xnox: Yeah, but if those are shipped with zipl, they get out of minimal. [10:16] true. [10:16] xnox: Since minimal doesn't include bootloaders on any other arch. [10:17] package name - zipl or s390-tools-zipl ? [10:17] Oh, chreipl_helper.device-mapper and zipl_helper.device-mapper are the same file. :P [10:17] yes, symlinks [10:17] xnox: I think it's probably important enough to warrant top level namespace. [10:17] xnox: But your call. And it would be nice if we can get this all back to Debian some day, so we're not horrible forked forever. [10:18] s/horrible/horribly/ [10:18] we forked pretty agressively, and are feeding changes back. [10:18] but it is slowish. [10:19] * infinity wonders if he should give up on sleep and just go buy a 2L thing of Coke to reanimate. [10:20] infinity, to be honest.... drop s390-tools & sysconfig-hardware out of minimal, make zipl-installer install those two packages -> jobs done. [10:20] or like move them to ubuntu-standard [10:20] xnox: True, we could just make zipl-installer pull the whole shebang in. [10:20] doko: gdcm builds fine locally, I think there might be something in -proposed that it doesn't like [10:21] xnox: FWIW, sysconfig-hardware has no deps outside of minimal, so it's fine. Unless it doesn't make sense to have it in, say, containers. [10:22] infinity, new one grows a dep on s390-tools [10:22] for chzdev/lszdev [10:22] Oh. [10:22] Heh. [10:22] however that is all good [10:23] * doko looks at one more juju package in NEW [10:24] xnox: Kay, yeah. Moving them from minimal to boot, and making installers pick them up might be the Right Thing. [10:24] xnox: Then a debootstrapped or container setup won't have them, which sounds correct. [10:24] and our s390-sysconfig-writer already had apt-install sysconfig-hardware but i dropped that (not sure why) [10:24] but i think i do want to add [10:25] apt-install s390-tools sysconfig-hardware in zipl-installer [10:25] for zipl & initramfs-hooks [10:25] and then we can drop both out of minimal. [10:25] When does s390-sysconfig-writer run? [10:25] I'd assume before the bootloader install. [10:25] So it probably wants to install the things it intends to use. [10:26] ginggs, it wants to link with libproj9 (according to ubuntu1), but there is no libproj* being installed, so I assume there are dependencies /b-d's dropped [10:26] But no harm in both of them doing it, apt-install $(already_installed_thing) doesn't hurt. [10:28] -y [10:28] ah sorry, apt-install, ignore me [10:34] doko: ah ok, so one of gdcm's build-deps dropped libproj9 as a dep? can we just add libproj9 as a build-dep to gdcm then? [10:34] ginggs, better the -dev package [10:36] doko: libproj-dev yes. shall i test and upload? [10:37] ginggs, please do, you became our "science" specialist ;p [10:38] ahh, that is -med ... anyway [10:38] doko: no problem, i'll do it [10:40] infinity, well new one doesn't run anything from target, it simply writes out generated udev rules to /target/etc/udev/rules.d [10:40] yeah, but zipl-installer really should make sure zipl is in target. [10:42] mwhudson, sinzui: juju-mongodb-tools's debian/copyright seems to miss the license for vendor/src/golang.org/x/ [10:42] hi, we were wondereing about a missing dbgsyms package - openvswitch-switch-dpdk-dgbsym in particular [10:42] it was there the last few weeks just fine, but now seems gone [10:42] there was no rebuild since then [10:43] and the launchpad pages about it look ok https://launchpad.net/ubuntu/+source/openvswitch/2.5.0-0ubuntu1/+build/9328367 and https://launchpad.net/ubuntu/xenial/amd64/openvswitch-switch-dpdk-dbgsym/2.5.0-0ubuntu1 [10:43] The only thing that was around that package is that they were dropping out of main due to the changes how dependencies were handled [10:43] they were seeded back in two days ago [10:44] others build by the same source are still there: openvswitch-dbg openvswitch-common-dbgsym openvswitch-switch-dbgsym openvswitch-testcontroller-dbgsym openvswitch-vtep-dbgsym openvswitch-ipsec-dbgsym [10:44] cpaelzer, you do have ddebs repository enabled right? [10:44] any guidance / idea what might have happened to the package? [10:44] xnox: sure the other dbgsyms come in just fine [10:45] the package also is no more in http://ddebs.ubuntu.com/dists/xenial/main/binary-amd64/Packages [10:45] so it is really missing in the archive [10:45] I hope tht was the right place to check [10:45] i see [ ] openvswitch-switch-dpdk-dbgsym_2.5.0-0ubuntu1_amd64.ddeb 10-Mar-2016 14:44 1.2K in http://ddebs.ubuntu.com/pool/universe/o/openvswitch/?C=M;O=D [10:45] cpaelzer, s/main/universe/ [10:46] mwhudson, sinzui: juju-mongodb-tools: and vendor/src/golang.org/x/ reference a LICENSE file which doesn't exist in the sources. Please add it [10:46] xnox: so it is related to the main/universe changes then [10:46] cpaelzer, which is not published. [10:46] the dbgsyms package didn't make it back into main [10:46] pitti, things look slightly inconsistent on ddebs.ubuntu.com the ddebs are there, but not "published" [10:47] jamespage: on reseeding openvswitch-swicth-dpdk would we have needed another step to re-main the dbgsyms as well^^ ? [10:47] cpaelzer, do you need it, or do you need it published? =) [10:47] mwhudson, sinzui: rejected for now. afaics the other license information, and the packaging seem to be okish [10:47] cpaelzer, download with $ wget http://ddebs.ubuntu.com/pool/universe/o/openvswitch/openvswitch-switch-dpdk-dbgsym_2.5.0-0ubuntu1_amd64.ddeb [10:47] xnox: I don't need it like - right now [10:48] I just wanted to make sure it gets back in before release time [10:48] and IFF that identifies a general issue get some others back in [10:48] xnox: how do you mean? http://ddebs.ubuntu.com/dists/xenial/main/binary-amd64/Packages.xz has symbols for 2.2.0-0ubuntu6 and that's the current version [10:48] Looks like perhaps a bug in how ddebs handles (or doesn't) component changes. Or maybe it's just a "be patient" thing. [10:49] afk for a while [10:49] oh, openvswitch, not dpdk [10:49] pitti, not really. openvswitch-switch-dpdk-dbgsym is not there. [10:50] cpaelzer, hey - your dpdk change looks OK from my perspective - what testing has it had? [10:50] pitti: we were looking for openvswitch-switch-dpdk[-dbgsyms] 2.5.0-0ubuntu1 [10:50] pitti, the ddeb is in universe pool, and in none of the Packages files. [10:50] Yeah. I just promoted it in the last day. [10:50] pitti: Does ddebs track component moves, or need some sort of cleanup run to find them, or...? [10:51] jamespage: it was through 4 types of autotests (i386, amd64, amd64 + cpu features, amd64 + cpu features + low memory) and all those fixes came to existance due to testing, so they were kind of tested from the beginning [10:51] infinity: it just takes the archive's Packages and builds a corresponding archive for the ddebs it finds, nothing too clever [10:51] infinity: so in principle it should [10:51] pitti: But in practice... :P [10:51] jamespage: unfortunately I can't test not-yet uploaded with my CI yet (known TBD), but as soon as it is I'll run it against various more tests /tetspmd, l2fwd, openvswitch-switch-dpdk benchmarking) [10:52] It's a shame ddeb-retriever doesn't routinely log everything to a file [10:52] but it wouldn't re-run for that package if there aren't new ddebs, so maybe that's some weird cache effect [10:52] pitti: it should get a new binary publication [10:52] so, no off-hand idea [10:52] unless it thinks it's not new just because it has the file [10:52] cpaelzer, ack [10:53] pitti: ah yes, so look in the "try to install ddebs from publishing history records" block [10:53] pitti: I think that decides it exists (because it's in ddeb_map at the right version/arch) but doesn't check component [10:54] cjwatson: but shouldn't that mean that /pool would be wrong too? [10:54] I thought this was only an index creation problem [10:54] pool is wrong. [10:54] jamespage: also all but one fix of that upload are already upstream accepted (=extra testing & review) [10:54] It's in universe in the pool, when it should have moved to main. [10:54] ah, that would make more sense then [10:56] infinity, uploading zipl-installer that has apt-install s390-tools & sysconfig-hardware. Once that's in, and migrated, we can demote both to ubuntu-standard or some such. [10:57] xnox: They're both in boot already, they can just be dropped from minimal, probably. [10:57] yeah. [10:57] xnox: If all installers always install those packages, and they're not needed in non-hardware (ie: container/chroot) contexts, that should be enough. [10:57] xnox: s390-tools should be around everywhere - IMHO I'd drop it from nowhere [10:58] cpaelzer: Why? [10:58] cpaelzer, buildd chroot does not need [10:58] cpaelzer, docker image does not need it [10:58] cpaelzer, etc. [10:58] yeah ok, the virtual cases - ok you got a point [10:59] but if possible we should try to not open up a chance that anybody might end up on real HW without s390-tools [10:59] cpaelzer, in practice it will be available on all installed systems that boot with zipl. [10:59] cpaelzer: If you only need it in the places where you'd need, say, bootloaders or a kernel, then it doesn't belong in minimal. [10:59] xnox: will it be in the install environment as well? [10:59] cpaelzer, when you say install environment, i have no idea what you mean =) no, zipl is not available in d-i and never was. [11:00] s390-tools-udeb only ships dasdfmt & fdasd. very recently i've added chzdev and lszdev. [11:00] There's a tiny subset of s390-tools in the d-i env. [11:00] Yeah, those. [11:00] if the install has any issues or something that brings people to "exit to console" people would expect s390-tools to be around to debug [11:00] cpaelzer, good luck to them =) [11:00] xnox: hehe [11:00] cpaelzer, and no, they really don't. [11:00] xnox: I know how to get that shit out of sysfs :-= [11:01] well i'm ok - thats the H in my IMHO, then keep it as is and we only consider it in case someone else complains ok? [11:01] cpaelzer, they can do anna-install openssh-client and then do scp of things they do need, in and out. [11:02] cpaelzer: No one's complained much yet (in fact, people just seem to be signing the praises of how we suck less than our competitors), so let's not invent problems for them to complain about. ;) [11:03] * infinity declares sleep a lost cause and goes shopping. [11:03] infinity: I know a few I expect to just wait in the wings to start yelling at us - but I'm totalyl fine and also happy about the feedback so far [11:04] just rich tooling in install env is something they really asked for, so far they just asked me verbally [11:04] I might just redirect them to officially report it in case they REALLY want it [11:04] cpaelzer: There's always going to be some "you're not RHEL" style feedback, which we generally should push back on with "no, we're not, learn Ubuntu instead of asking us to be RHEL", but there are legitimate requests too. [11:04] cpaelzer, ok - uploaded - release team will need to ack that as well [11:04] cpaelzer: If we're missing some handy tools for debugging in our udebs, we can certainly add some. [11:05] Though, parts of s390-tools have dependencies that pretty much require a full Linux env to get going. [11:05] And we're not doing that. [11:05] infinity: yeah I think the dependencies are what breaks us from getting all the useful ls* tools [11:05] pitti: would you be able to check one armhf "Test in progress" https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-016/excuses.html that doesn't seem to be really running [11:06] Our installer is busybox and a bunch of C, not a full Linux with perl and python and every whiz-bang library. [11:07] cpaelzer, ls* tools are excessive. i did add lszdev which is a small compiled binary and it does most of what the rest of ls* tools do. or rather those that matter during installation: qeth, dasd, zfcp [11:07] I think due to xnox adding lszdev we have the basics which is great [11:07] yes - we just thought the same [11:08] jamespage: thanks I just saw it popping up in #ubuntu-release [11:08] cpaelzer, "we" -> there are more than one person behind cpaelzer nick? [11:08] =) [11:09] anyway, need to fix more bugs. [11:09] xnox: no, you were more or less writing the same than I did that lszdev will cover most whats needed [11:09] ah, ack. [11:10] xnox: zipl-installer change looks sane to me. [11:11] xnox: I'll make the same change for cloud images, and when that's all migrated, un-minimal those two packages and see how my reports love me. [11:13] oh it would be really nice to do it properly - that is have rootfs-livefs install those two in the disk1.img only, and not in the lxc/lxd tarball [11:13] unlike other bootloaders.... === hikiko is now known as hikiko|ln [11:29] xnox: "unlike other bootloaders"? Do the lxd images have grub in them? [11:32] infinity, ... [11:32] xnox: Legitimate question, I don't use lxd. :P [11:32] they do have grub-legacy-ec2 i believe [11:33] and bits of removed grub [11:34] jamespage, doko: I'll take a look at that python-pint ftbfs === uaa is now known as Guest95487 [11:52] lifeless, any idea about http://bugs.debian.org/802124 ? [11:52] Debian bug 802124 in src:pyjunitxml "pyjunitxml: FTBFS: test_erroring_test (junitxml.tests.test_junitxml.TestJUnitXmlResult) fails" [Serious,Open] [12:00] pitti, ^^^ you NMUed three years ago. the package is unused. just seeded. ok to remove it from the seed? [12:00] doko: absolutely, please kill it; probably just seeded to consistently keep all binaries in main, I suspect [12:01] bzoltan: retried [12:01] pitti: thanks [12:02] Laney, could you have a look at the development seed in the desktop section, and remove Python2 binary packages? [12:08] xnox: Was the block-proposed on s390-sysconfig-writer just so it would get review? [12:08] cjwatson, you added python-gpod to the development seed in 2007. can it be removed (no python3 package)? [12:09] infinity, it was there such that i am here to rebuild d-i [12:09] which i am. === hikiko|ln is now known as hikiko [12:10] because old d-i + new sysconfig-hardware is tested to work correctly, but is ugly =) [12:10] xnox: Heh. Kay. We'll, let's hold off until all those bits migrate *and* I demote things I need to, then we can redo d-i and spin a test ISO to make sure it all looks sane. [12:10] right yes [12:10] in that case d-i upload is a bit pre-mature. Or like do not accept it. [12:11] xnox: Removed the tag. [12:11] infinity, i thought d-i builds with proposed enabled, no? [12:12] xnox: It does. I want to make sure everything looks right with the seed changes I committed and after I mangle overrides, etc. [12:12] xnox: In theory, none of that should affect d-i, but... [12:12] =) [12:12] xnox: Anyhow, temp rejected for now, I'll accept a bit later. Going to go find caffeine. [12:13] cool [12:14] pitti, can we remove python-libapparmor from thesupported seed? the python3 module is there too. oth there is no python3-ufw package [12:14] doko: gdcm uploaded. I was unable to find where libproj9 was dropped though, I even checked in Debian unstable and gdcm still builds there. [12:14] doko: I think we should remove all python-* from the seeds [12:14] we want to move to py3, after all [12:15] pitti, sure, if people agree ... [12:15] jdstrand, we have a python-ufw package, but no python3-ufw package [12:15] I thought we already agreed to that on some ML a few weeks/months back [12:16] pitti: Did we agree to drop all the python stuff, or update it to py3? I thought the whole point of that seed was to have a set of python modules we claim we support. [12:16] ohh, ok, then I'll remove all of them [12:16] (Not that I care at all if it all goes to universe) [12:16] infinity, there are some which don't have a python3 package [12:16] moving to python3-* for those that exist sounds fine [12:16]