[01:05] <TJ-> cjwatson: question about "dch -r" - I just noticed it doesn't do what the man-page says, which is to use the previous changelog distribution entry, instead it inserted the host OS's distribution. Specifically, I was working on  host bionic with a package that had "unstable" as the last changelog entry
[01:05] <TJ-> cjwatson: is the man-page out of sync or do I misunderstand ?
[01:40] <kyrofa> It seems pygraphviz is busted in bionic for armhf, see bug #1834379. Anyone know why just rebuilding the deb seems to work, and how we might fix it?
[01:43] <sarnold> kyrofa: if it were mine to debug I'd probably start with a no-change rebuild of the package in a ppa
[02:26] <kyrofa> Thanks sarnold, we'll give that a shot. If that ends up working, is there a way to just request a rebuild of that package?
[04:14] <cpaelzer> ddstreet: thanks for having some awake eyes, great hint!
[06:13] <alkisg> Hi, I read in https://discourse.ubuntu.com/t/call-for-testing-chromium-browser-deb-to-snap-transition/11179/55 that there's a plan that some .debs will only be available as snaps from 19.10 and on
[06:13] <alkisg> Would it make a difference if a few thousands users opposed that? If yes, where would be a good place to start a petition against it?
[06:19] <valorie> alkisg: a petition?
[06:20] <alkisg> valorie: not a native English speaker, I'm not sure if it's the correct word, I mean a place where concerned users would voice their arguments and vote against it
[06:20] <valorie> what helps is getting involved in development and be one of the peoples steering the decisions
[06:20] <alkisg> I spend 10 hours per day in development, sure
[06:20] <valorie> the people who do the work make the decisions about what they want to do
[06:21] <alkisg> Well, if everyone would do whatever they wanted in their packages, there wouldn't be a debian/ubuntu community
[06:21] <valorie> I personally don't like snaps and don't like to think of debs going away
[06:21] <alkisg> All developers want to hear valid concerns
[06:21] <valorie> or just regular packages
[06:21] <valorie> of course
[06:21] <valorie> people work in teams
[06:21] <alkisg> Right, and I'm doing my part in the packages I maintain
[06:21] <valorie> I can't see Debian moving to snaps, personally
[06:22] <valorie> well, cool
[06:22] <alkisg> Sure; I'd like to try to convince canonical otherwise, before switching the Greek schools to Debian
[06:22] <alkisg> That's exactly why I'm asking here
[06:22] <alkisg> To see if there's a chance for it
[06:22] <valorie> aha, well then I'll hush
[06:23] <Unit193> 'Petition' would mainly indicate a list of people that agree such a move would be bad, discussion with arguments and counter-arguments is different.  It does sound like you did mean petition, to some extent.
[06:23] <alkisg> Maybe it's just me; and all my concerns are invalid; but maybe there are thousands of users that feel like me, and it would be best not to FORCE snaps on people that want to keep using debs
[06:23] <Unit193> alkisg: FWIW, valorie also indicated a distate of snaps, as do I and some other devs.
[06:24] <Unit193> Distaste, rather.
[06:25] <alkisg> For example, technical arguments would be "they waste RAM; they have a lot of mounts for apps I don't use"; but all those could be easily ignored by persons wanting to push snaps; while, e.g. 10.000 "votes" would be harder to ignore, they would indicate a user  base that would leave Ubuntu if that indeed happens
[06:25] <alkisg> So I'm not sure which of those methods would work better in this case
[06:26] <tjaalton> alkisg: if you have technical issues, the fourth reply to the post explains how to file them
[06:27] <tjaalton> and as for voting, well this isn't a democracy ;)
[06:27] <alkisg> tjaalton: the snapcraft forum? ...ok, I can invite users that do not want snaps to sign up and participate there, but it doesn't sound like the appropriate place...
[06:27] <alkisg> Of course it's not; still, I'm pretty sure Ubuntu does want to hear the voice of its users
[06:28] <alkisg> The day that someone claims otherwise, is the day I'll abandon this boat :)
[06:29] <seb128> alkisg, I missed the start but https://community.ubuntu.com/t/please-do-not-use-snap-into-ubuntu-its-too-early/11206 has already quite some discussion from people who don't like snaps
[06:29] <alkisg> Thank you seb128, reading...
[06:30] <tjaalton> i don't think two separate builds of a security sensitive browser would be maintained forever
[06:30] <alkisg> It *is* possible, even if you think 1%, that snaps may be abandoned in the future. It would be bad if users left because of a failed attempt, but never came back just because of it
[06:31] <tjaalton> possible yes, but not free
[06:31] <tjaalton> of cost
[06:31] <seb128> whatever you do you will have hates and people who resist to change and world moving and are going to rage quite over something
[06:32] <seb128> I don't think we are going to stop doing work because some users are resistant to change
[06:32] <alkisg> Sure. I enjoyed the "wayland by default" bug on debian; very civilized discussion even on a heated topic. I'd love to see a similar civilized discussion on snaps.
[06:32] <seb128> we do listen to feedback and work on fixing issues like the mount noise you mentioned
[06:32] <seb128> that discourse topic is civilized
[08:32] <seb128> Laney, sil2100, hey there, re. the SRU/autopkgtest regresssion&comment on bugs, could the system detect infra issues and avoid commenting on the bug in those cases?
[08:33] <seb128> like the g-s-d regressions are the arm64 chroot failing to install the kernel
[08:33] <Laney> probably not
[08:33] <Laney> I mean if we could analyse and determine what those were we could auto-retry them
[08:33] <seb128> http://autopkgtest.ubuntu.com/packages/i/indicator-session/disco/arm64
[08:33] <Laney> at least it's a hint so that someone can go and retry or nag to get it fixed
[08:33] <seb128> if version is "unknown" that's usually sign of an infra issue no?
[08:35] <Laney> sometimes, but it can also be that the pkg is broken and couldn't unpack or something like that
[08:35] <seb128> k
[08:35] <seb128> so I guess next question is for Lukasz then
[08:35] <seb128> what's the way to clear the situation for SRU team?
[08:36] <seb128> commenting back on the bug saying "please don't block on those, they are not a problem in the package"?
[08:36]  * Laney thinks that's what they want from those mails
[08:36] <Laney> the first comment is like what the SRU team would have done manually
[08:41] <seb128> ideally they would have checked it's a really issue before nagging, but alright
[08:41] <seb128> I commented on the bug
[08:41] <seb128> thx
[08:42] <seb128> it's getting very tedious to get a SRU going
[08:44] <seb128> (that adds up to the regular "e.u.c has a bug report, we stopped the line" false positives)
[09:02] <sil2100> seb128: it's just an automated message, nothing really changed in the SRU process here - I mean, even if such a 'notice' comment is sent to a bug, if I do my SRU shift and see one failure that's basically something obvious, I won't block on it and act by myself as I always did
[09:03] <seb128> sil2100, I'm concerned that it makes the process even more tedious for the uploaders who don't understand what they could/should do in such cases
[09:03] <seb128> like if it's a problem in the package fair
[09:03] <seb128> but now I'm being nagged about some arm64 machine failing to install a kernel package
[09:04] <sil2100> seb128: it was always the uploaders responsibility to acknowledge and check any autopkgtest failures triggered by one's upload
[09:04] <sil2100> So nothing changed here, only a notification comment is now happening
[09:05] <seb128> nobody ever nagged me on a SRU because of those autopkgtest infra issue before, I think reviewer usually did the reasonable thing to do about those and just ignored them
[09:06] <sil2100> seb128: infra issues like that usually require some action, usually a re-run - and if it's reproducible, only then ignore, so it's still sometihng that needs *some* action from one person or the other
[09:07] <seb128> I tried a retry didn't work
[09:07] <sil2100> If I get to the bug first before the uploader, see this, re-run it (or check that it's really nothing to worry about), I will release without the need of action from the uploader
[09:07] <seb128> I can't be bothered chassing arm64 insallability issues for a disco SRU though
[09:07] <sil2100> But if you do it before me, that's even better
[09:08] <seb128> k
[09:08] <seb128> well I understand the intend and I made my comment
[09:08] <seb128> thx for listening :)
[09:09] <seb128> it does feel tedious nowadays to drive a SRU as an uploader, you keep being nagged by buggy systems/bots and have to defend against false positive to unblock your work
[09:09] <seb128> which I know some people just give up on and let the SRU stalle
[09:09] <sil2100> No worries, I can understand your point, but I think the number of cases where this might cause confusion is smaller than the number of cases where we had to manually write comments 'hey, autopkgtests are failing, please take a look' because of people completely not looking at that
[09:09] <seb128> right, for sure it's good to comment on the bug when a regression in the test happens
[09:10] <seb128> it's the false positive that are annoying
[09:10] <seb128> to be fair I'm mostly annoyed about the e.u.c ones
[09:10] <seb128> those keep triggering and blocking SRUs
[09:10] <seb128> those autopkgtest is just yet another case pilling up
[09:12] <sil2100> Indeed, for the SRU case this is just an annoying notification - so please treat it more like a 'helper tool' to not make you have to look at excuses, waiting for tests to finish
[09:12] <sil2100> ;p
[10:43] <sahid> sil2100: o/ anychance you look at #1831754, if you can accept nova we could start the testing
[10:44] <sahid> https://bugs.launchpad.net/cloud-archive/+bug/1831754/
[10:46] <sil2100> sahid: hey! So the problem with that one is that there's already a nova upload in disco-proposed that's pending verification
[10:46] <sil2100> sahid: one of the 4 bugs is still not verified, accepting the new nova would mean clobbering the current SRU info and verification
[10:47] <sil2100> sahid: I think I poked coreycb about that already, I think they have some problems in getting the verification done...
[10:48] <sahid> oh... that is unfortunate, do you have the link in hand?
[10:49] <sil2100> sahid: looks like it's this one: https://bugs.launchpad.net/nova/+bug/1808951
[10:51] <sahid> sil2100: thanks a lot I will try to se wheher I can make the tests moving forward
[10:52] <sil2100> sahid: thanks! Once we have this verified and released, I'll quickly pick up the pending SRU in unapproved
[12:51] <sahid> sil2100: https://bugs.launchpad.net/nova/+bug/1808951 is that OK for you?
[14:00] <TJ-> when building a package imported from Debian without ubuntu changes, should I ignore the Lintian error "changes: bad-distribution-in-changes-file unstable"
[14:23] <Skuggen> TJ-: The changelog entry generally specifies the distribution you're building it for (disco, eoan, etc), and it sounds like right now it says "unstable", which is debian-specific
[14:26] <cjwatson> In general the changelog header is an instruction to the source upload machinery.
[14:26] <cjwatson> If you're building a source package you've got from somewhere else then it's immaterial.
[14:27] <cjwatson> It's normal for packages synced without modifications from Debian to say "unstable" there.
[14:27] <cjwatson> So yes, you should ignore that Lintian tag./
[14:33] <sil2100> sahid: hmmm, so the test-case mentioned deploying with TLS endpoints - has that been done during testing? Since the output of catalog list seems to include http:// only
[14:58] <rbalint> seb128 i'm thankful for sil2100's comment on my sru bug about autopkgtest failures which i would have noticed much later
[15:44] <sahid> sil2100: good catch, you are right i need to fix that
[15:44] <sil2100> sahid: thanks! ;)
[15:50] <TJ-> cjwatson: thanks; that is what I thought but I always like to clear all warnings let alone errors - sbuild was happy anyhow
[16:47] <seb128> rbalint, +1 for comments about actual issues, I was -1ing on nagging bug reporter and package uploaders when it's the infra that is at fault
[23:44] <kyrofa> sarnold, regarding https://bugs.launchpad.net/ubuntu/+source/python-pygraphviz/+bug/1834379 , it seems that a no-change rebuild in a PPA does indeed work, what would be the next step?
[23:46] <sarnold> kyrofa: very good question :) I *think* an SRU with debdiff, where the changelog includes "No change rebuild (LP: 1834379)" would be a reasonable next step
[23:46] <sarnold> there's likely more, there's always more..
[23:48] <kyrofa> sarnold, ah darn, guess I'll need to relearn that! Thanks for the pointers :)