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