alkisgHi 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:09
alkisgIt's been tested in hundreds of schools in September, so I don't expect any regressions05:11
RAOFalkisg: You're after a Feature Freeze Exception06:07
RAOF!ffe | alkisg06:07
ubottualkisg: Feature Freeze Exception. See https://wiki.ubuntu.com/FreezeExceptionProcess for the freeze exception process.06:07
alkisgRAOF: 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 it06:08
alkisgAnyways let me try it and see... thank you06:09
tjaaltonisn't ffe mostly for seeded packages?06:10
RAOFNot unless we've changed that recently?06:11
RAOFSeeded 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:11
RAOFalkisg: 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
RAOFalkisg: “Migrated from python2 → python3 and gtk2 → gtk3” should be a pretty compelling reason :)06:14
ubottuLaunchpad bug 1795797 in Ubuntu "FFe: sync epoptes 1.0.1-1 (universe) from Debian unstable (main)" [Undecided,New]06:36
=== lifeless_ is now known as lifeless
=== thegodfather is now known as fabbione
willcookeLocutusOfBorg, hi!  Do you know if Debian has any plans to upgrade modem manager in sid to 1.8?07:56
Laneywillcooke: cyphermox is the mainatiner of that08:10
=== realitix_ is now known as realitix
willcookeLaney, ah, thx.  In which case, cyphermox - Do you know when/if Debian will update m-m?08:12
=== albert23` is now known as albert23
=== Mirv_ is now known as Mirv
cyphermoxI'm updating modemmanager12:30
cyphermoxI don't know about NM12:30
rbasaksil2100_: 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.12:53
ubottubug 1782031 in openscap (Ubuntu Xenial) "[SRU][xenial] Enable SCE option and systemd probe in libopenscap8" [Undecided,In progress] https://launchpad.net/bugs/178203112:53
sil2100rbasak: hey! I'm preparing lunch now but I'll look at it afterwards (and after one small meeting)13:04
ahasenackinfinity: hi, you said squid-4 is crashing for you regularly? wrt #179455313:18
alkisgHi, 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
alkisgI 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:42
ubottuLaunchpad bug 1795797 in Ubuntu "FFe: sync epoptes 1.0.1-1 (universe) from Debian unstable (main)" [Low,Triaged]13:42
rbasakalkisg: looks like it has entered proposed: https://launchpad.net/ubuntu/+source/epoptes13:47
alkisgrbasak: 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
rbasakalkisg: 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:48
rbasakalkisg: 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 two13:49
rbasak(actually it appears in there briefly regardless)13:49
alkisgThank you, so I'll just wait until it appears in the release pocket and I'll close the bug then13:49
rbasakThat'll be fine. Thank you for looking after this in Ubuntu for us!13:49
alkisgThank you for this great OS too. :)13:50
rbasakmdeslaur, 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:01
jbichajust 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:04
rbasakWhy the security pocket?14:05
mdeslaurrbasak: because it was needed for a webkit2gtk security update and we don't build with -updates enabled14:06
rbasakmdeslaur: I don't follow. Why would a no change rebuild be needed in that direction?14:06
rbasakUnless I misunderstand the depndency direction?14:07
mdeslaurto promote it to main, and be properly handled by ubuntu-support-status, we need a no-change rebuild14:07
mdeslaurthe no-change rebuild needs to happen in -security14:07
rbasakAh, so that the webkit2gtk build can find it?14:08
rbasakNo implications for a Xenial SRU then. Thanks!14:08
mdeslaurhrm, I also needed an armhf fix in bionic14:08
mdeslauror it FTBFS14:08
mdeslaurdoes the xenial sru one build on armhf?14:08
rbasakjbicha: ^ that's a question for you I think14:09
jbichaI didn't test on armhf :)14:09
jbicharbasak: I think I'll need an AA to handle this SRU anyway14:10
rbasakIt's in xenial unapproved atm14:11
jbichacurrently 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-614:12
jbichaso once brotli & woff2 are in place, I was going to do an SRU to re-enable woff2 support there14:12
rbasakOK, so you still want to land this brotli SRU?14:14
rbasakCould you test the armhf build please, eg. in a PPA? Would save going round the queue twice.14:14
jbichaI am testing the armhf build now14:14
rbasakjuliank: 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:16
ubottubug 1795614 in packagekit (Ubuntu Bionic) "packagekit frontend locking" [Undecided,Triaged] https://launchpad.net/bugs/179561414:16
rbasakmwhudson: bug 1785026, Regression Potential "Nothing." isn't acceptable. Please see the docs and update.14:24
ubottubug 1785026 in skiboot (Ubuntu Bionic) "[LTCTest][OPAL][OP920] OPAL PRD generated logs is not available in /var/log/opal-prd.log file" [Undecided,In progress] https://launchpad.net/bugs/178502614:24
rbasakmwhudson: 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:26
ubottubug 1794936 in dh-golang (Ubuntu Bionic) "new gccgo version update (4:8.2.0-1ubuntu2.1) is triggering dh-golang <1.35 bug" [Undecided,In progress] https://launchpad.net/bugs/179493614:26
rbasakmwhudson: think of it as informing anyone performing SRU verification on where to look.14:27
rbasaktjaalton: shouldn't bug 1794690 go in via the security pocket?14:29
ubottubug 1794690 in libxkbcommon (Ubuntu Bionic) "Backport 0.8.2 for a CVE update" [Undecided,In progress] https://launchpad.net/bugs/179469014:29
daniel-mcrHi 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
tjaaltonrbasak: maybe?14:30
daniel-mcrIf it is not the right place, please advise which channel etc. Thanks14:31
rbasaktjaalton: could you liase with the security team please? If it's going to security, then it's a different process than an SRU upload14:31
juliankrbasak: I added something about race conditions and broken install operations to that14:33
rbasakdaniel-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-mcrrbasak: cheers, appreciated.14:33
daniel-mcrrbasak: Sorry OFTC?14:34
daniel-mcrcjwatson: cheers14:35
cjwatsonOr indeed https://www.debian.org/support#irc14:35
rbasakjuliank: 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:35
jbicharbasak: brotli built on all arches for me, but like I said before I think we need an AA to handle this SRU14:36
rbasakjbicha: 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
rbasakjbicha: thanks for testing the armhf side14:37
jbichait needs to be promoted to main too14:37
jbichasimilarly, there is woff2 in the xenial new queue14:38
didrocksbdmurray: hey! do-release-upgrade -d on bionic doesn't want to update to cosmic, telling I'm not on the last supported version15:19
xnoxdidrocks, change from 'lts' to 'normal' in /etc/....15:20
xnoxdidrocks, we park people on ltses... everytime they get to one15:20
didrockseven if they run manually with -d?15:20
xnoxdidrocks, /etc/update-manager/release-upgrades15:20
bdmurrayYeah, because -d on LTS would be the LTS release under development15:21
xnoxdidrocks, we keep saying "--prompt=normal|lts" should be a command line falg15:21
bdmurrayxnox: we do?15:21
xnoxbdmurray, we have =)15:21
didrocksbdmurray: oh, I wasn't seeing it like that, but ok, kind of makes sense15:21
didrocksthe error message is confusing though15:21
didrocksthanks xnox, bdmurray :)15:21
xnoxbdmurray, 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.15:22
=== chrisccoulson_ is now known as chrisccoulson
infinityahasenack: So it would seem.19:15
ahasenackinfinity: can you try the packages from the ppa I posted in the bug/19:26
infinityahasenack: Can do, though I'm not sure how to trigger the crash itself.19:28
ahasenackinfinity: sure. I'm counting on it going from "frequent" to "haven't seen it since <x>"19:28
ahasenackinfinity: any particular config you might be using?19:28
infinityahasenack: a pretty stock squid-deb-proxy, modulo adding a few more whitelist sites.19:29
ahasenackI also have squid as a cache for my home network and haven't seen the crash yet19:29
ahasenackI'm not using squid-deb-proxy, though, just squid with a generous caching config19:29
infinityahasenack: 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". :P19:33
ahasenackthat might be something in /var/crash/ itself, but I'm just guessing19:33
ahasenackinfinity: 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 them19:34
infinityahasenack: Logs don't look particularly helpful.  And yes, I tihnk it's respawned when it dies.19:37
infinityahasenack: Oh, hrm, I also seem to have two squids running.  One with squid-deb-proxy.conf, one without.  That doesn't seem right.19:39
ahasenackdoesn't the deb-proxy one run in another port?19:40
ahasenack8000 maybe?19:40
ahasenackit runs with its own config file, it *shouldn't* conflict with normal squid19:40
infinityahasenack: Yes, but the non-deb-proxy shouldn't be running at all.  It certainly wasn't in the past.19:40
infinityI wonder what changed to make that happen, and if it was my fault somehow.19:40
* ahasenack tries "apt install squid-deb-proxy"19:41
infinityahasenack: 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/squid19:42
ahasenacka fresh install in bionic has the same result, two squids running19:42
infinitySo now I get two when I don't want two.19:42
infinityI guess I could mask the service.  Ick.19:43
ahasenackhm, I don't have an /etc/default/squid19:43
ahasenackis this system something you have been release-upgrading for a while?19:43
ahasenackI 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 it19:46
ahasenackand the initscript has this check: [ -x $DAEMON ] || exit 019:47
ahasenackso if you set DAEMON to something that is not -x, the initscript will silently exit19:47
ahasenacksame for squid-deb-proxy's initscript, except it sources /etc/default/squid-deb-proxy if it exists19:47
infinityahasenack: Right, exactly.19:51
infinityahasenack: Hence I created that to stop squid from running.19:51
infinityahasenack: And the sysv->systemd upgrade entirely ignores that.19:51
ahasenackright, and with systemd, that doesn't work anymore bceause the file is not read19:52
ahasenacksounds like a bug19:52
infinityahasenack: The squid changelog claims it's documented in NEWS.Debian... Which doesn't appear to exist. ;)19:54
ahasenackI see it in the source, maybe it's not being installed19:54
ahasenackhow is that file handled again?19:58
infinityahasenack: dh_installchangelogs, however NEWS.Debian should be debian/NEWS (or debian/<package>.NEWS) in the source, which is the bug here.20:00
infinityahasenack: So the maintainer has been screaming his news into the void for a while. :P20:00
ahasenackI've seen some packages using <package>.docs:NEWS*20:00
ahasenackok, I see the dh_installchangelogs manpage20:01
ahasenackok, I can fix that20:02
ahasenackand submit to debian20:02
infinityahasenack: 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
infinityahasenack: But functional news would have helped, since I actually read it :)20:02
infinity(yay, apt-listchangelogs)20:02
ahasenackindeed, on both accounts20:03
ahasenackI've seen that /etc/default/ bug in bind9 in the past20:03
ahasenack(and fixed it)20:03
infinityahasenack: 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
ahasenackinfinity: I'll ask the original reporter if he is also running squid-deb-proxy, but I also doubt it20:04
infinitySince the crash started happening at the same time as the ignoring of /etc/default, that's a couple too many variables.20:04
infinityahasenack: Original reporter was jibel, he may well be running squid-deb-proxy.20:05
ahasenackjust asked20:05
ahasenackdo you know him?20:06
infinitySeems a more likely use of squid for a QA engineer than having a full proxy.20:06
ahasenackjibel: oh, is that you?20:06
infinityahasenack: Do I know him? :P20:06
infinityahasenack: (hint: you were just at a sprint with him)20:06
* ahasenack refrains from further silly questions20:06
ahasenackinfinity: one more question: which squid was crashing: the deb-proxy one, the main one, or both randomly? Can you tell?20:44
infinityahasenack: Can't tell now, crash reports are gone. :/20:49
infinity(and not sure I could have known with the crash report, but maybe...)20:49
ahasenacknothing about the crash in squid's own logs either?20:50
ahasenackjibel's might have been the "main" squid, at least the command line shown in the bug doesn't include the extra config from deb-proxy20:51
infinityNot that I could find in either set of logs.20:51
ahasenackok, thanks20:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!