[00:44] vorlon: Hi! You have a longstanding patch in irssi, did you ever file an issue upstream for that or talk to someone in #irssi? I'm presuming it has something to do with connecting to Canonical's IRC network, or getting out from there. [00:44] Unit193: it was filed upstream; upstream rejected it; the patch in question is mandatory if you want proxies to work properly w/ ssl [00:45] unless upstream has since fixed things differently [00:49] Unfortunate.. [06:15] rbalint, hey, is unattended-upgrades supposed to be installing standard updates in disco? or is that a bug? [06:17] vorlon, ^ maybe you know? [06:17] seb128, not at all! u-u starts upgrades 21 days before the release https://github.com/mvo5/unattended-upgrades/pull/149 [06:17] rbalint: vorlon: associated bug: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1824470 [06:18] Launchpad bug 1824470 in unattended-upgrades (Ubuntu) "unattended-upgrade is running on the dev version, updating regular packages" [Undecided,New] [06:18] rbalint, well, we are in that timeframe, but it seems to apply any disco update [06:18] but isn't it supposed to only install security updates? [06:18] (we don't have anything in security at this point) [06:19] seb128, didrocks: u-u runs in Debian unstable and testing all the time to catch bugs in u-u and in every other package [06:19] rbalint, I noticed because in the mornings my apt is being locked/not usable for long times [06:19] rbalint: this is annoying on the development version, where you want people to have control over their updates though [06:20] like this morning, there was a known mutter issue [06:20] I wanted to check [06:20] updates [06:20] and check the fix [06:20] didrocks, it is possible to disable it [06:20] here, I was puzzled because suddenly things are updated under my feet [06:20] right, I can disable the systemd service [06:20] but maybe won't reenable it after release [06:20] sounds weird, the GUI options tells this service only apply security updates [06:20] didrocks, i'd suggest using the config file instead [06:20] rbalint, sorry your answer are not clear to me. So what you say is that it doesn apply every updates by design on unstable series (= disco)? [06:21] which it doesn't [06:21] rbalint, is it going to stop doing that when disco turns stable? (do we need an upload for changing the behaviour or does it has a notion of what are unstable/stable series?) [06:22] seb128, didrocks: the release pocket and -security are enabled [06:22] relese pocket freezes after the release, thus packages from -security will continue flowing in [06:22] ah, I guess it means once disco it's stable release is not changing and it's not handing -updates [06:23] *only handling updates [06:23] seb128, yes [06:23] sorry -*not* [06:23] rbalint, k, makes sense [06:23] * didrocks finds this new behavior a little bit puzzling though [06:23] rbalint, the user experience is not really nice, we should do integration work in the desktop to tell the user what's going on [06:23] e.g indicator or something [06:24] would be nice if apt was also hinting that "unattended upgrades are being applied" rather than just telling that there is a lock set [06:24] I often end up with a system which I can't use to do work in the morning wondering how long it's going to take before I've my apt back [06:25] I killed unattended-upgrades after 10 min the other day [06:25] especially as it treats one package after another [06:25] as also, you don't know if you are testing the updated version or the one for the day before, like in the mutter case [06:25] because apt policy will tell you are you on the latest, but you didn't restart the software [06:25] (which is actually what happened this morning) [06:26] which is OK in the released version, a little bit less on a dev one IMHO [06:27] (that point is probably a "need to learn about how things changed/are done now" more than a long term issue, once you know it's doing update in bg when you start the machine you can teach yourself to check the update timestamp) [06:28] if you have something that reminds you "we are in those 21 days period before release…" [06:28] yeah, I think the real issue is that we don't surface what's going on in the UI [06:28] yep [06:28] which is also true for security on stable [06:28] right [06:29] we have a class of bugs about that [06:29] like "system hang on shutdown" [06:29] (which is "waits for that service finishes working") [06:31] rbalint, do you have any opinion on the right venue to discuss properly surfacing to the user/in the desktop that u-u is doing its thing in the background (so you know that your updates are being handled, what is making your internet/disk busy, what is locking your packaging tools) [06:31] rbalint, also we should fix software-properties to not tell that "only security updates are being applied" where it's obviously not true [06:35] seb128, probably it would be #ubuntu-desktop [06:36] seb128, terminal users don't really need that [06:37] seb128, ther can be a desktop applet showing when the apt lock is taken [06:37] seb128, it is not only u-u doing things in the background, it can be landscape or other management tool [06:38] seb128, but in a stable release the upgrade should not be noticable [06:40] rbalint, I'm not sure I agree with that, as I said I needed apt to do work the other day and I couldn't use it for 10 min+, I had to lsof on the lock to figure out what was going on, so it's not only desktop [06:41] apt way of telling you that "the lock is taken" without details is an issue for command line users imho [06:41] seb128, i'd just run top or pstree [06:42] because you know what to look for [06:42] I did ps and looked for dpkg processes [06:42] didn't find any [06:42] well, pstree is really nice [06:42] but maybe that was looking for the wrong thing, u-u is not using dpkg? [06:43] seb128, well, it uses mostly libapt, but keeps the lock for the whole session [06:44] right, so I was looking for the wrong thing [06:44] I though it would use dpkg if it was installing packages [06:44] and looked for that [06:44] bottom line is that apt could tell you who owns the lock [06:44] and what's going on [06:44] imho [06:44] seb128, this sounds like an apt wishlist bug [06:44] rbalint, also "it's not an issue on stable" is probably true for a machine which is modern and that you use daily, the other day I turned one a computer I didn't use for a month which has a non-ssd drive [06:45] u-u took like half an hour [06:45] seb128, this is challenging but not unexpected at all [06:45] k [06:46] well, seems we disagree on what makes a good user experience and what can confuse users [06:46] which I guess is the way it is, no point arguing for hours over it [06:46] rbalint, thx for listening and for the replies! [06:46] seb128, no, i agree that showing that apt working in the background could be useful on desktop [06:47] seb128, i have hight expectation of users using dev release on their main machine [06:47] I see that :) [06:48] and i believe we should optimize for high quality stable relases instead of not putting pressure on dev users [06:49] the extra pressure is little imo, i got few complaints from Debian devs for running u-u all the time in testing and sid [06:50] I think thus such changes should have been announced, it impacts everybody using the dev release and announcing those is high development standard IMHO [06:52] didrocks, i agree, i had the plans to write a blog post about it on planet ubuntu, but this got lost in the priorities. I'm sorry. [06:52] rbalint: no worry, but it's not too late! It can help others [06:57] rbalint, right, I agree with that, as Didier said it just probably missed at least an email to ubuntu-devel@ with a FYI [06:58] rbalint, oh, last question for today and then I stop bothering you ... does u-u provide a "client API" (dbus or other) that a potential desktop indicator could use to reflect the current status? [07:00] seb128, no, just the log files, but since not u-u is the only background apt frontend imo it would be better to query the lock file [07:01] rbalint, ideally we would probably like to display the number of pending updates to apply (and a time estimate? but I guess that would be more difficult) [07:01] (or % done estimate) [07:02] a "btw something has a lock" is useful but not that useful [07:03] software management tools do tell you that they fail working because there is a lock [07:03] by itself it's confusing unless you know what has the lock/why/how long it's still going to do things [07:04] otherwise you can't tell appart a "something crashed and left a stalled lock" from "u-u is applying update, it's done with 27 of the 30 pending ones, it should be done soon" [07:37] didrocks, seb128 just sent the email, thanks for the reminder [07:37] rbalint, thx! [07:38] rbalint, so, who is the person to talk to about maybe scheduling work to add a proper status reporting API to u-u? ;) [07:38] I've a feeling it's going to end up being too low priority to make it on the roadmap for next cycle, but I think it's worth having a discussion about it at least [07:38] seb128, it would be me :-) [07:39] rbalint, :-) [07:39] I need to check with willcooke also if he believes that's important enough from a desktop side to commit to work on it [07:39] or if that's in a land of wishlists we are not likely going to be able to work on [07:40] seb128, in general i agree we should let users know that something is going on when the system is working hard, i see devel as a special case [07:40] right, I don't care so much about devel [07:40] but that problem exists in stable series as well [07:40] seb128, and package upgrades should take a few seconds tops [07:41] seb128, i have a few work items around that [07:41] on my inspiron test machine regenerating the locales when there is a libc update takes like 3 minutes by itself [07:42] seb128, imo this is the problem, not the indicator [07:42] I think the "few seconds" depends a lot of what is in the upgrade and your hardware/disk [07:42] the issue is that packages are installed grouped by grouped [07:42] not in one apt transaction [07:42] kernel updates and regenerating the initrd also take a while [07:43] I don't know why there is this design [07:43] didrocks, that wouldn't make a difference on the "can lock the apt db for a long time" [07:43] seb128, initrd should be lz4 [07:43] seb128: it does add more time though, as apt everytime recompute the dep coherence [07:44] didrocks, upgrades are grouped to gracefully stop when needed between them, so you can shut down your system [07:44] didrocks, it's a problem but I think it's orthogonal, even if we changed that, generating locales would still take 3 min on the inspiron and the apt db could still be locked for 10 min on a "non trivial" update which includes kernel and libc [07:45] I think the granularity is a little too small. Like 7 "transactions" in a 45 seconds sounds wrong [07:45] didrocks, /usr/share/doc/unattended-upgrades/NEWS.Debian.gz , 0.95 entry [07:45] seb128: yeah, but you suffer from fsyncing then 7 times instead of one, which is what adds up [07:46] I guess an intermediate granularity may be worth exploring (but we need to have an idea of the estimate time to isntall this group of packages, which is hard) [07:47] didrocks, i'm sorry but no, one failing package would fail the whole set [07:48] failing package is rare, so then a fallback on package by package is doable [07:48] which is more code, but more smartness to add to the system as well [07:49] didrocks, i plan further speed optimization of debs and u-u [07:50] didrocks, i'm thinking about randomizing the order of sets which is expected to cause bigger sets [07:50] interesting idea [07:51] didrocks, to avoid a single broken package blocking the installation of bigger sets [07:52] who do i talk to about [07:52] apt-esm-hook: hook.cc:186: int main(int, char**): Assertion `ppid == getppid_of("self")' failed. [07:52] Aborted (core dumped) [07:52] breaking all the livefs builds [07:52] e.g. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/disco/ubuntu-server-live/+build/161947 [07:52] juliank: do you know about this one? ^^ [08:01] rbalint, anyway, back to other topics/work for me, thx for the discussion, it was interesting! and good to know you are more optimizations planned :) (also you might hear again from me on the topic if we decide to do the indicator, I might then bother you with how to best get the info we need out of u-u) [08:34] seb128, thank you too! [08:38] seb128, regarding indicating u-u's state i opened a bug some time ago and i think this is more annoying than the morning u-u runs LP: #180358 [08:38] Launchpad bug 180358 in firefox (Ubuntu) "news paper cant read malayalam in firefox browser" [Undecided,Invalid] https://launchpad.net/bugs/180358 [08:39] rbalint, I guess you lack a digit in that bug number? [08:40] LP: #1803581 [08:40] Launchpad bug 1803581 in gnome-shell (Ubuntu) "PrepareForShutdown() signal from logind is not handled" [Low,Triaged] https://launchpad.net/bugs/1803581 [08:42] rbalint, thx [09:08] mwhudson: oh oh [09:09] so I assume the problem is that there is no grandparent process of the hook [09:09] but that's odd [09:13] no hang on [09:13] it's got no /proc/self I guess === Wryhder is now known as Lucas_Gray === ricab is now known as ricab|lunch [12:05] Can the distro revision of a package be numbered like -1ubuntuY.Z ? [12:06] Does ubuntuY.Z instead represents the series that the package applies to? [12:10] danyspin97: you might find my writeup helpful: http://www.justgohome.co.uk/blog/2015/01/ubuntu-package-versions.html [12:10] danyspin97: also https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging [12:36] rbasak: Thank you === ricab|lunch is now known as ricab === Wryhder is now known as Lucas_Gray [15:59] rbasak: > A tilde (~) is defined to sort before anything else. Is there any article/reference I can read more about this for PPA? [16:02] danyspin97: https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage maybe? And https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version for the actual spec, which should help it all make sense. [16:10] rbasak: Ah, I see. It wasn't clear to me that ~ was in the Debian specification. Thank you! [17:11] vorlon, cyphermox: Any reason why the mokutils in Disco/Cosmic hasn't been upstreamed to Debian? There's an open RC bug in Debian citing Much Brokenness. [17:15] you mean the int-signedness patch? [17:15] because everything else is just upstream. [17:18] All of it. :) [17:18] vorlon is the maintainer, which is why I pinged. [17:18] I'm sure vorlon would have no issues sponsoring your upload to update it [17:19] I'm a DD, I can upload myself if vorlon acks my NMU. ;) [17:19] ah [17:19] I don't want to speak for him but I'm reasonably sure that would be just fine ;) [17:19] I mean, unless he wants to do it. :P [17:21] cyphermox: One other reason I pinged is, I don't exactly know what I should test... [17:22] I would assume I should do some testing prior to an NMU. [17:23] tsimonq2: that RC bug should be downgraded, "this howto I followed somewhere didn't work thus mokutils is completely unusable" is not RC [17:24] but it's reasonable to also fix [17:25] ok [17:26] vorlon: How do you want to do this? 0-day NMU, DELAYED NMU, you do it...? [17:27] tsimonq2: you adopt the package? ;) [17:28] vorlon: Only if I can add you and cyphermox as comaintainers ;) [17:28] Sure, why not [17:28] nah [17:28] I mean, if you're serious, I can take it off your hands... [17:29] tsimonq2: I am serious; I'm not maintaining it, the Vcs-Bzr field points to an absolete location, there's no increase in my Debian time committment on the horizon [17:30] ack :) [17:31] cyphermox: I'll still offer to add you as a comaintainer ^^^ [18:28] <[rg]> hello [18:28] <[rg]> is there a regular expression package names conform to? [18:39] [rg]: Try looking in Debian policy for that. [18:43] [rg]: though I don't think there's a *regex* that they conform to, more like a package naming convention instead... [18:44] <[rg]> teward: ok that convention should be similar to man page style option descriptons right [18:46] teward: The naming convention can certainly be expressed as a regex. [18:46] infinity: it can? *blinks* got such a regex? [18:46] so long as it doesn't require eg balanced parens.. :D [18:46] hah [18:46] "Package names (both source and binary, see Package) must consist only of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). They must be at least two characters long and must start with an alphanumeric character." [18:47] teward: No, I don't have said regex handy, but given any algorithm describing how to construct a string can be expressed as a regex, I leave it as an exercise to the user. [18:47] [rg]: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-source [18:48] heh [18:48] <[rg]> infinity: yes I am fine doing that, was just looking for docs, thanks [18:48] [a-z][a-z0-9+-.]. seems about right. [18:48] infinity: i must have missed that part, guess being tired hinders that side of the brain :) [18:50] Maybe with some escaping necessary, depending on the language one's embedding that in. :P [19:22] rbasak so with git ubuntu, with the pre-commit/post-checkout hooks, are we forced to use --no-verify with affected repos *forever*? that's super annoying [19:23] oh, i guess someone can upload a pkg removing the dir - just can't do it from git [19:27] seb128: hi, don't know if you saw my follow-up on LP: #1800542, but I could use some help figuring out how to provide proper debug info for nm-openvpn [19:27] Launchpad bug 1800542 in network-manager-openvpn (Ubuntu) "OpenVPN connection not stable after upgrade to 18.10 (udp, ipv6)" [High,Incomplete] https://launchpad.net/bugs/1800542 [20:20] vorlon, hey, I saw and I've it on my backlog to reply to, the week has been a bit crazy but hopefully on monday (I don't know offhand what changed/why the intructions are not working so I need to poke a bit) [20:23] but eow for now, have a nice w.e! [20:43] ddstreet: you can remove the hook if you like. It does nothing apart from detect and warn you. [20:43] ddstreet: it's a workaround. [20:44] rbasak well i can't remove it, snaps are r/o filesystems... :) [20:44] but i can ignore it [20:45] ddstreet: I mean remove the hook from your local checkout directory [20:45] ah [20:45] ddstreet: it's installed in .git/hooks. git ubuntu clone does that. [20:45] nice definitely will remove that then [20:45] ddstreet: the thing to note is that it can break your build [20:46] Some builds require the empty directory to be present, and your checkout won't have it. [20:46] Hence the warning, etc. [20:49] vorlon: you don't need to restart NM, but if you had just "closed" or lost the connection, then you need to wait a little bit before you change the .name file; then it'll work fine. [20:50] cyphermox: how long is a little bit? [20:50] at most 30 seconds, I'd say [20:51] there'd be a line in syslog that says something about killing the service IIRC [20:51] also, make sure to run nm-openvpn-service as root [22:48] vorlon: (mokutil uploaded to Debian) [22:54] tsimonq2: Hmm, I seem to recall you claiming you'd fix pastebinit. [22:55] Oh, did I? [22:55] Got a link? [22:57] Link to? [23:00] he'd link you if he could, but pastebinit's busted... [23:00] * sarnold runs [23:01] Truth! [23:01] arc paste works wonderful (of course you need a phabricator instance) :) [23:01] Only on disco and busted, err, buster. [23:01] wxl: Sounds broken to me. [23:02] works for me XD [23:03] sarnold: You popped up last time too, < sarnold> python :( || < sarnold> tsimonq2: just a recurring sadness [23:03] lol [23:03] Unit193: A link to what I'm supposed to be looking at. [23:04] Ah, Debian 916372, LP 1812232 [23:04] Debian bug 916372 in pastebinit "pastebinit: multiple deprecation warnings under Python 3.7" [Normal,Open] http://bugs.debian.org/916372 [23:04] Launchpad bug 1812232 in pastebinit (Ubuntu) "Deprecation warnings" [Low,Confirmed] https://launchpad.net/bugs/1812232 [23:04] Patch attached in the Debian one, from someone that has a clue too. [23:15] Unit193: DELAYED/5 . [23:15] G'luck! [23:15] Too late for Disco, unless you think it's SRU-worthy. [23:15] it probably is if it's going to shout at the user every time they touch it [23:16] Got a dsc I can backport to a disco PPA? :) [23:24] sarnold: Good point. [23:25] Unit193: You mean the one you can find in the Debian archive once it's processed? ;) [23:51] pastebinit is so useful when someone's in trouble [23:51] bad install or so [23:53] Or to paste debdiffs, git format-patch, config, etc, etc. [23:53] right, I don't spend much time in the console, but for those who do, I imagine endlessly useful