| 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:44 |
| vorlon | unless upstream has since fixed things differently | 00:45 |
| Unit193 | Unfortunate.. | 00:49 |
| seb128 | rbalint, hey, is unattended-upgrades supposed to be installing standard updates in disco? or is that a bug? | 06:15 |
| 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:17 |
| ubottu | Launchpad bug 1824470 in unattended-upgrades (Ubuntu) "unattended-upgrade is running on the dev version, updating regular packages" [Undecided,New] | 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| didrocks | which is OK in the released version, a little bit less on a dev one IMHO | 06:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:31 |
| rbalint | seb128, probably it would be #ubuntu-desktop | 06:35 |
| rbalint | seb128, terminal users don't really need that | 06:36 |
| 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:37 |
| rbalint | seb128, but in a stable release the upgrade should not be noticable | 06:38 |
| 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:40 |
| 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:41 |
| 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:42 |
| rbalint | seb128, well, it uses mostly libapt, but keeps the lock for the whole session | 06:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| rbalint | seb128, i have hight expectation of users using dev release on their main machine | 06:47 |
| seb128 | I see that :) | 06:47 |
| rbalint | and i believe we should optimize for high quality stable relases instead of not putting pressure on dev users | 06:48 |
| 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:49 |
| 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:50 |
| 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:52 |
| 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:57 |
| 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? | 06:58 |
| 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:00 |
| 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:01 |
| seb128 | a "btw something has a lock" is useful but not that useful | 07:02 |
| 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:03 |
| 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:04 |
| rbalint | didrocks, seb128 just sent the email, thanks for the reminder | 07:37 |
| seb128 | rbalint, thx! | 07:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| rbalint | didrocks, i'm sorry but no, one failing package would fail the whole set | 07:47 |
| 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:48 |
| rbalint | didrocks, i plan further speed optimization of debs and u-u | 07:49 |
| rbalint | didrocks, i'm thinking about randomizing the order of sets which is expected to cause bigger sets | 07:50 |
| didrocks | interesting idea | 07:50 |
| rbalint | didrocks, to avoid a single broken package blocking the installation of bigger sets | 07:51 |
| 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? ^^ | 07:52 |
| 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:01 |
| rbalint | seb128, thank you too! | 08:34 |
| 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:38 |
| ubottu | Launchpad bug 180358 in firefox (Ubuntu) "news paper cant read malayalam in firefox browser" [Undecided,Invalid] https://launchpad.net/bugs/180358 | 08:38 |
| seb128 | rbalint, I guess you lack a digit in that bug number? | 08:39 |
| rbalint | LP: #1803581 | 08:40 |
| ubottu | Launchpad bug 1803581 in gnome-shell (Ubuntu) "PrepareForShutdown() signal from logind is not handled" [Low,Triaged] https://launchpad.net/bugs/1803581 | 08:40 |
| seb128 | rbalint, thx | 08:42 |
| juliank | mwhudson: oh oh | 09:08 |
| juliank | so I assume the problem is that there is no grandparent process of the hook | 09:09 |
| juliank | but that's odd | 09:09 |
| juliank | no hang on | 09:13 |
| juliank | it's got no /proc/self I guess | 09:13 |
| === Wryhder is now known as Lucas_Gray | ||
| === ricab is now known as ricab|lunch | ||
| danyspin97 | Can the distro revision of a package be numbered like -1ubuntuY.Z ? | 12:05 |
| danyspin97 | Does ubuntuY.Z instead represents the series that the package applies to? | 12:06 |
| 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:10 |
| danyspin97 | rbasak: Thank you | 12:36 |
| === ricab|lunch is now known as ricab | ||
| === Wryhder is now known as Lucas_Gray | ||
| danyspin97 | rbasak: > A tilde (~) is defined to sort before anything else. Is there any article/reference I can read more about this for PPA? | 15:59 |
| 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:02 |
| danyspin97 | rbasak: Ah, I see. It wasn't clear to me that ~ was in the Debian specification. Thank you! | 16:10 |
| 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:11 |
| cyphermox | you mean the int-signedness patch? | 17:15 |
| cyphermox | because everything else is just upstream. | 17:15 |
| 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:18 |
| 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:19 |
| tsimonq2 | cyphermox: One other reason I pinged is, I don't exactly know what I should test... | 17:21 |
| tsimonq2 | I would assume I should do some testing prior to an NMU. | 17:22 |
| 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:23 |
| vorlon | but it's reasonable to also fix | 17:24 |
| tsimonq2 | ok | 17:25 |
| tsimonq2 | vorlon: How do you want to do this? 0-day NMU, DELAYED NMU, you do it...? | 17:26 |
| vorlon | tsimonq2: you adopt the package? ;) | 17:27 |
| 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:28 |
| 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:29 |
| tsimonq2 | ack :) | 17:30 |
| tsimonq2 | cyphermox: I'll still offer to add you as a comaintainer ^^^ | 17:31 |
| [rg] | hello | 18:28 |
| [rg] | is there a regular expression package names conform to? | 18:28 |
| tsimonq2 | [rg]: Try looking in Debian policy for that. | 18:39 |
| teward | [rg]: though I don't think there's a *regex* that they conform to, more like a package naming convention instead... | 18:43 |
| [rg] | teward: ok that convention should be similar to man page style option descriptons right | 18:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| infinity | Maybe with some escaping necessary, depending on the language one's embedding that in. :P | 18:50 |
| 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:22 |
| ddstreet | oh, i guess someone can upload a pkg removing the dir - just can't do it from git | 19:23 |
| 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 | 19:27 |
| ubottu | 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 | 19:27 |
| 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:20 |
| seb128 | but eow for now, have a nice w.e! | 20:23 |
| 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:43 |
| ddstreet | rbasak well i can't remove it, snaps are r/o filesystems... :) | 20:44 |
| ddstreet | but i can ignore it | 20:44 |
| 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:45 |
| 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:46 |
| 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:49 |
| vorlon | cyphermox: how long is a little bit? | 20:50 |
| cyphermox | at most 30 seconds, I'd say | 20:50 |
| 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 | 20:51 |
| tsimonq2 | vorlon: (mokutil uploaded to Debian) | 22:48 |
| Unit193 | tsimonq2: Hmm, I seem to recall you claiming you'd fix pastebinit. | 22:54 |
| tsimonq2 | Oh, did I? | 22:55 |
| tsimonq2 | Got a link? | 22:55 |
| Unit193 | Link to? | 22:57 |
| sarnold | he'd link you if he could, but pastebinit's busted... | 23:00 |
| * sarnold runs | 23:00 | |
| 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:01 |
| wxl | works for me XD | 23:02 |
| 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:03 |
| Unit193 | Ah, Debian 916372, LP 1812232 | 23:04 |
| ubottu | Debian bug 916372 in pastebinit "pastebinit: multiple deprecation warnings under Python 3.7" [Normal,Open] http://bugs.debian.org/916372 | 23:04 |
| ubottu | Launchpad bug 1812232 in pastebinit (Ubuntu) "Deprecation warnings" [Low,Confirmed] https://launchpad.net/bugs/1812232 | 23:04 |
| Unit193 | Patch attached in the Debian one, from someone that has a clue too. | 23:04 |
| 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:15 |
| Unit193 | Got a dsc I can backport to a disco PPA? :) | 23:16 |
| tsimonq2 | sarnold: Good point. | 23:24 |
| tsimonq2 | Unit193: You mean the one you can find in the Debian archive once it's processed? ;) | 23:25 |
| valorie | pastebinit is so useful when someone's in trouble | 23:51 |
| valorie | bad install or so | 23:51 |
| 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 | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!