[04:57] <tjaalton> vorlon: making libsdl2 tests cross-build happy broke it on non-cross-build ;)
[04:59] <tjaalton> vorlon: cmake doesn't seem to be happy about passing empty strings to it, like 'cmake .. ""' in this case
[05:06] <tjaalton> vorlon: I'll drop the quotes, seems to work here
[06:15] <vorlon> tjaalton: ah, cheers, I hadn't had a chance yet to look at it
[08:19] <tarzeau> is there anything i can do about https://bugs.launchpad.net/ubuntu/+source/cloudcompare/+bug/1855846 ?
[08:22] <seb128> tarzeau, you could provide a debdiff for disco and mae the bug SRU compliant (https://wiki.ubuntu.com/StableReleaseUpdates)
[08:23] <tarzeau> i guess that's not worth it for 19.04 getting no more support (soon or already)
[08:23] <tarzeau> but thanks, i learnt something new (reading up anyways)
[08:24] <seb128> right, I wouldn't bother about disco at this point
[08:37] <seb128> is there some known issue with the armhf/arm64 autopkgtests instances?
[08:38] <seb128> e.g https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/arm64/p/pango1.0/20200112_120621_7c044@/log.gz
[08:38] <seb128>   File "/usr/lib/python3/dist-packages/novaclient/v2/shell.py", line 655, in _poll_for_status
[08:38] <seb128>     raise exceptions.ResourceInErrorState(obj)
[08:38] <seb128> novaclient.exceptions.ResourceInErrorState: <Server: adt-focal-arm64-pango1.0-20200112-110205>
[08:38] <seb128> juliank, Laney, vorlon, ^?
[08:39] <seb128> half the world seems to be failing on those archs
[08:41] <juliank> I haven't heard anything
[08:44] <juliank> but arm64 runs on cloud, whereas armhf runs on lxd
[08:46] <seb128> something is weird, https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages has a stack of arm failing tests where it was clear on friday
[08:48] <juliank> seb128: i see a few packages failing on arm64 like that, but most still seem to succeed
[08:49] <juliank> seb128: No valid host was found. There are not enough hosts available.
[08:49] <juliank> seb128: Seems we are running out of cloud resources
[08:49] <seb128> so what's the solution? wait/retry?
[08:50] <juliank> seb128: Decreasing the number of workers to its normal value again, it was doubled for the focal opening
[08:51] <seb128> juliank, is that something you can do or should I open a RT/nag someone else?
[08:51] <juliank> I'm on it
[08:53] <seb128> great, thx
[08:53] <seb128> (brb, changing location)
[08:58] <juliank> on armhf, everything looks fine right now
[08:58] <juliank> I rudely stopped half of the arm64 workers so we'll lose some time because the tests need to restart, but should be fine
[09:03]  * Laney pats juliank 
[09:04] <LocutusOfBorg> doko, hello, sorry for assigning you the bug, but looks like binutils is not yet fully fixed?
[09:04] <LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1859404
[09:04] <LocutusOfBorg> even golang-1.13 is FTBFS on arm64
[09:06] <juliank> seb128: the poppler author is looking for reviews on the cairo/glib in https://lists.freedesktop.org/archives/poppler/2019-December/014101.html and nobody responded, so the glib/cairo sides of poppler are basically dead atm. Maybe that's something that someone in desktop can help with?
[09:06] <doko> LocutusOfBorg: is llvm using clang itself for the bootstrap?
[09:07] <doko>     /<<PKGBUILDDIR>>/build-llvm/./bin/clang  -fuse-ld=gold -fPIC -Wno-unused-command-line-argument -Wno-unknown-warning-option   -fuse-ld=gold -fPIC -Wno-unused-command-line-argument -Wno-unknown-warning-option -Wl,--build-id  CMakeFiles/cmTC_552db.dir/testCCompiler.c.o  -o cmTC_552db
[09:07] <doko>     clang-9: error: unable to execute command: Illegal instruction (core dumped)
[09:07] <doko>     clang-9: error: linker command failed due to signal (use -v to see invocation)
[09:09] <juliank> heh there are three different merge requests dealing with correctly setting anti-aliasing in a cairo context
[09:18] <seb128> juliank, I will have a look if there is anything we can do to help there, thx for pointing it out
[09:27] <LocutusOfBorg> yes doko
[09:31] <doko> LocutusOfBorg: well, then I'll remove llvm-9 from -proposed, and upload again
[09:42] <LocutusOfBorg> doko, what llvm in proposed?
[09:43] <LocutusOfBorg> doko, clang used by llvm is the one just built before, not the one in proposed
[09:43] <LocutusOfBorg> its a self contained bootstrap
[09:43] <LocutusOfBorg> btw looks like all of your rebuilds for libffi have SIGILL in arm64
[09:44] <LocutusOfBorg> at least all the haskell related
[09:48] <doko> LocutusOfBorg: but you just said, that llvm-9 uses llvm-9 for the build, didn't you?
[09:48] <doko> LocutusOfBorg: are you fixing the llvm-8 python/python3 mess?
[09:49] <LocutusOfBorg> doko, llvm-9 uses llvm-9 stage one built on the same build process
[09:49] <LocutusOfBorg> built with gcc I would say
[09:50] <LocutusOfBorg> not the one in release
[09:50] <LocutusOfBorg> it depends on libllvm9 because of doxygen dependency, not because it needs it
[09:50] <LocutusOfBorg> (at least I think)(
[09:50] <LocutusOfBorg> for llvm-8, ack I can do it
[09:51] <doko> ta
[09:51] <LocutusOfBorg> but only after binutils is fixed I would say...
[10:01] <doko> LocutusOfBorg: ugh, you "fixed" llvm by uploading a binary build?
[10:04] <LocutusOfBorg> yes
[10:05] <LocutusOfBorg> from bileto
[11:04] <doko> tumbleweed: s/python/python2/ in b-d's for pypy/pypy3 please
[11:10] <doko> smb: you seem to be uploader for the xen packages ... xen-hypervisor-4.6-armhf, xen-hypervisor-4.7-armhf, xen-hypervisor-4.8-armhf, xen-system-armhf, xen-utils-4.9  these need rebuilds for s/python/python2/, but ftbfs. can these be removed?
[11:15] <smb> doko, focal? xen would need to moved to a newer Debian version and to universe but I cannot say when I will find time for that
[11:16] <doko> `smb: yes
[11:21] <doko> smb: https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1859432
[11:39] <smb> doko, there is a xen upload in disco/proposed which allows to compile with gcc-9. This should get copied forward to eoan and focal. Problem is that when compiled with gcc-9 it produces a completely broken hypervisor. But it could give you a way to clean out the python2 parts more quickly than waiting on the new xen version
[11:58] <gpiccoli> o/ rbasak, sil2100  - hope you had great EOY! Can you please take a look in LP #1847924 ?
[11:59] <gpiccoli> I've managed to implement the suggested changes, but I'd aprpeciate some review in order to validate it can be uploaded to -proposed
[13:10] <tumbleweed> doko: sure. I was waiting for tooling to catch up on that
[14:55] <seb128> juliank, bug #1859477 ... those python2 build-depends look like leftover since you removed the python2 support in 19.10?
[14:56] <juliank> seb128: sounds like it
[14:56] <juliank> seb128: I'll go remove them
[14:56] <seb128> juliank, thanks!
[15:11] <juliank> seb128: hmm, it does not build now because dh_auto_clean calls pyversions and that does not exist (doko ?)
[15:11] <juliank> Maybe it needs porting away from debhelper compat 78
[15:11] <juliank> *7
[15:13] <juliank> I think most stuff can be removed from d/rules
[15:16] <juliank> fixing ...
[15:16] <juliank> switching it to pybuild and compat 12
[15:24] <seb128> juliank, thx :)
[15:26] <juliank> I even ran autopkgtests this time before uploading :)
[15:27] <doko> juliank: yes, I usually only bump to v9
[15:28] <juliank> 12 seems to work fine here, so I cleaned it up a bit and bumped it that far
[16:05] <Laney> rafaeldtinoco: congrats on core-dev :-)
[16:06] <rafaeldtinoco> thanks Laney!
[18:25]  * RikMills watches the ubuntu-devel mailing list
[18:25] <Eickmeyer[m]> Weird stuff on the ubuntu-devel mailing list.
[18:27] <mdeslaur> someone need to get a life.
[18:27] <mdeslaur> needs*
[18:55] <bryce> mdeslaur, which they can get for the low price of 0.18367473287 bitcoins?
[18:55] <mdeslaur> bryce: yes! :)
[18:57] <coreycb> doko: thanks for the networkx upload. I was hitting some examples failures on Friday but maybe they went away.
[19:08] <doko> coreycb: that was just to get rid off the component mismatches
[19:08] <coreycb> doko: yes, was just hitting other issues when trying to fix the mismatches
[19:12] <doko> coreycb: how is openstck going with 3.8? already asked james page
[19:13] <coreycb> doko: we only have a gauge on unit tests so far and it's not bad. just a few test failures here and there. I plan to give a deployment a test soon.
[19:20] <doko> jamespage: can we remove python-otherstuf?
[19:26] <doko> jamespage: also python-stuf
[19:29] <sarnold> is there any way to find out how much memory was available on a given build system? a friend is curious how we got firefox to build in a 32 bit environment, on bos02-arm64-047 -- https://launchpad.net/builders/bos02-arm64-047
[19:40] <xnox> sarnold:  rebuid procenv and look at the build log
[19:41] <xnox> MemTotal:        8170344 kB
[19:41] <xnox> https://launchpadlibrarian.net/436053202/buildlog_ubuntu-eoan-arm64.procenv_0.50-1ubuntu2_BUILDING.txt.gz
[19:41] <xnox> sarnold:  but note that we use arm64 kernel + armhf userspace.
[19:42] <xnox> i believe we are using native toolchain
[19:42] <sarnold> xnox: ah, not an armhf qemu?
[19:42] <xnox> not sure how much shared vs built-in libraries we use
[19:42] <xnox> sarnold:  i believe we do not do armhf qemu. As we still don't have images working with that, i think.
[19:43] <xnox> Kernel version: Linux bos02-arm64-028 4.4.0-157-generic #185-Ubuntu SMP Tue Jul 23 09:17:28 UTC 2019 aarch64
[19:43] <xnox> https://launchpadlibrarian.net/436053201/buildlog_ubuntu-eoan-armhf.procenv_0.50-1ubuntu2_BUILDING.txt.gzat the top of
[19:43] <xnox> so yeah aarch64 kernel with chroots to build armhf code
[19:44] <sarnold> xnox: cool cool. I had wondered how the heck we managed to fit firefox in armhf myself, but never looked into it until a friend asked :)
[19:45] <doko> jamespage: is python-mock-services still needed?
[20:49] <eoli3n_> Hi
[20:50] <eoli3n_> defaultly allow users to set crontab seems to me a securty breach
[20:52] <eoli3n_> a user shouldn't be allowed to run anything outside his main shell without superuser agreement
[20:52] <eoli3n_> same for systemd timers
[20:54] <eoli3n_> when setting a crontab with a user, using crontab -e write a file under /var/spool/cron/crontabs/*, which is owned by root
[21:03] <infinity> How do you figure this is a security breach?
[21:04] <infinity> Other than your arbitrary statement about what users should be allowed to do (which has never been true in the history of UNIX or Linux), I see no problem with cron and/or timers..
[21:04] <eoli3n_> because a user is by definition a untrusted account. An untrusted account shouldnt be able to run something in background
[21:05] <eoli3n_> so why isn't all users in docker account when installing docker for exemple ?
[21:05] <infinity> Again, according to what/who?  I could say "a user shouldn't be allowed to play Solitaire", but that won't generate CVEs because I can play card games.
[21:06] <infinity> Unprivileged users running things in the background is pretty much how most things get done.
[21:06] <eoli3n_> running code in background should be root aggreed
[21:06] <eoli3n_> most things ? like ?
[21:06] <infinity> Like nearly all daemons?
[21:06] <eoli3n_> huhu, daemons owned by users ?
[21:07] <eoli3n_> just a test, please pgrep 'your user' while not connecting with it
[21:07] <eoli3n_> and paste it here
[21:07] <infinity> www-data isn't root.
[21:07] <eoli3n_> www-data is a account managed by a package
[21:07] <infinity> If you think human users are inherently different from system users, that's your call to not trust humans you know and restrict them, but that's not the system design.
[21:08] <infinity> The short answer to your concern is "it's not a concern, that's how UNIX works".
[21:08] <infinity> The long answer is "if you don't trust your users, lock them down more".
[21:08] <eoli3n_> hm
[21:08] <infinity> Despite your claims, there's no universal belief (and quite the opposite) that users shouldn't be able to run background processes.
[21:10] <eoli3n_> why users need to be in audio group to use pulseaudio ? "docker" group for docker
[21:10] <ogra> they dont
[21:10] <eoli3n_> ogra: please explain
[21:10] <ogra> the audio group has been obsolete since years ... device access for audio particulary is managed via ACLs
[21:11] <eoli3n_> sorry "pulse" group
[21:11] <eoli3n_> https://doc.ubuntu-fr.org/pulseaudio
[21:12] <infinity> There are many groups still needed for raw device access, like dialout for serial TTYs and kvm for /dev/kvm, but I don't see how that relates to background processes.
[21:12] <ogra> aslk the person that made this up ? on my ubuntu machines there is no pulse group
[21:12] <eoli3n_> why not defaulty allow all users to acces thoses files
[21:13] <eoli3n_> /dev/kvm 777 is like default crontab for users
[21:13] <ogra> not really
[21:13] <ogra> the user crontab runs as the user
[21:14] <infinity> For serial, it's a lack of locking, so you need to trust everyone with access to play nice.
[21:14] <ogra> it cant magically escalate privs
[21:14] <infinity> /dev/kvm allows you to see into every VM running under it, ish.
[21:15] <infinity> crontab has neither of those concerns.
[21:15] <infinity> Hundreds of people can have crontabs, and other than memory/cpu pressure (which you can limit in other ways), they can't interfere with each other or see each others' data, and they all run as the user who created them.
[21:16] <eoli3n_> that's exemples. user run crontab -e and it writes on a dir owned by root. afaik, that's not how unix works. privileges separation
[21:16] <eoli3n_> infinity: they could run a cryptominer
[21:16] <eoli3n_> i run 800 hosts in a university
[21:16] <infinity> Yes, they could.  They could do that interactively too.
[21:17] <infinity> If you're suggesting no one should be able to start a task, background it, and log off, you've destroyed the use-case for 99% of scientific users on university networks.
[21:17] <eoli3n_> interactivly, that's not a problem, a user could do what he does, running things is the purpose of a shell. But when the shell is gone...
[21:17] <eoli3n_> infinity: i work in a university and everybody makes everythings possible to not allow that
[21:18] <infinity> And if you think interactive and background are somehow magically different, then I'll just run my crypto-miner interactively and never log off (with, say, screen, or something else to keep a controlling TTY)
[21:18] <eoli3n_> nop screen is not installed by default
[21:18] <eoli3n_> crontab is
[21:18] <infinity> What you're looking for is CPU and memory quotas, not arbitrary limits on how a user can use UNIX.
[21:19] <eoli3n_> we don't agree, not a problem. But i keep thinking that everythings outside main shell of a users shouldn't exist
[21:19] <eoli3n_> defaultly i mean
[21:20] <infinity> screen doesn't need to be installed by default to be usable to detach sessions...
[21:20] <infinity> I mean, cryptominers aren't installed by default either, but you're concerned about their use.
[21:20] <eoli3n_> downloading binary in user space ?
[21:20] <infinity> A binary doesn't need to be "installed" or owned by root for me to run it.
[21:20] <eoli3n_> you're right
[21:23] <eoli3n_> does exist some keylogger working in userspace nop ?
[21:23] <infinity> keyloggers need root.
[21:23] <eoli3n_> ok
[21:23] <infinity> Of course, almost every UNIX/Linux desktop has a root kelogger running.  We call it X11.
[21:24] <eoli3n_> i'm thinking that as you said, a user could just open tty2 and run what he wants then back to tty7
[21:24] <eoli3n_> infinity: huhu
[21:24] <eoli3n_> nop i'm running wayland :)
[21:24] <eoli3n_> but it's the same
[21:25] <infinity> It's not the same, actually.  Wayland has strict privsep.
[21:25] <eoli3n_> didn't know, cool
[21:25] <infinity> X11 is leaky between applications, pretty much by design.
[21:25] <eoli3n_> too old
[22:45] <seb128> vorlon, hey, do you have any idea what's the issue with cheese/i386, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/c/cheese/20200113_162419_c6674@/log.gz ?