[00:00] <juliank> Tomorrow we'll see apt 1.6~alpha6 with a new mirror method and very fast ipv6->ipv4 fallback
[00:01]  * juliank is already running it as 1.6~alpha5ubuntu1 - a weird anomaly :D
[00:02] <juliank> The new mirror method is amazing
[00:02] <juliank> it actually works
[00:03] <juliank> the previous one is broken for unknown reasons
[00:03] <juliank> at least in bionic
[00:03] <JackFrost> Hmm?
[00:03]  * juliank has not checked artful or older
[00:03] <juliank> It just hangs
[00:03] <juliank> in my bionic system
[00:03] <juliank> I think it worked fine in my sid
[00:04] <JackFrost> Using mirror://?  People actually use them? :3
[00:04] <juliank> I don't know, but we have a new method for it
[00:04] <juliank> :D
[00:04] <juliank> There's also mirror+https now
[00:04] <juliank> which you probably should be using
[00:04] <juliank> though, I don't know.
[00:04] <juliank> All I can say is that it works fine now
[00:05] <JackFrost> sources.list normally doesn't contain https :3
[00:06] <juliank> Well the thing with the mirror stuff is that it contains a completely untrusted mirror list
[00:06] <juliank> Using https gives you some security for that
[00:06] <juliank> sure, it would be nicer if the mirror list were signed
[00:08] <juliank> OK, we also do not only fall back fast from IPv6 to IPv4, we fall back fast on any connection problem.
[00:08] <juliank> :D
[00:09] <juliank> So we just do multiple attempts concurrently and pick the first winner
[00:09] <juliank> alternating between the v6 and v4 (or whatever preference your system has), and with 250 ms delay between attempts
[00:10] <JackFrost> Hrm, I need to figure out how to use .sources properly.
[00:10] <juliank> I think we also enabled retries by default
[00:10] <juliank> If something fails to fetch, APT now retries automatically
[00:11] <juliank> Or no, it might be off by default
[00:11] <juliank> But that's really useful with some CDNs......
[00:11] <juliank> JackFrost: Regarding https in sources.list - my debian system is mostly https
[00:12] <juliank> but then I rewrote the https stuff so I had to use it
[00:13] <juliank> https just adds modest levels of confidentiality
[00:13] <juliank> at the risk of having to run all that TLS code
[00:17] <JackFrost> http://paste.openstack.org/show/637558/ I had to hope that would work, but alas. :P
[00:19] <juliank> JackFrost: So, you gotta place that as a .sources file in .sources.list.d, it can't be a .list
[00:19] <JackFrost> I'm aware, and no the format is each URI in a separate block.
[00:20] <juliank> So you can only have one uri in the uris field?
[00:20] <juliank> or?
[00:21] <JackFrost> You don't know? :3  But yes, that's what it seems to be saying in the 'As an example, the sources for your distribution..' section of the manpage, which means 'URIs' is very misleading.
[00:22] <JackFrost> I'd be fine if it picked one so you could but a group of fallover ones there, but with that sources file apt just hangs.
[03:02] <mwhudson> can someone mark ubuntu-image/1.3+18.04ubuntu1 as a badtest?
[03:02] <mwhudson> it's failing because a new flake8 breaks the qa autopkgtest
[09:05] <JackFrost> LocutusOfBorg: Did you see my question the other day?
[09:09] <LocutusOfBorg> JackFrost, no
[09:09] <JackFrost> OK.  I wondered why you dropped remmina back to indicators from using ayatana indicators?
[09:10] <LocutusOfBorg> because it is not in main
[09:10] <LocutusOfBorg> feel free to request a MIR
[09:12] <cpaelzer> Is today some unusual business or shortage on builders?
[09:12] <cpaelzer> my ppa gets predicted times of 4-6 hours to start builds
[09:12] <cpaelzer> just wondering if I need to look for mistakes on my end or if it is just a hickup on the builders themselve
[09:12] <LocutusOfBorg> cpaelzer, I guess the kernel intel foo bug
[09:13] <cpaelzer> oh is today the patchday
[09:13] <cpaelzer> yeah things might recycle then
[09:13] <cpaelzer> but I wondered as all arches stall me
[09:13] <cpaelzer> but if there are core components recycled that could be possible
[09:14] <Laney> all builders are off, see the topic in here
[09:14] <cpaelzer> thanks Laney
[09:14]  * cpaelzer wonders if he every read a topic unless people ask him to do so :-)
[09:17] <LocutusOfBorg> I actually tried to read the topic, but hexchat when topic is long, shows just the end, not the begin :/
[09:18] <Laney> can't type /topic or something?
[09:19] <LocutusOfBorg> yep, but it didn't come in my mind that it could have been written at the begin, it was a brain bug :)
[09:21] <JackFrost> LocutusOfBorg: Aha, wondered if that was it.
[09:47] <JackFrost> Laney: I versioned it the way I did so that it'd satisify (>= 11) depends, though technically isn't the most accurate version.
[09:54] <JackFrost> LocutusOfBorg: I specifically wondered as I'm waiting to see what happens before I take action on xfce4-indicator-plugin.
[10:00] <Laney> JackFrost: thanks, can you post on the bug please so that I don't forget and others know?
[10:00] <JackFrost> Sure, I'm not attached to the version string though.
[10:03] <Laney> I guess someone can help review / consider it
[10:08] <LocutusOfBorg> JackFrost, the desiderata should be to move everything in main to the new dependency
[10:13] <LocutusOfBorg> jbicha, is it possible to switch network-manager-applet to aytana-appindicator?
[10:13] <JackFrost> Debian #880169.
[10:15] <LocutusOfBorg> nice
[10:15] <LocutusOfBorg> transmission can probaably loose support
[10:16] <JackFrost> https://wiki.debian.org/Ayatana/IndicatorsTransition
[10:16] <LocutusOfBorg> and update-notifier is left
[10:17] <LocutusOfBorg> why update-notifier is not in that list?
[10:18] <JackFrost> Because that's not a package.
[10:18] <JackFrost> !info update-notifier unstable
[10:20] <cking> Laney, FYI, I fixed that issue with stress-ng very late last night, so it should be fine now
[10:21] <cking> http://kernel.ubuntu.com/git/cking/stress-ng.git/commit/?id=25292428d235e2e96a3590ba7a48ef823ef0226a
[10:23] <Laney> cking: great, thanks!
[10:24] <Laney> if you ping me just before you upload it next time I can revert the blacklist
[10:24] <Laney> ha
[10:24] <Laney> nice fix
[10:24] <cking> stupid bug more like ;-)
[10:25] <Laney> try THIS for stress *pow pow pow*
[10:25] <cking> it's very good at stopping everything :-)
[10:52] <LocutusOfBorg> JackFrost, I'm talking about ubuntu
[10:52] <LocutusOfBorg> !info update-notifier bionic
[10:53] <cpaelzer> hmm - is is a common issue that dbgsym of old releases are not copied forward
[10:53] <cpaelzer> libopts25 was last uploaded in zesty
[10:53] <cpaelzer> and I can't find its -dbgsym in bionic
[10:53] <cpaelzer> I can however
[10:53] <cpaelzer> use https://launchpad.net/ubuntu/bionic/amd64/libopts25-dbgsym/1:5.18.12-3
[10:54] <cpaelzer> and things work
[10:54] <cpaelzer> just wondering if I stumble or found an actual issue
[11:04] <cpaelzer> rbasak: ahasenack: I'd appreciate if you could take a look at the dbgsym question I had above ^^ - just to be sure it is no real thing
[11:05] <ahasenack> cpaelzer: sorry, I don't see the question in my history, my irc proxy must have been down
[11:13] <rbasak> They end up on ddebs I think?
[11:13] <rbasak> https://wiki.ubuntu.com/Debug%20Symbol%20Packages
[11:13] <rbasak> libopts25-dbgsym isn't published in Zesty either.
[11:14] <rbasak> You have to add the ddebs repo to get it
[11:27] <ahasenack> rbasak: do you know if I have perms to use bileto now? I would like to run the ocfs2-tools dep8 tests there. I can upload that particular package to the archive, if that matters
[11:28] <cjwatson> bileto ain't going to get very far for a while (see topic)
[11:28] <ahasenack> I see
[11:28] <ahasenack> does that include ppas?
[11:28] <cjwatson> yes
[11:29] <ahasenack> ok
[11:32] <cpaelzer> rbasak: I have the repo in bionic
[11:32] <cpaelzer> rbasak: and I get other bionic ddebs just fine
[11:33] <rbasak> cpaelzer: ah, so it's a missing ddeb?
[11:33] <rbasak> ISTR some kind of publication problem for ddebs a while back.
[11:33] <rbasak> Where some ddebs were lost or something.
[11:33] <rbasak> I wonder if it's that.
[11:33] <cpaelzer> they are still avail on the LP link I had above
[11:34] <cpaelzer> let me check if it would have worked in zesty itself
[11:35] <cpaelzer> yep working just fine in zesty
[11:35] <cpaelzer> I'll sping up a few contianers and make an overview a) to be sure and b) to outline the issue better
[11:40] <cpaelzer> rbasak: ok - it works now on all releases I tested not only zesty
[11:40] <cpaelzer> checking the sys I originally had the issue now ...
[12:37] <doko> apw, xnox: about 1521174, who should be the bug subscriber?
[12:45] <xnox> doko, updates will be published in the upstream linux-firmware repository from now on. Not sure if it makes sense to have this package stand-alone or be folded into linux-firmware
[12:45] <xnox> doko, foundations or kernel.
[12:45] <xnox> either or both will do
[12:46] <xnox> subscribed foundations bugs
[12:55] <jbicha> LocutusOfBorg: I don't know anything about the current status of the ayatana stuff in Ubuntu, ask sunweaver or flexiondotorg
[13:01] <apw> bug #1521174
[14:49] <pavlix> pitti: HI!
[14:49] <pitti> hey pavlix, how are you? :-)
[14:52] <pavlix> pitti: I quit Red Hat at the end of April and went freelance. I moved back to Prague in August. And I started a short term contract on network configuration in September. What do you think? :)
[14:54] <pitti> pavlix: sounds great, good luck with it! certainly a lot more effort to look for customers yourself, but also exciting :)
[14:55] <pavlix> pitti: I actually had to postpone the search for customers as I was already in contact with more than I can handle simultneously.
[15:00] <pavlix> pitti: Sounds like this wans't a bad time to get back to the market after five years.
[15:01] <pavlix> pitti: Anyway, I heard Ubuntu has some news regarding network management.
[15:04] <pitti> pavlix: right, it's using netplan by default now, to replace ifupdown with networkd
[15:04] <pitti> and allow a more common config between that and NM from cloud configs, etc.
[15:05] <pavlix> pitti: When we're at it, unification and progress is exactly the area I'm attacking now.
[15:07] <pavlix> pitti: Debian is keeping ifupdown forever?
[15:09] <pitti> pavlix: not sure, but it's certainly not pushing strongly away from it
[15:09] <pavlix> pitti: What is the main motivation for networkd?
[15:09] <pitti> it had been unmaintained for a while, but now Guus took it over and he is pretty active
[15:10] <pavlix> pitti: As networkd is a half-baked and hacky solution.
[15:10] <pitti> pavlix: it's a lot simpler and more robust than ifupdown, supports real hotplugging, more types of virtual devices OOTB
[15:11] <pitti> well, ifupdown is doubly (or more) that :)
[15:12] <pavlix> pitti: I used ifupdown for ages and used all the scripting features there. I'm afraid networkd has close to no scripting features now.
[15:12] <pitti> https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-network-yaml links to the full specification and use case analysis, but it's Canonical-internal (so I can't access it either any more)
[15:12] <pitti> pavlix: well, it's not going away, just not used by default any more
[15:13] <pitti> also, these scripting facilities got abused a lot and were the source of many bugs and race conditions
[15:15] <pavlix> pitti: Everything can be abused. That's not the best reason to avoid it.
[15:19] <pitti> but a good reason to replace it with something more robust that avoids the races :)
[15:20] <pitti> as said, this is fine for the vast majority of use cases, like pretty much every cloud/virtual image; desktops use NM; and for the remaining 1% of use cases you can pick whatever tool you need
[15:20] <pitti> it's an opinionated default, nothing more
[15:21] <pavlix> pitti: Sure.
[15:27] <pavlix> pitti: Anyway I have a plan to automate testing a bit with kernel namespaces and test the network services that way.
[15:27] <xnox> pavlix, do checkout networking-test.py in systemd tree; and the intergration test-suite in netplan.
[15:28] <xnox> pavlix, the netplan integration tests a lot of networkd and network-manager.... which does uncover how unreliable network-manager is =/
[15:28] <xnox> pavlix, more networking setups and more networking tests is always needed, because it's really under-tested.
[17:30] <bdmurray> jbicha: So I should reject both evolution and e-d-s since there will be a new version shortly?
[17:44] <jbicha> bdmurray: that sounds good
[17:58] <bdmurray> mvo, ogra_: Could somebody respond to my comment on bug 1623125?
[18:11] <rbasak> smoser: what if we said that from Bionic onwards, cloud-init will default to manage_etc_hosts: localhost. What would that break?
[18:12] <rbasak> In addition, we declare that on Ubuntu, the responsibility to do the right thing lies with either the installer (for non-cloud), or cloud-init (for cloud).
[18:12] <rbasak> That would leave lxd the responsibility only when using a stgraber image, I think.
[18:13] <stgraber> rbasak: images:ubuntu/series/arch already templates /etc/hosts (and I do that for all distros we build images for)
[18:14] <stgraber> it's just with the images that use cloud-init that we don't mess with any of those files :)
[18:14] <rbasak> stgraber: oh? How does lxd know to apply templates?
[18:14] <rbasak> Is there metadata in the image or something?
[18:14] <stgraber> oh, except we do /etc/hostname even in the cloud-init ones these days due to the dhclient race IIRC
[18:15] <stgraber> rbasak: the metadata tarball contains a yaml doc that lists all the templates to run and when to run them
[18:15] <rbasak> I see. Nice!
[18:15] <rbasak> smoser: so my proposed solution works universally then I think?
[18:15] <rbasak> Treat lxd as an "installer" when using non-cloud.
[18:17] <smoser> rbasak: it would break the case where something expects hostname --fqdn to do something meaningful
[18:18] <smoser> which is a flawed expectation to be sure
[18:21] <rbasak> smoser: doesn't manage_etc_hosts: localhost *fix* "hostname -f" to return the specified FQDN?
[18:21] <rbasak> Unless the name supplied to cloud-init is bad, that is, but DNS had it right.
[18:21] <rbasak> In which case, isn't that a horribly broken cloud?
[18:22] <smoser> sorry, i think i mispoke. i think
[18:22] <smoser> its more
[18:22] <smoser>  $ hostname --ip-address
[18:22] <smoser> 127.0.1.1
[18:23] <smoser> some programs (i can't find the reference, but in my head it tends to be java/tomcat, but probably other things)
[18:23] <smoser> try to figure out "how can someone communicate with me"
[18:23] <smoser> and do so by looking up their hostname in dns
[18:23] <smoser> and then publishing that.
[18:23] <smoser> and when there is 127. address in /etc/hosts, that clearly is busted.
[18:24] <smoser> that is also very clearly broken assumptions and simplistic view of the world
[18:25] <smoser> i think i'm ok to do that though.
[18:25] <rbasak> I see
[18:26] <rbasak> I agree that it seems an appropriate thing to break in order to fix the general problem.
[18:27] <rbasak> (only in a new release of course)
[19:08] <pavlix> xnox: I know pretty well about reliability of NetworkManager and did quite some work to improve it but was unfortunately not able to continue.
[19:09] <pavlix> xnox: My special interest is in specialized tests...
[19:11] <pavlix> xnox: Nice to meet you, by the way.
[19:15] <mitya57> I get 500 internal server error when trying to retry autopkgtests, is that a known issue?
[19:15] <mitya57> URL is http://autopkgtest.ubuntu.com/request.cgi?release=bionic&arch=s390x&package=python-ruffus&trigger=mathjax/2.7.2%2Bdfsg-1&trigger=sphinx/1.6.5-4
[19:21] <pavlix> Son_Goku: You're everywhere. :)
[19:22] <pavlix> Son_Goku: I came here to visit pitti.
[19:22] <nacc> mitya57: i'm just guessing it might be due to /topic
[19:22] <Son_Goku> heh
[19:22] <Son_Goku> you know he's also in #cockpit
[19:23] <mitya57> nacc: not sure if autopkgtests are related to the buildd farm anyhow, but will try later, thanks
[19:28] <pavlix> Son_Goku: Yep, I do, he answered my e-mail.
[20:20] <dexterfoo> I found a bug in the apparmor profile of the inspircd package written by lamont jones. It doesn't allow connecting to(opening) any sqlite database files. This makes the included inspircd "m_sqlite3.so" module broken and useless
[20:21] <nacc> !bug | dexterfoo
[20:21] <sarnold> dexterfoo: woot
[20:21] <sarnold> dexterfoo: where's the profile for that live? in the package or somewhere else?
[20:21] <dexterfoo> sarnold: in the package
[20:22] <dexterfoo> https://packages.ubuntu.com/artful/amd64/inspircd/filelist
[20:22] <sarnold> dexterfoo: sweet, as nacc points out, a bug report might be best, https://bugs.launchpad.net/ubuntu/+source/inspircd/+filebug
[20:23] <dexterfoo> ok thanks
[20:58] <lamont> dexterfoo: I think I missed a lot of things when I wrote that apparmor profile, tbf.  bugs welcome
[21:03] <dexterfoo> lamont: cool. i'm not sure what the proper fix is to allow access to arbitrary sqlite files. but maybe just allow access to sqlite files in the /etc/inspircd/ directory. (The profile already allows reading all files in that directory, but for sqlite to work, it needs "k" permission in addition to "r" permission)
[23:59] <xnox> pavlix, hehehe well in that case you are all set i guess!
[23:59] <xnox> pavlix, i'm just a minion.