[00:03] <Unit193> https://salsa.debian.org/ruby-team/ruby-zip/commit/c2b41627b94269940c2cd4aa40f48c0b47c865a2 looks just as odd.
[00:07] <Unit193> new file mode 100644
[00:07] <Unit193> index 0000000..e74ee19
[00:07] <Unit193> --- /dev/null
[00:07] <Unit193> +++ b/test/data/symlink.zip
[00:12] <GunnarHj> rbasak: A day or two extra is no big deal. Would be good if you could consult with sil2100 soon.
[02:12] <lovepopsickle> why is booting on ubuntu 18.04 slower than 16.04
[02:50] <mwhudson> entropy
[02:51] <mwhudson> oh wait, sorry i though i was in a different channel :)
[02:51] <mwhudson> lovepopsickle: systemd-analyze blame?
[02:58] <lovepopsickle> mwhudson, not sure
[02:58] <lovepopsickle> mwhudson, its not a huge difference about 15 seconds added time
[02:59] <mwhudson> lovepopsickle: miiight be something to do with waiting for ipv6 ras?
[02:59] <mwhudson> lovepopsickle: but with the info you've provided we really can't say
[02:59] <lovepopsickle> i think i have ipv6 disabled
[02:59] <mwhudson> lovepopsickle: if you pastebin the output of systemd-analyze blame for both systems, at least that's something to start with
[03:01] <lovepopsickle> mwhudson, https://zerobin.net/?f842c3137adfb4a3#XVRu0obOxXb9e11nj6jU2HFtlucVFkLtRsMxzXA5ptE=
[03:07] <lovepopsickle> mwhudson, https://askubuntu.com/questions/1029050/long-boot-times-on-18-04
[03:10] <lovepopsickle> https://askubuntu.com/questions/1038368/slow-boot-on-ubuntu-18-04
[03:10] <lovepopsickle> https://www.reddit.com/r/Ubuntu/comments/8dws67/can_we_talk_about_the_boot_time_on_ubuntu_1804/
[03:10] <lovepopsickle> https://www.quora.com/Why-did-Ubuntu-18-04-slow-down-on-booting-How-do-I-solve-it?share=1
[03:10] <lovepopsickle> looks like there is a bug going on
[03:12] <lovepopsickle> plymouth-quit-wait.service looks like the major cause
[03:17] <lovepopsickle> bug report: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1742063
[03:17] <ubottu> Launchpad bug 1742063 in systemd (Ubuntu) "Systemd taking long time to boot into desktop 18.04" [Undecided,Confirmed]
[03:18] <lovepopsickle> mwhudson, did you see the blame link?
[03:18] <mwhudson> lovepopsickle: i did but it didn't mean very much to me i'm afraid
[03:19] <lovepopsickle> i mean its basically the same issue as those other links
[03:19] <mwhudson> i'm not sure that's true
[03:20] <mwhudson> there's no wait-online on there for example
[03:21] <lovepopsickle> not sure what you mean. What I was saying is that plymouth-quit-wait.service seems to be taking about 30 secs and there is a bug report on it
[03:22] <lovepopsickle> your saying i should have had a wait-online?
[03:22] <lovepopsickle> its the plymouth-quit-wait that seems to be the common theme
[03:23] <lovepopsickle> or is that the total seconds?
[03:26] <lovepopsickle> well its not a huge deal and maybe it will get fixed later. Those links did not see to have any good solutions maybe it will get worked out later
[03:27] <lovepopsickle> it doesnt take that long but it was noticeable from before.
[06:30] <jamespage> doko: re zvmcloudconnector I've re-uploaded with a tidied d/copyright - I could not find any missing copyright information, but there did appear to be a surplus copyright holder in d/copyright
=== gurmble is now known as grumble
[09:15] <seb128> juliank, hey, you previously merged wpa, could you do it again for the current revision? it fixes a CVE so would be nice to get into cosmic
[09:15] <seb128> https://packages.qa.debian.org/w/wpa/news/20180808T210425Z.html
[09:21] <juliank> seb128: ack
[09:21] <seb128> thx
[09:25] <juliank> I should really do some more merges
[09:26] <Unit193> Merges are nice, dropping delta is even better. :>
[09:30] <juliank> true
[09:30] <juliank> very true
[10:27] <jamespage> doko: ta ;)
[10:27] <jamespage> on the assumption it was you
=== alan_g is now known as alan_g|lunch
[13:00] <psusi> so I'm investigating reports of grub postinst failures and it looks like set -e is terminating the script on this line:
[13:00] <psusi> device_map="$(grub-mkdevicemap -m - | grep -v '^(fd[0-9]\+)' || true)"
[13:01] <psusi> shouldn't that || true catch any errors and keep the entire pipeline from failing and so it should not be possible to terminate the script here?
[13:02] <cjwatson> You'd have thought.  I'd suggest trying to construct smaller test cases
[13:03] <cjwatson> set -e has a few weird edge cases
[13:03] <cjwatson> And they're likely highly shell-dependent, so check what /bin/sh is
[13:04] <psusi> cjwatson: grub-pc.postinst's shbang calls for /bin/bash
[13:05] <cjwatson> so it does
=== alan_g|lunch is now known as alan_g
[13:08] <psusi> replacing either side with false doesn't seem to bail out of the script....
[13:10] <psusi> hrm... what if the child is terminated with a signal?
[13:13] <psusi> nope... script still continues....
[13:13] <psusi> how could that grep be the last thing that is run before the postinst errors out?  weird...
=== Laney changed the topic of #ubuntu-devel to: Archive: open (Cosmic Cuttlefish), auto-sync disabled temporarily | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first
[15:00] <jbicha> Laney: something is wrong with the armhf autopkgtests (excuses says Test in Progress for all of them), I retried the ones from today, but there is more from yesterday
[15:01] <Laney> jbicha: Please additionally ping slangasek, sil2100 (although not here atm), juliank
[15:01] <Laney> this is not a one person show any more
[15:01] <Laney> thankfully, because I can't really look atm
[15:01] <jbicha> ok, good :)
[15:01]  * juliank has meeting now
[15:04] <Laney> an example of one that you accuse of going missing would be helpful for $person to look in the logs
[15:09] <Laney> ah, what the hell, I just restarted everything, looks like the machine got a reboot :(
[15:10] <jbicha> thanks
[16:33] <bdmurray> roaksoax: It looks like there may be a regression with the maas SRU. https://errors.ubuntu.com/problem/243e461131f7d9c36fd09fee3e90d74a01401d5c
[16:37] <ahasenack> rbasak: hi, can you click the lander signoff one more time please? :) https://bileto.ubuntu.com/#/ticket/3351
[16:50] <rbasak> ahasenack: done
[16:50] <ahasenack> rbasak: thanks
[16:51] <ahasenack> sil2100 isn't here, I wanted to ask him why I can't do that step
[16:51] <rbasak> Perhaps it's restricted to uploaders but bileto doesn't know about packagesets and things?
[16:58] <ahasenack> it's probably related yes
[16:58] <ahasenack> but that restriction should apply to the "publish" button
[16:58] <ahasenack> I can do that step with krb5, which I can upload
[16:59] <ahasenack> squid (not squid3) is NEW
[18:09] <roaksoax> bdmurray: howdy, yes I saw that email. That said, who maintains the registration form ?
[18:18] <bdmurray> roaksoax: I do
[19:45] <roaksoax> bdmurray: ok, its not a regression. The same happens in older versions of MAAS
[19:54] <bdmurray> roaksoax: Could you show the error with previous versions?
[20:24] <howard> Hi!
[20:24] <howard> I'm looking for a breakdown of the standard options of the /etc/lsb_release file as I'm trying to modify it to describe a custom release
[20:25] <howard> Are there any options beyond the DISTRIB_ID, RELEASE, CODENAME, and DESCRIPTION fields?
=== Son_Goku is now known as Conan_Kudo
=== Conan_Kudo is now known as Son_Goku
[20:34] <rbasak> howard: see the lsb_release manpage. I believe the standard interface is the command, and the /etc/lsb_release file is an implementation detail.
[20:35] <rbasak> If you want to parse a file, then you might find https://www.freedesktop.org/software/systemd/man/os-release.html more useful.
[20:35] <rbasak> (/etc/lsb_release file is an implementation detail which you cannot rely on to be stable)
[20:39] <howard> I felt more okay with relying on it because I'm going to be writing the file. It's not a user lib trying to read OS information
[20:40] <howard> rbasak: like, I guess I mean I'm trying to edit the implementation detail
=== jdstrand_ is now known as jdstrand
=== Guest48018 is now known as RAOF