[00:44] <Unit193> 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] <vorlon> 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] <vorlon> unless upstream has since fixed things differently
[00:49] <Unit193> Unfortunate..
[06:15] <seb128> rbalint, hey, is unattended-upgrades supposed to be installing standard updates in disco? or is that a bug?
[06:17] <seb128> vorlon, ^ maybe you know?
[06:17] <rbalint> seb128, not at all! u-u starts upgrades 21 days before the release https://github.com/mvo5/unattended-upgrades/pull/149
[06:17] <didrocks> rbalint: vorlon: associated bug: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1824470
[06:18] <seb128> rbalint, well, we are in that timeframe, but it seems to apply any disco update
[06:18] <didrocks> but isn't it supposed to only install security updates?
[06:18] <seb128> (we don't have anything in security at this point)
[06:19] <rbalint> 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] <seb128> rbalint, I noticed because in the mornings my apt is being locked/not usable for long times
[06:19] <didrocks> rbalint: this is annoying on the development version, where you want people to have control over their updates though
[06:20] <didrocks> like this morning, there was a known mutter issue
[06:20] <didrocks> I wanted to check
[06:20] <didrocks> updates
[06:20] <didrocks> and check the fix
[06:20] <rbalint> didrocks, it is possible to disable it
[06:20] <didrocks> here, I was puzzled because suddenly things are updated under my feet
[06:20] <didrocks> right, I can disable the systemd service
[06:20] <didrocks> but maybe won't reenable it after release
[06:20] <didrocks> sounds weird, the GUI options tells this service only apply security updates
[06:20] <rbalint> didrocks, i'd suggest using the config file instead
[06:20] <seb128> 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] <didrocks> which it doesn't
[06:21] <seb128> 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] <rbalint> seb128, didrocks: the release pocket and -security are enabled
[06:22] <rbalint> relese pocket freezes after the release, thus packages from -security will continue flowing in
[06:22] <seb128> ah, I guess it means once disco it's stable release is not changing and it's not handing -updates
[06:23] <seb128> *only handling updates
[06:23] <rbalint> seb128, yes
[06:23] <seb128> sorry -*not*
[06:23] <seb128> rbalint, k, makes sense
[06:23]  * didrocks finds this new behavior a little bit puzzling though
[06:23] <seb128> 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] <seb128> e.g indicator or something
[06:24] <seb128> 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] <seb128> 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] <seb128> I killed unattended-upgrades after 10 min the other day
[06:25] <didrocks> especially as it treats one package after another
[06:25] <didrocks> 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] <didrocks> because apt policy will tell you are you on the latest, but you didn't restart the software
[06:25] <didrocks> (which is actually what happened this morning)
[06:26] <didrocks> which is OK in the released version, a little bit less on a dev one IMHO
[06:27] <seb128> (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] <didrocks> if you have something that reminds you "we are in those 21 days period before release…"
[06:28] <seb128> yeah, I think the real issue is that we don't surface what's going on in the UI
[06:28] <didrocks> yep
[06:28] <seb128> which is also true for security on stable
[06:28] <didrocks> right
[06:29] <seb128> we have a class of bugs about that
[06:29] <seb128> like "system hang on shutdown"
[06:29] <seb128> (which is "waits for that service finishes working")
[06:31] <seb128> 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] <seb128> 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] <rbalint> seb128, probably it would be #ubuntu-desktop
[06:36] <rbalint> seb128, terminal users don't really need that
[06:37] <rbalint> seb128, ther can be a desktop applet showing when the apt lock is taken
[06:37] <rbalint> seb128, it is not only u-u doing things in the background, it can be landscape or other management tool
[06:38] <rbalint> seb128, but in a stable release the upgrade should not be noticable
[06:40] <seb128> 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] <seb128> apt way of telling you that "the lock is taken" without details is an issue for command line users imho
[06:41] <rbalint> seb128, i'd just run top or pstree
[06:42] <seb128> because you know what to look for
[06:42] <seb128> I did ps and looked for dpkg processes
[06:42] <seb128> didn't find any
[06:42] <rbalint> well, pstree is really nice
[06:42] <seb128> but maybe that was looking for the wrong thing, u-u is not using dpkg?
[06:43] <rbalint> seb128, well, it uses mostly libapt, but keeps the lock for the whole session
[06:44] <seb128> right, so I was looking for the wrong thing
[06:44] <seb128> I though it would use dpkg if it was installing packages
[06:44] <seb128> and looked for that
[06:44] <seb128> bottom line is that apt could tell you who owns the lock
[06:44] <seb128> and what's going on
[06:44] <seb128> imho
[06:44] <rbalint> seb128, this sounds like an apt wishlist bug
[06:44] <seb128> 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] <seb128> u-u took like half an hour
[06:45] <rbalint> seb128, this is challenging but not unexpected at all
[06:45] <seb128> k
[06:46] <seb128> well, seems we disagree on what makes a good user experience and what can confuse users
[06:46] <seb128> which I guess is the way it is, no point arguing for hours over it
[06:46] <seb128> rbalint, thx for listening and for the replies!
[06:46] <rbalint> seb128, no, i agree that showing that apt working in the background could be useful on desktop
[06:47] <rbalint> seb128, i have hight expectation of users using dev release on their main machine
[06:47] <seb128> I see that :)
[06:48] <rbalint> and i believe we should optimize for high quality stable relases instead of not putting pressure on dev users
[06:49] <rbalint> 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] <didrocks> 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] <rbalint> 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] <didrocks> rbalint: no worry, but it's not too late! It can help others
[06:57] <seb128> 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] <seb128> 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] <rbalint> 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] <seb128> 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] <seb128> (or % done estimate)
[07:02] <seb128> a "btw something has a lock" is useful but not that useful
[07:03] <seb128> software management tools do tell you that they fail working because there is a lock
[07:03] <seb128> by itself it's confusing unless you know what has the lock/why/how long it's still going to do things
[07:04] <seb128> 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] <rbalint> didrocks, seb128 just sent the email, thanks for the reminder
[07:37] <seb128> rbalint, thx!
[07:38] <seb128> 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] <seb128> 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] <rbalint> seb128, it would be me :-)
[07:39] <seb128> rbalint, :-)
[07:39] <seb128> 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] <seb128> or if that's in a land of wishlists we are not likely going to be able to work on
[07:40] <rbalint> 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] <seb128> right, I don't care so much about devel
[07:40] <seb128> but that problem exists in stable series as well
[07:40] <rbalint> seb128, and package upgrades should take a few seconds tops
[07:41] <rbalint> seb128, i have a few work items around that
[07:41] <seb128> on my inspiron test machine regenerating the locales when there is a libc update takes like 3 minutes by itself
[07:42] <rbalint> seb128, imo this is the problem, not the indicator
[07:42] <seb128> I think the "few seconds" depends a lot of what is in the upgrade and your hardware/disk
[07:42] <didrocks> the issue is that packages are installed grouped by grouped
[07:42] <didrocks> not in one apt transaction
[07:42] <seb128> kernel updates and regenerating the initrd also take a while
[07:43] <didrocks> I don't know why there is this design
[07:43] <seb128> didrocks, that wouldn't make a difference on the "can lock the apt db for a long time"
[07:43] <rbalint> seb128, initrd should be lz4
[07:43] <didrocks> seb128: it does add more time though, as apt everytime recompute the dep coherence
[07:44] <rbalint> didrocks, upgrades are grouped to gracefully stop when needed between them, so you can shut down your system
[07:44] <seb128> 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] <didrocks> I think the granularity is a little too small. Like 7 "transactions" in a 45 seconds sounds wrong
[07:45] <rbalint> didrocks, /usr/share/doc/unattended-upgrades/NEWS.Debian.gz , 0.95 entry
[07:45] <didrocks> seb128: yeah, but you suffer from fsyncing then 7 times instead of one, which is what adds up
[07:46] <didrocks> 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] <rbalint> didrocks, i'm sorry but no, one failing package would fail the whole set
[07:48] <didrocks> failing package is rare, so then a fallback on package by package is doable
[07:48] <didrocks> which is more code, but more smartness to add to the system as well
[07:49] <rbalint> didrocks, i plan further speed optimization of debs and u-u
[07:50] <rbalint> didrocks, i'm thinking about randomizing the order of sets which is expected to cause bigger sets
[07:50] <didrocks> interesting idea
[07:51] <rbalint> didrocks, to avoid a single broken package blocking the installation of bigger sets
[07:52] <mwhudson> who do i talk to about
[07:52] <mwhudson> apt-esm-hook: hook.cc:186: int main(int, char**): Assertion `ppid == getppid_of("self")' failed.
[07:52] <mwhudson> Aborted (core dumped)
[07:52] <mwhudson> breaking all the livefs builds
[07:52] <mwhudson> e.g. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/disco/ubuntu-server-live/+build/161947
[07:52] <mwhudson> juliank: do you know about this one? ^^
[08:01] <seb128> 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] <rbalint> seb128, thank you too!
[08:38] <rbalint> 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:39] <seb128> rbalint, I guess you lack a digit in that bug number?
[08:40] <rbalint> LP: #1803581
[08:42] <seb128> rbalint, thx
[09:08] <juliank> mwhudson: oh oh
[09:09] <juliank> so I assume the problem is that there is no grandparent process of the hook
[09:09] <juliank> but that's odd
[09:13] <juliank> no hang on
[09:13] <juliank> it's got no /proc/self I guess
[12:05] <danyspin97> Can the distro revision of a package be numbered like -1ubuntuY.Z ?
[12:06] <danyspin97> Does ubuntuY.Z instead represents the series that the package applies to?
[12:10] <rbasak> danyspin97: you might find my writeup helpful: http://www.justgohome.co.uk/blog/2015/01/ubuntu-package-versions.html
[12:10] <rbasak> danyspin97: also https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[12:36] <danyspin97> rbasak: Thank you
[15:59] <danyspin97> 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] <rbasak> 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] <danyspin97> rbasak: Ah, I see. It wasn't clear to me that ~ was in the Debian specification. Thank you!
[17:11] <tsimonq2> 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] <cyphermox> you mean the int-signedness patch?
[17:15] <cyphermox> because everything else is just upstream.
[17:18] <tsimonq2> All of it. :)
[17:18] <tsimonq2> vorlon is the maintainer, which is why I pinged.
[17:18] <cyphermox> I'm sure vorlon would have no issues sponsoring your upload to update it
[17:19] <tsimonq2> I'm a DD, I can upload myself if vorlon acks my NMU. ;)
[17:19] <cyphermox> ah
[17:19] <cyphermox> I don't want to speak for him but I'm reasonably sure that would be just fine ;)
[17:19] <tsimonq2> I mean, unless he wants to do it. :P
[17:21] <tsimonq2> cyphermox: One other reason I pinged is, I don't exactly know what I should test...
[17:22] <tsimonq2> I would assume I should do some testing prior to an NMU.
[17:23] <vorlon> 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] <vorlon> but it's reasonable to also fix
[17:25] <tsimonq2> ok
[17:26] <tsimonq2> vorlon: How do you want to do this? 0-day NMU, DELAYED NMU, you do it...?
[17:27] <vorlon> tsimonq2: you adopt the package? ;)
[17:28] <tsimonq2> vorlon: Only if I can add you and cyphermox as comaintainers ;)
[17:28] <tsimonq2> Sure, why not
[17:28] <vorlon> nah
[17:28] <tsimonq2> I mean, if you're serious, I can take it off your hands...
[17:29] <vorlon> 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] <tsimonq2> ack :)
[17:31] <tsimonq2> 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] <tsimonq2> [rg]: Try looking in Debian policy for that.
[18:43] <teward> [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] <infinity> teward: The naming convention can certainly be expressed as a regex.
[18:46] <teward> infinity: it can?  *blinks* got such a regex?
[18:46] <sarnold> so long as it doesn't require eg balanced parens.. :D
[18:46] <teward> hah
[18:46] <infinity> "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] <infinity> 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] <infinity> [rg]: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-source
[18:48] <teward> heh
[18:48] <[rg]> infinity: yes I am fine doing that, was just looking for docs, thanks
[18:48] <infinity> [a-z][a-z0-9+-.]. seems about right.
[18:48] <teward> infinity: i must have missed that part, guess being tired hinders that side of the brain :)
[18:50] <infinity> Maybe with some escaping necessary, depending on the language one's embedding that in. :P
[19:22] <ddstreet> 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] <ddstreet> oh, i guess someone can upload a pkg removing the dir - just can't do it from git
[19:27] <vorlon> 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
[20:20] <seb128> 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] <seb128> but eow for now, have a nice w.e!
[20:43] <rbasak> ddstreet: you can remove the hook if you like. It does nothing apart from detect and warn you.
[20:43] <rbasak> ddstreet: it's a workaround.
[20:44] <ddstreet> rbasak well i can't remove it, snaps are r/o filesystems... :)
[20:44] <ddstreet> but i can ignore it
[20:45] <rbasak> ddstreet: I mean remove the hook from your local checkout directory
[20:45] <ddstreet> ah
[20:45] <rbasak> ddstreet: it's installed in .git/hooks. git ubuntu clone does that.
[20:45] <ddstreet> nice definitely will remove that then
[20:45] <rbasak> ddstreet: the thing to note is that it can break your build
[20:46] <rbasak> Some builds require the empty directory to be present, and your checkout won't have it.
[20:46] <rbasak> Hence the warning, etc.
[20:49] <cyphermox> 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] <vorlon> cyphermox: how long is a little bit?
[20:50] <cyphermox> at most 30 seconds, I'd say
[20:51] <cyphermox> there'd be a line in syslog that says something about killing the service IIRC
[20:51] <cyphermox> also, make sure to run nm-openvpn-service as root
[22:48] <tsimonq2> vorlon: (mokutil uploaded to Debian)
[22:54] <Unit193> tsimonq2: Hmm, I seem to recall you claiming you'd fix pastebinit.
[22:55] <tsimonq2> Oh, did I?
[22:55] <tsimonq2> Got a link?
[22:57] <Unit193> Link to?
[23:00] <sarnold> he'd link you if he could, but pastebinit's busted...
[23:00]  * sarnold runs
[23:01] <Unit193> Truth!
[23:01] <wxl> arc paste works wonderful (of course you need a phabricator instance) :)
[23:01] <Unit193> Only on disco and busted, err, buster.
[23:01] <Unit193> wxl: Sounds broken to me.
[23:02] <wxl> works for me XD
[23:03] <Unit193> sarnold: You popped up last time too, < sarnold> python :( || < sarnold> tsimonq2: just a recurring sadness
[23:03] <sarnold> lol
[23:03] <tsimonq2> Unit193: A link to what I'm supposed to be looking at.
[23:04] <Unit193> Ah, Debian 916372, LP 1812232
[23:04] <Unit193> Patch attached in the Debian one, from someone that has a clue too.
[23:15] <tsimonq2> Unit193: DELAYED/5 .
[23:15] <Unit193> G'luck!
[23:15] <tsimonq2> Too late for Disco, unless you think it's SRU-worthy.
[23:15] <sarnold> it probably is if it's going to shout at the user every time they touch it
[23:16] <Unit193> Got a dsc I can backport to a disco PPA? :)
[23:24] <tsimonq2> sarnold: Good point.
[23:25] <tsimonq2> Unit193: You mean the one you can find in the Debian archive once it's processed? ;)
[23:51] <valorie> pastebinit is so useful when someone's in trouble
[23:51] <valorie> bad install or so
[23:53] <Unit193> Or to paste debdiffs, git format-patch, config, etc, etc.
[23:53] <valorie> right, I don't spend much time in the console, but for those who do, I imagine endlessly useful