[03:55] <ejat> hi .. anyone can take a look into this bug
[03:55] <ejat> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1772683
[03:55] <ubottu> Launchpad bug 1772683 in libreoffice (Ubuntu) "[snap] Cannot sign a document, gpg keys are not listed" [Medium,Triaged]
[11:18] <xnox> doko:  so, not so fast with django, need to fix 5 more packages or so =/
[11:19] <doko> that's what I thought ...
[11:56] <xnox> doko:  if i do $ tox -e py37 => during a package build, it works. But if I do $ tox -e py38 => it does not.
[11:56] <xnox> doko:  are our wheels off the wheels somehow?
[11:57] <cjwatson> Any time I've tried to use tox in a package build, I've ended up giving up and using some other test runner instead
[11:57] <cjwatson> And finding that roughly nothing else in the archive is using tox in package builds
[11:57] <cjwatson> It's great upstream, I use it nearly everywhere I can, so this seems like a bit of a shame
[11:57] <xnox> cjwatson:  all i need is to make pybuild execute ./runtests.py and i naively thought that PYBUILD_TEST_TOX=1 will make it so
[11:57] <cjwatson> Yeah, I've naively thought that multiple times
[11:58] <cjwatson> But survey has always said no
[11:58] <xnox> i've added all the things I need into - debian/pybuild.testfiles
[11:58] <xnox> but failing to force pybuild to use a "custom" test runner
[11:58]  * xnox will just override the dh_auto_test i guess
[12:04] <doko> xnox: you'll have to ask the pybuild developer, and persist after his initial "see pybuild(1)" reply
[12:04] <doko> or "it's in the man page"
[12:08] <xnox> i'm ended up doing
[12:08] <xnox> override_dh_auto_test:
[12:08] <xnox>         pybuild --system=custom --test --test-args='python{version} runtests.py'
[12:08] <xnox> doko:  but it does seem like something is broken with tox, in focal for py38 at the moment.
[12:08] <xnox> and it's pip usage
[12:23] <doko> xnox: looking at the upstream git, I can't see any 3.8 specific issues, however a 14.x release seems to be planned
[12:24] <doko> and tox didn't migrate yet due to an arm64 autopkg test failure
[12:41] <xnox> doko:   i don't see any issues in tox itself, but in its inability to find a python3.8 pip when initializing 3.8 env
[12:43] <doko> xnox: hmm, why not? that's arch-indep. or is this marked as 3.7 only?
[12:46] <xnox> doko:  for example, pyvenv-3.8 does not exist
[12:46] <xnox> doko:  i thought tox creates a venv, and needs 3.8 wheel for pip, no?
[12:47] <cjwatson> Even if you fix that, IIRC the usual problem with using tox in package builds is that it tends not to have the pile of sdists it needs available to build the rest of the virtualenv
[12:47] <cjwatson> sdists or wheels
[12:48] <cjwatson> I think there was some problem with using system-site-packages too any time I tried, but don't remember what it was
[12:48] <cjwatson> Possibly trouble locating tests or something
[12:48] <xnox> sure, i'm not planning to use tox in the package build anymore. It's just I suspect our py3.8 as supported, is incomplete in the archive w.r.t. venvs.
[12:48] <xnox> whilst 3.7 works
[12:50] <xnox> hm, outside of chroot, on the host, it works.....
[12:59] <doko> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/n/natsort/20191104_094524_acaa7@/log.gz
[13:00] <ahasenack> rbasak: hm, I'm having an interesting problem with mysql8 in focal, due to fakeroot
[13:00] <doko> cjwatson, xnox: ^^^ so that downloads everything, and ignores everything in the distro ...
[13:01] <ahasenack> rbasak: d/rules calls out to d/setup-mysql.sh, which has:
[13:01] <doko> trying to understand what is getting tested
[13:01] <ahasenack> https://pastebin.ubuntu.com/p/Cr7wGg5NcH/
[13:01] <ahasenack> due to fakeroot, id -u returns 0, so it thinks it's running as root
[13:01] <ahasenack> then it does: + chown mysql: /home/ubuntu/git/packages/php7.3/php7.3/mysql_db
[13:01] <cjwatson> doko: Right, I think the only legitimate way to use tox in a package build would have to use --system-site-packages or however it's spelled
[13:02] <cjwatson> As opposed to upstream where you probably don't want that
[13:02] <ahasenack> and starts mysql, which fails: mysqld: Can't create directory '/home/ubuntu/git/packages/php7.3/php7.3/mysql_db/data/' (OS errno 13 - Permission denied)
[13:02] <ahasenack> hm, mysql shouldn't have been able to switch users, so it's still running as my build user... hmm....
[13:02] <xnox> cjwatson:  is there CI running on launchpad pull requests? or do I need to run things locally myself?
[13:02]  * xnox hasn't done a launchpad merge request in ages
[13:02] <cjwatson> Locally
[13:03] <cjwatson> We do post-landing CI but that's not what you want for making sure your MP is good
[13:03] <cjwatson> If you have an old tree lying around, note that we're on git now
[13:04] <cjwatson> For what I imagine you're doing, "bin/test -vvct lp.snappy" shouldn't take too long
[13:07] <rbasak> ahasenack: this is the PHP 7.3 FTBFS, or something else?
[13:07] <ahasenack> rbasak: that one, yes
[13:07] <rbasak> I thought Marc had resolved it?
[13:08] <rbasak> He pasted a solution somewhere
[13:08] <ahasenack> just wondering if you have seen that before, and also wondering how it worked before, but I've heard people comment that the tests were never run before correctly
[13:08] <rbasak> Or am I mixing things up?
[13:08] <ahasenack> rbasak: he disabled the tests in the end he said
[13:08] <rbasak> Ah
[13:08] <ahasenack> I'm going into more detail now
[13:08] <rbasak> No I've never really delved into this area
[13:08] <rbasak> I usually defer to Skuggen for this kind of thing :-)
[13:21] <doko> cjwatson: ouch, this test doesn't even test the built package, but downloads the package zip file from the net ;p
[13:22] <cjwatson> I'm not surprised
[13:39] <cjwatson> xnox: If you have trouble running the tests then I don't mind running them here for something simple like that branch
[13:51] <ahasenack> rbasak: it's the apparmor profile that's denying mysql's datadir in that directory
[13:51] <ahasenack> [Mon Nov  4 13:22:00 2019] audit: type=1400 audit(1572873722.995:988): apparmor="DENIED" operation="mkdir" namespace="root//lxd-andreas-focal-php73-mysql8_<var-snap-lxd-common-lxd>" profile="/usr/sbin/mysqld" name="/home/ubuntu/git/packages/php7.3/php7.3/mysql_db/data/" pid=18671 comm="mysqld" requested_mask="c" denied_mask="c" fsuid=1001000 ouid=1001000
[13:53] <rbasak> Ah!
[13:57] <ahasenack> rbasak: don't know yet how it was working before, afaik this profile is enabled by default
=== terry__ is now known as trudd
[14:34] <rafaeldtinoco> infinity: would u mind approving bionic sru for https://bugs.launchpad.net/ubuntu/+source/sg3-utils/+bug/1833618 ?
[14:34] <ubottu> Launchpad bug 1833618 in sg3-utils (Ubuntu Bionic) "MAAS can't deploy Ubuntu if ID_SERIAL of any block device is broken (USB pendrive in this case)." [High,In progress]
[14:35] <rafaeldtinoco> i just verified disco (ok to migrate) but bionic hasn't been approved to -proposed yet.
[14:36] <rbasak> ahasenack, bryce: so I think I'm finally ready with the importer test branch originally from Nish. I've resubmitted his MP, which means that Andreas is already listed as a reviewer. I added Bryce. I don't mind who reviews but I think it'll probably be Bryce?
[14:38]  * ahasenack thinks so too
[18:15] <infinity> ahasenack: I don't recall who on your team had context the last time (years ago?) I whined about this, but is there any intend to fix the "squid halts shutdown forever" bug for the upcoming LTS?
[18:17] <ahasenack> infinity: I could be convinced to work on it, I have a card even
[18:17] <ahasenack> infinity: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898469 right?
[18:17] <ubottu> Debian bug 898469 in squid "Squid waits on shutdown even though there are no active clients" [Normal,Open]
[18:19] <infinity> ahasenack: That's the one.
[18:20] <infinity> ahasenack: I like the comment about "squid 3.4 blah blah" and we're on 4.8
[18:28] <infinity> ahasenack: I imagine it's a pain point for people who run all the squids ever in clouds and grump at slow instance reboot times, but for people like me, it's totally squid-deb-proxy making my laptop take forever to reboot that drives me nuts. ;)
[18:29] <infinity> ahasenack: I guess I could mask the service to just shoot it in the head, but then I'm ignoring a bug that affects others, which I tend to prefer not to do.
[18:36] <ahasenack> infinity: I've been using it with a lower setting for shutdown_lifetime
[18:36] <infinity> ahasenack: See above, re: ignore bug that affects others. :)
[18:36] <ahasenack> but I also every now and then get an error about it failing to fetch an object from the cache, and I wonder if some corruption is happening
[18:37] <ahasenack> yeah< i mean that his recommendation of just lowering that value is probably not correct
[18:37] <infinity> I remember looking into it and, indeed, there's an intricate maze of fds and sockets it needs to close to shutdown cleanly, but there must be some way when that's done to signal "I got it all!" and then end the process, instead of just waiting and hoping for the best.
[18:38] <infinity> I mean, even the 30s timeout could be too short for some instances, while being too long for most.
[18:38] <ahasenack> correct
[18:38] <ahasenack> I'll try reaching out again
[18:39] <ahasenack> not in that bug, though, something different
[18:39] <infinity> Telepathy?
[18:52] <sarnold> I've always wondered why it cares to shut down cleanly. clients and servers ought to be prepared to get RSTs at crazy times. I don't know why it doesn't just _exit(0) and be done with it. harumph.
[19:25] <infinity> sarnold: Upstream's argument is that it isn't about shutting down client connections, it's about shutting down internal sockets/fds cleanly to avoid corruption of data, logs, etc.
[19:25] <infinity> sarnold: Still seems like a piss-poor argument for what amounts to poor design choices, IMO.
[19:27] <sarnold> infinity: I'm not too shocked that a program designed so long ago has such poor design choices, but even then, I'm not sure how a graceful cleanup would take more than half a second on the typical dev laptop, or maybe two seconds on a busy system..
[19:28]  * infinity nods.
[19:29] <infinity> sarnold: And, to be clear, it probably *is* only taking half a second or less on my laptop.  But, because they've entirely failed to write a way to record and signal a clean shutdown, the whole thing just sits in a wait loop and then hard muders itself with hope and bunnies.
[19:29] <sarnold> and "rewrite it with sqlite3 so we don't have to think so hard about corruption" is probably a fair amount of work
[19:29] <infinity> sarnold: So, for 99% of people, it's waiting 29 seconds too long, for 1%, it's still not shutting down cleanly.
[19:29] <sarnold> hah
[19:30] <sarnold> and to think this is the caching thingy that gave me the *least* amount of trouble
[19:30] <infinity> Yep.
[19:40] <infinity> rafaeldtinoco: I don't see an upload of sg3-utils in bionic's queue, so not much for me to review...
[19:42] <rafaeldtinoco> :/ I thought it was sponsored already, will check, sorry for the noise
[19:45] <infinity> dannf: Feel free to JFDI on the versioning fix if that's all you're waiting on to sponsor sg3-utils.
[19:47] <ahasenack> sarnold: infinity: what other cacheing proxy servers are out there? Anything promising that you know of?
[19:47] <ahasenack> "apt-cache search proxy | grep cache" isn't encouraging
[19:48] <dannf> infinity, rafaeldtinoco ack
[19:49] <sarnold> ahasenack: apt-cacher-ng was the one that gave me trouble, endless chasing hash sum mismatches. funny thing is, I know folks who've switched from squid-deb-proxy to apt-cacher-ng because squid gave them the hash sum mismatches..
[19:49] <ahasenack> ok, but that's just for debs anyway
[19:49] <ahasenack> I get hash sum mismatches on mirrors directly even
[19:49] <infinity> Really?  Still?
[19:49] <infinity> I haven't seen one since we switched to by-hash indexes.
[19:49] <ahasenack> yeah, the br mirror every now and then
[19:50] <ahasenack> I do have a proxy, but when I get that, i disable it, clean run apt get update, and it fails
[19:50] <ahasenack> then I switch to archive.u.c
[19:50] <infinity> sarnold: My complaint with apt-cacher-ng is that over time, it seems to corrupt its data just enough that the weekly cronjobs end up whining until you delete it all and start over.
[19:51] <infinity> Maybe that's fixed now, but I gave up and switched to squid and didn't look back.
[19:51] <sarnold> same here, squid's been a lot better for me, just the shutdown / reboot experience is bad news :)
[19:51] <infinity> Plus, squid is dogfooding an actually useful proxy server that thousands/millions use for all sorts of things, apt-cacher-ng is weird boutique software just for nerds like us.
[19:52] <ahasenack> kanashiro: your target branch in your MPs for merges from debian is incorrect, it should be debian/sid
[19:52] <ahasenack> that's why you have conflicts on those mps
[19:54] <kanashiro> ahasenack, ah, just noticed this... fixing them now
[19:54] <kanashiro> thanks btw
[19:54] <ahasenack> np
[19:55] <rafaeldtinoco> dannf: thx for the version fix
[19:55] <rafaeldtinoco> dannf: should I do something or u have already uploaded ?
[19:55] <dannf> rafaeldtinoco: np - its here now: https://launchpad.net/ubuntu/bionic/+queue?queue_state=1
[19:55] <rafaeldtinoco> great. thx!
[21:09] <melodie> hi
[21:10] <ahasenack> kanashiro: what cpaelzer and I do sometimes when a merge becomes a sync is to just file an MP anyway, showing that all delta can be dropped, for review purposes
[21:10] <melodie> I have used a few commands in the shell to try to get which package contains the /etc/passwd file and I didn't find any. I would like to know who is in charge of this file in the *ubuntu editions?
[21:11] <melodie> I have a premice related to computing and digital skills and I found a sensitive bug in one of my client's computer. So I'd like to send a mail to the right person
[21:11] <ahasenack> melodie: it's created in base-passwd's postinst
[21:11] <melodie> ahasenack thanks, let me see
[21:11] <dax> which also means it doesn't show up in the output of the usual "which package owns this" tools, because it's generated, not installed
[21:11] <ahasenack> or rather, preinst
[21:12] <rbasak> melodie: please don't just email the maintainer of base-passwd though
[21:12] <melodie> I should find a mail in the output of apt-cache show base-passwd I think?
[21:12] <melodie> rbasak why that? Who then?
[21:12] <rbasak> melodie: if you think you found a security bug in base-files package, please file a bug and mark it as either Public Security or Private Security as appropriate.
[21:13] <melodie> aha
[21:13] <melodie> let me have a look at the lauchpad bugs section
[21:13] <kanashiro> ahasenack, re a merge becoming a sync: nice, I'll submit a MP for review purpose
[21:13] <rbasak> melodie: because we use bug trackers to track issues so we can work on them collectively - private email is usually inappropriate for matters relating to public work like this
[21:14] <melodie> good to know
[21:15] <melodie> I see, maintainer shows Colin Watson. I'll do as you say and search for a "Private Security" option
[21:15] <melodie> I guess Colin Watson might have his plate full :D
[21:15] <rbasak> melodie: and also for security matters Ubuntu has a security team who are on a rota. For all you know, Colin is on vacation (though he isn't as it happens) :)
[21:16] <melodie> never mind rbasak everyone deserves his vacation, even if still here online
[21:16] <rbasak> :)
[21:17] <melodie> :)
[21:28] <melodie> rbasak ahasenack this is bug #1851300
[21:28] <ubottu> Error: Launchpad bug 1851300 could not be found
[21:28] <melodie> and thanks for your help!
[21:29] <melodie> ok ubottu bot, https://bugs.launchpad.net/ubuntu/+source/base-passwd/+bug/1851300
[21:29] <infinity> melodie: The bot can't find it because it's private. :P
[21:29] <sarnold> one moment..
[21:29] <melodie> infinity I thought so
[21:31] <infinity> /etc/passwd shouldn't have passwords in it at all, plain or hashed.
[21:31] <sarnold> melodie: how did this user change the password on her system?
[21:32] <infinity> And there's no way in our default installations for that to happen.
[21:32] <infinity> Gonna need a lot more info to figure out who/what did that. /
[21:32] <infinity> :/
[21:34] <melodie> sarnold she didn't. She is an old lady who would never be able to do that. An the "computer tech" who installed probably just did an regular install not complicated, through the install option in the live
[21:34] <melodie> I can tell as I have had several clients coming to me after served at his shop
[21:34] <infinity> I suspect you'll need to ask this "tech" how he's setting up user accounts.
[21:35] <infinity> He might be imaging systems and then echoing users/passwords into /etc/passwd or something equally insane.
[21:35] <melodie> infinity what I might be able to do: see if I shows again in other Xubuntu 18 installs
[21:35] <melodie> I perform some, once a while, as tomorrow I have one scheduled
[21:35] <melodie> if it shows again*
[21:36] <melodie> infinity not possible, he is a very simple tech who performs simple services
[21:37] <melodie> I can't ask him. He is a "lone wolf" kind of guy :D
[21:38] <melodie> still I don't fancy this guy doing crazy technical things, he doesn't use his time this way. He just wants to earn money and provide not too expensive services (even if he does not understand well the ins and outs in at gnu/linux distribution)
[21:38] <infinity> melodie: You say that's not possible, but I'm telling you that the scenario of "no one ever changed the password after ubiquity created the user" can't possible lead to anything in /etc/passwd other than "x"
[21:38] <infinity> melodie: I'd be open to the idea that some random xfce utility for user/password changes has done something very bad.  Or that the tech doing the install did something silly.
[21:39] <infinity> But if she didn't change it, and he didn't do it weird, we're at a bit of an impasse.
[21:39] <melodie> infinity all I can do is report a bug which I have recently seen, and when possible have a close look to see if it pops up again
[21:39] <melodie> and I have read a few years ago that this issue already arised once, in Ubuntu which was then fixed.
[21:40] <melodie> so I don't want to raise concerns among the users, I want it to be checked and looked closely. nothing more.
[21:40] <infinity> melodie: Err, when was this issue?
[21:40] <melodie> I am proud of being a GNU/Linux user, which I started almost right away after I got my first computer, 15 years ago.
[21:41] <melodie> infinity I met with it a few days ago.
[21:41] <infinity> melodie: I meant your claim that you "read a few years ago..."
[21:41] <infinity> melodie: I don't recall ever having a "clear text passwords in /etc/passwd" issue.
[21:42] <melodie> infinity this one, I don't remember
[21:42] <infinity> Not that we haven't had other issues, like passwords in log files (in 2005!) and wifi passwords in clear text...
[21:42] <melodie> I do remember about it
[21:43] <melodie> anyway I have always read that a security issue in a free software should first be brought to the people in charge of the concerned software, in order to get a fix for everyone before anything else
[21:44] <melodie> now, if you will all excuse me, I have to get up early tomorrow, I'll be back for more if I find more clues or other examples of this issue.
[21:45] <melodie> thanks for your help.
[21:45] <sarnold> thanks melodie :)
[21:45] <melodie> so, good night/week/evening...
[21:45] <melodie> sarnold welcome. :)
[22:23] <Phruis> where is the code linux uses to save its state on hibernation?
[22:53] <teward> slashd: FYI the nginx upload was accepted and has been in focal for a bit now, and should Just Work now for the nginx IPv6 stuff, please double check, my tests seem to reflect it's fixed but a second set of eyes and tests never hurts :)