=== G_ is now known as G
=== alan_g_ is now known as alan_g
=== cpaelzer__ is now known as cpaelzer
[10:16] <cjwatson> seb128,sil2100: We now have langpack export cron jobs for disco.  They're in the previous artful time slot, with the jobs starting at 10:30 UTC on Monday (they normally seem to take <90 minutes).  Is that enough for you to set up the langpack side of the schedule?
[10:20] <seb128> cjwatson, hey, I think it should be enough but it seems I lost access to the admin page (either acl changes/I dropped from a team, or I'm looking at the wrong place, it has been a while)
[10:21] <seb128> hopefully Lukasz still has access/can handle the initial export
[10:24] <seb128> ahasenack, hey, I commented on bug #1818431. i see you closed a bunch of similar bugs pointing out buggy setups, configs, etc. But I think there is a real issue with the package to address, even if their setup as buggy we should fail in the postinst if the service is failing to start, it let system is a wrecked status which is never right
[10:24] <ubottu> bug 1818431 in samba (Ubuntu) "Regression in winbind package postinstall script" [High,New] https://launchpad.net/bugs/1818431
[10:47] <sil2100> seb128, cjwatson: let me get to that once I handle the .6 RCs
[10:48] <seb128> k, I would be happy to look at it but I think I lost the acl required as said
[10:49] <seb128> or maybe I should apply to get them again, unsure to how/what team though
[10:50] <rbasak> seb128: unfortunately that's the nature of "server" type packages. Users are expected to change their configurations, and after that if they do it wrong then daemons will fail to start.
[10:50] <rbasak> We don't consider user misconfigurations to be bugs.
[10:50] <rbasak> If that should change, then what should the behaviour be instead?
[10:50] <rbasak> Or are these cases different from that generalisation somehow?
[10:50] <seb128> rbasak, well, to me failing install with a postinst error and letting the packaging system wrecked up is never a good idea
[10:51] <rbasak> I understand why you don't like it.
[10:51] <seb128> imho having a "start job || true" would be better than bailing out in the middle of an upgrade
[10:51] <rbasak> But right now that's how Debian is designed.
[10:51] <seb128> what's the value of stopping the upgrade that way?
[10:51] <rbasak> I've heard it argued that that still leads to a broken system but the user doesn't know that's the case, which is arguably worse.
[10:51] <seb128> rather than just ignoring the failure and letting the install sucess?
[10:52] <rbasak> I understand your perspective. We've discussed this kind of thing extensively. I'm just saying that there is no good answer, and that if we want to change it then it's a blueprint-level thing, rather than something we can address with a few bug reports.
[10:53] <seb128> ok, I was not aware that there was a consensus on that
[10:53] <rbasak> I'm not sure we have consensus, to be clear.
[10:54] <rbasak> I'm just saying that it's a non-trivial issue that I don't think we should be addressing piecemeal
[10:54] <seb128> also desktop and server perspective are probably different in that regard
[10:54] <rbasak> Yes, absolutely. On server packages, users are expected to change daemon configuration and therefore can be expected to be responsible for service start failures to some extent at least, and that's not the case on desktop.
[10:54] <seb128> on desktop the last thing you want is to have unattendeed-upgrades applying updates in bg for you, failing, letting your box in a corrupted state and having a system not booting as a result
[10:57] <seb128> rbasak, thx for the comment, but yeah, I don't have a clear answer here either, I just though we had consensus that failing install in postins was to be avoided in all cases, seems not which is fine, you guys probably gave it more thinking than I did for the server usecases
[10:58] <rbasak> I think we (server) have some specific cases where we consider it acceptable.
[10:58] <seb128> (it does feel the wrong hammer to me though, it should be the admin job ot make sure his machine has no failing systemd units and that they got proper monitor for errors)
[10:58] <seb128> of making*
[10:58] <rbasak> Eg. user installs daemon, user misconfigures daemon such that it will fail to start, user gets a security update -> postinst runs and fails to start daemon -> dpkg error.
[10:59] <seb128> it's not even clear from that in this case it's a configuration problem
[10:59] <rbasak> OTOH, a working, correctly configured and running daemon -> package update -> dpkg error is definitely a problem since that would be a regression.
[10:59] <seb128> and not a bug in the software or a failure to handle the environment around it leading to an error
[10:59] <seb128> yeah
[11:00] <seb128> well imho admins should have reporting of services errors
[11:00] <rbasak> Given my first acceptable case, it's a massive pain for us to be flooded with "bug reports" through apport for those cases. I've got an item to see about sending those to errors.u.c instead, since in aggregate it might still give us useful information.
[11:00] <seb128> relying on postinst failures to tell you about those feels wrong
[11:01] <rbasak> What do you mean by "these"? I've lost context, sorry.
[11:03] <seb128> if you have a configuration error and a service fails to start, you want to know that immediatly/whenever the service tries to start and fail
[11:04] <seb128> but I agree with what you said before, if the upgrade is what makes the service start erroring out, then it's a problem
[11:04] <seb128> snaps solve that :)
[11:05] <seb128> install, test, rollback if the new version fails
[11:05] <rbasak> Ah - so you'd prefer to avoid the postinst failure in favor of some kind of earlier failure in principole?
[11:05] <seb128> yes, I think breaking installs in the middle is a dangerous things to do
[11:05] <seb128> since it might lead to a system which is going to fail to reboot
[11:05] <rbasak> I wonder how difficult it would be to only restart a daemon on postinst if it was running at preinst time.
[11:05] <seb128> which is worth than a failing service
[11:05] <rbasak> Could that be implemented in debhelper/systemd?
[11:06] <rbasak> Then postinst wouldn't notify of failures.
[11:06] <rbasak> And separately, a motd notice (or via PAM after CLI login or something) for services that are configured to run but aren't running.
[11:06] <seb128> right
[11:07] <seb128> well, I guess at this point it's non trivial work so would need proper blueprint/discussion/plannification etc
[11:07] <rbasak> Yeah
[11:08] <rbasak> Right now I put this in my "the user screwed up but we could be more graceful about it" category.
[11:08] <rbasak> I'm marking this category of bugs Invalid still, but all the instances are a valid "affects me too" against a "could be more graceful" bug.
[11:09] <seb128> k
[11:09] <rbasak> Does that sound reasonable?
[11:09] <seb128> yes
[11:09] <rbasak> Thanks.
[11:09] <rbasak> It's important to us I think because we (server) get this category of bugs daily :)
[11:09] <seb128> thank you for the discussion/Explaning your position
[11:09] <rbasak> You're welcome. It's absolutely a valid issue :-/
[11:10] <seb128> there might be still a valid samba bug behind that one btw
[11:10] <rbasak> I'll include you in further discussion on this.
[11:10] <seb128> it's unclear to me if the problem is a configuration error
[11:10] <seb128> or if winbind is failing to handle a type of environment out of the bo
[11:10] <seb128> box
[11:10] <rbasak> OK
[11:10] <rbasak> I'll leave that to ahasenack I think, since he's generally most knowledgeable about samba/windbind
[11:10] <seb128> in which case the bug would be to fix winbind to not error out in that setup
[11:10] <seb128> makes sense
[11:10] <seb128> thx
[11:37] <klebers> LocutusOfBorg, hi! thanks for sponsoring the virtualbox pkg for trusty
[11:38] <klebers> LocutusOfBorg, would you be able to sponsor the pkgs for xenial as well?
[12:07] <shadeslayer> popey: hey, I heard you were looking for PineBooks?
=== yiko is now known as yikoru
=== ricab is now known as ricab|lunch
=== ]SiB[ is now known as Guest24778
=== ricab|lunch is now known as ricab
[15:19] <seb128> juliank, hey, did you say you would SRU that packagekit segfault fix?
[15:19] <juliank> right
[15:21] <seb128> k, just checking, thx :)
[15:33] <juliank> seb128: on it. Did we see any crashes on xenial? There's another function to fix there (show_warnings), but it should not be too complicated.
[15:34] <juliank> It's also in main in trusty, so we could fix it there too
[15:34] <juliank> though i'm not sure which releases use aptcc vs apt
[15:35] <juliank> ah they all do
[15:35] <seb128> juliank, I wouldn't bother going back to trusty for desktop fixes at this point, especially that this fix is in the error handling code so it's not like it was failing something would have worked otherwise
[15:35] <juliank> ack
[15:36] <seb128> juliank, looking at the error tracker it doesn't seem to bite much xenial users (did we still use aptdaemon then for gnome-software?), I would only do bionic I think
[15:37] <juliank> hmm
[15:39] <seb128> juliank, yeah, gnome-software depends on aptdaemon in xenial, it was using the backend robert_ancell wrote at the time because pacagekit was still not up to what we needed
[15:39] <juliank> ok
[15:40] <seb128> SRU team, what would be the right place to discuss maybe revisiting the requirement of landing fixes in non-LTS-current to be able to SRU to the LTS?
[15:41] <seb128> I think that rule is not always bringing much value but increasing cost of landing fixes to the LTS
[15:41] <bdmurray> seb128: I think the release mailing list would be a fine spot
[15:42] <seb128> bdmurray, thx
[15:45] <juliank> +0.5 on that
[15:52] <ogra> hmm, any screen specialists here  ? i have an arm board that defaults to 1500000 baud ... seems using screen with that value doesnt actually make it go up to 1500000 but still stuck at 115200
[15:52] <ogra> is there a limit ?
[15:56] <rbasak> ogra: IIRC baud rate is set by an ioctl (or at least can be) with a set of enumeration constants. I don't think it's a free form integer.
[15:57] <rbasak> ogra: here you are: https://stackoverflow.com/questions/4968529/how-to-set-baud-rate-to-307200-on-linux
[15:57] <rbasak> Perhaps screen doesn't support that?
[16:00] <ogra> yeah, seems like ... minicom works fine but is a pain to use ... i feel like back in the 90s
[16:23] <seb128> bdmurray, sometime I wonder what are you criterious to convert e.u.c reports into launchpad bug...
[16:24] <seb128> bdmurray, bug #1818540 has 3 reports ever, all on 18.04, 2 in 2018 and 1 in 2019, all on armhf ... for sure that's not a priority for any sort nor ranking on any top 100 list of any filter, how did you even get to it?
[16:24] <ubottu> bug 1818540 in gnome-settings-daemon (Ubuntu) "/usr/lib/gnome-settings-daemon/gsd-color:8:__libc_do_syscall:__libc_signal_restore_set:__GI_raise:__aeabi_ldiv0:gcm_session_device_reset_gamma" [Undecided,New] https://launchpad.net/bugs/1818540
[16:26] <bdmurray> seb128: all the crashes were from non x86 systems which I thought was noteworthy but I could be wrong.
[16:28] <seb128> bdmurray, yeah, all 3 are on armhf, which I don't think we care enough to put resources into fixing things like color calibration atm (I'm not even there it works at all on that platform)
[16:28] <seb128> anyway, I closed it
[16:28] <seb128> just feels like a weird one to pick from the error tracker
[16:29] <bdmurray> seb128: okay, noted
[16:29] <seb128> anywa, sorry for the verbose mode, it mostly made curious about your filters/the lists you reviewed :)
[16:31] <bdmurray> seb128: There's a search of successful armhf/arm64 crashes I review and I appreciate the feedback.
[16:31] <seb128> k, I don't think arm* desktop is a thing atm though
[16:32] <seb128> it doesn't mean we shouldn't try to fix existing bugs, but that ranks rather low in our priority list/too low to be acted on seeing the flow of work on things we care about
[17:32] <Laney> doko: infinity: what's the status of glibc's migration? any way we could help?
[17:33] <Laney> We've got a few bits stacked up behind that which people ought to be using before the release ideally
[17:34] <doko> Laney: I'm trying to figure out what else is missing ... didn't get any feedback about the floating point issues
[20:29] <mwhudson> Laney: https://bugs.launchpad.net/ubuntu/+source/partman-base/+bug/1818285 <- i bet you were super happy to learn all those things
[20:29] <ubottu> Launchpad bug 1818285 in ubiquity (Ubuntu Disco) "[disco desktop] Installation fails with parted_server: No data in infifo. parted_server: Line 2387. CRITICAL ERROR!!! EXITING." [Critical,Confirmed]
=== tacocat` is now known as tacocat
[23:13] <tsimonq2> What is the copyright holder for Bileto? I assume Canonical Ltd, but what should I put for e.g. Year?
[23:13] <tsimonq2> I'm working on a project that involves reusing some Bileto code and I want to make sure I'm dotting my Is and crossing my Ts.
=== Spads_ is now known as Spads