[01:19] <vpa1977> terje: I believe you need to create an openpgp key and add it to your launchpad profile https://help.ubuntu.com/community/GnuPrivacyGuardHowto
[01:20] <vpa1977> then it you can use dput to upload your package: dput ppa:<your-lp-name>/<your-ppa> <your-package-source.change>
[01:42] <vpa1977> looking at: mapserver-bin depends on conflicting packages: libcurl3t64-gnutls=8.5.0-2ubuntu8 vs libcurl3-gnutls=8.5.0-2ubuntu2
[01:49] <teward> mwhudson: did... you happen to not see there's a newer `xca` already in the archive?  *points at 2.5.0-1build12*
[01:50] <teward> 'cause... I think you missed that when you tried to do a rebuild against the t64 version of a qt5 package for build deps
[01:50] <teward> s/1build12/1build2/
[01:51] <mwhudson> teward: i ran my script without setting APT_CONFIG properly
[01:52] <teward> mwhudson: ah, ok.  XCA is on my direct ping list 'cause i'm also the DM for the package :P
[01:52] <mwhudson> teward: where do rejected uploads get reported though??
[01:52] <teward> i get emails on rejects
[01:52] <mwhudson> i did not know that!
[01:52] <mwhudson> i just uploaded a better one
[01:52] <teward> ye i receive Rejected, etc. as the package maintainer
[01:52] <teward> so things where i'm in the Maintainer field get me notified :p
[01:53] <mwhudson> til
[01:53] <mwhudson> anyway i've just uploaded a better versioned version
[01:53] <mwhudson> i think there is some difference in debian and ubuntu wrt which qt packages are getting renamed but that can be next week's problem
[01:53] <teward> oh i'm pretty sure there are
[01:53] <teward> AFAICT we're doing full renames on packages, etc.  Debian is not
[01:54] <teward> but that may be me being semi-ignorant and not watching closelyt
[01:54] <mwhudson> replacing the build-dep with one on the -dev package would help!!
[01:54] <teward> if only that actually worked :p
[01:55] <teward> *shrugs* Qt is weird
[02:30] <arraybolt3> mkukri: asking you since you uploaded it last - is there a reason that the 70_no-bitmaps.conf file in fontconfig was changed from "<patelt name="scalable"><bool>false</bool></patelt>" to "<patelt name="outline"><bool>false</bool></patelt>"? (Note "scalable" vs "outline".) When the value is set to "outline", it kills the ability for any native app in a KDE Plasma session to use Noto Color
[02:30] <arraybolt3> Emoji, meaning emojis are broken all over the place.
[02:30] <arraybolt3> Setting that value to "scalable" like it is on Jammy instantly fixes the issue.
[02:36] <arraybolt3> (It also results in LibreOffice seeing Noto Color Emoji like it does on Jammy, but since this is a major regression I think we can live with that.)
[02:42] <vpa1977> looking at:   * htcondor depends on conflicting packages: libcurl4t64=8.5.0-2ubuntu8 vs libcurl4=8.5.0-2ubuntu2
[03:32] <mwhudson> mmpf
[03:32] <mwhudson> https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1987920 -- unity-control-center depends on this
[03:32] -ubottu:#ubuntu-devel- Launchpad bug 1987920 in indicator-datetime (Ubuntu) "indicator-datetime fails to build with default gcc (gcc-12)" [High, Confirmed]
[03:53] <mwhudson> vorlon: should we remove indicator-datetime and rdeps?
[03:53] <mwhudson> (which includes a fair bit of unity afaics)
[04:07] <mwhudson> although haha it might be quite easy to fix
[04:07] <mwhudson> broken by the default colours changing in evolution-data-server...
[04:26] <mwhudson> ok fix works on amd64, let's see if it builds on armhf when i upload...
[05:15] <vorlon> mwhudson: unity has a supported flavor
[05:16] <vorlon> s/supported/official/
[05:16] <mwhudson> vorlon: i fixed it anyway
[05:16] <vorlon> ok
[05:16] <mwhudson> poor impulse control
[08:33] <mkukri> arraybolt3: that might be an upstream change and/or mismerge, let me check
[08:36] <mkukri> arraybolt3: we have inherited that from Debian (it changed in 2.15.0-1), it is not something i have changed.
[08:36] <mkukri> jbicha: you look like the uploader of the revision that changed that. is that something we should keep in ubuntu?
[09:44] <ginggs> sil2100: here's an armhf binary removal LP: #2058768
[09:44] -ubottu:#ubuntu-devel- Launchpad bug 2058768 in libwfa2 (Ubuntu) "libwfa2: Please RM armhf binaries" [Undecided, New] https://launchpad.net/bugs/2058768
[09:44] <ginggs> juliank: do you want to exclude libwfa2 from your reports?
[09:45] <juliank> ginggs: if binaries get removed they'll disappear 30 mins later
[09:45] <ginggs> juliank: cool!
[09:51] <dviererbe> Hi, can someone sync 1. golang-github-google-go-github (60.0.0-1) and 2. dh-make-golang (0.7.0-1) from debian unstable. This fixes dh-make-golang FTBFS (see LP: #2046369). Note: The build order is important.
[09:51] -ubottu:#ubuntu-devel- Launchpad bug 2046369 in dh-make-golang (Ubuntu) "dh-make-golang 0.6.0-2 fails to build from source" [Undecided, New] https://launchpad.net/bugs/2046369
[09:52] <schopin> dviererbe: on it.
[09:52] <dviererbe> thx
[09:52] <sil2100> ginggs: on it
[09:54] <ginggs> ta!
[09:55] <schopin> dviererbe: erm, that's quite a version bump for that first package :/
[09:57] <dviererbe> schopin: according to the changelog, there is no intermediate version
[09:57] <dviererbe> for both packages
[09:58] <sil2100> ginggs: should be done now o/
[10:01] <schopin> dviererbe: could you document in the bug why both new upstream versions should be synced (aside from "well, at least those build correctly")?
[10:04] <schopin> sil2100: so, LP: #2058912 is back on the RM train after all :/
[10:04] -ubottu:#ubuntu-devel- Launchpad bug 2058912 in xwiimote (Ubuntu) "t64: please remove xwiimote and rdeps armhf binaries from noble" [Undecided, New] https://launchpad.net/bugs/2058912
[10:05] <dviererbe> schopin: I think I have no other reason than fixing the FTBFS
[10:07] <adrien> a general question is how aggressive we can be wrt removing packages on armhf: I think we should drop all of R, would that be likely accepted if there aren't dependent packages outside of the R realm?
[10:08] <sil2100> schopin: looking!
[10:08] <waveform> anybody looking at the FTBFS on amd64 for cairo-dock-plug-ins? I see that's in universe, so I'll have a look if no-one else is already
[10:08] <adrien> that's probably quite a lot of work to assess so I'd prefer to have some input on that first
[10:09] <schopin> adrien: I think that'd be accepted, but you'd need to do the legwork of actually coming up with the list of binary packages :)
[10:09] <schopin> But I'm no AA.
[10:15] <adrien> I'm going to come up with a few categories and ask AAs directly
[10:15] <adrien> like bioinformatics
[10:17] <sil2100> schopin: so looking at the packages in your rm bug, I see that xf86-input-xwiimote has a version in -proposed which does have armhf binaries, and deps on the t64 ones
[10:18] <sil2100> Guess I'll remove the noble-proposed one as well
[10:20] <schopin> sil2100: how is that possible? oO
[10:21] <sil2100> ah, no, so I see it rebuilt but the libxwiimote didn't change, just the changelog entry is confusing now
[10:21] <sil2100> I'll drop the -proposed version alltogether I think
[10:24] <juliank> We could still execute https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.with-proposed-missing.txt :)
[10:25] <juliank> plug holes hard :)
[10:27] <sil2100> schopin: done
[10:27] <schopin> ta
[10:27] <juliank> or is it too weird to potentially only remove *some* binaries of a package, because I don't track if all packages in the source are leaf packages?
[11:06] <adrien> going to wait for britney to run, especially after the current test re-queues
[11:06] <adrien> and for the amd64 queue to stabilize
[11:07] <jbicha> arraybolt3: I believe the emoji issue is fixed with fontconfig from noble-proposed
[11:22] <juliank> src:tanglet: libqt6gui6
[11:22] <juliank> src:tetzle: libqt6gui6
[11:22] <juliank> src:theli: libcurl4
[11:23] <juliank> fixed these now
[11:24] <juliank> src:rustc-1.62: libllvm14
[11:24] <juliank> src:rustc-1.68: libllvm15
[11:25] <juliank> src:rustc-1.73: libllvm17
[11:25] <juliank> src:rustc-1.74: libllvm17
[11:25] <juliank> I guess I'll have a stub at these
[11:25] <juliank> * stab
[11:28] <doko> TheRedQueen: ^^^???
[11:28] <juliank> Thanks doko
[11:28] <juliank> doko: It's a bot, it automuted due to flooding
[12:07] <waveform> @pilot in
[12:38] <doko> adrien: R removals, please file a bug report, with what you think should be removed, with a rdeps analysis
[12:39] <juliank> Retried arm64 test failures
[12:40] <juliank> Waiting for qa team to see about merging arm64 runs, it will drop the queue from 1481 -> 898
[12:41] <juliank> doko: to clarify source removals need bugs, armhf removals just pinging on irc with reason and short analysis summary
[12:52] <juliank> Retrying armhf test failures after all teh weekend fixing
[12:52] <juliank> (queues on armhf are empty)
[12:54] <juliank> ugh kernels for focal have been uploaded, taking precious autopkgtest resources
[12:55] <juliank> I feel like these tests could wait until after time_t deadline
[13:01] <doko> sure, but for that large number of R packages ...
[13:40] <ginggs> adrien: are you already looking at rdeps for R removals?
[13:40] <ginggs> rrrdeps
[13:49] <adrien> ginggs: no, not yet: I was looking at test queues this morning and just finished lunch, why?
[13:51] <juliank> Issuing some more no-change rebuilds
[13:51] <ginggs> adrien: there's a subset of them (r-bioc-rhtslib and rdeps) which definitely can be removed
[13:52] <ginggs> (debian decided to drop 32-bit architectures instead of doing time_t)
[13:52] <adrien> good to know, thanks
[13:52] <ginggs> so i wondering whether i should go ahead and file a but for removal of those
[13:52] <adrien> do you have a link to a discussion? I'm curious as to why it would only be a subset
[13:52] <ginggs> bug*
[13:52] <adrien> (or maybe others didn't require changes?)
[13:53] <adrien> (if so, I shouldn't have fixed the analysis for R packages and said every one of them required a transition :D )
[13:53] <ginggs> adrien: i can point you at debian bug #1063275
[13:53] -ubottu:#ubuntu-devel- Debian bug 1063275 in src:r-bioc-rhtslib "r-bioc-rhtslib: identified for time_t transition but no ABI in shlibs" [Serious, Fixed] https://bugs.debian.org/1063275
[13:53] <adrien> thanks a lot!
[13:55] <ginggs> should i file i bug for r-bioc-rhtslib in the meantime
[13:58] <adrien> ginggs: that would be great, thanks! I see r-bioc-rsamtools is mentioned there too (I see both as issues in armhf logs)
[13:59] <ginggs> adrien: ack, i'll do that
[14:00] <adrien> and I was looking for a third one: r-bioc-variantannotation which I think is in the same boat with a removal request ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063378 )
[14:00] -ubottu:#ubuntu-devel- Debian bug 1063378 in ftp.debian.org "RM: r-bioc-variantannotation [armel armhf i386 hppa m68k powerpc sh4] -- ROM; r-bioc-rhtslib does not support of 32 bit architectures any more" [Normal, Open]
[14:00] <adrien> I think these three are the top offenders I've seen in logs
[14:05] <ginggs> adrien: for reference, LP: #2058933
[14:05] -ubottu:#ubuntu-devel- Launchpad bug 2058933 in r-bioc-rhtslib (Ubuntu) "r-bioc-rhtslib: Please RM armhf binaries" [Undecided, New] https://launchpad.net/bugs/2058933
[14:09] <adrien> awesome, thanks!
[15:10] <vorlon> @pilot in
[15:14] <adrien> I'm looking at pyxplot in order to ask for its removal; it's only used by debian-science metapackages and debian_science has a "dependency_data" directory which seems to be a versioning of the results of d/control: does anyone know how they're built and what they're used for?
[15:14] <adrien> it's only Recommends: pyxplot so it doesn't matter much IIUC but I'm curious
[16:04] <waveform> @pilot out
[16:11] <mkukri> what's the solution if i have a package that has @builddeps@ in its test depends, and failing tests because it needs the new dpkg from proposed. (passes with --apt-pocket=proposed=src:dpkg locally)
[16:12] <mkukri> is re-trigger with all_proposed=1 a solution to that?
[16:14] <juliank> everything is being triggered with all proposed right now, at least on noble
[16:14] <juliank> regardless of what you do
[16:14] <juliank> the general answer would be to add &trigger=dpkg/<version of dpkg in proposed> to the url, though
[16:34] <mkukri> anyone looked at libbsd x gvmd? it seems to have a broken assumption that `%ld` is correct scanf arg for time_t where on 32-bit that's an obvious fail. is there a point fixing that, or removing armhf better?
[16:35] <adrien> there are several such cases btw (do you have the exact warning btw?)
[16:35] <juliank> if it can be removed it should be removed
[16:36] <juliank> but you can also fix it after asking for removal
[16:36] <juliank> it just doesn't become a blocker anymroe
[16:36] <mkukri> adrien: `format ‘%ld’ expects argument of type ‘long int *’, but argument 3 has type ‘time_t *’ {aka ‘long long int *’} [-Wformat=]`
[16:36] <mkukri> only a problem if long long != long, which is the case on armhf...
[16:39] <mkukri> juliank: the offending version already migrated despite the regression listed, so maybe it was already removed? and it is not in the removal_candidates.txt you shared
[17:45] <vorlon> mkukri: the immediate answer is to ask for removal of armhf binaries where they are broken.  the long-term answer is that yes, this should be changed to %lld -> (long long) time_t_var
[17:47] <arraybolt3> jbicha: ah, it appears you're right. Didn't realize this wasn't Kubuntu-specific. Thank you!
[17:47] <arraybolt3> (re: the emoji breakage)
[18:52] <mkukri> vorlon: i think the short answer was already done as the package in question is already in -release, i was just misled by it being on the update excuses page
[22:05] <arraybolt3> doko: Going to try to fight the hard-coded shlib depends, are there packages in particular that need attacked? I'm not quite sure what packages are to be fixed and what packages have already had their armhf binaries removed from the reports on juliank's server.
[22:09] <doko> arraybolt3: the list (what I sent to the ML) is done
[22:09] <arraybolt3> ah, so there's no more to fix?
[22:09] <arraybolt3> or is there more to fix somewhere? I'm wanting to help out with the time_t transition if possible.
[22:37] <doko> arraybolt3: at this point, look to fix build failures in -proposed, where packages ftbfs on non-armf


[00:58] <andywork> hey what do I need to do to include the libs from libasound2 into my snap package?
[00:59] <andywork> I have it declared under "stage-packages:" but somehow it is not bundled into the snap
[09:35] <mpounta> Hello, does anyone know if there is a related channel to ubuntu-core? :)
[14:32] <jdstrand> ogra_: thanks for the bbb image-- I reflashed my bbb and it is working great! :)
[14:32] <jdstrand> $ snap list
[14:32] <jdstrand> Name               Version       Rev  Developer  Notes
[14:32] <jdstrand> bbb                16.04-1       1    ogra       -
[14:32] <jdstrand> core               16.04.1       396  canonical  -
[14:32] <jdstrand> linux-generic-bbb  4.4.0-46-1    6    ogra       -
[14:32] <jdstrand> ufw                0.36pre-16.3  3    canonical  -
[15:52] <|zno> I'm having problems with installing snaps in LXC. Does any one have experience with this?
[15:52] <|zno> Its a Privileged LXC
[15:55] <stgraber> |zno: yeah, that's not going to work. Snaps need to be able to mount squashfs and setup apparmor and seccomp policies.
[15:55] <stgraber> |zno: it will very soon be possible to reliably install snaps inside unprivileged containers though as support for apparmor stacking is now in the Ubuntu kernel (with a few last bugs being looked at), but that feature will not be available to privileged containers
[15:57] <stgraber> jjohansen (apparmor developer) is working on fixing what's hopefully the last blocking issue with running snaps, once that's fixed and pushed to the Ubuntu kernels, I'll publish a blog post explaining how to get everything working so you can install snaps in containers
[15:58] <|zno> stgraber, Ok thanks... Maybe it's time to have a look at LXC. (But to move my lxcs... maybe in 4,5 years ;) )
[15:58] <|zno> jjohansen, nice, wheres the blog?
[15:59] <|zno> And I ment LXD ...
[16:00] <stgraber> |zno: it's going to be on my personal blog (https://www.stgraber.org) as I've got quite a lot of LXD posts there already, but it's syndicated on Planet Ubuntu and usually picked up by ubuntu.com too, so should be pretty visible once it gets out :)
[16:02] <|zno> stgraber, Ok, thanks for the info. I will definitely have a look at your blog then.
[20:29] <brenda> hi there
[20:30] <brenda> just installed core 16 on a raspberry pi 3, screen and keyboard are attached and I get the login prompt
[20:30] <brenda> but the default user/password ubuntu/ubuntu won't work
[20:30] <brenda> anybody have an idea?
[20:30] <brenda> ssh with the ubuntu one ssh key doesn't work either
[20:34] <ogra_> brenda, how do you try to ssh ? and do you have the secret key on the machine you try to ssh from ?
[20:35] <ogra_> local logins are disabled by default but after ssh'ing in you can run "sudo passwd $USER" and can set a password for a local login
[20:39] <brenda> hi there
[20:40] <brenda> i generated the key on my laptop, copied the pub content to ubuntu one, set up the box, it only requested the registered email address
[20:40] <brenda> entered that and then the box sits at the prompt
[20:41] <brenda> i then used ssh ubuntuonename@ip
[20:41] <brenda> i didnt set a passphrase, so I shouldn't need to enter a password
[20:41] <brenda> so i just hit enter but the login fails
[20:43] <brenda> i'm using the nextcloud box with the RP3 by the way
[21:18] <Pharaoh_Atem> elopio: yay, the unit tests pass
[21:18] <Pharaoh_Atem> now I just have to wait for the integration tests to finish and turn the checkmark green :D
[21:23] <digitalcoder> hi !
[21:23] <digitalcoder> plz wanna get the default login/pass firstboot Snappy Ubuntu Core on Raspberry Pi 2
[21:34] <digitalcoder> could U help me ?
[22:06] <femme> are there going to be vagrant images of the new ubuntu core 16?