| 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:05 |
| 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:40 |
| ubottu | bug 1834379 in python-pygraphviz (Ubuntu) "armhf Bionic python3-pygraphviz package errors for simple use case" [Undecided,New] https://launchpad.net/bugs/1834379 | 01:40 |
| sarnold | kyrofa: if it were mine to debug I'd probably start with a no-change rebuild of the package in a ppa | 01:43 |
| 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? | 02:26 |
| cpaelzer | ddstreet: thanks for having some awake eyes, great hint! | 04:14 |
| === tmhoang1 is now known as tmhoang2 | ||
| === tmhoang2 is now known as tmhoang1 | ||
| === tmhoang1 is now known as tmhoang2 | ||
| === tmhoang2 is now known as tmhoang1 | ||
| 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:13 |
| valorie | alkisg: a petition? | 06:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| Unit193 | Distaste, rather. | 06:24 |
| 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:25 |
| tjaalton | alkisg: if you have technical issues, the fourth reply to the post explains how to file them | 06:26 |
| 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:27 |
| alkisg | The day that someone claims otherwise, is the day I'll abandon this boat :) | 06:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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 | 06:32 |
| === abeato_ is now known as abeato | ||
| 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:32 |
| 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:33 |
| 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:35 |
| 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:36 |
| 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:41 |
| seb128 | it's getting very tedious to get a SRU going | 08:42 |
| seb128 | (that adds up to the regular "e.u.c has a bug report, we stopped the line" false positives) | 08:44 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| seb128 | k | 09:08 |
| seb128 | well I understand the intend and I made my comment | 09:08 |
| seb128 | thx for listening :) | 09:08 |
| 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:09 |
| 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:10 |
| 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 | 09:12 |
| sahid | sil2100: o/ anychance you look at #1831754, if you can accept nova we could start the testing | 10:43 |
| sahid | https://bugs.launchpad.net/cloud-archive/+bug/1831754/ | 10:44 |
| ubottu | Launchpad bug 1831754 in nova (Ubuntu Disco) "[SRU] stein stable releases" [Undecided,New] | 10:44 |
| 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:46 |
| sil2100 | sahid: I think I poked coreycb about that already, I think they have some problems in getting the verification done... | 10:47 |
| sahid | oh... that is unfortunate, do you have the link in hand? | 10:48 |
| sil2100 | sahid: looks like it's this one: https://bugs.launchpad.net/nova/+bug/1808951 | 10:49 |
| ubottu | Launchpad bug 1808951 in tripleo "python3 + Fedora + SSL + wsgi nova deployment, nova api returns RecursionError: maximum recursion depth exceeded while calling a Python object" [High,Triaged] | 10:49 |
| sahid | sil2100: thanks a lot I will try to se wheher I can make the tests moving forward | 10:51 |
| sil2100 | sahid: thanks! Once we have this verified and released, I'll quickly pick up the pending SRU in unapproved | 10:52 |
| sahid | sil2100: https://bugs.launchpad.net/nova/+bug/1808951 is that OK for you? | 12:51 |
| ubottu | Launchpad bug 1808951 in tripleo "python3 + Fedora + SSL + wsgi nova deployment, nova api returns RecursionError: maximum recursion depth exceeded while calling a Python object" [High,Triaged] | 12:51 |
| === ricab is now known as ricab|lunch | ||
| === waveform_ is now known as waveform | ||
| 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:00 |
| === ricab|lunch is now known as ricab | ||
| 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:23 |
| 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:26 |
| 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:27 |
| 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:33 |
| rbalint | seb128 i'm thankful for sil2100's comment on my sru bug about autopkgtest failures which i would have noticed much later | 14:58 |
| === rikmills is now known as RikMills | ||
| sahid | sil2100: good catch, you are right i need to fix that | 15:44 |
| sil2100 | sahid: thanks! ;) | 15:44 |
| TJ- | cjwatson: thanks; that is what I thought but I always like to clear all warnings let alone errors - sbuild was happy anyhow | 15:50 |
| 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 | 16:47 |
| 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:44 |
| ubottu | Launchpad bug 1834379 in python-pygraphviz (Ubuntu) "armhf Bionic python3-pygraphviz package errors for simple use case" [Undecided,New] | 23:44 |
| 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 |
| ubottu | Launchpad bug 1834379 in python-pygraphviz (Ubuntu) "armhf Bionic python3-pygraphviz package errors for simple use case" [Undecided,New] https://launchpad.net/bugs/1834379 | 23:46 |
| sarnold | there's likely more, there's always more.. | 23:46 |
| kyrofa | sarnold, ah darn, guess I'll need to relearn that! Thanks for the pointers :) | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!