[02:48] <lifeless> sinzui: if you're back, I've moved the profile module to lp.services as per your request, but it looks to me like it does not meet the namespace policy about deps. I've mailed the bug
[02:48] <lifeless> s/bug/mp/
[10:36] <rinze> sinzui, hi
[12:55] <noodles775> Hi salgado, if you've got a spare few mins, can you take a look at the issue I've identified at: https://code.edge.launchpad.net/~michael.nelson/launchpad/db-598464-get-or-create-from-identity/+merge/28885
[12:55] <noodles775> Let me know if I'm not making sense on the MP.
[12:56] <salgado> noodles775, sure, I have it in my inbox and will get to it shortly
[12:56] <noodles775> salgado: thanks.
[13:06] <salgado> noodles775, in which case is the sreg extension not included in the response?
[13:07] <noodles775> salgado: normal login with existing account. ie. 1) start dev server, 2) click login 3) enter admin@canonical.com:test 4) click login. In this case calling _getEmailAddressAndFullName raises the assert.
[13:08] <noodles775> It's not seen in the current code as _getEmailAddressAndFullName is only called if the account doesn't exist.
[13:10] <salgado> noodles775, that's weird because the code that generates the positive openid response is including the sreg extension unconditionally
[13:10]  * salgado tries to dupe
[13:11] <salgado> indeed, duped
[13:12] <noodles775> Yeah, I'd assumed the sreg response should always be there, and was surprised too.
[13:14] <salgado> noodles775, but this is a bug in the testopenid implementation
[13:14] <noodles775> Where should I look?
[13:14] <salgado> testopenid == the OpenID provider we use when developing/testing
[13:14] <salgado> I'm checking it now
[13:14] <salgado> noodles775, lib/lp/testopenid/browser/server.py
[13:15] <noodles775> OK, so we can be confident that the staging/production SSO always include the sreg.
[13:15] <salgado> createPositiveResponse() adds the sreg extension, but it's empty
[13:15] <noodles775> Thanks.
[13:16] <salgado> noodles775, I think I've found the problem
[13:17] <salgado> noodles775, OpenIDLogin.render() asks for 'email' and 'fullname' in the sreg response
[13:17] <salgado> bug testopenid ignores that and only includes the nickname
[13:17] <salgado> s/bug/but
[13:18] <noodles775> Right... I see.
[13:18] <noodles775> So should it instead include *only* the requested items (email/fullname) or in addition to the nickname?
[13:19] <salgado> I think it's fine to include the 3 of them, but the nickname shouldn't be used anywhere
[13:20] <noodles775> OK, I'll update it... thanks salgado !
[13:22] <noodles775> salgado: also, I assume you don't have time to review the actual branch, but if you could have a brief look and make sure you think it's a sane change, that would be great.
[13:24] <salgado> noodles775, sure, I can do that
[13:25] <noodles775> Ta.
[13:27] <salgado> noodles775, out of curiosity, why somebody needs a launchpad account to buy stuff from the software center?  wouldn't a Ubuntu SSO account be more appropriate in this case?
[13:28] <noodles775> salgado: yes, the must already have an SSO account to make the payment, it's after they've paid for the software, we need to give them access to a private PPA (ie. a private ppa subscription), and that's only possible if you've got an LP account.
[13:29] <salgado> I see
[13:29] <salgado> and it'd be lots of work to make it possible for someone to have a private ppa subscription without having a Launchpad profile, I assume?
[13:30] <noodles775> Yes, but that is the long-term plan.
[13:31] <salgado> cool!
[13:38] <salgado> 415	+        except LookupError:
[13:38] <salgado> 416	+            assert email_address is not None and full_name is not None, (
[13:38] <salgado> 417	+                "An email address and full name are required to "
[13:38] <salgado> 418	+                "create an account.")
[13:38] <salgado> noodles775, I'd move that assert out of the except block
[13:39] <noodles775> That won't be required... I'd only added it because of the above issue.
[13:40] <noodles775> Hrm, although, it's still possible for other callsites in the future to pass in None (even if processPositive.. doesn't).
[13:40] <noodles775> So yep, will do.
[13:40] <salgado> indeed
[13:48] <salgado> noodles775, I think you can get rid of checked_for_email and the two email_set.getByEmail(email_address) calls by doing "email = email_set.getByEmail(email_address)" at the beginning instead of "email = None"
[13:50] <noodles775> salgado: yep - that was part of r9514 which I've reverted after our discussion (I couldn't do it at the beginning at that point, because email was None when called via processPositive..)
[13:50] <salgado> right
[13:50] <salgado> I guess I should reload the m-p page, then
[13:50]  * noodles775 hasn't pushed... hangon.
[13:52] <noodles775> OK, pushed r9515...
[14:02] <salgado> noodles775, IPersonSet.getOrCreateByOpenIDIdentifier() has a requestor argument but the actual implementation doesn't
[14:02] <noodles775> salgado: thanks, I'll remove it from the IFace. I've just pushed 9516 which just adds the email/fullname to the sreg response for the testopenid server too.
[14:04] <salgado> cool, let me reload again
[14:31] <noodles775> Thanks salgado... I'll paste the irc conversation on the MP too. (And I've pushed the changes you suggested so far). I think that should be enough to get a normal review.
[14:39] <salgado> noodles775, np
[14:57] <noodles775> jelmer-lunch: if you've time when you get back: https://code.edge.launchpad.net/~michael.nelson/launchpad/db-598464-get-or-create-from-identity/+merge/28885
[14:59] <jtv> jelmer-lunch: my windmill tests pass now...  I think there was some change in setup that we both needed to synchronize to.
[15:00] <jelmer_> noodles775: ok
[15:01] <jelmer_> jtv: I'll have another look, thanks.
[15:08] <noodles775> Sure.
[16:24] <jtv> noodles775: anything to add to jelmer's review?
[16:28] <noodles775> jtv: I pasted our irc conv. on the mp.
[16:30] <jtv> noodles775: that's all about us being rusty and making dirty jokes afaics, nothing about the branch itself...
[16:30] <jtv> Ah, apart from the bit about henning's xxx that triggered the jokes
[16:31] <jtv> rinze: the tests on my JS branch are passing now, repeatedly and consistently... do I get your Approval vote?
[16:32] <jtv> noodles775: if you approve of the js, maybe you can hit the js review button?
[16:33] <noodles775> jtv: no, I was just making sure rinze hadn't missed anything obvious... I didn't do a proper review. As you mentioned in your MP, the branch is just cleaning up already working JS (outside of the chromium fix - just a different class)..
[16:33] <noodles775> Oh, but I can hit the js review button if you need it (sorry).
[16:33] <jtv> I'd love that, thanks!
[16:35] <rinze> jtv: Yeahp!
[16:35] <rinze> jtv: Updating the MP now
[16:35] <jtv> rinze: great!  Then I can still get it in before the deadline.
[16:36] <rinze> Also, if somebody here can review a oneliner: https://code.edge.launchpad.net/~jelmer/launchpad/fix-devel/+merge/29011
[16:36] <rinze> It's the testfix for devel
[16:37] <noodles775> rinze: done (and jtv too)
[16:37] <jtv> thanks
[16:37] <jtv> rinze: least I can do...
[16:37] <jtv> oh, too late :-)
[16:37] <rinze> jtv: noodles beat you to it, but thanks anyway :-)
[16:43]  * rinze looks at bigjools branch briefly
[16:43] <rinze> bigjools: there's a typo in paramter in your angry comment :-)
[16:43] <bigjools> I was too angry to speel
[16:44] <rinze> in lib/lp/soyuz/scripts/tests/test_populatearchive.py nonvirtualized seems to be a boolean parameter, yet it defaults to None and checks for "is not None"
[16:45] <rinze> I.e. if testCopyArchiveVirtualization specified nonvirtualized=False it would still not use virtualization
[16:45] <bigjools> rinze: yes deliberately, but I suppose it should default to False
[16:45] <bigjools> I was still too angry to think :)
[16:46] <bigjools> both fixed
[16:54] <rinze> bigjools: did you push your changes?
[16:54] <bigjools> rinze: no, I was waiting for more comments about my angry coding :)
[16:54] <rinze> hehe
[16:55] <rinze> bigjools: Tests pass here and I don't see any other issues.
[16:56] <rinze> perhaps you could add an assert somewhere that self.makeCopyArchive() can also still create archives that require virtualized builds
[16:56] <bigjools> yeah I saw that problem as you mentioned it too
[16:56] <bigjools> merde
[17:02] <rinze> bigjools: in your latest tip, the nonvirtualized argument to makeCopyArchive defaults to None rather than False
[17:02] <bigjools> rinze: some changes pushed up again
[17:02] <bigjools> ARGH
[17:02] <bigjools> missed it
[17:03] <bigjools> ok pushed up again
[17:05] <rinze> bigjools: I don't see the diff for that last change yet, but I trust that's correct :-) r=me
[17:05] <bigjools> thanks rinze :)
[17:05] <bigjools> saving me from my own stupidity on that branch
[17:18] <henninge> jtv: review sent (finally)
[17:18] <jtv> ahhh!
[17:19] <jtv> henninge: hope it's an approval!
[17:19] <henninge> jtv: almost
[17:19] <jtv> grrr
[17:19] <henninge> jtv: I mean, there are no big issues but I'd like to hear your opinions on some of my comments.
[17:20] <henninge> ;-)
[18:05] <bigjools> is anyone around for a simple but urgent review?
[19:49]  * bigjools meets rockstar here
[19:49] <rockstar> bigjools, I've come to the conclusion that soyuz is generally hard to understand unless you know the whole entire subsystem.
[19:49] <rockstar> The latter has become a new goal of mine.
[19:50] <bigjools> attaboy
[19:50] <bigjools> I still learn stuff 3.5 years after I started on it....
[19:53] <rockstar> bigjools, why do you "create copy archives for rebuild testing"? That's not a PPA thing, right?
[19:54] <bigjools> rockstar: no, it's more like a main archive presented like a PPA.  It allows us to copy source from somewhere else and rebuild it
[19:55] <rockstar> bigjools, presented like a PPA?  What's the use case there?
[19:55] <bigjools> UI code re-use :)
[19:55] <rockstar> (Patch looks fine, just trying to squeeze a few user stories out)
[19:55] <bigjools> we didn't want it looking like the normal distro pages
[19:55] <bigjools> the main use case is to find failed builds
[19:55] <rockstar> Why shouldn't it look the same?
[19:56] <rockstar> Er, why shouldn't it look like the normal distro pages?
[19:56] <bigjools> they're overkill for this type of archive, mainly
[20:08] <rockstar> bigjools, so I guess the thing I'm not understanding is what type of archive this is.
[20:08] <rockstar> Is it a distro archive or a PPA or something else I don't know about.
[20:12] <james_w> it's a third type
[20:14] <rockstar> james_w, which is?
[20:14] <rockstar> Is it like a throwaway archive just for rebuilding copies of existing packages?
[20:16] <james_w> rockstar: pretty much
[20:16] <rockstar> james_w, ah, okay.  That parses better now.
[20:16] <james_w> it's grown some extra features, but the primary use case is to copy sources from Ubuntu in to a new archive, and then rebuild them there
[20:17] <james_w> so the bug in question is where it copies a bunch of sources, and then fails while creating the build records for them
[20:17] <rockstar> Yeah, that makes sense.
[20:17] <james_w> in particular because the new archive doesn't have i386 enabled, and i386 is required to build arch "all" packages, it's the nominatedarchindep
[20:22]  * bigjools watches james_w explain how my branch works :)
[20:22] <bigjools> sorry - had to dash off, child-related poo emergency
[20:22] <james_w> nice
[20:22] <bigjools> actually it wasn't :(
[20:22] <rockstar> Yeah, I very much understand nominatedarchindep.  Remember that time that recipe builds were using the arm builder...
[20:24] <bigjools> unfortunately yes
[20:25] <james_w> damn you bigjools, I've now started typing poopy instead of poppy
[20:27] <james_w> rockstar: a small branch of my own if you would: https://code.launchpad.net/~james-w/launchpad/move-file-is-a-directory/+merge/29033
[20:28] <rockstar> james_w, I live serve...
[20:28] <rockstar> Er, I live to serve
[20:28] <james_w> \o/
[20:28] <rockstar> I apparently don't live to type correctly.
[20:29] <bigjools> james_w: haha
[20:38] <bigjools> rockstar: thanks for the review
[20:39] <rockstar> james_w, your branch is made of awesomeness.  Thanks for doing that.
[20:39] <bigjools> rockstar: aw jeez you Quoted me!
[20:39] <rockstar> One day, we'll have all our dependencies nice and neat.
[20:39] <rockstar> bigjools, yeah, it had to be done.
[20:40] <rockstar> bigjools, also, you're like, the 6th person today to tell me about poo related mishaps that occurred today.
[20:40] <bigjools> one day you will have kids and will enthusiastically join in
[20:40] <james_w> thanks rockstar


[02:27] <danderson> Hello all.
[02:29] <danderson> I'm trying to puzzle out what the difference between 'expect fork' and 'expect daemon' is in an upstart config.
[02:30] <danderson> I'm writing a config for tpmd (TPM emulator daemon). When exec'd, it backgrounds itself. Using 'expect daemon' makes the start/stop commands hang, whereas 'expect fork' starts and stops the daemon as expected.
[02:30] <danderson> what is the actual difference between these two expects?
[02:32] <juan__> I'm not sure but this entry seams relevant http://www.netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/
[02:36] <danderson> well, that talks about daemons and how to track them in general. I'm more looking for the distinction upstart makes between 'fork' and 'daemon'.
[15:10] <drocko> hello
[15:10] <drocko> i'm trying to write an upstart job to run when my system starts up, but it never seems to run. I can run it after the system is booted and everything is fine, but i really need this to run at startup. Can someone help me out?
[15:12] <babel> I don't think you will get some helpful information here. I asked some question like you a few days ago without any help. maybe you should try the mailling list next ...
[15:12] <drocko> rats
[15:12] <drocko> have you made an upstart job that has worked at boot?
[15:12] <drocko> I feel like im missing something that is probably obvious
[15:13] <drocko> like is there a command that you have to run to notify upstart that there are new scripts in /etc/init ?
[15:14] <babel> i tried to create a job that should be started before kvm shutdown (i would like to shutdown some kvm guest gracefully). i was able to run the job fine via an emit event, but I wasn't able to find a way to invoke the script before kvm was killed.
[15:15] <drocko> hm
[15:15] <drocko> dang
[15:17] <babel> drocko: no, this is done via inotify (and there you shouldn't need such a tool or command)
[15:17] <drocko> yeah that is what i figured
[15:18] <drocko> so let me ask you another question
[15:18] <babel> the upstart doc is somewhat ...
[15:18] <drocko> when upstart runs these jobs, it's running them as root, right?
[15:18] <babel> as fas as i know, yes.
[15:18] <babel> far
[15:19] <drocko> http://pastebin.com/d40ca71b9
[15:19] <drocko> this is my job
[15:19] <drocko> and it works, just not on boot
[15:20] <babel> start on stopped rc[2345] -> start on runleven[2345]
[15:21] <babel> runlevel
[15:21] <drocko> I'll try that
[15:21] <drocko> i dunno
[15:24] <drocko> wow, thanks babel. that worked!
[15:25] <drocko> also it means that this bullshit answer is totally wrong: https://answers.launchpad.net/upstart/+question/83223
[15:26] <babel> maybe.
[15:26] <drocko> yes
[15:26] <drocko> maybe
[15:26] <drocko> it's all voodoo
[15:26] <babel> now, better docs would help.
[15:26] <drocko> yeah, you know it's the same problem with grub2
[15:26] <drocko> like
[15:26] <babel> and something to make a dry-run
[15:26] <drocko> people think that a wiki would like really be great for documentation
[15:26] <drocko> because everyone could read it and contribute
[15:27] <drocko> but really it turns into like
[15:27] <babel> if the wiki is up to date that's true but.
[15:27] <drocko> a collection of cryptic notes
[15:27] <drocko> right
[15:27] <drocko> that are out of date
[15:28] <Keybuk> the trouble is, very few people are good at writing good documentation :)
[15:29] <Keybuk> danderson: the difference is how many forks upstart expects ;)
[15:29] <Keybuk> "expect fork" means Upstart counts one fork()
[15:29] <Keybuk> "expect daemon" means Upstart counts two fork()s
[15:29] <danderson> aaah.
[15:29] <danderson> I see.
[15:29] <Keybuk> to "properly" daemonise, a process needs to fork twice
[15:29] <danderson> so, this daemon I have isn't actually daemonizing properly, just forking into the background
[15:29] <Keybuk> of course, most things don't properly daemonise, so just "expect fork" is enough
[15:30] <danderson> right, I know; I assumed that the author of the software knew that as well :-)
[15:30] <Keybuk> the fact you need to be careful is because we use ptrace() to track this stuff
[15:30] <Keybuk> which is so less than ideal it's not even funny
[15:30] <danderson> (I'm just building an ubuntu package for his software, and writing the appropriate upstart config)
[15:30] <danderson> ouch ptrace().
[15:31] <danderson> but yeah, I don't see any other way to figure that out :(
[15:31] <Keybuk> there are some good new ways
[15:31] <Keybuk> kernel proc events and stuff
[15:32] <danderson> hmm, is the wiki read/write?
[15:32] <Keybuk> yes
[15:32] <danderson> perhaps I should try to start a "configuration writing manual" with some of this knowledge
[15:32] <sadmac> Keybuk: kernel proc events? Is that something new? reading material?
[15:33] <Keybuk> sadmac: proc connector, proc events, proc stats
[15:33] <Keybuk> just different names for the same thing
[15:33] <sadmac> Keybuk: ah
[15:35] <danderson> oh, and also, while people are around: woot upstart, thank you for building it! It's so much saner than futzing with init scripts it's unbelievable.
[15:39] <drocko> hm
[15:39] <drocko> alright so next challenge. my job runs at boot, but it needs to have the network up and running for it to be successful. how can i build in a dependency like that?
[15:42] <babel> try start on net-device-up
[15:43] <drocko> should i remove the start on runlevel [2345] or should I use both?
[15:43] <drocko> like start on (runlevel [2345]
[15:43] <drocko> and net-device-up)
[15:43] <drocko>  ?
[15:45] <babel> just start on net-device-up
[15:45] <babel> since you only depend on these event.
[15:46] <drocko> alright let's see what happened
[16:18] <drocko> babel2: thanks for the help. i think I got it sorted
[16:18] <babel2> no problem, share your knowlegde next time with some newbie :)
[16:19] <drocko> yeah definitelty
[16:19] <drocko> upstart is cleaner than like launchd on OS X and makes a little more sense than svcs on solaris, but like the documentation has to get there
[16:19] <drocko> Maybe i'll add what i've found to the wiki
[17:28] <mbiebl> Keybuk: around?
[17:29] <Keybuk> yus
[17:29] <mbiebl> having a problem with karmic and bridge devices
[17:30] <mbiebl> the system in question has two bridge devices configured
[17:30] <mbiebl> which are attached to kvm instances
[17:30] <Keybuk> yeah they don't work
[17:30] <mbiebl> ah, ok
[17:31] <mbiebl> seems the libvirt-bin init script tries to start the kvm instances beforce br0 and br1 are up
[17:32] <Keybuk> yes
[17:32] <mbiebl> Keybuk: is there a solution available?
[17:32] <Keybuk> actually nothing brings up br0 and br1
[17:32] <Keybuk> not that I know of
[17:33] <mbiebl> well, the devices are available after some time and if I add a sleep 30 inside the libvirt-bin init script, I can get it to work
[17:33] <mbiebl> this is of course fugly
[17:57] <wasabi> is there an event when br* comes up?
[17:57] <wasabi> net-device-added seems to be setup
[17:59] <ion> net-device-up, /etc/network/if-up.d/upstart
[17:59] <wasabi> ahh there iti s
[17:59] <wasabi> was wondering who was emitting it
[17:59] <mbiebl> I havea network-interface (br0) start/running
[17:59] <mbiebl> and the same for br1
[17:59] <wasabi> I'm kind of working on the same, with init scripts for virtualbox.
[18:00] <wasabi> Haven't yet tackled this. ;0
[19:33] <mbiebl> Keybuk: still around?


[03:23] <marcoagpinto> Morning!
[03:24]  * sarnold hides the soda
[03:31] <marcoagpinto> sarnold
[03:31] <marcoagpinto> !!!
[03:31] <marcoagpinto> what are you doing up at 3am?
[03:31] <sarnold> hi and bye marcoagpinto :)
[03:31] <marcoagpinto> ahhh
[03:31] <marcoagpinto> bye
[03:31] <marcoagpinto> take care
[03:31] <sarnold> heh, it's 1931 here, I'm just about to go cook dinner
[05:48] <lotuspsychje> good morning
[06:22] <marcoagpinto> hey hey hey
[06:22] <marcoagpinto> I am working on LanguageTool
[06:22] <marcoagpinto> I have a bug in the code
[06:22] <marcoagpinto> :)
[06:22] <marcoagpinto> trying to fix it
[06:23] <marcoagpinto> yesterday a guy told me: "c|_| care cup is empty"
[06:23] <marcoagpinto> :(((((((
[08:56] <ducasse> good morning
[08:56] <marcoagpinto> heya
[17:24] <badsektor> hey guys
[17:24] <lotuspsychje> hey welcome
[17:25] <badsektor> so what other distroes do you like?
[17:26] <badsektor> i am on a Mac right now
[17:26] <lotuspsychje> i also like ubuntu on macs
[17:26] <badsektor> i just realized that it has a terminal and its runs zsh
[17:27] <badsektor> no it is macOS
[17:27] <badsektor> did you know macOS has a terminal with zsh?
[17:27] <badsektor> i installed gcc
[17:27] <badsektor> to play with Advent of Code
[17:28] <badsektor> it is a Macbook Air
[17:36] <Maik> so far for a quality Ubuntu discussion
[17:36] <lotuspsychje> :p
[17:37] <lotuspsychje> in other news; https://www.omgubuntu.co.uk/2022/01/gnome-42-new-look-osd
[18:00] <Maik> yeah, already saw that. How you feel about it lotuspsychje?
[18:01] <lotuspsychje> might be good to have a slicker look
[18:02] <lotuspsychje> the most of hotkeys i use are my keyboard leds
[18:02] <Gallomimia> it's back! the splash screen that had my motherboard
[18:02] <Gallomimia> brand and Ubuntu is back
[18:02] <lotuspsychje> and that doesnt showup on gnome
[18:02] <Gallomimia> i saw it only once when i installed 21.10 clean, and then never again. but what caused this?
[18:02] <lotuspsychje> wich brand is that Gallomimia
[18:02] <Gallomimia> gigabyte
[18:03] <Gallomimia> it's obviously caused by something in the updateramfs
[18:03] <lotuspsychje> not all brands will show
[18:03] <lotuspsychje> clevo doesnt for example
[18:04] <Gallomimia> well i was going to come and ask about it a few days ago. why it's gone and never to be seen again
[18:04] <Gallomimia> i saw this different splash only one time. the proportions were different than usual too, making it look better
[18:05] <Maik> lotuspsychje: depends if you use UEFI and Secureboot iirc.
[18:54] <ogra> lotuspsychje, clevo isnt a brand, they produce whitebox devices for re-sellers to re-brand
[18:55] <lotuspsychje> i know ogra i sell them :p
[18:55] <ogra> and yeah, vendor logo needs UEFI boot (not necessarily secboot though)
[18:55] <ogra> heh


[15:21] <arraybolt3> Is it just me, or has Lunar not gotten a kernel update for a while? I don't think I've updated my kernel even once since I installed this system...
[15:23] <arraybolt3> apt-cache seems to be telling me that I have the latest kernel installed though. Maybe there's just not been a problem with the kernel for a while.


[14:59]  * vorlon waves
[14:59] <bdrung> \o
[14:59] <jawn-smith> o/
[15:00] <zhsj> o/
[15:00] <dbungert> o/
[15:00] <ogayot> o/
[15:00] <slyon> o/
[15:00] <schopin> o/
[15:01] <jawn-smith> #startmeeting Weekly Ubuntu Foundations team
[15:01] <meetingology> Meeting started at 15:01:03 UTC.  The chair is jawn-smith.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[15:01] <meetingology> Available commands: action, commands, idea, info, link, nick
[15:01] <dviererbe> o/
[15:02] <jawn-smith> The weekly status is here: https://discourse.ubuntu.com/t/foundations-team-updates-thursday-16-march-2023/34547
[15:02] <jawn-smith> let's all take our usual time to read and ask questions
[15:03] <slyon> vorlon: rendering of https://ubuntu-archive-team.ubuntu.com/component-mismatches-proposed.svg seems to be broken. I assume that might be related to the server migration you mentioned in your report?
[15:03] <jawn-smith> schopin: lol, just saw the glibc issue
[15:03] <vorlon> slyon: I'm seeing a truncated SVG, are you seeing the same?
[15:04] <slyon> ye
[15:04] <slyon> yes
[15:04] <vorlon> slyon: it *might* be related.  I'll dig into it today
[15:04] <slyon> thanks!
[15:05] <schopin> jawn-smith: I was inspired by Steve naming it "best bug report ever" ;)
[15:05] <vorlon> it's not bad timing of the rsync from the backend to the frontend, the truncation is present on the backend
[15:07] <bdrung> The best bug report ever is still "OpenOffice.org does not print on Tuesdays" for me (LP #248619)
[15:07] -ubottu:#ubuntu-meeting- Launchpad bug 248619 in file (Ubuntu Karmic) "file incorrectly labeled as Erlang JAM file (OOo does not print on Tuesdays)" [High, Fix Released] https://launchpad.net/bugs/248619
[15:08] <schopin> Ooooh that one is really good, yes!
[15:08] <vorlon> yes, my bug is best on a different axis
[15:08] <vorlon> "how to do maximally unsafe safe string handling"
[15:09] <schopin> "but at least you're not using sprintf"
[15:09] <jawn-smith> #topic Release incoming bugs
[15:09] <jawn-smith> #link https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ll-incoming-bug-tasks.html#foundations-bugs
[15:09] <vorlon> dviererbe: you talk about doing alternatives for ping. why is this necessary or desirable?
[15:10] <jawn-smith> I'll wait for bugs until that's answered
[15:11] <dviererbe> the autopackagetests of inetutils fail because inetutils tries to install inetutils-ping and that tries to uninstall iputils-ping which tries to uninstall ubuntu-minimal
[15:11] <slyon> vorlon: https://autopkgtest.ubuntu.com/packages/inetutils is failing all autopkgtests due to ping install conflict
[15:11] <slyon> iputils-ping (main) vs inetuils-ping (universe)
[15:11] <vorlon> dviererbe, slyon: ok I think introducing alternatives and adding runtime complexity across packages is a bad solution to this, I'd frankly just remove the autopkgtest and/or stop building inetutils-ping
[15:14] <zhsj> vorlon: this option was on the table. the disadvantage is we'll carry the delta with debian. (but i vote for it)
[15:15] <jawn-smith> bug 1999062
[15:15] -ubottu:#ubuntu-meeting- Bug 1999062 in orc (Ubuntu) "orc build test failure on arm64" [High, New] https://launchpad.net/bugs/1999062
[15:15] <jawn-smith> I believe that we've discussed this one before
[15:15] <zhsj> jawn-smith: isn' desktop
[15:16] <zhsj> isn't this under desktop-packages
[15:16] <jawn-smith> oh wow I totally typed in from the wrong list
[15:16] <jawn-smith> There actually aren't any foundations bugs ll
[15:16] <jawn-smith> Good job
[15:16] <jawn-smith> none in kk either
[15:17] <jawn-smith> #link https://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-jj-incoming-bug-tasks.html#foundations-bugs
[15:17] <jawn-smith> there's one!
[15:17] <jawn-smith> bug 1999345
[15:17] -ubottu:#ubuntu-meeting- Bug 1999345 in grub2 (Ubuntu) "please add luks2 module to the signed grub2 images" [Undecided, Confirmed] https://launchpad.net/bugs/1999345
[15:17] <jawn-smith> no updates from security team since january
[15:17] <jawn-smith> So juliank: anything for us to do?
[15:17] <juliank> no
[15:17] <jawn-smith> Awesome, let's move on then
[15:18] <jawn-smith> #topic proposed-migration
[15:18] <vorlon> things looking much healthier!
[15:18] <jawn-smith> #link https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs
[15:18] <jawn-smith> vorlon:
[15:18] <vorlon> waveform: are you still taking care of sbuild?
[15:19] <vorlon> shim-signed: nothing to do, still waiting for kernel updates
[15:20] <vorlon> ogayot: is systemd vs xz-utils on you?
[15:21] <ogayot> xz-utils is still with me. systemd came up as a new regression. I'll have a look. But don't restrain from assigning me an additional proposed-migration
[15:21] <vorlon> waveform is out, but this is still with him
[15:21] <vorlon> ack
[15:22] <slyon> ogayot: I think systemd vs xzutils actually passed on my last retry
[15:22] <vorlon> python3-stdlib-extensions breaks python3.10; I think this is going to shake out via removal of python3.10 which is supposed to happen after nvidia-cuda-toolkit update
[15:22] <vorlon> ginggs: will you follow through on this?
[15:22] <ginggs> python3.10 already removed
[15:22] <vorlon> ok then perhaps just a bit of hinting
[15:22] <ginggs> python3.11, stdlib-extensions and python3-defaults
[15:22] <dviererbe> I have noticed that the pycurl regression I was assigned to is gone https://autopkgtest.ubuntu.com/packages/pycurl
[15:23] <ginggs> should migrate soon
[15:23] <vorlon> ginggs: you'll follow through if not?
[15:23] <ginggs> sure
[15:23] <vorlon> jawn-smith: you still working e2fsprogs?
[15:23] <ogayot> vorlon: indeed, it passed, thanks
[15:23] <jawn-smith> Yes
[15:23] <vorlon> ginggs: tangentially, does new nvidia-cuda-toolkit fix python3-pycuda uninstallability (due to conflicts)?
[15:23] <jawn-smith> It's a non-trivial regression, just been focused on getting a few ubuntu-image PRs open before I do a deep dive
[15:23] <bdrung> can we build pycurl for i386 as well (to get rid of the devscripts diff)?
[15:24] <vorlon> I don't know, ask on #ubuntu-release after :)
[15:24] <ginggs> vorlon: yes, it looks like pycuda migrated earlier
[15:24] <vorlon> ginggs: great!
[15:24] <ginggs> i think there's a bug in the nvidia drivers though
[15:25] <ginggs> packages shouldn't be getting a dependency on the particular version of the driver they were built against
[15:25] <ginggs> this used to work, but seems something has gone wrong
[15:26] <vorlon> juliank: grub2 has uninstallable binaries which is surprising, can you follow up on this?
[15:26] <juliank> Not entirely surprising the grub2-unsigned upload isn't ready yet
[15:26] <juliank> Will resolve
[15:26] <vorlon> ah
[15:27] <vorlon> adrien: you uploaded openssl, will you follow through on the blocking regressions?
[15:27] <vorlon> oops adrien is out; well, I'll assume this is with him
[15:28] <vorlon> openssl: adrien
[15:29] <vorlon> bdrung: can you take libzstd?
[15:29] <vorlon> and then curl is just waiting for libreoffice tests - so that's it
[15:29] <bdrung> devscripts would probably suite me better
[15:29] <vorlon> if anyone is keen to help and didn't get an assignment, since adrien is out today/tomorrow you could prod openssl along
[15:29] <vorlon> bdrung: ok you can have devscripts
[15:30] <vorlon> dbungert: can you take libzstd?
[15:30] <dbungert> vorlon: ack
[15:30] <vorlon> thanks
[15:30] <vorlon> that's everything
[15:30] <vorlon> jawn-smith: back to you
[15:30] <ginggs> i'll prod openssl
[15:30] <jawn-smith> #topic AOB
[15:30] <bdrung> tzdata says: old binaries left on amd64: tzdata-right
[15:30] <bdrung> Do I need to request the removal?
[15:31] <vorlon> bdrung: you just did
[15:31] <bdrung> thanks vorlon
[15:32] <doko> is something known with the state of the buildds? I have a 60+h build which always finishes without logs
[15:32] <doko> llvm-16
[15:33] <vorlon> not that I've heard
[15:38] <jawn-smith> #endmeeting
[15:38] <meetingology> Meeting ended at 15:38:28 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-03-16-15.01.moin.txt
[15:41] <adrien> ginggs: thanks; most issues seem to just require new triggers


[03:20] <pleia2> I'll work on releasing soon
[03:22] <pleia2> alas, no other editors pitching in today, again :\
[04:37] <jose> pleia2: let me take a look real quick
[04:38] <pleia2> jose: thanks
[04:38] <pleia2> packing for scale, so much chaos over here
[04:38] <jose> I started packing as well
[04:38] <jose> anything you want me to bring from here?
[04:39] <pleia2> I don't think so
[04:39] <pleia2> I never asked Debra if she's sending any Ubuntu Book copies
[04:40] <jose> uh right, I forgot as well
[04:40] <jose> I'll ask her if she's gonna be there, she can probably bring some with her
[04:40] <pleia2> she's not :'(
[04:40] <pleia2> probably good, I owe her another book, haha
[04:40] <jose> oh! literally just pressed enter
[04:40] <pleia2> lol
[04:40] <pleia2> someone from pearson may be there
[04:41] <jose> I think a copy laying around here, I'll see if I can bring it
[04:41] <jose> otherwise, no books for us :(
[04:42] <pleia2> I have 3 copies left, so I can probably part with one
[04:51] <jose> ok, review done
[04:51] <jose> I've fixed a couple grammar thingies
[04:54] <pleia2> thanks
[04:54] <jose> glad to help :)
[06:25] <pleia2> ugh, still not released, got pulled into other things, will hopefully do soon
[06:29] <jose> pleia2: want me to release?
[06:31] <pleia2> jose: no, I've been looking forward to doing 450
[06:31] <jose> oooooh, I didn't notice we were in 450
[06:31] <jose> go ahead :)
[06:31] <jose> I'll go to bed, just checked in :)
[07:30] <pleia2> Welcome to the Ubuntu Weekly Newsletter, Issue 450 for the week January 11 - 17, 2016 https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue450