| xnox | 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 |
|---|---|---|
| xnox | https://github.com/systemd/systemd/pull/3025/files | 00:09 |
| cjwatson | Why isn't that a terminfo thing? | 00:11 |
| cjwatson | I mean if you say TERM=dumb systemctl status blah.service then you don't get colour escape codes, for instance. | 00:12 |
| cjwatson | Maybe bits of systemd should be terminfoing harder, but that patch seems pretty wrong :) | 00:15 |
| xnox | cjwatson, hm, that's about log messages pid 1 prints to console, and it defaults to LogColor=yes unconditionally irrespective of terminfo | 00:26 |
| xnox | there is no terminfo when pid1 starts, or is there already inherited from initramfs? | 00:26 |
| xnox | at the moment it really just does LogColor=yes all the time to whatever is boot messages console. | 00:27 |
| xnox | this is not about systemctl | 00:27 |
| smoser | slangasek, yeah, there is definitely a race in that code, but it should only end up being a double-add | 00:30 |
| smoser | 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 |
| smoser | i'm hitting the file being written and then truncated. | 00:31 |
| slangasek | smoser: erm, ifupdown does atomic replaces of that file | 00:32 |
| smoser | hhm.. | 00:33 |
| smoser | 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 |
| smoser | im' sure there are better ways to do what its trying to do, but the intent is 2 fold | 00:34 |
| smoser | a.) get mark the interface up so ifup doesnt try to bring it up and fail | 00:34 |
| smoser | b.) populate resolvconf with stuff from initramfs | 00:35 |
| smoser | slangasek, so how does ifupdown know that it is the "first" ? | 01:35 |
| smoser | 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. | 01:35 |
| === alexisb-afk is now known as alexisb | ||
| cyphermox | 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:47 |
| smoser | fudge. | 01:49 |
| smoser | good night. | 01:49 |
| TheMuso | cyphermox: I personally was done with ubiquity last week, was just helping out Mirv get some stuff in. Thanks anyway. | 02:06 |
| cyphermox | ok, well thanks for the changes :) | 02:07 |
| TheMuso | np | 02:11 |
| === shuduo-afk is now known as shuduo | ||
| slangasek | smoser: mm. it's the first because the file doesn't exist yet | 04:25 |
| darkxst | infinity, I have take2 of the casper fix (inject systemd unit) on bug 1561302 if you have time to have a look | 04:39 |
| ubottu | bug 1561302 in casper (Ubuntu) "gdm won't allow passwordless login" [Critical,Triaged] https://launchpad.net/bugs/1561302 | 04:39 |
| Mirv | TheMuso: cyphermox: thanks a lot, both for ubiquity and to cyphermox for u + u-s-u translations update | 05:07 |
| cpaelzer | good morning | 05:09 |
| TheMuso | Mirv: np | 05:25 |
| pitti | Good morning | 06:03 |
| pitti | smoser: you mean ifupdown removes an existing /run/network/ifstate on boot that o-iscsi wrote in the initramfs? | 06:05 |
| lathiat | i discovered ifupdown2 last week, I need to investigate that with more enthusiasm. otherwise systemd-networkd needs a lot of work. | 06:07 |
| pitti | 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 |
| pitti | smoser: perhaps better file a bug to collect information, easier to read than a smeared-out IRC conversation? | 06:07 |
| pitti | xnox: saw your PR, thanks | 06:08 |
| pitti | xnox: I suppose that's something which could land in an SRU? | 06:08 |
| xnox | 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:17 |
| pitti | 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:18 |
| Mirv | 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 |
| Mirv | pitti: ^ those are also the only reason the two packages are stuck in proposed now | 08:20 |
| pitti | ah, I just retried a few s390x tests | 08:21 |
| pitti | (and this morning too) | 08:21 |
| pitti | Mirv: I figure we don't care that much about Qt on s390x, so I'm okay with force-skiptesting Qt | 08:22 |
| Mirv | pitti: here are url:s to four successive icing rocs builds for example http://pastebin.ubuntu.com/15805849/ | 08:22 |
| Mirv | pitti: well I know xnox cares, he enabled it :) | 08:22 |
| pitti | oh, ok | 08:23 |
| Mirv | but maybe mostly build wise | 08:23 |
| Mirv | and not like running phone on his mainframes | 08:23 |
| pitti | 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 |
| Mirv | and these new compiler crashes are unlikely due to Qt changes and more likely due to gcc... | 08:23 |
| pitti | but I guess it'd be enough to file a bug with the URL to the build log and let them pass | 08:24 |
| xnox | pitti, yeah forcing should be fine. but compiler shouldn't ICE either. | 08:24 |
| pitti | can someome file a gcc bug? | 08:24 |
| Mirv | pitti: either is fine for me too, as long as they eventually get in | 08:24 |
| Mirv | filing | 08:24 |
| xnox | pitti, well i'm guessing Mirv doesn't have easy s390x access =) trying to reproduce rocs ICE | 08:24 |
| doko | Mirv, s390x-linux-gnu-g++: internal compiler error: Killed (program cc1plus) | 08:25 |
| caribou | 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 |
| doko | looks like you're running out of memory. maybe half the parallelism? | 08:25 |
| caribou | what needs to be done to have it removed ? | 08:26 |
| xnox | caribou, ping anybody in #ubuntu-release to reject it. | 08:26 |
| caribou | xnox: thanks! | 08:26 |
| Mirv | xnox: doko: you can make this bug #1569750 prettier | 08:26 |
| ubottu | bug 1569750 in gcc-5 (Ubuntu) "s390x new ICEs" [Undecided,New] https://launchpad.net/bugs/1569750 | 08:26 |
| pitti | caribou: rejected | 08:27 |
| caribou | pitti: thanks ! didn't even have time to ask ! | 08:27 |
| caribou | (in #ubuntu-release I mean) :) | 08:27 |
| pitti | caribou: de rien :) | 08:27 |
| caribou | that's what happens when you do that type of work during training | 08:27 |
| pitti | caribou: même pas mal -- that's why we have unapproved queues :) | 08:28 |
| xnox | caribou, also we know suspect you are not running xenial =) | 08:28 |
| caribou | yeah, I still hate that | 08:28 |
| doko | Mirv, did you read what I wrote? | 08:31 |
| Mirv | 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 |
| doko | ok | 08:33 |
| xnox | Mirv, well the autopkgtests on s390x run in lxd containers so share resources. not reproducible on a standalone zvm. | 08:34 |
| xnox | Mirv, the rules file looks crazy | 08:35 |
| pitti | 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 |
| xnox | i have no idea how to disable parallel build. | 08:35 |
| xnox | pitti, right, and the whole zvm shares memory with other zvms, I have totally seen performance fluctuations. | 08:36 |
| doko | xnox, strip parallel=% from DEB_BUILD_OPTIONS, and explicitly append parallel=1 | 08:36 |
| pitti | sorry, they have 26 GB in total, and 8 parallel runners (the above was armhf) | 08:36 |
| pitti | xnox: oh, this is overcommitted? | 08:36 |
| pitti | anyway, there wasn't anything running this morning when I retried | 08:37 |
| xnox | horum, weird. | 08:37 |
| xnox | doko, but this is autopkgtest.... or does the autopkgtest set redicious parallel= setting? | 08:38 |
| doko | ginggs, https://launchpad.net/ubuntu/+source/gdcm/2.6.3-3ubuntu2 are you aware of anything that changed in b-d's? | 08:38 |
| doko | xnox, well, it's building the package first | 08:39 |
| doko | pitti, but yes, autopkg tests maybe should print out the value of DEB_BUILD_OPTIONS, and maybe available memory, swap and cpu's | 08:40 |
| doko | ahh, dh_auto_build '--buildsystem=kf5' --parallel | 08:41 |
| doko | make -j8 | 08:41 |
| xnox | dh_auto_build '--buildsystem=kf5' --parallel | 08:41 |
| xnox | make -j8 | 08:41 |
| xnox | yesh | 08:41 |
| xnox | but from an autopkgtest i don't see that it compiles the whole thing. | 08:41 |
| xnox | pitti, Mirv - why is rocs doing a full build? and with -j8? | 08:41 |
| ginggs | doko: going to have a look | 08:41 |
| Mirv | xnox: I think that's what most kde packages do in their autopkgtests | 08:41 |
| Mirv | xnox: but I'm not familiar with rocs | 08:42 |
| xnox | Restrictions: build-needed | 08:42 |
| xnox | however, no idea where -j8 is coming from then. | 08:42 |
| xnox | adt itself? | 08:43 |
| pitti | export DEB_BUILD_OPTIONS=parallel=$(grep -c ^processor /proc/cpuinfo | sed 's/^0$/1/') | 08:43 |
| pitti | yes | 08:43 |
| pitti | (from bug 1399177) | 08:43 |
| xnox | pitti, do you know about $ nproc ? | 08:43 |
| ubottu | bug 1399177 in autopkgtest (Ubuntu) "adt-run should parallelize builds as necessary by default" [Wishlist,Fix released] https://launchpad.net/bugs/1399177 | 08:43 |
| Laney | nproc! | 08:43 |
| Laney | high five | 08:44 |
| pitti | xnox: yes, but only after I added that :) | 08:44 |
| pitti | not sure where I stole that from | 08:44 |
| xnox | pitti, right but 3.25GB of ram is not enough for -j8 of c++ code | 08:46 |
| xnox | 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:47 |
| pitti | xnox: yes, I'll think about how to do that; most preferably, by only giving one or two CPUs to each container | 08:48 |
| xnox | pitti, right that would work too. | 08:48 |
| pitti | I adjusted bug 1569750 accordingly | 08:49 |
| ubottu | bug 1569750 in Auto Package Testing "s390x new ICEs" [Undecided,New] https://launchpad.net/bugs/1569750 | 08:49 |
| doko | that probably also explains why we had test failures for mariadb-10.0 which disapparead after disabling the parallel build | 08:52 |
| pitti | does this also do a package build in its autopkgtest? | 08:52 |
| pitti | it's already expensive enough for all those KDE packages | 08:53 |
| doko | anybody familiar with gbp? | 08:54 |
| pitti | I'm using it quite regularly | 08:56 |
| infinity | pitti: You stole that grep/sed from launchpad-buildd, because it had to work on series' before nproc(1) existed. ;) | 09:10 |
| pitti | ah, that was probably it :) | 09:10 |
| pitti | but it exists on precise, so we should be okay | 09:10 |
| mwhudson | doko: the main thing with gdb is to use import-orig and nothing else | 09:19 |
| mwhudson | doko: :-) | 09:19 |
| mwhudson | er | 09:20 |
| mwhudson | gbp | 09:20 |
| pitti | gbp buildpackage is kinda the main point, gbp clone is nice, and gbp pq rather useful | 09:20 |
| doko | mwhudson, pitti: I now just synced sparkleshare, there was no delta left ... | 09:20 |
| doko | was just wondering about the ubuntu diff | 09:21 |
| mwhudson | oh right, pq sounds nice, i've never really used it in anger | 09:21 |
| pitti | doko: yeah, if the appindicator bits went to Debian and we synced, having an ubuntu branch is also obsolete | 09:23 |
| xnox | pitti, looking at our initramfs: ${recovery:+--startup-event=recovery} -> surely that's upstartism that does not work with systemd. | 09:25 |
| pitti | xnox: right, that would just be "recovery" | 09:26 |
| pitti | as per friendly-recovery.service | 09:26 |
| xnox | pitti, and i take it the phone/touch stuff cannot really boot into upstart recovery, can it? | 09:27 |
| pitti | xnox: I'm not entirely sure, but it's rather hard to set boot params there and -ENOKEYBOARD either | 09:27 |
| pitti | xnox: so I'd say "no" is a pretty safe answer indeed | 09:28 |
| doko | jamespage, could you have a look at the openstack test rebuild ftbfs at https://launchpad.net/ubuntu/+archive/test-rebuild-20160401/+build/9502328 ? | 09:29 |
| jamespage | doko, going to point that to coreycb > https://launchpad.net/ubuntu/+archive/test-rebuild-20160401/+build/9502328 | 09:30 |
| infinity | xnox: systemd's works fine because it just reads cmdline. | 09:32 |
| infinity | xnox: If you're suggesting tearing out the upstartism, don't. | 09:32 |
| xnox | ok | 09:38 |
| Mirv | 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:39 |
| bzoltan | Mirv: I am not sure if pitti has seen my lines on the ci-eng | 09:40 |
| Mirv | bzoltan: he's not on the channel so I doubt it | 09:41 |
| bzoltan | Mirv: possible... I used the android client what did not show | 09:41 |
| Mirv | bzoltan: you used _what_ client! :D | 09:42 |
| bzoltan | Mirv: shame on me, shame on me... | 09:42 |
| bzoltan | Mirv: I wish to have a quassel client for ubuntu touch | 09:42 |
| === pitti` is now known as pitti | ||
| === Bluefoxicy_ is now known as Bluefoxicy | ||
| === funkyHat_ is now known as funkyHat | ||
| infinity | 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. | 09:59 |
| infinity | xnox: (It's trying to yank perl and all its deps to priority:important, which isn't ideal) | 10:00 |
| infinity | Normally, I'd just set an ignore override in priority-mismatches, but perl's a bit of an oddball to ignore. | 10:00 |
| otto_ | Is this the correct channel to contact release-team as documented at https://wiki.ubuntu.com/FreezeExceptionProcess#Milestone_Freeze ? | 10:00 |
| infinity | otto_: -> #ubuntu-release | 10:01 |
| xnox | 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 |
| xnox | infinity, also note the sysconfig upload (and the auto-accepted s390-sysconfig-writer) packages =) you may want to review it | 10:03 |
| infinity | xnox: I skimmed, but I'm not really awake enough to be on the hook for reviewing. | 10:04 |
| xnox | 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:04 |
| xnox | and the generated udev rules are simply stored in /etc/udev/rules.d like one would normally expect. | 10:05 |
| infinity | xnox: For bonus points, making s390-tools mawk-compatible and dropping the gawk dep would be awesome, but meh. | 10:06 |
| xnox | 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:06 |
| xnox | infinity, to be honest we don't need s390-tools in minimal per-se. | 10:07 |
| xnox | howerver IBM will wine if it's not there. | 10:07 |
| xnox | it only needs to be there on full installs, and is mostly uterly useless in e.g. containers | 10:07 |
| pitti | so, ubuntu-standard then? | 10:07 |
| xnox | yeah. | 10:08 |
| pitti | speaking of which, we still put ureadahead into minimal | 10:08 |
| infinity | 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 |
| pitti | 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 |
| infinity | Which currently isn't an installer at all. :P | 10:08 |
| xnox | 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:08 |
| xnox | infinity, quite. | 10:09 |
| xnox | 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:09 |
| infinity | xnox: That'd be nice, but perhaps a bit ambitious for the next week. | 10:10 |
| infinity | Though, given it's a simple yaboot/silo config style, it's much easier to write than grub.cfg. | 10:10 |
| infinity | I wish grub were that readable. | 10:11 |
| xnox | 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 |
| xnox | and then we can drop s390-tools into standard. | 10:11 |
| infinity | 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 |
| xnox | ok | 10:12 |
| infinity | xnox: So, for d-i, zipl-installer should install it in the target before setting it up. | 10:12 |
| xnox | right | 10:12 |
| infinity | xnox: And for cloud images, we'll just add it to the install list. Easy peasy. | 10:12 |
| doko | 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 |
| infinity | 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 |
| infinity | Splitting the perl utils out would probably still be nice. | 10:13 |
| * xnox ponders where perl is used | 10:14 | |
| infinity | sower@z13-028:~$ dpkg -L s390-tools | xargs grep bin/perl 2>/dev/null | 10:14 |
| infinity | /lib/s390-tools/zipl_helper.device-mapper:#!/usr/bin/perl -w | 10:14 |
| infinity | /lib/s390-tools/cpumf_helper:#!/usr/bin/perl -W | 10:14 |
| infinity | /usr/sbin/chcpumf:#!/usr/bin/perl -W | 10:14 |
| infinity | /usr/sbin/ziorep_config:#!/usr/bin/perl | 10:14 |
| infinity | /usr/sbin/chmem:#!/usr/bin/perl | 10:14 |
| infinity | /usr/sbin/ziomon_fcpconf:#!/usr/bin/perl | 10:14 |
| infinity | /usr/sbin/ip_watcher.pl:#!/usr/bin/perl -w | 10:14 |
| infinity | /usr/sbin/lsmem:#!/usr/bin/perl | 10:14 |
| infinity | /usr/sbin/lsluns:#!/usr/bin/perl | 10:14 |
| infinity | /usr/bin/ts-shell:#! /usr/bin/perl -W | 10:14 |
| infinity | /usr/bin/lscpumf:#!/usr/bin/perl -W | 10:14 |
| infinity | /sbin/zfcpdbf:#!/usr/bin/perl | 10:14 |
| infinity | /lib/s390-tools/chreipl_helper.device-mapper:#!/usr/bin/perl -w | 10:14 |
| infinity | There. :P | 10:14 |
| pitti | 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 |
| xnox | 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:15 |
| xnox | other bits are optional-ish | 10:16 |
| infinity | xnox: Yeah, but if those are shipped with zipl, they get out of minimal. | 10:16 |
| xnox | true. | 10:16 |
| infinity | xnox: Since minimal doesn't include bootloaders on any other arch. | 10:16 |
| xnox | package name - zipl or s390-tools-zipl ? | 10:17 |
| infinity | Oh, chreipl_helper.device-mapper and zipl_helper.device-mapper are the same file. :P | 10:17 |
| xnox | yes, symlinks | 10:17 |
| infinity | xnox: I think it's probably important enough to warrant top level namespace. | 10:17 |
| infinity | 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:17 |
| infinity | s/horrible/horribly/ | 10:18 |
| xnox | we forked pretty agressively, and are feeding changes back. | 10:18 |
| xnox | but it is slowish. | 10:18 |
| * infinity wonders if he should give up on sleep and just go buy a 2L thing of Coke to reanimate. | 10:19 | |
| xnox | infinity, to be honest.... drop s390-tools & sysconfig-hardware out of minimal, make zipl-installer install those two packages -> jobs done. | 10:20 |
| xnox | or like move them to ubuntu-standard | 10:20 |
| infinity | xnox: True, we could just make zipl-installer pull the whole shebang in. | 10:20 |
| ginggs | doko: gdcm builds fine locally, I think there might be something in -proposed that it doesn't like | 10:20 |
| infinity | 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:21 |
| xnox | infinity, new one grows a dep on s390-tools | 10:22 |
| xnox | for chzdev/lszdev | 10:22 |
| infinity | Oh. | 10:22 |
| infinity | Heh. | 10:22 |
| xnox | however that is all good | 10:22 |
| * doko looks at one more juju package in NEW | 10:23 | |
| infinity | xnox: Kay, yeah. Moving them from minimal to boot, and making installers pick them up might be the Right Thing. | 10:24 |
| infinity | xnox: Then a debootstrapped or container setup won't have them, which sounds correct. | 10:24 |
| xnox | and our s390-sysconfig-writer already had apt-install sysconfig-hardware but i dropped that (not sure why) | 10:24 |
| xnox | but i think i do want to add | 10:24 |
| xnox | apt-install s390-tools sysconfig-hardware in zipl-installer | 10:25 |
| xnox | for zipl & initramfs-hooks | 10:25 |
| xnox | and then we can drop both out of minimal. | 10:25 |
| infinity | When does s390-sysconfig-writer run? | 10:25 |
| infinity | I'd assume before the bootloader install. | 10:25 |
| infinity | So it probably wants to install the things it intends to use. | 10:25 |
| doko | 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 |
| infinity | But no harm in both of them doing it, apt-install $(already_installed_thing) doesn't hurt. | 10:26 |
| pitti | -y | 10:28 |
| pitti | ah sorry, apt-install, ignore me | 10:28 |
| ginggs | 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 |
| doko | ginggs, better the -dev package | 10:34 |
| ginggs | doko: libproj-dev yes. shall i test and upload? | 10:36 |
| doko | ginggs, please do, you became our "science" specialist ;p | 10:37 |
| doko | ahh, that is -med ... anyway | 10:38 |
| ginggs | doko: no problem, i'll do it | 10:38 |
| xnox | 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 |
| xnox | yeah, but zipl-installer really should make sure zipl is in target. | 10:40 |
| doko | mwhudson, sinzui: juju-mongodb-tools's debian/copyright seems to miss the license for vendor/src/golang.org/x/ | 10:42 |
| cpaelzer | hi, we were wondereing about a missing dbgsyms package - openvswitch-switch-dpdk-dgbsym in particular | 10:42 |
| cpaelzer | it was there the last few weeks just fine, but now seems gone | 10:42 |
| cpaelzer | there was no rebuild since then | 10:42 |
| cpaelzer | 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 |
| cpaelzer | 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 |
| cpaelzer | they were seeded back in two days ago | 10:43 |
| cpaelzer | 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 |
| xnox | cpaelzer, you do have ddebs repository enabled right? | 10:44 |
| cpaelzer | any guidance / idea what might have happened to the package? | 10:44 |
| cpaelzer | xnox: sure the other dbgsyms come in just fine | 10:44 |
| cpaelzer | the package also is no more in http://ddebs.ubuntu.com/dists/xenial/main/binary-amd64/Packages | 10:45 |
| cpaelzer | so it is really missing in the archive | 10:45 |
| cpaelzer | I hope tht was the right place to check | 10:45 |
| xnox | i see [ ]openvswitch-switch-dpdk-dbgsym_2.5.0-0ubuntu1_amd64.ddeb10-Mar-2016 14:441.2K in http://ddebs.ubuntu.com/pool/universe/o/openvswitch/?C=M;O=D | 10:45 |
| xnox | cpaelzer, s/main/universe/ | 10:45 |
| doko | 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 |
| cpaelzer | xnox: so it is related to the main/universe changes then | 10:46 |
| xnox | cpaelzer, which is not published. | 10:46 |
| cpaelzer | the dbgsyms package didn't make it back into main | 10:46 |
| xnox | pitti, things look slightly inconsistent on ddebs.ubuntu.com the ddebs are there, but not "published" | 10:46 |
| cpaelzer | jamespage: on reseeding openvswitch-swicth-dpdk would we have needed another step to re-main the dbgsyms as well^^ ? | 10:47 |
| xnox | cpaelzer, do you need it, or do you need it published? =) | 10:47 |
| doko | mwhudson, sinzui: rejected for now. afaics the other license information, and the packaging seem to be okish | 10:47 |
| xnox | cpaelzer, download with $ wget http://ddebs.ubuntu.com/pool/universe/o/openvswitch/openvswitch-switch-dpdk-dbgsym_2.5.0-0ubuntu1_amd64.ddeb | 10:47 |
| cpaelzer | xnox: I don't need it like - right now | 10:47 |
| cpaelzer | I just wanted to make sure it gets back in before release time | 10:48 |
| cpaelzer | and IFF that identifies a general issue get some others back in | 10:48 |
| pitti | 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 |
| infinity | Looks like perhaps a bug in how ddebs handles (or doesn't) component changes. Or maybe it's just a "be patient" thing. | 10:48 |
| doko | afk for a while | 10:49 |
| pitti | oh, openvswitch, not dpdk | 10:49 |
| xnox | pitti, not really. openvswitch-switch-dpdk-dbgsym is not there. | 10:49 |
| jamespage | cpaelzer, hey - your dpdk change looks OK from my perspective - what testing has it had? | 10:50 |
| cpaelzer | pitti: we were looking for openvswitch-switch-dpdk[-dbgsyms] 2.5.0-0ubuntu1 | 10:50 |
| xnox | pitti, the ddeb is in universe pool, and in none of the Packages files. | 10:50 |
| infinity | Yeah. I just promoted it in the last day. | 10:50 |
| infinity | pitti: Does ddebs track component moves, or need some sort of cleanup run to find them, or...? | 10:50 |
| cpaelzer | 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 |
| pitti | infinity: it just takes the archive's Packages and builds a corresponding archive for the ddebs it finds, nothing too clever | 10:51 |
| pitti | infinity: so in principle it should | 10:51 |
| infinity | pitti: But in practice... :P | 10:51 |
| cpaelzer | 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:51 |
| cjwatson | It's a shame ddeb-retriever doesn't routinely log everything to a file | 10:52 |
| pitti | 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 |
| cjwatson | pitti: it should get a new binary publication | 10:52 |
| pitti | so, no off-hand idea | 10:52 |
| cjwatson | unless it thinks it's not new just because it has the file | 10:52 |
| jamespage | cpaelzer, ack | 10:52 |
| cjwatson | pitti: ah yes, so look in the "try to install ddebs from publishing history records" block | 10:53 |
| cjwatson | pitti: I think that decides it exists (because it's in ddeb_map at the right version/arch) but doesn't check component | 10:53 |
| pitti | cjwatson: but shouldn't that mean that /pool would be wrong too? | 10:54 |
| pitti | I thought this was only an index creation problem | 10:54 |
| infinity | pool is wrong. | 10:54 |
| cpaelzer | jamespage: also all but one fix of that upload are already upstream accepted (=extra testing & review) | 10:54 |
| infinity | It's in universe in the pool, when it should have moved to main. | 10:54 |
| pitti | ah, that would make more sense then | 10:54 |
| xnox | 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:56 |
| infinity | xnox: They're both in boot already, they can just be dropped from minimal, probably. | 10:57 |
| xnox | yeah. | 10:57 |
| infinity | 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 |
| cpaelzer | xnox: s390-tools should be around everywhere - IMHO I'd drop it from nowhere | 10:57 |
| infinity | cpaelzer: Why? | 10:58 |
| xnox | cpaelzer, buildd chroot does not need | 10:58 |
| xnox | cpaelzer, docker image does not need it | 10:58 |
| xnox | cpaelzer, etc. | 10:58 |
| cpaelzer | yeah ok, the virtual cases - ok you got a point | 10:58 |
| cpaelzer | 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 |
| xnox | cpaelzer, in practice it will be available on all installed systems that boot with zipl. | 10:59 |
| infinity | 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 |
| cpaelzer | xnox: will it be in the install environment as well? | 10:59 |
| xnox | cpaelzer, when you say install environment, i have no idea what you mean =) no, zipl is not available in d-i and never was. | 10:59 |
| xnox | s390-tools-udeb only ships dasdfmt & fdasd. very recently i've added chzdev and lszdev. | 11:00 |
| infinity | There's a tiny subset of s390-tools in the d-i env. | 11:00 |
| infinity | Yeah, those. | 11:00 |
| cpaelzer | 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 |
| xnox | cpaelzer, good luck to them =) | 11:00 |
| cpaelzer | xnox: hehe | 11:00 |
| xnox | cpaelzer, and no, they really don't. | 11:00 |
| cpaelzer | xnox: I know how to get that shit out of sysfs :-= | 11:00 |
| cpaelzer | 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 |
| xnox | cpaelzer, they can do anna-install openssh-client and then do scp of things they do need, in and out. | 11:01 |
| infinity | 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:02 |
| * infinity declares sleep a lost cause and goes shopping. | 11:03 | |
| cpaelzer | 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:03 |
| cpaelzer | just rich tooling in install env is something they really asked for, so far they just asked me verbally | 11:04 |
| cpaelzer | I might just redirect them to officially report it in case they REALLY want it | 11:04 |
| infinity | 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 |
| jamespage | cpaelzer, ok - uploaded - release team will need to ack that as well | 11:04 |
| infinity | cpaelzer: If we're missing some handy tools for debugging in our udebs, we can certainly add some. | 11:04 |
| infinity | Though, parts of s390-tools have dependencies that pretty much require a full Linux env to get going. | 11:05 |
| infinity | And we're not doing that. | 11:05 |
| cpaelzer | infinity: yeah I think the dependencies are what breaks us from getting all the useful ls* tools | 11:05 |
| bzoltan | 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:05 |
| infinity | Our installer is busybox and a bunch of C, not a full Linux with perl and python and every whiz-bang library. | 11:06 |
| xnox | 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 |
| cpaelzer | I think due to xnox adding lszdev we have the basics which is great | 11:07 |
| cpaelzer | yes - we just thought the same | 11:07 |
| cpaelzer | jamespage: thanks I just saw it popping up in #ubuntu-release | 11:08 |
| xnox | cpaelzer, "we" -> there are more than one person behind cpaelzer nick? | 11:08 |
| xnox | =) | 11:08 |
| xnox | anyway, need to fix more bugs. | 11:09 |
| cpaelzer | xnox: no, you were more or less writing the same than I did that lszdev will cover most whats needed | 11:09 |
| xnox | ah, ack. | 11:09 |
| infinity | xnox: zipl-installer change looks sane to me. | 11:10 |
| infinity | 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:11 |
| xnox | 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 |
| xnox | unlike other bootloaders.... | 11:13 |
| === hikiko is now known as hikiko|ln | ||
| infinity | xnox: "unlike other bootloaders"? Do the lxd images have grub in them? | 11:29 |
| xnox | infinity, ... | 11:32 |
| infinity | xnox: Legitimate question, I don't use lxd. :P | 11:32 |
| xnox | they do have grub-legacy-ec2 i believe | 11:32 |
| xnox | and bits of removed grub | 11:33 |
| coreycb | jamespage, doko: I'll take a look at that python-pint ftbfs | 11:34 |
| === uaa is now known as Guest95487 | ||
| doko | lifeless, any idea about http://bugs.debian.org/802124 ? | 11:52 |
| ubottu | Debian bug 802124 in src:pyjunitxml "pyjunitxml: FTBFS: test_erroring_test (junitxml.tests.test_junitxml.TestJUnitXmlResult) fails" [Serious,Open] | 11:52 |
| doko | pitti, ^^^ you NMUed three years ago. the package is unused. just seeded. ok to remove it from the seed? | 12:00 |
| pitti | doko: absolutely, please kill it; probably just seeded to consistently keep all binaries in main, I suspect | 12:00 |
| pitti | bzoltan: retried | 12:01 |
| bzoltan | pitti: thanks | 12:01 |
| doko | Laney, could you have a look at the development seed in the desktop section, and remove Python2 binary packages? | 12:02 |
| infinity | xnox: Was the block-proposed on s390-sysconfig-writer just so it would get review? | 12:08 |
| doko | cjwatson, you added python-gpod to the development seed in 2007. can it be removed (no python3 package)? | 12:08 |
| xnox | infinity, it was there such that i am here to rebuild d-i | 12:09 |
| xnox | which i am. | 12:09 |
| === hikiko|ln is now known as hikiko | ||
| xnox | because old d-i + new sysconfig-hardware is tested to work correctly, but is ugly =) | 12:10 |
| infinity | 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 |
| xnox | right yes | 12:10 |
| xnox | in that case d-i upload is a bit pre-mature. Or like do not accept it. | 12:10 |
| infinity | xnox: Removed the tag. | 12:11 |
| xnox | infinity, i thought d-i builds with proposed enabled, no? | 12:11 |
| infinity | 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 |
| infinity | xnox: In theory, none of that should affect d-i, but... | 12:12 |
| xnox | =) | 12:12 |
| infinity | xnox: Anyhow, temp rejected for now, I'll accept a bit later. Going to go find caffeine. | 12:12 |
| xnox | cool | 12:13 |
| doko | pitti, can we remove python-libapparmor from thesupported seed? the python3 module is there too. oth there is no python3-ufw package | 12:14 |
| ginggs | 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 |
| pitti | doko: I think we should remove all python-* from the seeds | 12:14 |
| pitti | we want to move to py3, after all | 12:14 |
| doko | pitti, sure, if people agree ... | 12:15 |
| doko | jdstrand, we have a python-ufw package, but no python3-ufw package | 12:15 |
| pitti | I thought we already agreed to that on some ML a few weeks/months back | 12:15 |
| infinity | 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 |
| doko | ohh, ok, then I'll remove all of them | 12:16 |
| infinity | (Not that I care at all if it all goes to universe) | 12:16 |
| doko | infinity, there are some which don't have a python3 package | 12:16 |
| pitti | moving to python3-* for those that exist sounds fine | 12:16 |
| pitti | and dropping the others | 12:16 |
| infinity | doko: Personally, I'm happy to see them all drop out unless they have seeded rdeps. | 12:16 |
| cjwatson | doko: I don't care about anything I added to the development seed in 2007 | 12:17 |
| infinity | But my opinion of python isn't high. :P | 12:17 |
| * infinity scratches his head at britney. | 12:17 | |
| cjwatson | (2006, actually) | 12:17 |
| pitti | mine is very high, but I mostly treat them like libfoo -- if they have rdepends in main, fine, but otherwise don't bother | 12:17 |
| infinity | cjwatson, pitti: Any ideas why britney would be doing the "trying to remove package" thing for something that doesn't exist in either unstable *or* testing? | 12:18 |
| cjwatson | infinity: Which package? | 12:18 |
| infinity | cjwatson: ubuntu-snappy. Top of excuss. | 12:18 |
| cjwatson | It must be somewhere or it wouldn't know the name. | 12:18 |
| infinity | Ahh. Old version of golang-snappy-dev hanging around. | 12:19 |
| infinity | Will sort. | 12:19 |
| pitti | hm, it was removed 15 hours agbo | 12:19 |
| pitti | https://launchpad.net/ubuntu/+source/ubuntu-snappy/+publishinghistory | 12:19 |
| cjwatson | pitti: it's NBS | 12:19 |
| xnox | pitti, on ubuntu, may I use /usr/lib/modules-load.d ? and i don't see /lib/modules-load.d to exist, does it? | 12:19 |
| cjwatson | goget-ubuntu-touch b-ds on it | 12:20 |
| xnox | pitti, or what is the ubuntu-ish/debian-ish way to load modules? | 12:20 |
| infinity | Yeah. Silly goget. | 12:20 |
| pitti | xnox: /usr/lib/modules-load.d/ should be fine | 12:22 |
| pitti | xnox: /lib/m-l.d might work, but the manpage doesn't document it thus we don't want to advertise it | 12:22 |
| xnox | pitti, right, and reading source code it does support /lib/m-l.d when built with SPLIT_USR | 12:23 |
| xnox | in my case the thing is in /usr anyway, so /usr/lib will do fine. | 12:23 |
| pitti | . o { /usr merge !!! } *sigh* | 12:24 |
| pitti | xnox: hm, so it turns out cgroups don't have a knob to say "2 CPUs", just "assign CPUs 0 and 3" | 12:25 |
| pitti | so, no cgroup magic for this | 12:26 |
| xnox | =( | 12:26 |
| xnox | pitti, but i thought lxd/lxc had extended syntax to "give me 50% cpus" | 12:26 |
| xnox | or some such. | 12:26 |
| xnox | summon stgraber ^ =) | 12:26 |
| pitti | xnox: I googled around and searched the manpages, didn't see anything | 12:26 |
| xnox | =( | 12:26 |
| infinity | $(($(nproc) / 4)) ? | 12:27 |
| xnox | pitti, doing it by hand is, well hard. I think adt-lxc should realise it sees _all_ cpus, but shouldn't use _all_ of them. | 12:27 |
| pitti | there is lxc.cgroup.cpuset.cpus and lxc.cgroup.cpu.shares | 12:27 |
| pitti | I'd actually like to resource-limit the container itself to only 1 CPu | 12:28 |
| xnox | pitti, and thus in adt -> if in lxc/lxd, use soemthing like no more than 2 CPUs. | 12:28 |
| xnox | pitti, and you don't care which CPU. | 12:28 |
| doko | jamespage, rbasak: the server-ship seed has python-libvirt. can this be replaced by python3-libvirt? | 12:28 |
| pitti | yeah, I guess adt-virt-lxc will need to grow a --num-cpu argument and write a /usr/local/bin/nproc that spits out that number | 12:28 |
| xnox | doko, OMG somebody ported that beast!!!! | 12:28 |
| === _salem is now known as salem_ | ||
| pitti | we configure the memory limit from outside, so I guess we also need to configure #cpus from outside | 12:29 |
| doko | jamespage, rbasak: the server-ship seed has python-urlgrabber. can this be removed? | 12:29 |
| infinity | mvo: goget-ubuntu-touch build-deps on a bunch of stuff that doesn't exist anymore (golang-goconfigparser-dev, golang-snappy-dev, golang-uboot-go-dev) ... What's the plan? | 12:30 |
| mvo | pitti, infinity: the version in proposed fixes this | 12:31 |
| coreycb | jamespage, doko: there's a fix in the upload queue for the python-pint ftbfs | 12:31 |
| mvo | infinity: however there is a ubuntu-emulator/i386 unsatisfiable Depends: ubuntu-emulator-runtime | 12:31 |
| mvo | infinity: I have no idea where this comes from, maybe sil2100 has an idea? | 12:31 |
| pitti | mvo: oh, how's that? https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.34-0ubuntu1 doesn't have any dependency changes | 12:32 |
| mvo | pitti: it does not? let me check, if so this is an imcomplete upload :( | 12:32 |
| === francisco is now known as Guest93488 | ||
| pitti | I don't think britney is clever enough to recognize dependencies from foreign architectures, this might need hinting? | 12:32 |
| pitti | mvo: http://launchpadlibrarian.net/251805206/goget-ubuntu-touch_0.33-0ubuntu3_0.34-0ubuntu1.diff.gz | 12:33 |
| mvo | pitti: sorry, this is confusing https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.33-0ubuntu3 | 12:33 |
| mvo | pitti: that is the one that dropped the dependencies | 12:33 |
| pitti | mvo: ah, there were several uploads done to -proposed | 12:33 |
| infinity | Oh, can fix. | 12:33 |
| mvo | pitti: yes | 12:33 |
| infinity | Sec. | 12:33 |
| pitti | mvo: ack, danke! | 12:33 |
| mvo | thank you and sorry again for letting this linger for so long | 12:34 |
| infinity | Oh. | 12:34 |
| infinity | That's not britney being wrong. | 12:34 |
| infinity | mvo: ubuntu-emulator-runtime is in multiverse, universe packages can't depend on it. | 12:35 |
| infinity | That was never caught before, but britney's been taught to honor components. | 12:35 |
| pitti | ah, so goget-ubuntu-touch needs to go to multiverse too? | 12:35 |
| === josepht` is now known as josepht | ||
| * infinity wonders what makes Android non-free. | 12:35 | |
| infinity | Yeah, goget would need to go to multiverse. | 12:36 |
| infinity | Or android to universe, if it's suitable. | 12:36 |
| infinity | But I assume someone had good reason for assuming it's not. | 12:36 |
| infinity | mvo: So.. Welcome to multiverse, I guess. | 12:38 |
| infinity | Just ubuntu-emulator, mind you. | 12:39 |
| infinity | The rest can stay in universe. | 12:39 |
| * infinity fixes now. | 12:39 | |
| pitti | qtcreator-plugin-ubuntu recommends: ubuntu-emulator | 12:39 |
| infinity | pitti, mvo: Should fix itself shortly. | 12:39 |
| pitti | I suppose that should be lowered to a Suggsets? | 12:39 |
| infinity | pitti: Ugh. Yeah, either a suggests, or that also needs to move. | 12:40 |
| mvo | infinity: yay | 12:40 |
| infinity | pitti: I guess a suggests, given its an ubuntu-sdk rdep. | 12:40 |
| infinity | pitti: Care to toss a quick fix up? | 12:41 |
| pitti | infinity: yup, coming (direct bzr commit/upload) | 12:41 |
| pitti | je suis core-dev | 12:41 |
| infinity | That'll kill all but 2 things from NBS. | 12:43 |
| infinity | Almost there. | 12:43 |
| pitti | smc is still FTBFS due to uninstallable build deps | 12:43 |
| pitti | (haven't investigated yet) | 12:43 |
| pitti | zr: ERROR: Cannot lock LockDir(chroot-93174736:///~ubuntu-sdk-team/qtcreator-plugin-ubuntu/trunk/.bzr/branch/lock): Transport operation not possible: readonly transport | 12:44 |
| pitti | meh | 12:44 |
| pitti | https://code.launchpad.net/~pitti/qtcreator-plugin-ubuntu/dep-fix/+merge/291748 | 12:45 |
| pitti | infinity: wow, you accepted that upload fast :) | 12:46 |
| pitti | (or does "Task: ubuntu-sdk" count as unseeded and it got auto-accepted?) | 12:47 |
| infinity | pitti: Yeah, it was auto-accepted. | 12:48 |
| infinity | Though, I was only 2 seconds behind. | 12:49 |
| infinity | Got the LP "screw you, queue state invalid" return. | 12:49 |
| infinity | Ahh, lovely, with the new meta, minimal-amd64 and minimal-s390x are identical. | 12:50 |
| jdstrand | doko: re python-ufw and python3-ufw. that is correct. ufw itself is python3 and what you might expect in python3-ufw is in ufw (along with the ufw command). python-ufw is something I support even though nothing in main uses it. if you want to take python-ufw off the supported seed, that's fine | 12:55 |
| jdstrand | pitti: ^ | 12:55 |
| doko | jdstrand, ok, doing then | 12:55 |
| barnes | in 16.04 lxc seems as default installed why is not that a choice to make in the installation? | 12:57 |
| barnes | 16.04 server that is | 12:57 |
| pitti | jdstrand: thanks | 13:02 |
| cyphermox | good morning | 13:02 |
| xnox | barnes, lxd specifically is now always available on server and cloud installations. and it's now part of what defines Ubuntu Server product. | 13:07 |
| xnox | barnes, note this is a development channel, questions like yours are probably better asked on e.g. #ubuntu-server for the future. | 13:07 |
| xnox | or #ubuntu+1 channel for development releases support =) | 13:08 |
| barnes | xnox: thanks for your answer, but still i don't see the awsomeness to include it in every install without the option to decide about it in the installation | 13:10 |
| xnox | barnes, the awesomeness is that everyone gets to interract with it =) even if it is with $ apt remove lxd =) | 13:11 |
| xnox | barnes, maybe it should be a task in task-select, which is selected by default, but one can untick it or something. | 13:12 |
| doko | pitti, I didn't understand the smc b-d uninstallability issue either | 13:12 |
| xnox | barnes, dunno, open a bug report against lxd package on launchpad =) | 13:12 |
| doko | Mirv, tjaalton, is it ok to demote these driver packages? http://people.canonical.com/~ubuntu-archive/component-mismatches.txt | 13:13 |
| barnes | xnox: yes an untick box would be enough, or an lts server minimal installation | 13:13 |
| xnox | barnes, well, open a bug report about that. | 13:14 |
| pitti | doko: ah, did you demote libiberty and friends? I re-promoted them yesterday as per slangasek's request as rdepends of these still need to be fixed to add Built-Using: to track the static/linked code copies | 13:14 |
| doko | pitti, ok, didn't know | 13:14 |
| pitti | libirman libiberty drac eperl gnu-efi libatomic-ops | 13:15 |
| tjaalton | doko: the vaapi/vdpau things? guess so, as nothing depends on them | 13:15 |
| tjaalton | doko: which reminds me.. I should be able to enable opencl support in mesa now? it wouldn't pull clang in main anymore :) | 13:16 |
| doko | tjaalton, sure | 13:17 |
| tjaalton | cool, diff getting smaller | 13:17 |
| barry | doko: i've looked at both pyjunitxml and configglue failures. both are really upstream bugs that haven't gotten any traction in a long while. i looked again at both but don't really have any good ideas for fixes. i've been looking at the lua failures on powerpc. those are likely due to c/c++ linkage issues. tough ones | 13:18 |
| doko | barry, pyjunitxml was seeded. removed it from the seed. lets see if it demotes | 13:18 |
| barry | doko: +1 | 13:18 |
| doko | tjaalton, demoted | 13:19 |
| pitti | tseliot: can we get rid of at least some of the 5 nvidia-XXX versions that we have in xenial? | 13:19 |
| pitti | tseliot: -310 and -319 are FTBFS even | 13:20 |
| Mirv | pinging both Timos does work if one doesn't remember which one does what :) | 13:25 |
| tjaalton | :) | 13:25 |
| doko | heh, it worked =) | 13:28 |
| tseliot | pitti: sure, how many of them do we have in the archive? | 13:37 |
| pitti | http://paste.ubuntu.com/15811195/ | 13:39 |
| pitti | tseliot: ^ (doesn't fit in IRC even) | 13:39 |
| pitti | tseliot: I figure we need some of the names as transitional packages for upgrades from trusty and wily | 13:39 |
| pitti | e. g. the nvidia-319 binary is now built by the nvidia-graphics-drivers-331 source, but we still have the nvidia-graphics-drivers-319{,-updates} source in xenial | 13:40 |
| tseliot | pitti: 331 is what we shipped in 14.04, then superseded by 352 | 13:41 |
| tseliot | 310 and 319 are really old | 13:41 |
| doko | cjwatson, ./supported-development-common seeds python-launchpadlib. should that be replaced by python3-launchpadlib? | 13:41 |
| pitti | tseliot: and I think nvidia-graphics-drivers-331 is missing transitional packaes for 319-updates? | 13:42 |
| === Guest95487 is now known as az | ||
| tseliot | pitti: 331 has transitional packages for 319, 331-updates <- 319-updates | 13:43 |
| pitti | tseliot: ah | 13:43 |
| === mapreri_ is now known as mapreri | ||
| pitti | tseliot: nvidia-319 is already a transitional in trusty, so I figure we can completly remove the two -319 sources from xenial, and even drop the transitionals from -331? | 13:44 |
| cjwatson | doko: probably, yes | 13:44 |
| doko | I mean, both are in main anyway | 13:44 |
| pitti | doko: did you re-promote these static libs? or should I? | 13:45 |
| doko | pitti, please do. I thought you would do it | 13:45 |
| pitti | ack | 13:45 |
| tseliot | pitti: yes, although 331 is already transitional in 14.04 (in updates). We have 361 in xenial | 13:46 |
| pitti | tseliot: so, -304, -310-updates, and -319{,-updates} should go/ | 13:46 |
| pitti | ? | 13:46 |
| cjwatson | doko: it's slightly awkward, the python 2 version is still very much more widely used, but it's not going to hurt anything if it drops out to universe somehow | 13:47 |
| tseliot | pitti: 304 is a legacy driver, same as 340 | 13:49 |
| doko | ahh, finally GCC 4.9 should demote | 13:49 |
| * smoser just can't believe he's the only oen that finds this terribly annoying | 13:49 | |
| smoser | https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1521302 | 13:49 |
| ubottu | Launchpad bug 1521302 in unity (Ubuntu Xenial) "gnome-terminal maximize than un-maximize behaves odd" [Medium,Confirmed] | 13:49 |
| pitti | tseliot: well, removing nvidia-graphics-drivers-310-updates nvidia-graphics-drivers-319 nvidia-graphics-drivers-319-updates would help as these are exactly the three packages which are FTBFS :) | 13:50 |
| tjaalton | tseliot: this might be a time to drop -updates, no? they aren't really used anyway | 13:50 |
| pitti | tseliot: so if 304 still actually works, fine to keep it | 13:50 |
| === beuno_ is now known as beuno | ||
| tseliot | tjaalton: sure, that would actually make maintenance a little easier | 13:51 |
| pitti | tseliot: oh right, -331 is already transitional in trusty, so should that go too? | 13:51 |
| pitti | tseliot: please just tell me which versions to keep and drop, easier than this boolean question/answer game :) | 13:51 |
| tjaalton | true | 13:52 |
| tjaalton | ;) | 13:52 |
| tseliot | pitti: ok, you can drop 1) 310 and 319 ( plain and -updates flavours) ; 2) 331 ( plain and -updates) only the source, not the transitional packages (provided by 352) | 13:54 |
| tseliot | tjaalton: I would need to add transitional packages in 361 and 340 in order to remove the -updates flavours | 13:54 |
| tjaalton | right | 13:55 |
| pitti | tseliot: done, thanks! | 13:56 |
| tseliot | pitti: thanks to you ;) | 13:56 |
| tseliot | tjaalton: I'm going to do that now | 14:02 |
| tjaalton | cool | 14:03 |
| stgraber | xnox, pitti: lxd either supports you giving "50%" of the CPU time (all cores visible) or giving a specific number of CPUs in which case it will pick the least loaded cores for your container and re-balance when something changes | 14:11 |
| stgraber | https://www.stgraber.org/2016/03/26/lxd-2-0-resource-control-412/ | 14:12 |
| pitti | stgraber: ah, lxd -- I didn't see this with lxc | 14:12 |
| pitti | we still use lxc in production (I'm working on moving armhf to lxd in scalingstack, this seems unblocked now) | 14:12 |
| stgraber | yeah, that's lxd only as it requires an active daemon processing uevents and such to allow for the balancing | 14:12 |
| xnox | lxc config set my-container limits.cpu 2 -> nice | 14:13 |
| pitti | stgraber: OOI, how do you tell apart "give cpu number 2" vs "give 2 CPUs"? | 14:15 |
| stgraber | 2 vs 2-2 | 14:15 |
| pitti | ah, clever :) | 14:15 |
| stgraber | well, other way around | 14:15 |
| pitti | (not that I'd ever care about pinning specific CPUs to a container) | 14:15 |
| pitti | stgraber: cheers! | 14:16 |
| pitti | anyway, going to finish the adt-run override for parallel=N now, I have 70% of it ready now | 14:16 |
| pitti | as moving over production to lxd will still take a bit | 14:16 |
| sil2100 | Laney: hey! I had a question regarding the last DMB meetings you had - do you remember if candidate Phillip Susi was reviewed? | 14:17 |
| sil2100 | I see he certainly doesn't have the privilages he requested for, but maybe he got rejected or something | 14:17 |
| Laney | sil2100: umm, lemme check | 14:18 |
| Laney | sil2100: doesn't look like it | 14:19 |
| Laney | probably worth a mail | 14:20 |
| sil2100 | Laney: yeah, I was just about to send one with a reschedule question but wanted to make sure he wasn't just rejected | 14:20 |
| sil2100 | Laney: thanks | 14:20 |
| xnox | sil2100, well.... | 14:35 |
| pitti | xnox, doko: hm, I reduced to parallel=2 now (from 8), and it still fails that way | 14:47 |
| pitti | xnox, doko: and this is perfectly reproducible manually (on s390x) | 15:00 |
| pitti | still fails with -j2, works with -j1 | 15:03 |
| pitti | so, no parallelism for s390x, I take it | 15:03 |
| infinity | xnox: Huzzah. s390-tools and sysconfig-hardware demoted to optional. Going to let your d-i through now. Will you have a chance to do a quick test install tonight to see if everything's cool, or will that wait for tomorrow? | 15:22 |
| pitti | doko: http://people.canonical.com/~ubuntu-archive/nbs.html \o/ | 15:23 |
| * pitti makes a flushing noise | 15:24 | |
| infinity | pitti: \o/ | 15:24 |
| infinity | And I just cleared out http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt | 15:25 |
| infinity | It's almost like we're getting close to release. | 15:25 |
| * pitti looks at smc and ugghs | 15:25 | |
| pitti | # apt-get install libcegui-mk2-dev | 15:26 |
| rbasak | There will be more NBS from src:mysql-5.6 removal :-/ | 15:26 |
| pitti | libcegui-mk2-dev : Depends: libfreetype6-dev but it is not going to be installed | 15:26 |
| pitti | # apt-get install libcegui-mk2-dev libfreetype6-dev | 15:26 |
| pitti | -> works | 15:26 |
| infinity | rbasak: mysql-5.6 removal should be smooth enough, once we get there. | 15:26 |
| infinity | pitti: Lemme look. | 15:26 |
| pitti | (doing that in an amd64 xenial-proposed schroot) | 15:27 |
| pitti | # apt-get install libcegui-mk2-dev libsdl1.2-dev libsdl-image1.2-dev libsdl-mixer1.2-dev libsdl-ttf2.0-dev | 15:27 |
| pitti | that also works | 15:27 |
| * pitti tries to decipher http://paste.ubuntu.com/15813463/ | 15:28 | |
| pitti | looks like some conflict between libpng12-dev and libpng16-devtools | 15:28 |
| pitti | ah, this alreayd affects xenial, not only -proposed | 15:29 |
| infinity | Huh. apt-get installing the build-deps doesn't fail. | 15:32 |
| pitti | infinity: with apt-get install <list of packages> or "apt-get build-dep smc"? the latter sure does fail here | 15:33 |
| infinity | pitti: Yeah, build-dep fails, list-of-build-deps doesn't. Curious. | 15:33 |
| cjwatson | build-dep -oDebug::pkgProblemResolver=true may help | 15:34 |
| infinity | cjwatson: Already done. | 15:34 |
| infinity | http://paste.ubuntu.com/15813463/ | 15:35 |
| pitti | that's the ... yes | 15:35 |
| cjwatson | ah right | 15:35 |
| pitti | libpng16-devtools Conflicts: libpng12-0-dev and libpng12-dev, and it somehow looks like the latter is being pulled in through something else | 15:35 |
| cjwatson | probably a virtual package somewhere | 15:36 |
| infinity | libpng16-devtools isn't involved at all when I do list-of-deps, though. | 15:36 |
| infinity | Which is fun. | 15:36 |
| pitti | libsdl-image1.2-dev only depends on the virtual libpng-dev, so apt would ideally pick the 16 one, not the 12 | 15:36 |
| dpb1_ | hi all -- on xenial, EFI, my grub has a debian background and 'gnu/linux' menu items instead of 'ubuntu' | 15:36 |
| infinity | Ah. | 15:36 |
| dpb1_ | what could I have done to cause that | 15:36 |
| cjwatson | libsdl-image1.2-dev might have to pick one at least temporarily | 15:37 |
| cjwatson | i.e. a preferred real alternative | 15:37 |
| infinity | libcegui-mk2-dev depends libpng16-dev, which depends libpng16-devtools | 15:37 |
| infinity | And everything else wants libpng12. | 15:37 |
| cjwatson | it probably works if libpng12-dev is removed from the archive or if libpng16-dev appears first, and otherwise is undefined. or something. | 15:37 |
| pitti | indeed, libpng12-dev is main, 16 still universe | 15:37 |
| cjwatson | (er, disclaimer, I can't remember whether we've done the 16 transition) | 15:37 |
| pitti | it seems we intend to keep 12 for now | 15:38 |
| pitti | and "apt-get install libcegui-mk2-dev libsdl1.2-dev libsdl-image1.2-dev libsdl-mixer1.2-dev libsdl-ttf2.0-dev" installs 12 | 15:38 |
| infinity | So, libcegui-mk2-dev probably want to be pinned to libpng12 for now. | 15:38 |
| infinity | And that should resolve smc. | 15:38 |
| * infinity grabs the cegui-mk2 source. | 15:39 | |
| pitti | that's a good theory | 15:39 |
| infinity | Looks like the correct theory. | 15:40 |
| pitti | libpng16-dev | libpng-dev → libpng-dev | 15:40 |
| pitti | that workss | 15:40 |
| pitti | I edited /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial_universe_binary-amd64_Packages in the schroot to verify | 15:40 |
| pitti | and now build-dep is hunky-dory | 15:40 |
| infinity | libpng16-16 Has no rdeps, so we've clearly not transitioned. | 15:41 |
| infinity | And libpng16-dev's only rdep is libcegui-mk2-dev | 15:41 |
| infinity | So, I'll fix that and we're good. | 15:41 |
| pitti | yay | 15:41 |
| * pitti stands by to review in unapproved | 15:41 | |
| xnox | infinity, i will be able to. | 15:43 |
| === Bluefoxicy_ is now known as Bluefoxicy | ||
| === BenC_ is now known as BenC | ||
| xnox | infinity, so accept that d-i whenever you can/want, i'll test it, and then i'll ask ibm to test too to make sure it's all good on their mega huge mainframes too. | 15:46 |
| xnox | cause i only have little z systems =) | 15:46 |
| infinity | xnox: Well, little is enough to make sure we got the zipl-installer bits right. | 15:46 |
| xnox | =) | 15:46 |
| infinity | xnox: And later, I'll want a test that I didn't break the cloud images, but that can wait for tomorrow. | 15:47 |
| infinity | Or whenever the next daily spits out. | 15:47 |
| infinity | xnox: d-i accepted and building. | 15:49 |
| doko | lamont, your postfix upload is stuck with failing autopkg tests | 15:56 |
| lamont | doko: that has been the subject of my session on the scalingstack instance where it is failing | 16:00 |
| lamont | which I believe I just figured out | 16:00 |
| lamont | now to understand wtf that host is doing with its hostname | 16:01 |
| === cmagina90 is now known as cmagina | ||
| === kyrofa_ is now known as kyrofa | ||
| === dobey_ is now known as dobey | ||
| === shadeslayer_ is now known as shadeslayer | ||
| pitti | mvo: are the depends: removals in http://launchpadlibrarian.net/253632879/snapd_1.9.1.1_1.9.2.diff.gz deliberate? changelog doesn't mention them | 16:19 |
| lamont | doko: and -3 uploaded to address the issue | 16:50 |
| doko | hmm, I should re-enable running the tests for openjdk-8 ... | 17:00 |
| Pharaoh_Atem | nacc: I've revised my libvirt-php patchset to work on top of the current git HEAD: https://www.redhat.com/archives/libvir-list/2016-April/msg00731.html | 17:19 |
| nacc | Pharaoh_Atem: cool | 17:37 |
| Pharaoh_Atem | nacc: the patch set is also available from git directly: https://gitlab.com/Conan_Kudo/libvirt-php7/commits/php7-review | 18:01 |
| nacc | Pharaoh_Atem: did you get any feedback? | 18:02 |
| Pharaoh_Atem | yes | 18:02 |
| Pharaoh_Atem | he couldn't apply it to get HEAD, which I fixed by during a lot of evil surgery on the commits | 18:03 |
| Pharaoh_Atem | *git HEAD | 18:03 |
| xevious | Is there a version of pbuilder available for trusty that's capable of creating chroots for xenial? | 18:03 |
| Pharaoh_Atem | and he said he couldn't compile it, which I could not reproduce, so I asked for more info | 18:03 |
| Pharaoh_Atem | I tested on CentOS 7 and Fedora 23 to get a sample of old and recent, and it worked fine in both | 18:03 |
| Pharaoh_Atem | it also worked on ubuntu xenial, so... *shrugs* | 18:04 |
| sarnold | xevious: iirc I had slight trouble setting up the schroot for xenial on trusty because debootstrap didn't have the right symlink.. | 18:07 |
| sarnold | xevious: making a symlink from xenial to gutsy in /usr/share/debootstrap/scripts/ make my sbuild work well enough, perhaps that's all it takes for you too | 18:07 |
| xevious | sarnold: Is there a workaround? | 18:07 |
| mvo | pitti: it is deliberate, not sure why its not in the changelog, its auto-generated with git-dch | 18:07 |
| xevious | Nice. I'll give that a shot. | 18:07 |
| mvo | pitti: probably "+ - debian: remove unneeded dependencies from snapd" - its a bit too terse I guess | 18:08 |
| xevious | sarnold: It's creating a chroot, at least. We'll see if it's xenial when it's done. | 18:09 |
| sarnold | xevious: hehehe | 18:09 |
| xevious | It worked. Thanks! | 18:12 |
| sarnold | \o/ | 18:14 |
| seb128 | awe, cyphermox, could you look at bug #1569649? seems like a regression in the nm init script for an issue was fixed earlier in the cycle | 18:26 |
| ubottu | bug 1569649 in network-manager (Ubuntu) "NetworkManager-wait-online.service not enabled after network-manager installation " [Undecided,New] https://launchpad.net/bugs/1569649 | 18:26 |
| nacc | slangasek: is my best bet for getting review of the php7.0 sru request to add it to the TechnicalBoardAgenda page? | 18:26 |
| seb128 | it claims the patch from bug #1515446 resolves the issue | 18:26 |
| ubottu | bug 1515446 in network-manager (Debian) "network file systems in FSTAB no longer mount at boot with NetworkManager" [Unknown,New] https://launchpad.net/bugs/1515446 | 18:26 |
| seb128 | cyphermox, awe, bug #1569613 also seems a new issue | 18:27 |
| ubottu | bug 1569613 in network-manager-applet (Ubuntu) "/usr/bin/nm-applet:11:g_hash_table_remove_all_nodes:g_hash_table_remove_all_nodes:g_hash_table_remove_all:nma_icons_reload:g_closure_invoke" [Undecided,New] https://launchpad.net/bugs/1569613 | 18:27 |
| awe | seb128, sure... in the middle of some touch testing, but will take a look | 18:28 |
| seb128 | awe, thanks | 18:28 |
| awe | np | 18:28 |
| seb128 | cyphermox, bug #1569590 and bug #1569484 and bug #1569301 seems also new issues worth investigating | 18:33 |
| ubottu | bug 1569590 in network-manager (Ubuntu) "wireless card disabled in network-manager" [Undecided,New] https://launchpad.net/bugs/1569590 | 18:33 |
| ubottu | bug 1569484 in network-manager-applet (Ubuntu) "Auto Ethernet connection profile appears. Wifi does not work anymore." [Undecided,Confirmed] https://launchpad.net/bugs/1569484 | 18:33 |
| ubottu | bug 1569301 in network-manager-pptp (Ubuntu) "cannot connect pptp-vpn after upgrading via apt from 1.0.* to 1.1.93" [Undecided,New] https://launchpad.net/bugs/1569301 | 18:33 |
| seb128 | cyphermox, awe, I can try helping to have a look but I'm at a sprint this week so limited debug cycles | 18:33 |
| cyphermox | ok | 18:33 |
| seb128 | it also seems the apport hook needs to be updated | 18:34 |
| seb128 | Error: Object 'nm' is unknown, try 'nmcli help' | 18:34 |
| seb128 | cyphermox, thanks | 18:34 |
| cyphermox | I'll look once I'm done with ubiquity | 18:34 |
| cyphermox | pptp failure is due to a bug in either ppp or pptp or whatever, but I haven't managed to debug that yet | 18:35 |
| cyphermox | (in fact, I have a hard time getting a good backtrace) | 18:35 |
| awe | seb128, can you tag these bugs and/or send an email with a list? I'm trying to land for the phone now, but will definitely help | 18:35 |
| cyphermox | awe: pptp/ppp failure is a good starting point fwiw ^ | 18:35 |
| awe | also fyi, rc2 landed yesterday as well | 18:35 |
| seb128 | awe, sure, can do | 18:36 |
| awe | cyphermox, sure, but seb128 just rattled off 1/2 dozen issues, so we should try and track 'em all | 18:36 |
| awe | ;)- | 18:36 |
| seb128 | just looking at recent reports | 18:36 |
| cyphermox | awe: there are bug reports, that's how we track bugs | 18:37 |
| seb128 | I think the upgrade works for most users so it's good | 18:37 |
| awe | yes cyphermox, I know | 18:37 |
| seb128 | but there seem to be a few regressions worth investigating | 18:37 |
| awe | we also use tags | 18:37 |
| cyphermox | seb128: if you want to help with the NM bugs, I would suggest making them rls-x-tracking if it's fine with the release team | 18:37 |
| seb128 | good idea | 18:37 |
| awe | cool | 18:38 |
| seb128 | pitti, bts I see report logs having "systemd-timesyncd[483]: Failed to call clock_adjtime(): Invalid argument" is that a known issue? | 18:38 |
| cyphermox | awe: ^ that's where we track release bugs -- http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-x-tracking-bug-tasks.html# | 18:38 |
| awe | cyphermox, right, only 500 bugs on that list... | 18:39 |
| awe | er, 510 | 18:39 |
| cyphermox | awe: ignore that stuff, it's separated by teams and whatnot | 18:39 |
| cyphermox | awe: I'll get that huge list dropped to something more manageable, linux-raspi2 should be listed as a kernel package I think ;) | 18:41 |
| cyphermox | also, disabling the Fix Committed/Fix Released helps | 18:42 |
| === bdmurray_ is now known as bdmurray | ||
| seb128 | cyphermox, awe, https://bugs.launchpad.net/ubuntu/+bugs?field.tag=nm11issue | 18:44 |
| awe | thanks seb128 | 18:45 |
| seb128 | yw | 18:45 |
| barry | doko, slangasek i captured what little i know about the lua ftbfs on powerpc in LP: #1570055, but that's about all i can do at this point | 18:47 |
| ubottu | Launchpad bug 1570055 in lua5.3 (Ubuntu) "FTBFS on powerpc" [Undecided,New] https://launchpad.net/bugs/1570055 | 18:47 |
| nacc | rbasak: is it possible that hte mysql-5.7 migration may have affected dbconfig? | 19:08 |
| rbasak | nacc: absolutely, yes. We patched dbconfig | 19:09 |
| rbasak | IIRC | 19:09 |
| nacc | rbasak: ok, so it should work as in the archive now? or is that still pending in proposed? | 19:10 |
| rbasak | Hmm. | 19:10 |
| rbasak | Looking | 19:10 |
| rbasak | Sorry, I was thinking of libdbi-drivers | 19:10 |
| rbasak | dbconfig had some dep8 issues perhaps, but they're all resolved now. | 19:11 |
| nacc | rbasak: was just trying to test a drupal7 rebuild and it didn't seem to like the passwords as generated by dbconfig, but if i manually went into mysql and set the same password, then it worked | 19:11 |
| rbasak | We're talking dbconfig-common right? | 19:11 |
| nacc | rbasak: ack | 19:11 |
| Skuggen | dbconfig-common was affected by a change in 5.7 that we patched in 5.7 | 19:11 |
| nacc | 2.0.4ubuntu1 is what is installed in this env i tested in | 19:11 |
| Skuggen | Tests failing with an error message about empty value for port | 19:12 |
| rbasak | Ah. Now I remember. Thanks :) | 19:12 |
| nacc | Skuggen: ack, i saw that as well with my uptodate xenial | 19:12 |
| rbasak | Could you be hitting bug 1567098? | 19:12 |
| ubottu | bug 1567098 in mysql-5.7 (Ubuntu) "Cannot log in as root user when not root Unix user" [High,New] https://launchpad.net/bugs/1567098 | 19:12 |
| nacc | rbasak: this was a non-root suer | 19:12 |
| nacc | "drupal7" :) | 19:12 |
| rbasak | Some tests are affected by this. When mysql-server-5.7 is installed no root password is set. | 19:12 |
| rbasak | Previously this worked as non-root (blank root password allowed). | 19:13 |
| nacc | yeah i recall a previous discussion about that | 19:13 |
| rbasak | Now it only works as root (Unix auth over socket only). | 19:13 |
| Skuggen | But dbconfig-common passed its dep8 tests with the updated mysql in proposed? | 19:13 |
| Skuggen | nacc: How does it initialize the database? | 19:14 |
| rbasak | The newest mysql-5.7 hasn't been accepted by the release team yet. | 19:14 |
| Skuggen | This was fixed earlier, though | 19:14 |
| Skuggen | Had to be to get it into the archive in the first place, iirc | 19:15 |
| rbasak | Which fix do you mean? | 19:15 |
| rbasak | Ports was, but bug 1567098 wasn't I think? | 19:15 |
| ubottu | bug 1567098 in mysql-5.7 (Ubuntu) "Cannot log in as root user when not root Unix user" [High,New] https://launchpad.net/bugs/1567098 | 19:15 |
| Skuggen | Oh, sorry, wrong bug :) | 19:15 |
| Skuggen | Yeah, but that one only affects the root user | 19:15 |
| rbasak | nacc: is it possible and not difficult for you to test against ppa:mysql-ubuntu/mysql-5.7? | 19:15 |
| rbasak | That has the fix for the 098 bug | 19:15 |
| Skuggen | nacc: Do you have the code in dbconfig that tries to set the password handy? | 19:16 |
| rbasak | For sbuild, something like --extra-repository="deb [trusted=yes] http://ppa.launchpad.net/mysql-ubuntu/mysql-5.7/ubuntu xenial main" (or add the apt key and then no need for trusted=yes) | 19:17 |
| nacc | rbasak: yeah it'll be easy for me to test | 19:17 |
| nacc | Skuggen: let me look in the drupal code, one sec | 19:17 |
| nacc | Skuggen: http://paste.ubuntu.com/15818808/ I think | 19:18 |
| === alexisb is now known as alexisb-afk | ||
| Skuggen | I gave up trying to understand dbconfig-common fully when we were trying to fix the ports issue, unfortunately | 19:23 |
| Skuggen | So you can log in as root, alter the password of the user and then it works? | 19:24 |
| nacc | Skuggen: let me start back over in a fresh container, now that i've got drupal working :) -- will ping if it reproduces clearly and with steps | 19:26 |
| Skuggen | Thanks. And test as rbasak suggested | 19:26 |
| nacc | Skuggen: ack | 19:26 |
| Skuggen | It's possible dbconfig-common is denied access when trying to set the password for the user | 19:27 |
| Skuggen | Though if the root user still has an empty password the newest version won't fix that, since it still requires unix root to log in in that case | 19:28 |
| slangasek | nacc: add to the TB agenda page is good, I also recommend starting the discussion on the TB mailing list so you're not waiting until the next TB meeting | 19:30 |
| nacc | slangasek: thanks | 19:31 |
| slangasek | nacc: btw, regarding 7.0.5 fixing a behavior regression in 7.0.4, that's the sort of thing that it's preferable to fix before release so that users don't come to rely on the broken behavior on Ubuntu | 19:33 |
| nacc | slangasek: ack, absolutely -- i've got a bug open for it, i guess i should jsut backport to 7.0.4 regardless of the SRU discussion | 19:35 |
| nacc | will do that today | 19:35 |
| === tlyu_ is now known as tlyu | ||
| Skuggen | nacc: I tested with phpmyadmin, and it also creates a user and sets the password, and that seems to work fine | 20:09 |
| lifeless | doko: looking | 20:18 |
| === NCommander is now known as Guest74315 | ||
| lifeless | doko: its the change in __qualname__ in Python 3.x; there's a patch being reviewed upstream at the moment | 20:18 |
| lifeless | doko: https://code.launchpad.net/~garyvdm/pyjunitxml/consistant_test_ids/+merge/291497 | 20:19 |
| pitti | seb128: known, bug 1566465 | 20:20 |
| ubottu | bug 1566465 in linux (Ubuntu Xenial) "[regression]: Failed to call clock_adjtime(): Invalid argument" [Medium,Confirmed] https://launchpad.net/bugs/1566465 | 20:20 |
| seb128 | pitti, thanks | 20:20 |
| seb128 | pitti, do you know if anyone from the kernel team is looking at it? | 20:21 |
| pitti | seb128: sorry, no; I haven't looked at it at all yet, I just overheard the number yesterday | 20:22 |
| seb128 | k | 20:22 |
| seb128 | seems like an annoying issue/something we might want to fix for release | 20:23 |
| Unit193 | FWIW: New cronic in Debian fixes a cvs, predictable tmpfiles. | 20:34 |
| rbasak | Unit193: looks like ginggs already synced it. | 20:38 |
| lamont | I have settings -> keyboard->shortcuts->typing->compose set to capslock, and I notice that the capslock key is now a capslock key... wtf? | 20:44 |
| === barry` is now known as barry_ | ||
| xnox | lamont, have you not noticed that keybindings are not preserved on every unity upgrade before? | 20:46 |
| === barry_ is now known as barry | ||
| === Elimin8r is now known as Elimin8er | ||
| === dasjoe_ is now known as dasjoe | ||
| === freeflying__ is now known as freeflying | ||
| === ivoks_ is now known as ivoks | ||
| * cjwatson hugs ~/unity-settings which has instructions on the superset of everything I've needed to restore across upgrades for the last couple of years | 20:47 | |
| === TheMaster is now known as Unit193 | ||
| lamont | xnox: you'll note that cjwatson was more helpful than you. :p | 20:48 |
| lamont | thanks for hte protips | 20:48 |
| Unit193 | It's cjwatson, he's master of all the things... | 20:48 |
| dobey | lamont: i noticed that same problem on my laptop :-/ | 20:48 |
| cjwatson | well. the existence of ~/unity-settings in my home directory is not actually of much practical help to anyone else | 20:49 |
| lamont | cjwatson: I was just coming to that conclusion | 20:56 |
| lamont | cjwatson: halp where get how do? | 20:56 |
| lamont | cjwatson: maybe a pastebin? | 20:56 |
| === zequence_ is now known as zequence | ||
| === \b is now known as benonsoftware | ||
| === sarnold_ is now known as sarnold | ||
| cjwatson | lamont: eh, well, mine is http://paste.ubuntu.com/15820302/ but it's totally specific to my preferences | 21:00 |
| === fginther` is now known as fginther | ||
| lamont | and for hilarity, fixing my compose key was as simple as disabling it and then changing it back to capslock. | 21:03 |
| lamont | sigh | 21:04 |
| lamont | which package gets that bug report? | 21:04 |
| seb128 | xorg-server? | 21:04 |
| seb128 | or unity-settings-daemon | 21:05 |
| seb128 | (but u-s-d didn't change for a while and I doubt anyone is going to read/pick up your bug there) | 21:05 |
| * lamont can't find "ubuntu unity plugin" in ccsm | 21:06 | |
| lamont | which clearly means I'm missing a package, but ... | 21:07 |
| === ochosi_ is now known as ochosi | ||
| seb128 | "unity" | 21:08 |
| lamont | ah... cjwatson line 11 wants "-> desktop" in front of it | 21:09 |
| cjwatson | believable. I probably jotted it down years ago | 21:10 |
| mwhudson | doko: for https://bugs.launchpad.net/ubuntu/+source/juju-mongodb/+bug/1558336, should we put the golang.org/x/crypto/LICENSE file that upstream removed back? | 22:07 |
| ubottu | Launchpad bug 1558336 in juju-mongodb (Ubuntu) "[needs-packaging] juju-mongo-tools3.2 in xenial, wily, and trusty" [Wishlist,New] | 22:08 |
| mwhudson | doko: or is just correcting debian/copyright sufficient? | 22:08 |
| mwhudson | (or we could remove the golang.org/x/crypto vendor copy from the tarball entirely, we don't use it) | 22:08 |
| mwhudson | anyone? tl;dr upstream removed a LICENSE file from a package they vendor, do we need to put it back (or remove the package, we don't use vendored copy)? | 22:40 |
| === henrix_ is now known as henrix | ||
| === salem_ is now known as _salem | ||
| === Zic_ is now known as Zic | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!