[04:57] vorlon: making libsdl2 tests cross-build happy broke it on non-cross-build ;) [04:59] vorlon: cmake doesn't seem to be happy about passing empty strings to it, like 'cmake .. ""' in this case [05:06] vorlon: I'll drop the quotes, seems to work here [06:15] tjaalton: ah, cheers, I hadn't had a chance yet to look at it [08:19] is there anything i can do about https://bugs.launchpad.net/ubuntu/+source/cloudcompare/+bug/1855846 ? [08:19] Launchpad bug 1855846 in cloudcompare (Ubuntu) "Please update cloudcompare to 2.10.1-2" [Undecided,Confirmed] [08:22] tarzeau, you could provide a debdiff for disco and mae the bug SRU compliant (https://wiki.ubuntu.com/StableReleaseUpdates) [08:23] i guess that's not worth it for 19.04 getting no more support (soon or already) [08:23] but thanks, i learnt something new (reading up anyways) [08:24] right, I wouldn't bother about disco at this point [08:37] is there some known issue with the armhf/arm64 autopkgtests instances? [08:38] 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] File "/usr/lib/python3/dist-packages/novaclient/v2/shell.py", line 655, in _poll_for_status [08:38] raise exceptions.ResourceInErrorState(obj) [08:38] novaclient.exceptions.ResourceInErrorState: [08:38] juliank, Laney, vorlon, ^? [08:39] half the world seems to be failing on those archs [08:41] I haven't heard anything [08:44] but arm64 runs on cloud, whereas armhf runs on lxd [08:46] 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] seb128: i see a few packages failing on arm64 like that, but most still seem to succeed [08:49] seb128: No valid host was found. There are not enough hosts available. [08:49] seb128: Seems we are running out of cloud resources [08:49] so what's the solution? wait/retry? [08:50] seb128: Decreasing the number of workers to its normal value again, it was doubled for the focal opening [08:51] juliank, is that something you can do or should I open a RT/nag someone else? [08:51] I'm on it [08:53] great, thx [08:53] (brb, changing location) [08:58] on armhf, everything looks fine right now [08:58] 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] doko, hello, sorry for assigning you the bug, but looks like binutils is not yet fully fixed? [09:04] https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1859404 [09:04] Launchpad bug 1859404 in binutils (Ubuntu) "binutils regressed llvm-toolchain-9 and llvm-toolchain-7 bootstrap on arm64" [Undecided,New] [09:04] even golang-1.13 is FTBFS on arm64 [09:06] 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] LocutusOfBorg: is llvm using clang itself for the bootstrap? [09:07] /<>/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] clang-9: error: unable to execute command: Illegal instruction (core dumped) [09:07] clang-9: error: linker command failed due to signal (use -v to see invocation) [09:09] heh there are three different merge requests dealing with correctly setting anti-aliasing in a cairo context [09:18] juliank, I will have a look if there is anything we can do to help there, thx for pointing it out [09:27] yes doko [09:31] LocutusOfBorg: well, then I'll remove llvm-9 from -proposed, and upload again [09:42] doko, what llvm in proposed? [09:43] doko, clang used by llvm is the one just built before, not the one in proposed [09:43] its a self contained bootstrap [09:43] btw looks like all of your rebuilds for libffi have SIGILL in arm64 [09:44] at least all the haskell related [09:48] LocutusOfBorg: but you just said, that llvm-9 uses llvm-9 for the build, didn't you? [09:48] LocutusOfBorg: are you fixing the llvm-8 python/python3 mess? [09:49] doko, llvm-9 uses llvm-9 stage one built on the same build process [09:49] built with gcc I would say [09:50] not the one in release [09:50] it depends on libllvm9 because of doxygen dependency, not because it needs it [09:50] (at least I think)( [09:50] for llvm-8, ack I can do it [09:51] ta [09:51] but only after binutils is fixed I would say... [10:01] LocutusOfBorg: ugh, you "fixed" llvm by uploading a binary build? [10:04] yes [10:05] from bileto [11:04] tumbleweed: s/python/python2/ in b-d's for pypy/pypy3 please [11:10] 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] 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] `smb: yes [11:21] smb: https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1859432 [11:21] Launchpad bug 1859432 in xen (Ubuntu) "xen needs to depend on python2 instead of python (or better python3)" [High,Confirmed] [11:39] 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] o/ rbasak, sil2100 - hope you had great EOY! Can you please take a look in LP #1847924 ? [11:58] Launchpad bug 1847924 in mdadm (Ubuntu Eoan) "Introduce broken state parsing to mdadm" [Medium,In progress] https://launchpad.net/bugs/1847924 [11:59] I've managed to implement the suggested changes, but I'd aprpeciate some review in order to validate it can be uploaded to -proposed === ricab is now known as ricab|lunch [13:10] doko: sure. I was waiting for tooling to catch up on that === ricab|lunch is now known as ricab [14:55] juliank, bug #1859477 ... those python2 build-depends look like leftover since you removed the python2 support in 19.10? [14:56] bug 1859477 in aptdaemon (Ubuntu) "FTBFS in focal due to missing python-defer" [High,New] https://launchpad.net/bugs/1859477 [14:56] seb128: sounds like it [14:56] seb128: I'll go remove them [14:56] juliank, thanks! [15:11] seb128: hmm, it does not build now because dh_auto_clean calls pyversions and that does not exist (doko ?) [15:11] Maybe it needs porting away from debhelper compat 78 [15:11] *7 [15:13] I think most stuff can be removed from d/rules [15:16] fixing ... [15:16] switching it to pybuild and compat 12 [15:24] juliank, thx :) [15:26] I even ran autopkgtests this time before uploading :) [15:27] juliank: yes, I usually only bump to v9 [15:28] 12 seems to work fine here, so I cleaned it up a bit and bumped it that far [16:05] rafaeldtinoco: congrats on core-dev :-) [16:06] thanks Laney! === alan_g is now known as alan_g_ [18:25] * RikMills watches the ubuntu-devel mailing list [18:25] Weird stuff on the ubuntu-devel mailing list. [18:27] someone need to get a life. [18:27] needs* [18:55] mdeslaur, which they can get for the low price of 0.18367473287 bitcoins? [18:55] bryce: yes! :) [18:57] doko: thanks for the networkx upload. I was hitting some examples failures on Friday but maybe they went away. [19:08] coreycb: that was just to get rid off the component mismatches [19:08] doko: yes, was just hitting other issues when trying to fix the mismatches [19:12] coreycb: how is openstck going with 3.8? already asked james page [19:13] 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] jamespage: can we remove python-otherstuf? [19:26] jamespage: also python-stuf [19:29] 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] sarnold: rebuid procenv and look at the build log [19:41] MemTotal: 8170344 kB [19:41] https://launchpadlibrarian.net/436053202/buildlog_ubuntu-eoan-arm64.procenv_0.50-1ubuntu2_BUILDING.txt.gz [19:41] sarnold: but note that we use arm64 kernel + armhf userspace. [19:42] i believe we are using native toolchain [19:42] xnox: ah, not an armhf qemu? [19:42] not sure how much shared vs built-in libraries we use [19:42] sarnold: i believe we do not do armhf qemu. As we still don't have images working with that, i think. [19:43] 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] https://launchpadlibrarian.net/436053201/buildlog_ubuntu-eoan-armhf.procenv_0.50-1ubuntu2_BUILDING.txt.gzat the top of [19:43] so yeah aarch64 kernel with chroots to build armhf code [19:44] 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] jamespage: is python-mock-services still needed? [20:49] Hi [20:50] defaultly allow users to set crontab seems to me a securty breach [20:52] a user shouldn't be allowed to run anything outside his main shell without superuser agreement [20:52] same for systemd timers [20:54] 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] How do you figure this is a security breach? [21:04] 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] because a user is by definition a untrusted account. An untrusted account shouldnt be able to run something in background [21:05] so why isn't all users in docker account when installing docker for exemple ? [21:05] 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] Unprivileged users running things in the background is pretty much how most things get done. [21:06] running code in background should be root aggreed [21:06] most things ? like ? [21:06] Like nearly all daemons? [21:06] huhu, daemons owned by users ? [21:07] just a test, please pgrep 'your user' while not connecting with it [21:07] and paste it here [21:07] www-data isn't root. [21:07] www-data is a account managed by a package [21:07] 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] The short answer to your concern is "it's not a concern, that's how UNIX works". [21:08] The long answer is "if you don't trust your users, lock them down more". [21:08] hm [21:08] Despite your claims, there's no universal belief (and quite the opposite) that users shouldn't be able to run background processes. [21:10] why users need to be in audio group to use pulseaudio ? "docker" group for docker [21:10] they dont [21:10] ogra: please explain [21:10] the audio group has been obsolete since years ... device access for audio particulary is managed via ACLs [21:11] sorry "pulse" group [21:11] https://doc.ubuntu-fr.org/pulseaudio [21:12] 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] aslk the person that made this up ? on my ubuntu machines there is no pulse group [21:12] why not defaulty allow all users to acces thoses files [21:13] /dev/kvm 777 is like default crontab for users [21:13] not really [21:13] the user crontab runs as the user [21:14] For serial, it's a lack of locking, so you need to trust everyone with access to play nice. [21:14] it cant magically escalate privs [21:14] /dev/kvm allows you to see into every VM running under it, ish. [21:15] crontab has neither of those concerns. [21:15] 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] 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] infinity: they could run a cryptominer [21:16] i run 800 hosts in a university [21:16] Yes, they could. They could do that interactively too. [21:17] 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] 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] infinity: i work in a university and everybody makes everythings possible to not allow that [21:18] 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] nop screen is not installed by default [21:18] crontab is [21:18] What you're looking for is CPU and memory quotas, not arbitrary limits on how a user can use UNIX. [21:19] we don't agree, not a problem. But i keep thinking that everythings outside main shell of a users shouldn't exist [21:19] defaultly i mean [21:20] screen doesn't need to be installed by default to be usable to detach sessions... [21:20] I mean, cryptominers aren't installed by default either, but you're concerned about their use. [21:20] downloading binary in user space ? [21:20] A binary doesn't need to be "installed" or owned by root for me to run it. [21:20] you're right [21:23] does exist some keylogger working in userspace nop ? [21:23] keyloggers need root. [21:23] ok [21:23] Of course, almost every UNIX/Linux desktop has a root kelogger running. We call it X11. [21:24] i'm thinking that as you said, a user could just open tty2 and run what he wants then back to tty7 [21:24] infinity: huhu [21:24] nop i'm running wayland :) [21:24] but it's the same [21:25] It's not the same, actually. Wayland has strict privsep. [21:25] didn't know, cool [21:25] X11 is leaky between applications, pretty much by design. [21:25] too old [22:45] 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 ?