[05:09] <alkisg> Hi all, my package epoptes got a major update due to GSoC, and today has migrated to debian testing. Would it be possible to request a sync even so late in the release cycle? We (upstream) don't support the old epoptes release anymore...
[05:11] <alkisg> It's been tested in hundreds of schools in September, so I don't expect any regressions
[06:07] <RAOF> alkisg: You're after a Feature Freeze Exception
[06:07] <RAOF> !ffe | alkisg
[06:08] <alkisg> RAOF: thank you, that "FeatureFreeze for new upstream versions" seems like a lot of work, are all those necessary? The new version involved a python2/gtk2 to python3/gtk3 rewrite, so I'm not sure what a diff woulc reveal about it
[06:09] <alkisg> Anyways let me try it and see... thank you
[06:10] <tjaalton> isn't ffe mostly for seeded packages?
[06:11] <RAOF> Not unless we've changed that recently?
[06:11] <RAOF> Seeded packages get extra scrutiny (and have a harder freeze during image building), but AFAIK an FFe is still expected, even for something in universe.
[06:14] <RAOF> alkisg: The diff is not meant to be of the code, but of the changelog - ie: “Please describe what's new, and why we should have it”
[06:14] <RAOF> alkisg: “Migrated from python2 → python3 and gtk2 → gtk3” should be a pretty compelling reason :)
[06:36] <alkisg> https://bugs.launchpad.net/ubuntu/+bug/1795797
[07:56] <willcooke> LocutusOfBorg, hi!  Do you know if Debian has any plans to upgrade modem manager in sid to 1.8?
[08:10] <Laney> willcooke: cyphermox is the mainatiner of that
[08:12] <willcooke> Laney, ah, thx.  In which case, cyphermox - Do you know when/if Debian will update m-m?
[12:30] <cyphermox> I'm updating modemmanager
[12:30] <cyphermox> I don't know about NM
[12:53] <rbasak> sil2100_: around? May I have a second SRU opinion on bug 1782031 please? Seems to me there may be a functional (surprising) change to users there if unknown/notchecked ends up going to fail.
[13:04] <sil2100> rbasak: hey! I'm preparing lunch now but I'll look at it afterwards (and after one small meeting)
[13:18] <ahasenack> infinity: hi, you said squid-4 is crashing for you regularly? wrt #1794553
[13:42] <alkisg> Hi, regarding https://bugs.launchpad.net/ubuntu/+bug/1795797, I got an ACK from ubuntu-release and then I ran `syncpackage epoptes -d unstable`.
[13:42] <alkisg> I think I have enough permissions there to upload myself, so I don't need a sponsor, right? So I should just close the bug now?
[13:47] <rbasak> alkisg: looks like it has entered proposed: https://launchpad.net/ubuntu/+source/epoptes
[13:48] <alkisg> rbasak: what's the process after that? Do I need to test it and give an "OK" somewhere? Do I need to wait for some approval? Or it's ok and I should just close the bug?
[13:48] <rbasak> alkisg: usually bugs only get marked Fix Released when they land in the release pocket. Migration will take an hour or two unless it gets stuck for some reason. But for sync bugs, it's more fuzzy. syncpackage has a -b option that'll mark Fix Released that predates proposed migration. I doubt people running it today wait for that to finish before closing the bug through the script.
[13:49] <rbasak> alkisg: it should appear in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html if it gets held up for some reason. Otherwise it should land in the release pocket in an hour or two
[13:49] <rbasak> (actually it appears in there briefly regardless)
[13:49] <alkisg> Thank you, so I'll just wait until it appears in the release pocket and I'll close the bug then
[13:49] <rbasak> That'll be fine. Thank you for looking after this in Ubuntu for us!
[13:50] <alkisg> Thank you for this great OS too. :)
[14:01] <rbasak> mdeslaur, jbicha: looking at brotli in xenial unapproved. Does the Xenial backport need to be rebased on 1.0.3-1ubuntu1.2 that's in the security pocket? It's not obvious to me why a no change rebuild was needed for security, so I'm wondering if any consideration of that reason is needed for the Xenial backport.
[14:04] <jbicha> just a guess but I'm thinking the packages in bionic release are frozen and we need a new package version to promote it to main ??
[14:05] <rbasak> Why the security pocket?
[14:06] <mdeslaur> rbasak: because it was needed for a webkit2gtk security update and we don't build with -updates enabled
[14:06] <rbasak> mdeslaur: I don't follow. Why would a no change rebuild be needed in that direction?
[14:07] <rbasak> Unless I misunderstand the depndency direction?
[14:07] <mdeslaur> to promote it to main, and be properly handled by ubuntu-support-status, we need a no-change rebuild
[14:07] <rbasak> Oh
[14:07] <rbasak> Right
[14:07] <mdeslaur> the no-change rebuild needs to happen in -security
[14:08] <rbasak> Ah, so that the webkit2gtk build can find it?
[14:08] <mdeslaur> yeah
[14:08] <rbasak> No implications for a Xenial SRU then. Thanks!
[14:08] <mdeslaur> hrm, I also needed an armhf fix in bionic
[14:08] <mdeslaur> or it FTBFS
[14:08] <mdeslaur> does the xenial sru one build on armhf?
[14:09] <rbasak> jbicha: ^ that's a question for you I think
[14:09] <jbicha> I didn't test on armhf :)
[14:10] <jbicha> rbasak: I think I'll need an AA to handle this SRU anyway
[14:11] <rbasak> It's in xenial unapproved atm
[14:12] <jbicha> currently I believe we're not sure whether we're going to be able to do further security uploads for webkit2gtk in xenial since the new version wants gcc-6
[14:12] <jbicha> so once brotli & woff2 are in place, I was going to do an SRU to re-enable woff2 support there
[14:14] <rbasak> OK, so you still want to land this brotli SRU?
[14:14] <rbasak> Could you test the armhf build please, eg. in a PPA? Would save going round the queue twice.
[14:14] <jbicha> I am testing the armhf build now
[14:14] <rbasak> Thanks
[14:16] <rbasak> juliank: in bug 1795614, please could you describe the actual impact to users of the bug? Right now all I see is a technical description of the problem, but I can't infer from that how users are actually affected.
[14:24] <rbasak> mwhudson: bug 1785026, Regression Potential "Nothing." isn't acceptable. Please see the docs and update.
[14:26] <rbasak> mwhudson: same with bug 1794936 please. " It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what could happen in the event of a regression." -- so "unlikely" is also pointless.
[14:27] <rbasak> mwhudson: think of it as informing anyone performing SRU verification on where to look.
[14:29] <rbasak> tjaalton: shouldn't bug 1794690 go in via the security pocket?
[14:30] <daniel-mcr> Hi all, apologies if this is not the right place to ask this. I'm using Debian 9 with Gnome 3, Software and Updates, Updates tab, drop down When there are other updates is blank, is this intentional?
[14:30] <tjaalton> rbasak: maybe?
[14:31] <daniel-mcr> If it is not the right place, please advise which channel etc. Thanks
[14:31] <rbasak> tjaalton: could you liase with the security team please? If it's going to security, then it's a different process than an SRU upload
[14:31] <tjaalton> ok
[14:33] <juliank> rbasak: I added something about race conditions and broken install operations to that
[14:33] <rbasak> daniel-mcr: if you're not using Ubuntu, then Ubuntu channels are the wrong place. Try #debian on OFTC for user support for Debian users.
[14:33] <daniel-mcr> rbasak: cheers, appreciated.
[14:34] <daniel-mcr> rbasak: Sorry OFTC?
[14:34] <cjwatson> https://wiki.debian.org/IRC
[14:35] <daniel-mcr> cjwatson: cheers
[14:35] <cjwatson> Or indeed https://www.debian.org/support#irc
[14:35] <rbasak> juliank: so that explains why frontend locking is necessary, but how does this particular bug impact users? What's wrong for users as a consequence of this bug? Eg. what user story is broken?
[14:36] <jbicha> rbasak: brotli built on all arches for me, but like I said before I think we need an AA to handle this SRU
[14:36] <jbicha> https://launchpad.net/~jbicha/+archive/ubuntu/arch/+sourcepub/9464055/+listing-archive-extra
[14:37] <rbasak> jbicha: AA -> because it's a new binary? AIUI, an SRU team member needs to consider it against SRU policy and accept, and only then will it go into the new queue for an AA to review.
[14:37] <rbasak> jbicha: thanks for testing the armhf side
[14:37] <jbicha> it needs to be promoted to main too
[14:38] <jbicha> similarly, there is woff2 in the xenial new queue
[15:19] <didrocks> bdmurray: hey! do-release-upgrade -d on bionic doesn't want to update to cosmic, telling I'm not on the last supported version
[15:20] <xnox> didrocks, change from 'lts' to 'normal' in /etc/....
[15:20] <xnox> didrocks, we park people on ltses... everytime they get to one
[15:20] <bdmurray> update-manager/release-upgrades
[15:20] <didrocks> even if they run manually with -d?
[15:20] <xnox> didrocks, /etc/update-manager/release-upgrades
[15:21] <bdmurray> Yeah, because -d on LTS would be the LTS release under development
[15:21] <xnox> didrocks, we keep saying "--prompt=normal|lts" should be a command line falg
[15:21] <bdmurray> xnox: we do?
[15:21] <xnox> bdmurray, we have =)
[15:21] <didrocks> bdmurray: oh, I wasn't seeing it like that, but ok, kind of makes sense
[15:21] <didrocks> the error message is confusing though
[15:21] <didrocks> thanks xnox, bdmurray :)
[15:22] <xnox> bdmurray, to be fair '-d' could be either, as it will never be the case that there is both "a normal devel release" and "a new lts release" because we will not jump past an lts release, to a normal devel one.
[19:15] <infinity> ahasenack: So it would seem.
[19:26] <ahasenack> infinity: can you try the packages from the ppa I posted in the bug/
[19:26] <ahasenack> ?
[19:28] <infinity> ahasenack: Can do, though I'm not sure how to trigger the crash itself.
[19:28] <ahasenack> infinity: sure. I'm counting on it going from "frequent" to "haven't seen it since <x>"
[19:28] <ahasenack> infinity: any particular config you might be using?
[19:29] <infinity> ahasenack: a pretty stock squid-deb-proxy, modulo adding a few more whitelist sites.
[19:29] <ahasenack> I also have squid as a cache for my home network and haven't seen the crash yet
[19:29] <ahasenack> ok
[19:29] <ahasenack> I'm not using squid-deb-proxy, though, just squid with a generous caching config
[19:33] <infinity> ahasenack: I'll give it a whirl.  I also need to figure out how to undo my telling appot to "ignore future erors of this type". :P
[19:33] <ahasenack> that might be something in /var/crash/ itself, but I'm just guessing
[19:34] <ahasenack> infinity: is squid restarted automatically when it crashes? Also, the logs from /var/log/squid/cache.log could be useful, maybe they say what triggered the crash, if you still have them
[19:37] <infinity> ahasenack: Logs don't look particularly helpful.  And yes, I tihnk it's respawned when it dies.
[19:37] <ahasenack> ok
[19:39] <infinity> ahasenack: Oh, hrm, I also seem to have two squids running.  One with squid-deb-proxy.conf, one without.  That doesn't seem right.
[19:40] <ahasenack> doesn't the deb-proxy one run in another port?
[19:40] <ahasenack> 8000 maybe?
[19:40] <ahasenack> it runs with its own config file, it *shouldn't* conflict with normal squid
[19:40] <infinity> ahasenack: Yes, but the non-deb-proxy shouldn't be running at all.  It certainly wasn't in the past.
[19:40] <infinity> I wonder what changed to make that happen, and if it was my fault somehow.
[19:41]  * ahasenack tries "apt install squid-deb-proxy"
[19:42] <infinity> ahasenack: Oh, it switched to systemd units.  I bet there used to be a "please don't run" thing in /etc/default that's now ignored. :/
[19:42] <infinity> # cat /etc/default/squid
[19:42] <infinity> DAEMON=nonexistant
[19:42] <infinity> Yeah.
[19:42] <ahasenack> a fresh install in bionic has the same result, two squids running
[19:42] <infinity> So now I get two when I don't want two.
[19:43] <infinity> I guess I could mask the service.  Ick.
[19:43] <ahasenack> hm, I don't have an /etc/default/squid
[19:43] <ahasenack> is this system something you have been release-upgrading for a while?
[19:46] <ahasenack> I guess in bionic you could create an /etc/default/squid file, because the sysv initscript will source that if it exists, and use $DAEMON to run it
[19:47] <ahasenack> and the initscript has this check: [ -x $DAEMON ] || exit 0
[19:47] <ahasenack> so if you set DAEMON to something that is not -x, the initscript will silently exit
[19:47] <ahasenack> same for squid-deb-proxy's initscript, except it sources /etc/default/squid-deb-proxy if it exists
[19:51] <infinity> ahasenack: Right, exactly.
[19:51] <infinity> ahasenack: Hence I created that to stop squid from running.
[19:51] <infinity> ahasenack: And the sysv->systemd upgrade entirely ignores that.
[19:52] <ahasenack> right, and with systemd, that doesn't work anymore bceause the file is not read
[19:52] <ahasenack> sounds like a bug
[19:54] <infinity> ahasenack: The squid changelog claims it's documented in NEWS.Debian... Which doesn't appear to exist. ;)
[19:54] <ahasenack> I see it in the source, maybe it's not being installed
[19:58] <ahasenack> how is that file handled again?
[20:00] <infinity> ahasenack: dh_installchangelogs, however NEWS.Debian should be debian/NEWS (or debian/<package>.NEWS) in the source, which is the bug here.
[20:00] <infinity> ahasenack: So the maintainer has been screaming his news into the void for a while. :P
[20:00] <ahasenack> I've seen some packages using <package>.docs:NEWS*
[20:01] <ahasenack> ok, I see the dh_installchangelogs manpage
[20:02] <ahasenack> ok, I can fix that
[20:02] <ahasenack> and submit to debian
[20:02] <infinity> ahasenack: I'm not super happy about /etc/default being ignored in systemd upgrades, but this isn't the first package to do it, so I think I just need to get over it.
[20:02] <infinity> ahasenack: But functional news would have helped, since I actually read it :)
[20:02] <infinity> (yay, apt-listchangelogs)
[20:03] <ahasenack> indeed, on both accounts
[20:03] <ahasenack> I've seen that /etc/default/ bug in bind9 in the past
[20:03] <ahasenack> (and fixed it)
[20:04] <infinity> ahasenack: Aaaanyhow, I *doubt* the crash relates to running two instances at once, but I suppose there's an outside chance it might.  Maybe I should mask out the non-deb-proxy one for a while and see if things are better before I try your PPA.
[20:04] <ahasenack> infinity: I'll ask the original reporter if he is also running squid-deb-proxy, but I also doubt it
[20:04] <infinity> Since the crash started happening at the same time as the ignoring of /etc/default, that's a couple too many variables.
[20:05] <infinity> ahasenack: Original reporter was jibel, he may well be running squid-deb-proxy.
[20:05] <ahasenack> just asked
[20:06] <ahasenack> do you know him?
[20:06] <infinity> Seems a more likely use of squid for a QA engineer than having a full proxy.
[20:06] <ahasenack> jibel: oh, is that you?
[20:06] <infinity> ahasenack: Do I know him? :P
[20:06] <infinity> ahasenack: (hint: you were just at a sprint with him)
[20:06]  * ahasenack refrains from further silly questions
[20:10] <nacc> lol
[20:44] <ahasenack> infinity: one more question: which squid was crashing: the deb-proxy one, the main one, or both randomly? Can you tell?
[20:49] <infinity> ahasenack: Can't tell now, crash reports are gone. :/
[20:49] <ahasenack> ok
[20:49] <infinity> (and not sure I could have known with the crash report, but maybe...)
[20:50] <ahasenack> nothing about the crash in squid's own logs either?
[20:51] <ahasenack> jibel's might have been the "main" squid, at least the command line shown in the bug doesn't include the extra config from deb-proxy
[20:51] <infinity> Not that I could find in either set of logs.
[20:51] <ahasenack> ok, thanks