=== pieq_ is now known as pieq
[06:15] <cpaelzer> oSoMoN: seb128: doko: xnox: (wow +1 pinigng is a nice long list today) - I updated https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Status again as I was checking my ongoing +1 activities. That should be fine for initial coordination
[06:16] <cpaelzer> once I start something else after breakfast (all current things are waiting on something/someone) I'll let you know
[06:19] <cpaelzer> six and python-azure things are fully completed and migrated
[06:21]  * tsimonq2 loves all of the +1 maintenance activity
[06:26] <cpaelzer> thanks tsimonq2
[06:26] <cpaelzer> I'm afraid if I send my mail at the end of my double week it will be a book and no one will read it
[06:26] <cpaelzer> maybe I should send at the end of each week ...
[06:27] <tsimonq2> cpaelzer: Was speaking generally, but each person makes up a chunk of that, so you're welcome.
[06:27] <tsimonq2> If only there was a more centralized way to provide an audit log of sorts.
[06:28] <tsimonq2> So e.g. on a daily basis, interested people could just look there.
[06:28] <tsimonq2> ¯\_(ツ)_/¯
[06:28] <cpaelzer> we (all) need to find which way of commuication works best to a) do not feel like a burden/pain but b) gets out to the people so everyone can see and is aware what is going on
[06:30] <tsimonq2> That's agreeable.
[06:33] <eoli3n_> Hi
[06:33] <eoli3n_> i don't get what changed about netboot : http://cdimage.ubuntu.com/netboot/focal/
[06:33] <eoli3n_> can't i get focal netboot image ?
[06:37] <eoli3n_> ok found : http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-arm64/current/legacy-images/netboot/
[07:08] <cpaelzer> oSoMoN: seb128: doko: xnox: there is a test fail in lintian for the new libclass-xsaccessor-perl, I'll look at that next since this eventually will be needed for the overall perl things to complete
[07:09] <seb128> hey cpaelzer, k
[07:15] <eoli3n_> arm... not amd
[07:15] <eoli3n_> so where can i get focal netboot please ?
[07:18] <eoli3n_> http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/
[07:20] <cpaelzer> eoli3n_: that is the legacy build like you were used to it - alternatively you might follow http://cdimage.ubuntu.com/netboot/ to http://cdimage.ubuntu.com/netboot/focal/ which will lead you to https://discourse.ubuntu.com/t/netbooting-the-live-server-installer/14510
[07:20] <cpaelzer> worth a read to consider this going forward
[07:20] <eoli3n_> i have my own netboot server since many years with a kickstart file etc...
[07:21] <eoli3n_> don't stop to provide legacy netboot for next releases
[07:23] <LocutusOfBorg> seb128, I think a better pulseaudio/riscv64 would have been this patch https://git.launchpad.net/~ubuntu-audio-dev/pulseaudio/commit/?h=ubuntu&id=40db304aba4f2258edfb3d524787b1e0f22baacb
[07:23] <LocutusOfBorg> what is your opinion?
[07:27] <seb128> LocutusOfBorg, the test does work on other archs but maybe yes, ideally that would be upstreamed
[07:28] <seb128> LocutusOfBorg, it does sound similar to https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/619 , they fixed it by disabling the ffmath option but that's on for us it seems, maybe the patch to the test there would still make sense
[08:44] <xnox> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots: xnox
[08:45] <xnox> I am here working on +1 maintenance = meaning all things groovy. If you have anything not in groovy or stuck in groovy-proposed, ask me to help getting it moving!
[08:46] <Unit193> \o/
[09:12] <oSoMoN> xnox, this is my first +1 maintenance shift, I'm not familiar with good practices yet, am I supposed to also @pilot in/out when I start/end my day?
[09:13] <oSoMoN> or are you doing both +1 maintenance and patch piloting today?
[09:14] <xnox> oSoMoN: I think we came up with idea of (ab)using pilon in on Tuesday for patch piloting.
[09:15] <xnox> oSoMoN: i.e. if there are any other +1 maintenance people without upload rights they know, that I am around to click autopkgtest retires for them, or like sponsor uploads.
[09:16] <oSoMoN> ack
[09:18] <xnox> *retries
[09:26] <LocutusOfBorg> cpaelzer, any timeline for qemu 5.0 in groovy? :)
[09:33] <cpaelzer> LocutusOfBorg: ~August
[09:34] <LocutusOfBorg> thanks :)
[09:43] <cpaelzer> sil2100: this week you looked at ntirpc/nfs-ganesha
[09:43] <cpaelzer> did you (or someone else) make nfs-ganesha a sync while doing so?
[09:44] <cpaelzer> because there is a component mismatch left, so one old delta at least needs to get back
[09:44] <cpaelzer> I can do that, but I wanted to know the intention/plan to not make things worse by making this a merge again
[09:54] <cpaelzer> oSoMoN: seb128: doko: xnox: I'll ping the NFS-ganesha merge that is needed to make ntirpc migrate
[09:54] <cpaelzer> s/ping/take/
=== CarwynNelson4 is now known as CarwynNelson
[09:58] <xnox> working on removal of ubuntu-app-launch & url-dispatcher without breaking anything that depends on it for the DE we actually ship
[10:02] <cpaelzer> ok,t hanks for the info xnox
[10:04] <doko> xnox: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950404 is awaiting feedback
[10:05] <ubottu> Debian bug 950404 in src:ndpi "ndpi FTBFS on arm64, i386, ppc64el and s390x due to test failures" [Serious,Open]
[10:07] <doko> RikMills: https://launchpad.net/ubuntu/+source/nootka/1.2.0-0ubuntu4/+build/19239722 any idea? otoh the package could be removed, no rdeps
[10:07] <doko> not in Debian either
[10:11] <xnox> doko:  i'm sorry that's out of scope for +1 maintainance in Ubuntu atm. ndpi is not blocked in groovy, is it?
[10:17] <RikMills> doko: nootka? had not heard of that. very out of date (1.2 vs latest 1.4.7), and their website supplies ubuntu debs. I guess I could work to update it, but have zero motivation to do so and maintain/support it
[10:19]  * RikMills guesses removal bug is required
[10:19] <RikMills> if people want it, looks like a snap candidate
[10:20] <RikMills> \o/ they have a flatpak and an android version in the play store as well
[10:25] <doko> RikMills: could you file one?
[10:25] <RikMills> LP: #1880630
[10:25] <ubottu> Launchpad bug 1880630 in nootka (Ubuntu) "Please remove nootka from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1880630
[10:25] <doko> ta
[10:25] <RikMills> looks like already done. I have commented with context
[10:25] <doko> ahh, there already was one
[10:28] <juliank> Make experts! How do I write ".man.8: Makefile" correctly?
[10:28] <juliank> because this triggers "warning: ignoring prerequisites on suffix rule definition"
[10:29] <juliank> making it "%.8: %.man Makefile" makes automake complain that's gnu make stuff
[10:31] <juliank> Ah I see I need to get all explicit .8 targets and add depends for those
[10:31] <juliank> nasty
[10:39] <juliank> So, flatpak-builder says
[10:39] <juliank> echo Building
[10:39] <juliank> make: echo: Operation not permitted
[10:39] <juliank> on s390x
[10:39] <juliank> what am I supposed to do with that?
[10:39] <juliank> with make 4.3
[10:40] <juliank> seems fine with older make
[10:40] <doko> waveform: is this supposed to build? https://launchpad.net/ubuntu/+source/linux-raspi2-5.4/5.4.0-1001.1build1
[10:40] <doko> sforshee: ^^^
[10:44] <cpaelzer> oSoMoN: seb128: doko: xnox: for ntirpc/nfs-ganesha this will be needed https://code.launchpad.net/~paelzer/ubuntu/+source/nfs-ganesha/+git/nfs-ganesha/+merge/385106 - I'd appreciate if one could take a look for a sanity check
[10:46] <xnox> juliank:  is it shell builtin, or /usr/bin/echo, what's stdout connect to?
[10:46]  * juliank probably should have tested the dpkg makefile & autoreconf upload before uploading it
[10:46] <xnox> juliank:  for example, normally there is no tty1 on s390x
[10:46] <juliank> xnox: I have no idea really, but this must have changed between make 4.2 and 4.3
[10:46] <xnox> cure
[10:47] <juliank> probably could find out by recreating a stdout that is not writable?
[10:47] <xnox> *cute
[10:47] <xnox> juliank:  where is it a problem?
[10:47] <xnox> it seems to build fine (i.e. dpkg is built now?!)
[10:48] <juliank> xnox: flatpak-builder autopkgtest
[10:48] <xnox> juliank:  all we care is for make to be in groovy-proposed =) cause it's used to build all the things ;-)
[10:49] <juliank> looking at the log, this seems a real regression: http://autopkgtest.ubuntu.com/packages/f/flatpak-builder/groovy/s390x
[10:49] <juliank> because it only fails in the make 4.3 runs, but works in the ones betwee nthose
[10:49] <juliank> GNU make will now use posix_spawn() on systems where it is available.
[10:49] <juliank> ^ this?
[10:50] <xnox> juliank:  ack. I can take a look into that on s390x box later today.
[10:50] <xnox> with like strace on fds
[10:50] <xnox> plus autopkgtests have multiple indirections of what stdout is
[10:51] <doko> RikMills: kopete was removed in Debian testing, because linphone was removed (ftbfs). can we remove it in Ubuntu too?
[10:51] <doko> or build it without libphone support
[10:52] <juliank> xnox: I could actually just investigate this on the autopkgtest infra directly with a --shell-fail rerun
[10:53] <juliank> ok, other cross-toolchain-base-* uploads to do, and then that's the remaining blocker for make-dfsg
[10:53] <juliank> :)
[10:54] <waveform> doko, no - we renamed linux-raspi2 to linux-raspi for focal, so it's only relevant on bionic at this point
[11:06] <doko> waveform: can we remove the package?
[11:07] <doko> if yes, please file a bug report and subscribe ubuntu-archive
[11:07] <waveform> doko, it's still used in bionic so I don't we can just yet
[11:08] <waveform> doko, (linux-raspi2 generally that is, not that particular version which only appears to be built for focal and groovy where it definitely isn't used)
[11:09] <doko> waveform: I'm talking about groovy
[11:09] <waveform> doko, in that case definitely - I'll file the issue
[11:09] <doko> ta
[11:37] <doko> waveform: so you filed a bug for linux-raspi2, but I asked for linux-raspi2-5.4. can both be removed?
[11:50] <seb128> xnox, fftw3 i386 autopkgtest are still red with your fixes, did you notice?
[11:51] <xnox> seb128:  i have
[11:51] <xnox> seb128:  my next plan is to skip them.
[11:51] <seb128> k
[11:51] <xnox> seb128:  because i fail to comprehend how come cross compiler is installed, i386 library is installed, and yet it fails to use i386 search paths for libs.
[11:52] <xnox> seb128:  but also, we only do native i386 building & testing cross-buildability of fftw3 is outofscope for i386-on-amd64 cross-autopkgtesting i think
[12:12] <oSoMoN> I have added a force-badtest for metis/i386, can someone from the release team please review/merge https://code.launchpad.net/~osomon/britney/hints-ubuntu-i386-badtests/+merge/385113 ?
=== mfo_ is now known as mfo
[12:35] <cpaelzer> oSoMoN: seb128: doko: xnox: there is abunch of tests in excuses on ppc64 that failed with a infa error like "Creating nova instance ...ERROR: autopkgtest"
[12:35] <cpaelzer> oSoMoN: seb128: doko: xnox: I'd have gone for scanning test status for those cases and re-queue them
[12:35] <cpaelzer> or is anyone of you already on this?
[12:36] <oSoMoN> I'm not
[12:36] <seb128> cpaelzer, I clicked some I saw on the by team excuse
[12:36] <seb128> we really need those improvements to not requeue things already queued
[12:36] <cpaelzer> seb128: only on the Desktop "by team" ?
=== antoine5 is now known as antoine
[12:37] <seb128> cpaelzer, mostly, but I glanced over the foundations section as well and clicked a few there
=== Enlik is now known as Guest52001
[12:48] <waveform> doko, ah apologies - didn't realize that was a separate "project" in launchpad; linux-raspi2 itself should be removed at some point but I'm assuming we need to keep it alive whilst bionic is still supported
[12:48] <waveform> doko, I'll re-file
[12:50] <cpaelzer> seb128: ok you had gnutls28 but sepia and pinto are not in the per team view and not currently queued
[12:50] <cpaelzer> so I restarted those two
[12:50] <seb128> cpaelzer, thanks
[12:52] <cpaelzer> oSoMoN: seb128: doko: xnox: FYI I'll be looking at jinja2/oca-core test fails
[12:53] <seb128> k
[12:55] <RikMills> doko: kopete does not build depend on linphone any more as far as I can see. the previous linphone build depends are now provided with a higher version by the ortp and mediastreamer2 source packages
[12:56] <cpaelzer> oSoMoN: seb128: doko: xnox: lintian tests all passed as well now (one more peice in the perl puzzle)
[12:56] <RikMills> plus
[12:56] <RikMills> reverse-depends src:linphone
[12:56] <RikMills> No reverse dependencies found
=== dannf is now known as dannf`
[13:54] <doko> $ reverse-depends -b src:linphone
[13:54] <doko> Reverse-Build-Depends
[13:54] <doko> * kopete                        (for libmediastreamer-dev)
[13:54] <doko> * kopete                        (for libortp-dev)
[13:54] <doko> RikMills: ^^^
[13:54] <doko> hmm, ok
[14:28] <cpaelzer> oSoMoN: seb128: doko: xnox: jinja case resolved - it is indeed broken and should not migrate - I filed an updateexcuse bug so the next one looking at the queue is aware without re-debugging it
[14:28] <cpaelzer> I'm in meetings from now on, probably no more +1 cases for me today
[14:46] <eoli3n_> what do i see ?? apt embeed snap packages now ?
[14:47] <eoli3n_> does snap packages still doesn't work when home is not local..?
[15:09] <juliank> ddstreet: did you see me approving your software-properties branch?
[15:10] <juliank> (last thu)
[15:12] <juliank> seb128: you committed  a change to software-properties repo middle of April, are you going to follow up on that? https://git.launchpad.net/software-properties/commit/?id=e375293fd8787f8a40b6eded51dde808f9d9cb09
[15:12] <juliank> because it's not uploaded
[15:13] <seb128> juliank, there was no hurry that's why I didn't upload, I though other changes would come at some point and it could wait for the next upload
[15:14] <juliank> seb128: ok
[15:14] <juliank> It's a small change anyway
=== ErichEickmeyer is now known as Eickmeyer
[15:54] <oSoMoN> cpaelzer, seb128, xnox, doko : I went through all the rdeps of ttf-dejavu* that are blocking the migration of fonts-dejavu and I filed bugs/attached patches
[15:57] <xnox> oSoMoN:  oooh nice!
[15:57] <xnox> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: Open | 20.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Focal | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
[15:57]  * xnox is finishing up for the day, but i will be back tomorrow!
[16:04] <ddstreet> juliank yes thanks, i'll try to get time to push it (if i have acl...)
[16:06] <juliank> it's ~ubuntu-core-dev owned iirc?
=== AdmWiggin is now known as tianon
=== ben_r_ is now known as ben_r
[18:24] <oSoMoN> I'm looking into the fontforge s390x build failures (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961841)
[18:24] <ubottu> Debian bug 961841 in src:fontforge "fontforge FTBFS on 64bit big endian: test failures" [Serious,Open]
[18:33] <oSoMoN> that's encouraging: https://launchpad.net/~osomon/+archive/ubuntu/fontforge-bigendian-groovy/+build/19408615
[19:49] <ahasenack> in focal, we have both golang 1.13 and 1.14, with 1.13 being the default
[19:49] <ahasenack> golang-defaults creates the symlinks from /usr/bin/go to the 1.13 binary somewhere in /usr/lib
[19:50] <ahasenack> is there sometihng that does the same for golang 1.14? Create the symlinks and such? Or should I do it by hand, if I want to use 1.14 in focal?
[19:51]  * ahasenack wonders if it's managed by alternatives
[19:51] <ahasenack> no, looks like alternatives was used once upon a time, but not anymore
[19:51] <sarnold> ahasenack: it's my understanding that 1.14 is there for riscv64 -- I don't know if that's any help to you or not :) but I'm not sure the intention is to use 1.14 for non-riscv64 architectures
[19:54] <ahasenack> that's unexpected reasoning :)
[19:54]  * ahasenack tries the manual symlinks
[19:55] <ahasenack> the thing built, so far so good