=== pieq_ is now known as pieq
cpaelzeroSoMoN: 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 coordination06:15
cpaelzeronce I start something else after breakfast (all current things are waiting on something/someone) I'll let you know06:16
cpaelzersix and python-azure things are fully completed and migrated06:19
* tsimonq2 loves all of the +1 maintenance activity06:21
cpaelzerthanks tsimonq206:26
cpaelzerI'm afraid if I send my mail at the end of my double week it will be a book and no one will read it06:26
cpaelzermaybe I should send at the end of each week ...06:26
tsimonq2cpaelzer: Was speaking generally, but each person makes up a chunk of that, so you're welcome.06:27
tsimonq2If only there was a more centralized way to provide an audit log of sorts.06:27
tsimonq2So e.g. on a daily basis, interested people could just look there.06:28
cpaelzerwe (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 on06:28
tsimonq2That's agreeable.06:30
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:33
eoli3n_ok found : http://ports.ubuntu.com/ubuntu-ports/dists/focal/main/installer-arm64/current/legacy-images/netboot/06:37
cpaelzeroSoMoN: 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 complete07:08
seb128hey cpaelzer, k07:09
eoli3n_arm... not amd07:15
eoli3n_so where can i get focal netboot please ?07:15
cpaelzereoli3n_: 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/1451007:20
cpaelzerworth a read to consider this going forward07:20
eoli3n_i have my own netboot server since many years with a kickstart file etc...07:20
eoli3n_don't stop to provide legacy netboot for next releases07:21
LocutusOfBorgseb128, I think a better pulseaudio/riscv64 would have been this patch https://git.launchpad.net/~ubuntu-audio-dev/pulseaudio/commit/?h=ubuntu&id=40db304aba4f2258edfb3d524787b1e0f22baacb07:23
LocutusOfBorgwhat is your opinion?07:23
seb128LocutusOfBorg, the test does work on other archs but maybe yes, ideally that would be upstreamed07:27
seb128LocutusOfBorg, 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 sense07:28
xnox@pilot in08:44
=== 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
xnoxI 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:45
oSoMoNxnox, 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:12
oSoMoNor are you doing both +1 maintenance and patch piloting today?09:13
xnoxoSoMoN: I think we came up with idea of (ab)using pilon in on Tuesday for patch piloting.09:14
xnoxoSoMoN: 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:15
LocutusOfBorgcpaelzer, any timeline for qemu 5.0 in groovy? :)09:26
cpaelzerLocutusOfBorg: ~August09:33
LocutusOfBorgthanks :)09:34
cpaelzersil2100: this week you looked at ntirpc/nfs-ganesha09:43
cpaelzerdid you (or someone else) make nfs-ganesha a sync while doing so?09:43
cpaelzerbecause there is a component mismatch left, so one old delta at least needs to get back09:44
cpaelzerI can do that, but I wanted to know the intention/plan to not make things worse by making this a merge again09:44
cpaelzeroSoMoN: seb128: doko: xnox: I'll ping the NFS-ganesha merge that is needed to make ntirpc migrate09:54
=== CarwynNelson4 is now known as CarwynNelson
xnoxworking on removal of ubuntu-app-launch & url-dispatcher without breaking anything that depends on it for the DE we actually ship09:58
cpaelzerok,t hanks for the info xnox10:02
dokoxnox: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950404 is awaiting feedback10:04
ubottuDebian bug 950404 in src:ndpi "ndpi FTBFS on arm64, i386, ppc64el and s390x due to test failures" [Serious,Open]10:05
dokoRikMills: https://launchpad.net/ubuntu/+source/nootka/1.2.0-0ubuntu4/+build/19239722 any idea? otoh the package could be removed, no rdeps10:07
dokonot in Debian either10:07
xnoxdoko:  i'm sorry that's out of scope for +1 maintainance in Ubuntu atm. ndpi is not blocked in groovy, is it?10:11
RikMillsdoko: 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 it10:17
* RikMills guesses removal bug is required10:19
RikMillsif people want it, looks like a snap candidate10:19
RikMills\o/ they have a flatpak and an android version in the play store as well10:20
dokoRikMills: could you file one?10:25
RikMillsLP: #188063010:25
ubottuLaunchpad bug 1880630 in nootka (Ubuntu) "Please remove nootka from Ubuntu" [Undecided,New] https://launchpad.net/bugs/188063010:25
RikMillslooks like already done. I have commented with context10:25
dokoahh, there already was one10:25
juliankMake experts! How do I write ".man.8: Makefile" correctly?10:28
juliankbecause this triggers "warning: ignoring prerequisites on suffix rule definition"10:28
juliankmaking it "%.8: %.man Makefile" makes automake complain that's gnu make stuff10:29
juliankAh I see I need to get all explicit .8 targets and add depends for those10:31
juliankSo, flatpak-builder says10:39
juliankecho Building10:39
juliankmake: echo: Operation not permitted10:39
juliankon s390x10:39
juliankwhat am I supposed to do with that?10:39
juliankwith make 4.310:39
juliankseems fine with older make10:40
dokowaveform: is this supposed to build? https://launchpad.net/ubuntu/+source/linux-raspi2-5.4/5.4.0-1001.1build110:40
dokosforshee: ^^^10:40
cpaelzeroSoMoN: 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 check10:44
xnoxjuliank:  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 it10:46
xnoxjuliank:  for example, normally there is no tty1 on s390x10:46
juliankxnox: I have no idea really, but this must have changed between make 4.2 and 4.310:46
juliankprobably could find out by recreating a stdout that is not writable?10:47
xnoxjuliank:  where is it a problem?10:47
xnoxit seems to build fine (i.e. dpkg is built now?!)10:47
juliankxnox: flatpak-builder autopkgtest10:48
xnoxjuliank:  all we care is for make to be in groovy-proposed =) cause it's used to build all the things ;-)10:48
julianklooking at the log, this seems a real regression: http://autopkgtest.ubuntu.com/packages/f/flatpak-builder/groovy/s390x10:49
juliankbecause it only fails in the make 4.3 runs, but works in the ones betwee nthose10:49
juliankGNU make will now use posix_spawn() on systems where it is available.10:49
juliank^ this?10:49
xnoxjuliank:  ack. I can take a look into that on s390x box later today.10:50
xnoxwith like strace on fds10:50
xnoxplus autopkgtests have multiple indirections of what stdout is10:50
dokoRikMills: kopete was removed in Debian testing, because linphone was removed (ftbfs). can we remove it in Ubuntu too?10:51
dokoor build it without libphone support10:51
juliankxnox: I could actually just investigate this on the autopkgtest infra directly with a --shell-fail rerun10:52
juliankok, other cross-toolchain-base-* uploads to do, and then that's the remaining blocker for make-dfsg10:53
waveformdoko, no - we renamed linux-raspi2 to linux-raspi for focal, so it's only relevant on bionic at this point10:54
dokowaveform: can we remove the package?11:06
dokoif yes, please file a bug report and subscribe ubuntu-archive11:07
waveformdoko, it's still used in bionic so I don't we can just yet11:07
waveformdoko, (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:08
dokowaveform: I'm talking about groovy11:09
waveformdoko, in that case definitely - I'll file the issue11:09
dokowaveform: so you filed a bug for linux-raspi2, but I asked for linux-raspi2-5.4. can both be removed?11:37
seb128xnox, fftw3 i386 autopkgtest are still red with your fixes, did you notice?11:50
xnoxseb128:  i have11:51
xnoxseb128:  my next plan is to skip them.11:51
xnoxseb128:  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:51
xnoxseb128:  but also, we only do native i386 building & testing cross-buildability of fftw3 is outofscope for i386-on-amd64 cross-autopkgtesting i think11:52
oSoMoNI 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 ?12:12
=== mfo_ is now known as mfo
cpaelzeroSoMoN: 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
cpaelzeroSoMoN: seb128: doko: xnox: I'd have gone for scanning test status for those cases and re-queue them12:35
cpaelzeror is anyone of you already on this?12:35
oSoMoNI'm not12:36
seb128cpaelzer, I clicked some I saw on the by team excuse12:36
seb128we really need those improvements to not requeue things already queued12:36
cpaelzerseb128: only on the Desktop "by team" ?12:36
=== antoine5 is now known as antoine
seb128cpaelzer, mostly, but I glanced over the foundations section as well and clicked a few there12:37
=== Enlik is now known as Guest52001
waveformdoko, 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 supported12:48
waveformdoko, I'll re-file12:48
cpaelzerseb128: ok you had gnutls28 but sepia and pinto are not in the per team view and not currently queued12:50
cpaelzerso I restarted those two12:50
seb128cpaelzer, thanks12:50
cpaelzeroSoMoN: seb128: doko: xnox: FYI I'll be looking at jinja2/oca-core test fails12:52
RikMillsdoko: 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 packages12:55
cpaelzeroSoMoN: seb128: doko: xnox: lintian tests all passed as well now (one more peice in the perl puzzle)12:56
RikMillsreverse-depends src:linphone12:56
RikMillsNo reverse dependencies found12:56
=== dannf is now known as dannf`
doko$ reverse-depends -b src:linphone13:54
doko* kopete                        (for libmediastreamer-dev)13:54
doko* kopete                        (for libortp-dev)13:54
dokoRikMills: ^^^13:54
dokohmm, ok13:54
cpaelzeroSoMoN: 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 it14:28
cpaelzerI'm in meetings from now on, probably no more +1 cases for me today14:28
eoli3n_what do i see ?? apt embeed snap packages now ?14:46
eoli3n_does snap packages still doesn't work when home is not local..?14:47
juliankddstreet: did you see me approving your software-properties branch?15:09
juliank(last thu)15:10
juliankseb128: 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=e375293fd8787f8a40b6eded51dde808f9d9cb0915:12
juliankbecause it's not uploaded15:12
seb128juliank, 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 upload15:13
juliankseb128: ok15:14
juliankIt's a small change anyway15:14
=== ErichEickmeyer is now known as Eickmeyer
oSoMoNcpaelzer, 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 patches15:54
xnoxoSoMoN:  oooh nice!15:57
xnox@pilot out15:57
=== 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 is finishing up for the day, but i will be back tomorrow!15:57
ddstreetjuliank yes thanks, i'll try to get time to push it (if i have acl...)16:04
juliankit's ~ubuntu-core-dev owned iirc?16:06
=== AdmWiggin is now known as tianon
=== ben_r_ is now known as ben_r
oSoMoNI'm looking into the fontforge s390x build failures (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961841)18:24
ubottuDebian bug 961841 in src:fontforge "fontforge FTBFS on 64bit big endian: test failures" [Serious,Open]18:24
oSoMoNthat's encouraging: https://launchpad.net/~osomon/+archive/ubuntu/fontforge-bigendian-groovy/+build/1940861518:33
ahasenackin focal, we have both golang 1.13 and 1.14, with 1.13 being the default19:49
ahasenackgolang-defaults creates the symlinks from /usr/bin/go to the 1.13 binary somewhere in /usr/lib19:49
ahasenackis 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:50
* ahasenack wonders if it's managed by alternatives19:51
ahasenackno, looks like alternatives was used once upon a time, but not anymore19:51
sarnoldahasenack: 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 architectures19:51
ahasenackthat's unexpected reasoning :)19:54
* ahasenack tries the manual symlinks19:54
ahasenackthe thing built, so far so good19:55

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!