[00:07] <arraybolt3[m]> I'd think it was just my VM environment if it wasn't for the file names of the .efi files. I should also download an ISO that does ship the 32-bit EFI files and see if that works in the VM (I think Fedora does that?)
[00:08] <arraybolt3[m]> Yeah, Fedora has a "BOOTIA32.EFI" file in there along with other ia32 files.
[00:09] <kc2bez[m]> Yeah, good idea
[00:16] <arraybolt3[m]> Fedora is trying to boot at least. It's hanging early in the boot process, but the bootloader starts and is able to load the kernel and initrd and kick off the boot process.
[00:19] <tsimonq2> Sup guys
[00:19] <arraybolt3[m]> Simon Quigley (Developer): Not too bad, how 'bout you?
[00:19] <arraybolt3[m]> Simon Quigley (Developer): Fighting with an EFI bug ATM.
[00:20] <tsimonq2> arraybolt3[m]: Towards the tail end of the personal stuff going on, getting there... thanks
[00:20] <tsimonq2> arraybolt3[m]: Oh nice, you found the only difficult part of our Cala settings package >:P
[00:20] <arraybolt3[m]> Simon Quigley (Developer): Worse than that. Found a mess in the ISO build itself.
[00:21] <tsimonq2> Last time I touched that I chugged about two or three monsters. I understood that code exactly once. I do apologize for my messiness. :P
[00:21] <tsimonq2> arraybolt3[m]: Which stage?
[00:21] <arraybolt3[m]> Dan Simmons: Fedora boots with 64-bit EFI, but it at least tries to boot with 32-bit EFI. Ubuntu won't even try.
[00:21] <arraybolt3[m]> Simon Quigley (Developer): GRUB bootloader.
[00:21] <kc2bez[m]> I guess it never worked?
[00:21] <tsimonq2> Oooooooh
[00:21] <kc2bez[m]> Weird
[00:21] <arraybolt3[m]> Simon Quigley (Developer): There aren't any 32-bit EFI files on the ISO, so 64-bit systems with a 32-bit EFI don't work.
[00:22] <arraybolt3[m]> (PCs like certain Asus EeePC's are therefore locked out of using Lubuntu.)
[00:22] <kc2bez[m]> Which was contrary to my memory. So much for that.
[00:22] <arraybolt3[m]> Dan Simmons: I'm not sure what's wrong, but my Fedora ISO won't even boot all the way on 64-bit EFI, and I even checked it for integrity 😦
[00:23] <arraybolt3[m]> I wonder if my VM config is messed up.
[00:24] <arraybolt3[m]> Even Lubuntu doesn't like it. OK, I botched something...
[00:25] <arraybolt3[m]> There we go, QXL graphics was the missing link.
[00:27] <arraybolt3[m]> But Fedora still doesn't work with my hybrid EFI. So I think Lubuntu is messed up, but a VM in my particular config isn't sufficient for testing this for real.
[00:31] <kc2bez[m]> That's fair. I'd hesitate to file a bug directly due to that. However if we get somewhere further on the Discourse thread we could have the OP file one.
[00:31] <arraybolt3[m]> Too bad. I really thought this trick would work.
[00:32] <kc2bez[m]> I thought you were on to something too.
[00:33] <arraybolt3[m]> The kernel just always hangs. Not panics, just hangs. Maybe it's something wrong with Fedora's kernel in particular, but I dunno.
[00:34] <arraybolt3[m]> (I guess maybe it's one of those situations where you have to let it sit for 10 minutes before it boots? I'll just leave it for a good long time and see if it works. I don't have high hopes, though.)
[00:36] <arraybolt3[m]> At any rate, Simon Quigley (Developer) I had a crazy night and only managed to get 1 PR properly made, but I'm on the verge of a second and third ready to be merged.
[00:36] <arraybolt3[m]> I have to go afk right now, but I'll be back to give the link in just a bit.
[00:58] <arraybolt3[m]> Simon Quigley (Developer): https://github.com/lubuntu-team/qtermwidget-packaging/pull/1
[01:41] <arraybolt3[m]> Dan Simmons: I just realized I wasn't properly following the directions for doing the EFI boot, so I'm going to try to actually do what the guide I was following said.
[01:43] <arraybolt3[m]> Nope, fail. Oh well.
[01:45] <arraybolt3[m]> Simon Quigley (Developer): https://github.com/lubuntu-team/lximage-qt-packaging/pull/1
[01:46] <arraybolt3[m]> Simon Quigley (Developer): If my PRs are bugging you, feel free to tell me to hold off and I'll just keep track locally.
 "Simon Quigley (Developer): If my..." <- sleep 12h && fullsend
[05:40] <arraybolt3[m]> Just leaving this here for whoever sees it next. The LXQt stack badly needs a full copyright file audit. This is going to be the second or third package I've had to totally rebuild the copyright file of, and I suspect I've probably missed some. I don't think there's any way I'm going to manage to do the whole backport and audit before our sprint on the 7th, so I'm not going to do that yet, but it needs done eventually.
[05:41] <arraybolt3[m]> (I mean, I'm going to try to finish the backport, and I think I'll succeed, but the audit on the copyright files will need to wait.)
[05:41] <guiverc> ack & thank you for your diligence arraybolt3[m]
[05:42] <arraybolt3[m]> No problem. Thank you!
[08:08] <arraybolt3[m]> (Something to consider, I just found a tool called FOSSology that may help immensely with copyright file updating and auditing. It's a Docker-based web app, I'm thinking of trying it out and if it works well on my end and would work well for everyone, maybe we can talk our friendly local chaotic sysadmin into setting up an instance for everyone to use?)
[08:11]  * guiverc smiles
[12:00] <arraybolt3[m]> Dan Simmons: Oh. My gosh. You are not going to believe this, I just got a mixed-mode EFI VM to boot. I had assigned too high of system specs (was doing 8GB RAM and 4 CPU cores), which I guess was confusing the EFI. I dropped down to 2 GB RAM and 1 CPU core, and I just got a Debian multiarch ISO to boot with 32-bit EFI on a 64-bit VM.
[12:04] <arraybolt3[m]> Oddly enough, the VM locks up if you use 2 CPUs. So mixed-mode EFI VMs have to be single-core AFAICT. But that means we can test it now, and if we can test it, we can hopefully make it work.
[12:05] <arraybolt3[m]> I've also confirmed that Lubuntu 18.10 does not work with mixed-mode EFI, even with a working VM config.
[12:20] <arraybolt3[m]> Lubuntu 19.04 also fails with mixed-mode EFI.
[12:25] <kc2bez[m]> Interesting.
[12:27] <arraybolt3[m]> (I do find it odd that QEMU can't pull off mixed-mode EFI with more than one CPU core when the Intel Atom CPUs used in this configuration appear to be 2- and 4-core chips...)
[12:27] <kc2bez[m]> I've got a strong feeling it will be hard to persuade folks to build iso's to support such an arrangement.
[12:28] <arraybolt3[m]> One Google search reveals that there's a lot of people out there who would benefit from having this work. Which makes me hopeful, at least.
[12:30] <arraybolt3[m]> I mean, it can't hurt to try and write a bug report, right? I could also start a conversation on #ubuntu-discuss and see what people think.
[12:31] <kc2bez[m]> It can't hurt.
[12:32] <arraybolt3[m]> OK. I'll save it for after the sprint we're planning so I can spend more time on things that for sure matter.
[12:32]  * arraybolt3[m] just figured out what terminal my SSH instance was running in... 🤦♂
[12:33] <kc2bez[m]> arraybolt3[m]: That makes sense. I am curious to see what others think too.
 "sleep 12h && fullsend" <- Ready to fullsend whenever you're ready to fullreceive.
[17:26] <arraybolt3[m]> There's only 8 packages left to be backported! We're almost there!
[17:26] <nteodosio> Looking at bug 1977465, which proposes to change #debian to #lubuntu in the default configs, what about users of other variations of Ubuntu (say default Ubuntu or Kubuntu)? Do we assume that since the program is a Qt one, we can simply consider it "belongs" to Lubuntu?
[17:27] <arraybolt3[m]> nteodosio: That's a good point, Ubuntu Studio also ships with Quassel. I'm not sure if there's a separate config package or not.
[17:28] <Eickmeyer[m]> There isn't.
[17:28] <arraybolt3[m]> A quick apt-cache search reveals that there does not appear to be separate config packages.
[17:28] <arraybolt3[m]> Eickmeyer: Beat me to it.
[17:28] <nteodosio> Would it be a good compromise then to connect to both #ubuntu and #lubuntu?
[17:29] <nteodosio> Or #ubuntu-studio, better said?
[17:29] <Eickmeyer[m]> *#ubuntustudio
[17:29] <arraybolt3[m]> nteodosio: That's probably for Eickmeyer and Simon Quigley (Developer) to decide, they're the distro leads who ship Quassel. But having anything distro-specific shipping in Quassel seems like a bad idea to me, since people using other flavours might also install Quassel.
[17:29] <Eickmeyer[m]> Easier said than done.
[17:30] <arraybolt3[m]> Random idea - create config packages for Quassel sorta like how we do for calamares-settings-ubuntu, and have each one have flavour-specific config? So have Quassel ship with #ubuntu by default and then have the config packages add #lubuntu to Lubuntu and #ubuntustudio to Ubuntu Studio?
[17:31] <Eickmeyer[m]> arraybolt3: Again, easier said than done. It would have to overwrite Debian's config.
[17:31] <arraybolt3[m]> Ouch.
[17:31] <arraybolt3[m]> (That would mean we'd be looking at three additional packages at a minimum, plus an Ubuntu delta? Yikes.)
[17:31] <Eickmeyer[m]> Yep.
[17:32] <arraybolt3[m]> #ubuntu supports all the flavours, and is where most of the action is, so it would probably be easiest and best to make Quassel point to #ubuntu by default. Then we only have an Ubuntu delta to manage.
[17:32] <Eickmeyer[m]> And then taking over maintainership, meaning constant monitoring of the upstream.
[17:33] <Eickmeyer[m]> One of the reasons Ubuntu Studio ships Quassel by default is because Konversation is hard-patched to go to #kubuntu by default. I wasn't happy about that, so Quassel it was.
[17:33] <nteodosio> arraybolt3[m]: I agree with that. TBH I think the right thing is to join no default channel.
[17:34] <Eickmeyer[m]> nteodosio: I agree with that approach over the default channel approach. It's relatively trivial to add a server, and one can simply ask the upstream to add a libera configuration.
[17:35] <arraybolt3[m]> Eickmeyer: That's a good idea, that allows us to shift the responsibility for maintainership to Debian if they're willing to accept it.
[17:36] <arraybolt3[m]> (But even if they don't accept it, one tiny Ubuntu delta won't be too much to deal with, just throw it in as a Quilt patch, right? If this sounds insanely ignorant, that's because is probably is...)
[17:36] <Eickmeyer[m]> Yeah, we have a tiny ubuntu delta now for whatever reason. It didn't used to be that way, but it is now.
[17:36] <Eickmeyer[m]> Looks like it's due to an apparmor profile.
[17:39] <nteodosio> Eickmeyer[m]: Not sure if this is clear, but the behavior of joining #debian is in a debian/patches. If we are syncing the package from Debian, adding Libera upstream doesn't avoid a delta, does it?
[17:40] <Eickmeyer[m]> It doesn't. I might be able to remove the patch (if it's a patch), but doing an SRU on something this trivial seems like a lot of work for something so silly.
[17:41] <Eickmeyer[m]> I mean, as an Ubuntu Studio seeded component, I'm within my rights to do it.
[17:41] <arraybolt3[m]> Eickmeyer: We have backports. Not that that's the ideal solution, but it might be less work than a full-on SRU.
[17:42] <Eickmeyer[m]> arraybolt3: Backports is kinda reserved for less-than-trivial things, like full-fledged version updates and stuff like that.
[17:43] <Eickmeyer[m]> Yeah, it's a patch. That's annoying. Ugh.
[17:43] <arraybolt3[m]> Eickmeyer: Hmm. K. And we can't use PPAs - why does it seem like fixing paper-cut bugs can be like navigating the inside of an nVidia mystery...
[17:43]  * Eickmeyer[m] reluctantly prepares an SRU
[17:44]  * arraybolt3[m] yawns and goes back to fighting with the LXQt stack backport
[17:45] <nteodosio> I'm curious to find what will come into the "regressions potential" section of it :)
[17:46] <arraybolt3[m]> nteodosio: I guess it might cause the people who actually use #debian to open Quassel one day and be like, "Ey! Where'd my channel go? /join #debian" and that would be the end of it.
[17:47] <Eickmeyer[m]> nteodosio: HAHAHAHAHA I've made sillier regression potential sections. I did one with a plasmoid one-line change to have it re-run a shell script in case of a failure that said, "I mean, I suppose it could completely crash Plasma, but that seems unlikely as the script literally just ran prior to being run again."
[17:48] <arraybolt3[m]> Regression potential: This could cause your computer to burst into flames, but only if there's a serious hardware fault that should have lit it up months ago.
[17:48] <nteodosio> arraybolt3[m]: Technically not a regression though, just an upset user. But I think users of IRC know better, that's why I would say the Debian patch is not warranted.
[17:49] <arraybolt3[m]> nteodosio: Well, I get the idea of making live chat support a hardwired feature. Not everyone knows what IRC is, they just know they can get chat support for their OS through it. You don't want to figure out how to configure an IRC client when your OS is busy having the time of its life without regard to what you want it to do.
[17:50] <arraybolt3[m]> Thus why I'm for including #ubuntu by default.
[17:50] <nteodosio> arraybolt3[m]: Convinced!
[17:51] <arraybolt3[m]> I get both sides though, and I could live with either.
[17:51] <Eickmeyer[m]> Meh, I can change the patch to #ubuntu on libera pretty easily.
[17:51] <Eickmeyer[m]> I mean, it'd be trivial.
[17:51] <arraybolt3[m]> As it is, a user goes to get live chat support, stumbles into Debian with a Lubuntu question, figures out how to register a nick, gets told to go to #ubuntu, and then has to figure out how to configure their IRC client.
[17:52] <nteodosio> Eickmeyer[m]: That what I was thought when I found the bug =P
[17:52] <nteodosio> arraybolt3[m]: Yeah, it's good to put oneself in newcomers shoes
[17:53] <Eickmeyer[m]> The regression potential will be something like, "Users of Ubuntu who think they're on a Debian system might be irked they're no longer going to Debian support, but this is not likely."
[17:53] <arraybolt3[m]> nteodosio: Double take here, you found KGIII's bug, or you are KGIII?
[17:54] <arraybolt3[m]> Eickmeyer[m]: That would be like saying "Pop!_OS users might be annoyed that they're no longer being told their in the wrong channel when they come into #ubuntu."
[17:54] <arraybolt3[m]> (That's a compliment on the humor value, btw.)
[17:54] <Eickmeyer[m]> Hehehe
[17:55] <arraybolt3[m]> And people who are Ubuntu users but offer Debian support in #debian should be knowledgeable enough to get their IRC client back to where it was.
[17:56] <Eickmeyer[m]> arraybolt3: And to the right network (OFTC).
[17:56] <arraybolt3[m]> True.
[17:56] <nteodosio> arraybolt3[m]: Not KGIII, I found the report when I were on my way to report another one.
[17:59] <nteodosio> Eickmeyer[m]: Ha, while you are at it, you may well as see bug 1872204.
[17:59] <nteodosio> Bottom line: There's no such thing as satisfacting everyone
[18:00] <Eickmeyer[m]> WTF?
[18:00] <arraybolt3[m]> He suggested #ubuntu as the right option too.
[18:01] <Eickmeyer[m]> Yeah, so, I'm going to "Won't Fix" on kubuntu-settings, lubuntu-default-settings, and dup that to the SRU I'm writing for quassel.
[18:02] <Eickmeyer[m]> He's on the bug triage team too and should know better.
[18:02] <Eickmeyer[m]> Of course, he's not a packager, so there's that.
[18:05] <nteodosio> Sorry, what should he know better? Are you refering to the reporter?
[18:05] <Eickmeyer[m]> nteodosio: Yes, but I could be wrong.
[18:06] <Eickmeyer[m]> https://bugs.launchpad.net/ubuntu/+source/quassel/+bug/1980687 in progress
[18:06] <kc2bez[m]> Sorry I am late to the party but I think #ubuntu makes sense. It is at least on  the right network.
[18:07] <Eickmeyer[m]> kc2bez[m]: Working on the patch/upload right now. Should have it to Kinetic soon and queued for Jammy soon as well awaiting SRU approval.
[18:07]  * Eickmeyer[m] is fast on these SRUs, has practice
[18:11] <nteodosio> Eickmeyer[m]: Out of curiosity, why didn't you add the SRU to the original bug report?
[18:11] <Eickmeyer[m]> nteodosio: I already had the original SRU written, so it was too late, and the original bug report was against Focal, not Kinetic or Jammy.
[18:12] <Eickmeyer[m]> I'm not going to SRU to Focal.
[18:12] <Eickmeyer[m]> Focal has < 1 year of support left (9 months, actually).
[18:15] <kc2bez[m]> I agree kinetic and jammy make sense
[18:19] <kgiii> Ah, y'all are gonna fix the bug in Quassel. That'll be nice.
[18:20] <kgiii> The config from the previous version should fix it, but I am not a developer. I just find your bugs.
[18:21] <Eickmeyer[m]> kgiii: The problem is that both Ubuntu Studio and Lubuntu are seeding it, so pointing to #lubuntu doesn't cut it anymore.
[18:21] <Eickmeyer[m]> So, I'm fixing it to point to #ubuntu.
[18:22] <kgiii> It should point to Lubuntu - or it did.
[18:22] <Eickmeyer[m]> It did, but again, that's not a good idea anymore.
[18:22] <kgiii> It used to point you to #lubuntu - on the proper server.
[18:23] <arraybolt3[m]> kgiii: Ubuntu Studio ships Quassel by default, we don't want it pointing to #lubuntu:libera.chat .
[18:23] <Eickmeyer[m]> kgiii: I'm the flavor lead for Ubuntu Studio. You're not reading what I'm saying, are you?
[18:24] <kgiii> That's just a hassle all around. That's not very helpful. The user will be told to join another channel to get support. Surely there's a better choice.
[18:25] <arraybolt3[m]> kgiii: #ubuntu supports all flavours, Lubuntu and Ubuntu Studio included.
[18:25] <kgiii> If that were accurate, we'd have no need for #lubuntu.
[18:28] <arraybolt3[m]> kgiii: Not true, many problems with Ubuntu flavours can be solved in the main chat. It's only where you get into the specifics (like a KDE issue or an LXQt issue) that the main channel starts to not be so great. If we don't want to do a boatload of work, and want to give users the best experience possible, this is the best solution. Ideal? No. But close, and it doesn't take a monumental effort.
[18:31] <kgiii> So, rather than send 'em to the people that know Lubuntu best, you're going to waste new user's time and add confusion instead of doing a 'boatload of work'? Is it possible to package flavor-specific versions of Quassel?
[18:32] <arraybolt3[m]> kgiii: That's what I suggested, but that would be a monumental amount of work. Being in "developer-in-training" land, I just showed up here and my plate is already full up and falling over, so factoring in our own workloads is important.
[18:33] <Eickmeyer[m]> kgiii: I need to remind you that everyone who works on Ubuntu Studio and Lubuntu is a volunteer; everyone is devoting their time to do it, nobody is paid to do it. Carrying an attitude like that is very offputting. We want to minimize the amount of time we have to take care of packaging things. Packaging two versions of the same application in the same archive is also not allowed.
[18:34] <kgiii> Sorry if it's off-putting, but this hasn't been a problem for the year or so that we've had it like this. Maybe I'm underestimating the time it'd take to do this differently?
[18:35] <Eickmeyer[m]> You're greatly underestimating the time and effort it takes to do this.
[18:35] <kgiii> My main concern is the end-user's experience. I don't want them to have a bunch of friction to learn/appreciate Linux.
[18:35] <arraybolt3[m]> kgiii: It would take a lot of time initially, but then additionally, it would make us the maintainers of the extra packaging, which would result in an extra continuous workload, overall reducing the time we have for more important things and lowering the quality of the distros. No one wants that.
[18:36] <arraybolt3[m]> kgiii: I've seen plenty of Kubuntu people in #ubuntu, and things go just fine. I think I redirected one guy once. Plus, when we're pointing to the right server, switching channels is as easy as "/join #lubuntu" and you're done, as opposed to "reconfigure IRC server, reg nick, figure out what I'm looking at in the settings, then /join #lubuntu.
[18:36] <arraybolt3[m]> (And I'm not sure I should have redirected that one guy.)
[18:37] <kgiii> If there's no other choice, there's no other choice - but it's gonna suck for at least a subset of people who are trying to get help - and not just with Lubuntu, but also with Ubuntu Studio.
[18:37] <arraybolt3[m]> kgiii: You might look at the #ubuntu support channel, it's not as bad as you think. I'm there very frequently, and things go just fine.
[18:38] <kgiii> I think you overestimate the skills of new users and the familiarity people have with IRC. Folks aren't familiar with IRC anymore. Again, if this is how it must be then it must be.
[18:38] <kgiii> I'm in there right now - I read it most every day.
[18:38] <kgiii> I've done so for quite a while now. (I don't help, but I skim through.)
[18:53] <Eickmeyer[m]> Here's the other thing: What if someone, other than a Lubuntu or Ubuntu Studio user, wishes to install Quassel? It's not a Lubuntu package or an Ubuntu Studio package. Neither team owns it. It should be as generic as possible.
[18:53] <Eickmeyer[m]> Anyhow, kinetic and jammy packages uploaded. Kinetic should be done soon, awaiting SRU approval for Jammy.
[18:54] <nteodosio> So are some packages owned by particular teams?
[18:54] <Eickmeyer[m]> In the Ubuntu world? Not really.
[18:55] <nteodosio> So the statement "neither team owns it" is always true?
[18:55] <Eickmeyer[m]> Generally speaking, yes.
[18:56] <nteodosio> Is there a package that you'd say "this is Lubuntu's", apart from config ones?
[18:56] <Eickmeyer[m]> However, some teams have "ownership" of certain things. Such as the Lubuntu team has the LXQt components.
[18:56] <arraybolt3[m]> Some teams do watch over certain packages more than others (for instance, Lubuntu generally babies LXQt), but anyone could install LXQt on their system if they wanted to and knew enough.
[18:56] <arraybolt3[m]> Eickmeyer: How do you keep beating me to stuff? I type 90+ WPM!
[18:56] <Eickmeyer[m]> And Ubuntu Studio generally babies the Multimedia packages.
[18:56] <Eickmeyer[m]> arraybolt3: I'm quick too.
[18:57] <arraybolt3[m]> LOL
[18:57] <arraybolt3[m]> Fair.
[18:58] <nteodosio> I really can't keep up with you two. Have to be really fast or the message I'm responding to drifts away
[18:58] <nteodosio> (Exaggerated, but still :)
[18:59] <arraybolt3[m]> nteodosio: If you're on Matrix, there's a little "Reply" button you can use to keep track of what you're talking about and who you're talking to. I use Element as my Matrix client.
[18:59] <nteodosio> Ah, I'm on (guess what?) Quassel
[18:59] <Eickmeyer[m]> I'm a MOTU (master-of-the-universe, gives me upload privs to Universe and Multiverse), which means that, while I'm on the Ubuntu Studio team and the Kubuntu team, I can jump-in and help with other teams when I'm needed. Case in point: this quassel issue and the calameres issues from time-to-time.
[19:00] <nteodosio> Talk about a cool title!
[19:00] <arraybolt3[m]> nteodosio: Well then good luck and type fast :)
[19:01] <arraybolt3[m]> (OK, that's a joke.)
[19:01] <arraybolt3[m]> (The type fast thing, I mean.)
[19:01] <nteodosio> lol yeah I got it
[19:02] <arraybolt3[m]> Agreed, it is a cool title. I still feel weird in the middle of people who do all this stuff when I'm not even to Lubuntu Member yet (though I'm reaching for it).
[19:02] <Eickmeyer[m]> Yeah, I have a few different hats/titles with Ubuntu.
[19:03] <nteodosio> arraybolt3[m]: I think everyone starts at that point
[19:03] <nteodosio> It's part of the process, right?
[19:03] <arraybolt3[m]> You've got MOTU, Simon's got Core Dev and Debian Developer, Chris has Lubuntu Council and Ubuntu News, and yet you're fine with training someone who has... Lubuntu contributor? That's not even a title.
[19:03] <arraybolt3[m]> Thank you all.
[19:03] <arraybolt3[m]> (And Dan's got Lubuntu Council and Lubuntu Developer.)
[19:04] <arraybolt3[m]> nteodosio: Yeah, but for me, who hasn't done very many big projects in life, this is huge.
[19:08] <Eickmeyer[m]> Thomas and I also have Ubuntu Community Council.
[19:08] <arraybolt3[m]> Wow. That's so cool.
[19:08] <tsimonq2> Eickmeyer[m]: Nerd. :P
[19:09] <arraybolt3[m]> Simon Quigley (Developer): Hey, you're here! I have 11 or 12 PRs to dump on you!
[19:09] <Eickmeyer[m]> tsimonq2: Dork.
[19:09] <Eickmeyer[m]> Simon and I know each other IRL.
[19:09] <tsimonq2> arraybolt3[m]: Hold your horses I'm not at a computer yet ;)
[19:09] <arraybolt3[m]> Simon Quigley (Developer): Just going gung-ho on fullsend LOL.
[19:10] <arraybolt3[m]> I'm not quite ready to throw all the links out there yet either, though, I'm just finishing up with lxqt-session.
[19:10] <Eickmeyer[m]> Simon Quigley (Developer): Gave everyone here a very special present: https://bugs.launchpad.net/ubuntu/+source/quassel/+bug/1980687
[19:12] <tsimonq2> Eickmeyer[m]: Do you have upload access to that package?
[19:12] <Eickmeyer[m]> Simon Quigley (Developer): I'm a MOTU now.
[19:12] <tsimonq2> Eickmeyer[m]: Since when?!? Why didn't you seek my endorsement my friend :)
[19:12] <tsimonq2> I would have loved to grill you ;P
[19:12] <Eickmeyer[m]> I tried, but you were crickets.
[19:12] <Eickmeyer[m]> Yeah, that happened during your hiatus.
[19:13] <Eickmeyer[m]> It's been about a year and a half-ish?
[19:13] <tsimonq2> Eickmeyer[m]: I like to call it my partyatus :P
[19:13] <tsimonq2> yes I was partying daily during that time
[19:14] <tsimonq2> Clear packaging mind > partying packaging mind :P
[19:14] <tsimonq2> But regardless... Congrats :) very belated
[19:14] <Eickmeyer[m]> ha, thanks. teward helped me get there, a lot of credit goes to him.
[19:15] <arraybolt3[m]> Eickmeyer[m]: Wow, for a second I thought teward had actually joined Matrix when I saw that tag.
[19:15] <arraybolt3[m]> Nope. Oh well. Dead fish still incoming.
[19:15] <tsimonq2> I'm glad in general that he's been able to fill in a lot of the gaps for me
[19:15] <arraybolt3[m]> So the two guys who made my two favorite operating systems are friends. That's odd, and really cool.
[19:16] <tsimonq2> arraybolt3[m]: We all know each other in some way, would it surprise you to know that I actually have met vorlon in person before?
[19:16] <arraybolt3[m]> No, since I kinda read that you said that before. 🅰
[19:17] <arraybolt3[m]> (Why does matrix keep doing that to :-P ?)
[19:17] <arraybolt3[m]> :-P != 🅰
[19:17] <tsimonq2> I was in Portland for exactly 48 hours and I was able to keep sign with 2 Debbie developers and 2 members of the boot to security team
[19:17] <Eickmeyer[m]> #BlameElement
[19:18] <tsimonq2> tsimonq2: Don't you guys love talk to text?
[19:18] <arraybolt3[m]> You mean talk to Texans.
[19:18] <arraybolt3[m]> Yeah. I was just browsing around in PC man of them cute just the other day, looking for my deli ann phials.
[19:20] <arraybolt3[m]> (Attempted to intentionally mangle text to look like talk to text, now I'm getting crickets, what happened...)
[19:20] <tsimonq2> arraybolt3[m]: I just didn't see it yet
[19:21] <arraybolt3[m]> tsimonq2: I'm only just now realizing that this is talk to text, I thought "Debbie" was intentionally short for "Debian"...)
[19:21] <arraybolt3[m]> I did raise an eyebrow at "boot to security team".
[19:21] <tsimonq2> arraybolt3[m]: Ubuntu Security Team
[19:22] <arraybolt3[m]> OK, so now that I've thoroughly derailed the topic of this channel... I'll be back in a few with 12 PRs ready.
[19:23] <Eickmeyer[m]> I boot to security team all the time. 👀
[19:23] <arraybolt3[m]> Eickmeyer: Yeah, who needs security? It's not like hackers exist or anything.
[19:24] <Eickmeyer[m]> Nah, not at all. /s
[19:24]  * arraybolt3[m] uninstalls AppArmor and logs in as root
[19:25] <Eickmeyer[m]> Oh, Simon Quigley (Developer) , thought you'd get a kick out of the quassel SRU regressions section: "Users of Ubuntu who think they're on a Debian system might be irked they're no longer going to Debian support, but this is not likely."
[19:37] <arraybolt3[m]> Simon Quigley (Developer): For whenever you have time, here's the PRs. I think there's only 8 or 7 packages left before the backport is complete. https://pastebin.com/J4tSNUxd
[19:37] <arraybolt3[m]> s/8/7/, s/7/8/
[19:38] <arraybolt3[m]> (This way I don't end up afk when you're ready and messing everything up.)
[19:53] <arraybolt3[m]> Simon Quigley (Developer): Oh, also, it's been more than four days since I tried to sign up for Debian Salsa and I've still not gotten approved. I was going to send an email to<EMAIL_ADDRESS>(which was listed as a support email address on Debian's website), and I was wondering if it would be OK to Cc you on the email so you can see what I wrote and maybe back it up. I'm happy to pastebin the email first so you can review
[19:53] <arraybolt3[m]> it before I send it if you think that would be good to do.
[20:30] <arraybolt3[m]> * ready and thus end up with me messing everything
 "Simon Quigley (Developer): Oh..." <-<EMAIL_ADDRESS>[20:40] <arraybolt3[m]> Oh, OK, thank you. I was going to use the Ubuntu.com email, but I'll use the Debian one instead.
[22:32] <tsimonq2> Thanks :)


[11:35] <BluesKaj> Hi folks
[11:36] <fhf> hey
[16:43] <not_roasted_> anybody seeing issues installing today's daily of 15.10? Every time I try to install it crashes with apport.
[17:02] <BluesKaj> not_roasted_, does it work on 'try ubnuntu' on live media?
[17:02] <not_roasted_> BluesKaj: it works in neither instance.
[17:02] <not_roasted_> BluesKaj: if I try, launch, it crashes with apport. If I hit install @ boot, it crashes and says taking me to live session now.
[17:04] <BluesKaj> don't install on  /boot , use either / or  / and /home on separate partitions
[17:05] <not_roasted_> what?
[17:05] <not_roasted_> I mean the boot screen
[17:05] <not_roasted_> where it says do you want to install, or do you want to run it live without changes to your computer
[17:05] <BluesKaj> oh , i thought you meant /boot
[17:06] <not_roasted_> naw, just the boot screen option
[17:07] <BluesKaj> so it doesn't get to a desktop on try ubuntu, that's a problem with hardware recognititon i think
[17:07] <BluesKaj> did you the md5sum on the iso after downloading?
[17:07] <BluesKaj> check
[17:07] <not_roasted_> yep, md5sum matches
[17:07] <BluesKaj> ok
[17:08] <not_roasted_> I'm trying 15.04 for kicks to see if it works. If that fails too, I'll try another usb drive.
[17:08] <BluesKaj> so it's probly a hardware thing ....this could be because the pc is really new or really old
[17:17] <not_roasted_> BluesKaj: yeahhhhhhhh it's not a hardware thing.
[17:17] <not_roasted_> ran ubuntu on here for years.
[17:17] <BluesKaj> not  I'm running kubuntu 15.10 beta on a 7yrold pc with nvidia PCIe graphics, 6G RAM oand dual core cpu and all is well except for the odd crash on some apps like system settings
[17:17] <not_roasted_> manjaro, mint, debian, you name it. all worked great.
[17:17] <not_roasted_> trying 15.04
[17:17]  * BluesKaj nods
[17:18] <not_roasted_> and 15.04 works
[17:18] <not_roasted_> so it's 15.10 specific
[17:19] <BluesKaj> not_roasted_, actually I had more bugs on 15.04 than on 15.10 beta
[17:19] <not_roasted_> BluesKaj: that's fine.
[17:19] <not_roasted_> but when 15.04 installs and 15.10 doesn't...
[17:19] <not_roasted_> the other details don't really matter. :P
[17:20] <not_roasted_> I'll run with 15.04 on this laptop and test it in a VM for sake of helping.
[17:20] <not_roasted_> not much I can do if it won't install.
[17:20] <BluesKaj> well, it would be nice to know what's causing the 15.10 install refusal
[17:21] <not_roasted_> I'll try other flash drives then. I just didn't bother because the others I have are USB2 and need data moved off of them before I use it as a live flash drive.
[17:21] <not_roasted_> I only have 1 USB3 drive I use for installing distros.
[17:21] <not_roasted_> it may be bad, who knows. It's aged. But 15.04 is flying on it now...
[17:22] <BluesKaj> there are some graphics problems after installation that are difficult to track down
[17:22] <BluesKaj> on 15.10
[17:23] <BluesKaj> ahh USB connected ...maybe the installer doesn't recognze non sata connections on 15.10
[17:24] <BluesKaj> not a good practice anyway
[17:26] <not_roasted_> BluesKaj: have you used whatever unity 8 is available in 15.10 yet?
[17:26] <not_roasted_> curious how that's going
[17:26] <not_roasted_> last I used it it just froze upon trying to log in...
[17:27] <BluesKaj> not_roasted_, no I'm KDE guy, haven't used Unity
[17:27] <not_roasted_> I been using plasma 5 on manjaro. It's nice. Not quite finished yet (some things in plasma 5 missing). I'm curious if they'll be around come Kubuntu 15.10's release.
[17:28] <BluesKaj> think ubuntu still uses lightdm
[17:28] <BluesKaj> plasma 5 is default on kubuntu 15.04
[17:28] <not_roasted_> what?
[17:29] <not_roasted_> that sounds a little crazy
[17:29] <not_roasted_> given here in sept plasma 5 still has some issues.
[17:29] <BluesKaj> not crazy. plasma5 is part of KF5/KDE
[17:31] <not_roasted_> just seems a little premature. I had some stability issues on plasma 5. Thought it was just me but it's not exactly rare to find other reports of it.
[17:31] <not_roasted_> anyway I'm heading out to lunch. be back soon.
[17:31] <BluesKaj> yup, it certainly has issues , but the devs tell us they're all part of the transititon from plasm4 to 5 and the complete transistion will be finished some time after the the official 15.10 release
[21:28] <furkan> would anybody here mind sharing what's in their /etc/pulse directory? my pulseaudio isn't working
[21:33] <furkan> sorry, disregard that... managed to solve my issue by purging and reinstalling the relevant packages


[00:29] <robru> ogra_, rsalveti: time to kick an image build I think? cyphermox and I just landed the big mir transition. looking good on our end
[00:30] <rsalveti> robru: cool, let me check if everything is already in
[00:30] <robru> rsalveti, oh, and if you can ensure that python2.7 2.7.6-2ubuntu1 gets in, that would be super ;-)
[00:31] <rsalveti> sure
[00:32] <rsalveti> hm, python is still in proposed
[00:33] <robru> rsalveti, yeah, just noticed that. it's absolutely critical for running AP tests though
[00:33] <rsalveti> Invalidated by dependency
[00:33] <rsalveti> Not considered
[00:33] <rsalveti> Depends: python2.7 libffi (not considered)
[00:34] <rsalveti> autopkgtest for git-annex 5.20131127.1: FAIL (Jenkins: public, private)
[00:34] <rsalveti> for libffi
[00:34] <robru> rsalveti, i'm not familiar with libffi
[00:35] <rsalveti> sync from debian, upload by doko
[02:03] <Saviq> cihelp, ps-nvidia-gt630 fails otto again http://s-jenkins.ubuntu-ci:8080/computer/ps-nvidia-gt630/builds :/
[02:03] <Saviq> again the "could not start container" issue
[04:06] <rsalveti> [04:06] <rsalveti> should have latest mir/unity8/python2.7/etc
[05:13]  * Mirv upgrades
[07:33] <vila> Saviq: yeah, "again". Root cause https://bugs.launchpad.net/otto/+bug/1253198 , workaround https://code.launchpad.net/~vila/otto/stop-running-container/+merge/196594 waiting approval to be landed and deployed
[07:34] <vila> Saviq: the container has been stopped manually in the mean time
[07:42] <jibel> vila, where is the code that install debs? I cannot find it in otto trunk
[07:42] <jibel> is it a custom branch of otto?
[07:45] <vila> jibel: I don't know of any otto custom branch, there are some uncommitted changes on most of the otto nodes but mainly for setting memory sizes
[07:49] <jibel> vila, it's in usr/local/bin/run-autopilot.sh, so not otto
[07:50] <jibel> in the script that calls autopilot
[07:50] <jibel> vila, I don't know where is comes from do you?
[07:52] <vila> jibel: first line of defense is to stop the otto container to unblock other jobs, that's the priority
[07:52] <jibel> vila, that script is broken
[07:52] <jibel> vila, there is a shebang with sh -eu
[07:52] <jibel> vila, but then it call apt with sh  -c
[07:52] <ogra_> hmm, these crashers in the ubnity8 tests on mako dont look good
[07:52] <didrocks> ogra_: yep :/
[07:53] <didrocks> ogra_: new mir, new crashers :p
[07:53] <ogra_> hud wouldnt worry me as much, but NM
[07:53] <didrocks> ogra_: well, better to figure it out first
[07:54] <ogra_> right
[07:54] <vila> jibel: where do you see this script ? It's not on the otto node
[07:54]  * ogra_ has a plumber in the house in 5min ...
[07:54] <ogra_> not sure i'll make it in time for the call ... but i'll try my best
[07:55] <didrocks> ogra_: no worry
[07:55] <didrocks> ogra_: "swim" well ;)
[07:55] <ogra_> heh that was two weeks ago ...
[07:55] <jibel> vila, /var/lib/lxc/trusty-amd64-20131023-0529/run/delta/usr/local/bin/run-autopilot.sh
[07:55] <ogra_> i plastered a patch on the pipe ... thats what he has to fix properly today
[07:55] <jibel> on ps-radeon-8350
[07:56] <didrocks> ogra_: you used DEP3 headers I hope? ;)
[07:56] <didrocks> ogra_: joke apart, I hope it won't cost you too much
[07:56] <ogra_> lol, nope, a tar patch
[07:56] <didrocks> inline patch! how ugly :p
[07:56] <ogra_> haha
[07:57] <ogra_> i dont care about the costs ... the pipes are 50 years old ... they all need replacement all across the 200m² over 3 floors
[07:57] <vila> jibel: can you review https://code.launchpad.net/~vila/otto/stop-running-container/+merge/196594 ?
[07:57] <ogra_> but i prefer that to happen in summer
[07:58] <ogra_> my house has 4 bathrooms ... lots of pipes :(
[07:58] <vila> jibel: and add https://launchpad.net/~canonical-ci-engineering to https://launchpad.net/~otto-dev ?
[07:58] <didrocks> ogra_: yeah, summer will be better to shutdown the whole water system…
[07:59] <vila> jibel: making that team admin would be more in line with responsibilities too
[08:07] <jibel> vila, when do you want to run this script?
[08:08] <vila> jibel: This script is used as a post-build task in jenkins to catch containers left running. as mentioned in the MP
[08:09] <vila> jibel: and how to do that is described in the script itself
[08:10] <jibel> vila, but if you abort a job it won't be called, isn't it?
[08:10] <vila> jibel: and it has been tested on q-jenkins
[08:10] <vila> jibel: it is called even if the job is aborted
[08:11] <vila> jibel: it's explained in the script: This script is used as 'Post-build action' and as such is invoked after a
[08:11] <vila> 16	+# job is finished, including aborted.
[08:13] <jibel> vila, its annoying that it kills everything, can you restrict to the container that have been started by the test?
[08:14] <jibel> vila, as fginther suggested once, write a flag in the main job for example or limit to the containers following the naming convention used by the tests
[08:17] <jibel> didrocks, or anyone, I'd need https://code.launchpad.net/~pitti/autopilot-gtk/fix-1254996/+merge/196703 in the distro, what's the procedure?
[08:17] <jibel> it is blocking installer tests
[08:18] <didrocks> jibel: just adding to the landing ask, I'm handling it
[08:18] <vila> jibel: further refinements can be done later (as explained in the MP)
[08:19] <vila> jibel: for now, I want to unblock Saviq and other users that face https://bugs.launchpad.net/otto/+bug/1253198
[08:19] <jibel> vila, it is not a refinement, it kills all running container without distinction
[08:20] <vila> jibel: It is indeed not a refinement, it is a workaround as explained in the MP and the script, refinements can come *later*
[08:20] <jibel> vila, for Saviq 's problem, fix the script run-autopilot.sh
[08:20] <jibel> used by medium tests
[08:20] <jibel> this script is like saying "I've a bug on my machine, I don't know what it is, let press the power button"
[08:21] <vila> jibel: exactly
[08:21] <vila> jibel: and that's what I want
[08:21] <jibel> so you'd better fix the runner instead
[08:21] <vila> jibel: no, that workaround is a catch-up so the ci engine keeps running, other bugs will be fixed later
[08:21] <vila> catch-all
[08:23] <vila> jibel: can I have that MP approved or https://launchpad.net/~canonical-ci-engineering added to https://launchpad.net/~otto-dev or should I just deployed my branch  on the otto nodes ?
[08:24] <jibel> vila, I disagree with the approach of killing all running container, please restrict to the containers used by the tests.
[08:25] <vila> jibel: fine, I'll deploy my branch then
[08:26] <vila> jibel: we can continue the discussion later
[08:34] <Saviq> vila, oh cool, nice that the problem is tracked down
[08:36] <jibel> vila, commented on the MP
[08:41] <vila> Saviq: note that the root cause (wrong deps) won't be fixed by ci, someone has to look at them
[08:41] <Saviq> vila, of course
[08:43] <Saviq> vila, another one I've noticed from time to time bug #1256227
[09:28]  * ogra_ will be late to the meeting but i will come ...
[09:29] <didrocks> ogra_: no worry!
[09:49] <sil2100> didrocks: can you ACK the packaging diff? Sortage mostly, as other changes were made by core devs ;p http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/QA/job/cu2d-qa-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_autopilot-gtk_1.4+14.04.20131128.1-0ubuntu1.diff
[09:50] <Saviq> ev, hey, it seems makos are in a bad state this morning :/ https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/
[09:50] <Saviq> bug #1256227
[09:50] <ogra_> Saviq, there are a ton of network manager crashes in the latest image smoketests too
[09:51] <ogra_> (no idea if that could be related)
[09:51] <Saviq> ogra_, yeah, no idea either, don't get it what it complains about
[09:52] <didrocks> sil2100: +1
[09:52] <ogra_> popey, did you already try r37 on mako ?
[09:52] <popey> am testing now ogra_
[09:53] <ogra_> the lockscreen issue on maguro is fixed
[09:53] <popey> never saw that on mako
[09:53] <ogra_> yeah, that was driver specific
[09:55] <ogra_> didrocks, oh, btw, i would like to switch on cron after tonights meeting, would be good if everyone could think about the best times for the cron entry
[09:55] <ogra_> ^^^^ rest of team too ^^^^
[09:55] <didrocks> ogra_: hum, I would vary doing that while asac is sick/not around
[09:55] <didrocks> as he's the one disagreeing
[09:55] <ogra_> i would like to have some feedback data before he returns
[09:55] <didrocks> but otherwise, yeah, we need to check with psivaa and plars in particular so that it matches their schedule
[09:56] <ogra_> we can still switch it off if he objects
[09:56] <didrocks> so that basically most of the tests are ran when they arrive
[09:56] <didrocks> they can work on correcting/relaunching
[09:56] <didrocks> (so have some slack time)
[09:56] <didrocks> and then, we rekick the next one
[09:56] <ogra_> right, well, the tests have 8h to run
[09:56] <didrocks> psivaa: what would work for you? ^
[09:57] <ogra_> so i can set the schedule in a way that one image is just ready when they get up
[09:57] <didrocks> ogra_: I would say, when psivaa starts his day, it would be better that the tests are already running for 3 hours
[09:57] <ogra_> or has run a chunk of automated tests already
[09:57] <ev> Saviq: okay, adding to the queue. Thank you!
[09:57] <didrocks> yeah, exactly
[09:57] <ogra_> yeah
[09:57] <popey> http://popey.com/~alan/phablet/device-2013-11-29-095719.png  anyone ever see that? where a key gets wedged on?
[09:57] <popey> note it wasn't the last key I pressed, it stayed wedged even when pressing other keys
[09:58] <psivaa> didrocks: ogra_ i would like to have all the tests completed when i come in so that i could relaunch if there is any test that needs it
[09:58] <didrocks> psivaa: when are you starting UTC-wise?
[09:58] <ogra_> psivaa, when do you usually start
[09:58] <ogra_> heh, snap
[09:58] <didrocks> :p
[09:58] <psivaa> ogra_: didrocks: it's UTC 9:00
[09:59] <didrocks> so half an hour before the meeting
[09:59] <psivaa> right
[09:59] <ogra_> so i should put the build say 4h before that ? does that suffice ?
[09:59] <didrocks> this makes it 6 to start running the tests
[09:59] <didrocks> so 5 to build the image?
[09:59] <didrocks> 5 + 8 = 1PM UTC
[09:59] <psivaa> ogra_: that sounds good
[10:00] <didrocks> so tests done by 5 UTC
[10:00] <didrocks> which is the other meeting time
[10:00] <didrocks> hum
[10:00] <didrocks> better to get that done one hour before the other meeting
[10:00] <didrocks> so 4
[10:00] <didrocks> we still have 3 hours for psivaa to fix things up in the morning
[10:00] <ogra_> ok, i'll schedule one build at 5am ... lets wait for plars input if such a schedule works for him too ...
[10:01] <didrocks> ogra_: 4 would work better for the afternoon meeting
[10:01] <ogra_> we dont need to be strict on 8h or wanything
[10:01] <didrocks> 4 -> 12 + 1 hour building + 3 hours of tests == 4 PM
[10:01] <didrocks> (so one hour before the evening meeting)
[10:02] <ogra_> that wont give plars much wiggle room
[10:03] <ogra_> i would start the second build ~ 2h earlier 13:00 UTC or so
[10:03] <ev> heads up: Jenkins on s-jenkins just crashed on us
[10:04] <popey> ogra_: 37 is good here
[10:04] <ogra_> but lets wait for his input
[10:04] <ogra_> popey, no OSK for me
[10:04] <didrocks> sil2100: once https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/disable-autopilot-tests/+merge/197152 is merged, can you add  ubuntu-system-settings-online-accounts to your bucket?
[10:04] <popey> fine here
[10:04] <ogra_> popey, yeah, because you use a werid language/locale setting :P
[10:05] <sil2100> didrocks: sure! Keeping that on the radar ;)
[10:05] <popey> ogra_: CONFORM!
[10:05] <psivaa> ogra_: didrocks: unity8 tests on both devices came good with 37. in transit to the dashboard
[10:06] <didrocks> psivaa: great!
[10:07] <ogra_> didrocks, so still no OSK on maguro (no surprise since nothing changed there)
[10:08] <ogra_> waking up the screen needs sometimes two power button presses ... but at least no tapping on screen anymore
[10:08] <ogra_> (still not 100% fixed though)
[10:08] <didrocks> ogra_: ah, interesting, mind pinging greyback?
[10:08] <ogra_> about kbd or screen ?
[10:09] <greyback> no OSK on maguro! First I've heard of it.
[10:09] <ogra_> greyback, on non english locale
[10:11] <ogra_> greyback, bug 1255999
[10:11] <greyback> ogra_: ok thanks. I'll poke tmoenicke too
[10:11] <ogra_> he should be able to test a german setting i guess :)
[10:14] <sil2100> Mirv: https://code.launchpad.net/~sil2100/cupstream2distro-config/extra_for_qa/+merge/197157 could you take a lookie?
[10:14] <ogra_> psivaa, there was a saucy 102 build and i dont see any tests for it ... would be good to have some results within the next week (no hurry)
[10:15] <psivaa> ogra_: ack, will add to the list
[10:15] <Mirv> sil2100: looks good
[10:15] <sil2100> Mirv: thank you!
[10:18] <Mirv> sil2100: one for you too https://code.launchpad.net/~timo-jyrinki/cupstream2distro-config/libavutil52/+merge/197159
[10:20] <didrocks> ogra_: sorry, was chatting on something else, so no, on the power button
[10:20] <didrocks> greyback:  ^
[10:20] <ogra_> didrocks, yeah, all sorted
[10:20] <ogra_> (see above)
[10:20] <sil2100> Mirv: oh, ok, not sure why but I'm somehow amused by this change ;p +1
[10:22] <Mirv> sil2100: Friday? ;) I added another commit though, it seems it's installing both at the moment since I already did a really quick test run
[10:22] <sil2100> Mirv: ok, then I re-approve that
[10:23] <sil2100> Mirv: probably ;p
[10:23] <Mirv> thanks!
[10:24] <Mirv> libav9 migration just completed today/yesterday, which was nice to notice
[10:30] <popey> bug 1256265
[10:34] <didrocks> psivaa: so, can you flash latest image
[10:35] <didrocks> (locally)
[10:35] <didrocks> try to get previous glib version
[10:35] <didrocks> and see?
[10:35] <didrocks> (if the crashes still happens)
[10:35] <psivaa> didrocks: ok, i have a maguro and the crashes (network manager) is only happening on mako
[10:35] <didrocks> psivaa: argh, ok
[10:37] <psivaa> didrocks: network-manager somehow depends on libffi6 which is an upgraded package in 37
[10:38] <didrocks> psivaa: do you have access to device in the lab where you can test backing it out? (I'm testing locally)
[10:38] <didrocks> that + retracing will really help I guess
[10:38] <psivaa> didrocks: yes, doing that. i have access to the device
[10:38] <didrocks> great, will confirm you shortly if I have the crash here (phone booting)
[10:38] <didrocks> with r37
[10:38] <psivaa> ack
[10:50] <didrocks> psivaa: ok, so got the crash, reverting glib -> no crash FYI
[10:51] <psivaa> didrocks: ahh ok, thanks. i'll confirm
[10:51] <didrocks> psivaa: hands over a stacktrace once retraced
[10:51] <asac> seb128: ^^
[10:51] <seb128> asac, hey
[10:52] <asac> will you backout given that glib has caused issues on touch and other parts?
[10:52] <asac> :)
[10:52] <seb128> asac, ssssssure
[10:52] <asac> or do you have a lead
[10:52] <asac> cool
[10:52] <asac> leading by example
[10:52] <asac> hehe
[10:52] <asac> sorry... we need to get our proposed testing story sorted
[10:52] <asac> so we have a better safety net...
[10:53] <psivaa> didrocks: doesn't http://q-jenkins.ubuntu-ci:8080/job/trusty-touch-mako-smoke-ubuntu-rssreader-app-autopilot/39/artifact/clientlogs/_usr_sbin_NetworkManager.0.crash/*view*/ have the required trace information?
[10:53] <seb128> psivaa, it doesn't have debug symbols
[10:54] <didrocks> psivaa: do you know how to retrace a crash file?
[10:54] <psivaa> didrocks: i have not done in the past
[10:55] <didrocks> ah, maybe we should pair someone with you
[10:55] <didrocks> Mirv: mind giving a hand to psivaa? ^
[10:55] <didrocks> I think it's important that he learns about it
[10:55] <didrocks> you have the -dbg files directly btw for glib
[11:21] <Mirv> didrocks: sure, in a bit
[11:21] <Mirv> psivaa: you'll need lp:daisy on host
[11:22] <psivaa> Mirv: ok, i'll get it
[11:25] <vila> Saviq: workaround deployed on s-jenkins, you may still encounter failing jobs but they should not block the following ones anymore
[11:25] <Saviq> vila, thanks
[11:25] <sil2100> didrocks: packaging ACK! http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Misc./job/cu2d-misc-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_phablet-tools_1.0+14.04.20131129-0ubuntu1.diff ? :)
[11:26] <didrocks> sil2100: +1
[11:29] <sil2100> didrocks: thanks!
[11:29] <sil2100> hm
[11:29] <sil2100> Does anyone know why this is happening? http://q-jenkins.ubuntu-ci:8080/job/autopilot-trusty-daily_release/658/label=autopilot-nvidia/console
[11:29] <sil2100> I: No test left to run
[12:36] <psivaa> seb128: didrocks: just an update.. still have not collected the crash debug information.. seeing issues like http://pastebin.ubuntu.com/6493858/
[12:38] <didrocks> psivaa: maybe, you can try retracing it directly on the phone?
[12:38] <psivaa> didrocks: let me try that
[12:38] <didrocks> psivaa: you apport-unpack the .crash file
[12:38] <didrocks> and then follow https://wiki.ubuntu.com/Backtrace on the CoreDump you will get
[12:38] <rsalveti> ogra_: do we have a bug for the weird nm bug you said already?
[12:39] <didrocks> (having the debug symbols
[12:39] <ogra_> rsalveti, not sure
[12:39] <psivaa> didrocks: ack, will try that
[12:39] <ogra_> i didnt file one (and dont have my mako on -proposed)
[12:39] <rsalveti> let me flash the latest
[12:39] <ogra_> rsalveti, the dashboard has a ton of crash files though
[12:39] <rsalveti> oh =\
[12:40] <ogra_> http://ci.ubuntu.com/smokeng/trusty/touch/mako/37:20131129:20131129/5168/
[12:40] <ogra_> all tests with 2 or more crashes are likely to have the NM one
[12:41] <seb128> the nm one is a known issue which is being worked
[12:41] <ogra_> oh, cool
[12:42] <rsalveti> seb128: right, but do we have a bug for it?
[12:42] <seb128> rsalveti, not sure, I've a fix in a ppa and I'm waiting for desrt to get online to validate it
[12:42] <rsalveti> alright
[12:42] <seb128> I confirmed the fix, I just want sanity check that I'm not doing something boggy to gobject
[12:47] <Mirv> didrocks: I think the problem psivaa is seeing, based on the output he's getting, is that it's not a problem/crash that would create coredump
[12:47] <didrocks> Mirv: I doubt there is no coredump, I can see one on the dashboard
[12:48] <Mirv> didrocks: ok. it's what apport is telling him though, and I've had some of those with eg. python crashes. but it might be some different kind of problem.
[12:48] <Mirv> didrocks: the method I gave psivaa I've used successfully with unity8 backtracing at lest
[12:48] <Mirv> least
[12:48] <seb128> that report is working
[12:48] <seb128> I got the dump out this morning to look at it
[12:49] <seb128> that's not rocket science, just use apport tools (e.g unpack and gdb it)...
[12:49] <vila> sil2100: literally, I: No test left to run
[12:49] <vila> means that all tests in the spool dir have run and there is no more to run
[12:49] <Mirv> I'll try retracing too
[12:49] <sil2100> vila: but it results in an error, and the autopilot suite has more than 0 tests
[12:49] <vila> sil2100: this comes from run-autopilot.sh
[12:50] <vila> sil2100: that's not why it results in an error IIUC:
[12:50] <sil2100> I actually ran them on my desktop and there all tests ran
[12:50] <seb128> Mirv, don't bother, no need to be several doing it
[12:50] <vila>     if [ ! "$(ls -A $spooldir/)" ]; then
[12:50] <vila>         echo "I: No test left to run"
[12:50] <vila>         sudo shutdown -h +1
[12:50] <vila>     fi
[12:50] <seb128> Mirv, that's dupping work for no good reason
[12:50] <vila> sil2100: that's the way it always finish the job
[12:51] <Mirv> seb128: well, I'm interested in seeing if I get similar error as psivaa, or not. my computer's CPU and network cycles are free :)
[12:51] <Mirv> (almost, at least)
[12:51] <seb128> Mirv, k, your call
[12:51] <Mirv> psivaa got his .crash file from the device, so I'm checking if we get similar results on that downloadable one
[12:51] <Mirv> seb128: we were asked to pair work on this anyhow..
[12:52] <Mirv> psivaa: yeah, on that jenkins one I got retrace, no problems
[12:53] <vila> sil2100: i.e. there may be another previous error leading to *not* producing a test suite to run but I can't see why from that log
[12:54] <vila> sil2100: /var/local/autopilot/autopilot.log: Loading tests from: /usr/lib/python2.7/dist-packages kind of means autopilot has run and failed for an unknown reason (few lines above that 'No test left ro run' line)
[12:54] <sil2100> hmmm
[12:54] <sil2100> vila: thanks for the analysis!
[12:54] <vila> sil2100: my pleasure, learning with you here
[12:55] <vila> sil2100: in fact, I think autopilot has run indeed, yet a few lines before:
[12:55] <vila> /var/local/autopilot/autopilot.log: I: Running autopilot run autopilot -v -f xml -r -rd /var/local/autopilot//videos/ --record-options=--fps=6,--no-wm-check -o /var/local/autopilot//junit//autopilot.xml
[12:58] <vila> sil2100: so, was that job about running autopilot tests themselves ?
[12:59] <vila> sil2100: i.e. 'autopilot run autopilot' ?
[13:14] <psivaa> ogra_: i'm done with image 37.. please feel free to kick 38 :)
[13:16] <ogra_> doing :)
[13:16] <ogra_> [13:38] <popey> \o/
[13:57] <Saviq> ev, hey, can you tell me how to subscribe to packages for errors.u.c? or where to read about e.u.c for that matter?
[14:00] <seb128> ev, define "subscribe"?
[14:00] <seb128> ups
[14:00] <seb128> Saviq, ^^
[14:00] <seb128> Saviq, like getting emails for issues?
[14:01] <seb128> Saviq, by default it lists packages you are subscribe to in launchpad
[14:01] <Saviq> seb128, how do I do that? on https://launchpad.net/ubuntu/+source/unity8 ?
[14:01] <sil2100> Damn, LP acts strange today..
[14:02] <seb128> Saviq, https://launchpad.net/ubuntu/+source/unity8/+subscribe
[14:02] <seb128> click the "I want to receive these notifications by e-mail."
[14:02] <seb128> Saviq, that doesn't give you emails from e.u.c though, but the default view is to list reports for the packages your user is subscribed to
[14:02] <Saviq> seb128, right, I was team-subscribed to that
[14:03] <seb128> Saviq, well, you can customize your url
[14:03] <seb128> Saviq, e.g https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=unity-team&period=day
[14:03] <Saviq> seb128, right, thanks!
[14:03] <didrocks> ok, exercising time
[14:04] <seb128> yw
[14:04] <seb128> Saviq, https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=saviq&period=day
[14:04] <Saviq> seb128, what does it mean when a row is greyed out?
[14:04] <Saviq> retrace failed?
[14:04] <seb128> Saviq, I think it means it hasn't been seen with the current version of the package
[14:04] <Saviq> ah
[14:04] <Saviq> nice one
[14:04] <seb128> so it might be fixed
[14:04] <seb128> crossed is when the bug is closed
[14:05] <seb128> red is when it's closed but the issue is still reported with the current version
[14:05] <seb128> would be nice to have a legend on the page
[14:05] <seb128> ev tried to make it "obvious enough by itself" but it's still confusing
[14:06] <Saviq> seb128, can it be greyed out if it's crossed, too? like https://errors.ubuntu.com/problem/f27a9186b6a83d502641e0fd89381bcd62095395
[14:06] <Saviq> seb128, it's fixed, not greyed out - but not found in current version
[14:06] <Saviq> probably doesn't make sense to be greyed out if crossed
[14:06] <seb128> right, fixed is just crossed
[14:07] <seb128> it would turn red if it was seen in the current version
[14:07] <Saviq> seb128, aanyway, there anywhere I could read so that I don't bother you? :)
[14:07] <seb128> Saviq, try asking to mpt on #ubuntu-devel if there is a document explaining e.u.c or its design
[14:08] <Saviq> seb128, will do, thanks
[14:08] <seb128> yw
[14:22] <psivaa> seb128: didrocks: Mirv has reported the bug for NetworkManager crash, bug #1256299
[14:22] <seb128> psivaa, Mirv: you can close it, the fix has already been uploaded
[14:23] <psivaa> seb128: i'll wait for the fix to land and work before closing it
[14:23] <seb128> ok, your call
[14:23] <seb128> testing for the fix (that's the new glib just uploaded to trusty-proposed) is welcome
[15:39] <didrocks> psivaa: mind testing it from proposed?
[15:41] <psivaa> didrocks: the tests are running on the device. i was planning to test it once the tests are done
[15:41] <psivaa> i mean the tests with r38
[15:41] <didrocks> psivaa: ok ;)
[15:53] <dobey> transitioning stuff to daily-release is hard
[16:30] <Laney> can I get permissions to re-run autopkgtests?
[16:37] <Laney> (what happened to the matrix reloaded?)
[16:38] <cjohnston> Laney: can you file a bug against ubuntu-ci-services-iteself with your request.. im not sure what may have changed with the move, but that way it can be followed up on when people from the US get back
[16:38] <Laney> cjohnston: ok, in the meantime can you re-run glib2.0 please?
[16:38] <cjohnston> Laney: link please?
[16:38] <Laney> http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/21/
[16:40] <cjohnston> Laney: I'm not familiar.. so I see 'matrix reloaded', on that page I see amd64 which is green and i386 which is red and checked...
[16:40] <cjohnston> what about the downstream builds? do I check that?
[16:41] <Laney> I don't know
[16:41] <Laney> there used to be Matrix Reloaded to make the tests re-run
[16:41] <Laney> don't ask me what it did, but I'm guessing it's a plugin which we don't have any more
[16:41] <Laney> jibel: ^- any clue?
[16:42] <cjohnston> Laney: the plugin still seems to exist (for me atleast)
[16:42] <Laney> oh, you /do/ see it, sorry - misread
[16:42] <cjohnston> Laney: I'm just not sure with the plugin, do  I just leave it at the default for what they set
[16:42] <Laney> so tick both of them and press publish or whatever it is
[16:42] <Laney> that should create a new entry to re-run the tests
[16:42] <cjohnston> "Matrix Reload downstream builds: "
[16:42] <cjohnston> any idea on that tick box?
[16:42] <Laney> can't remember
[16:43] <Laney> ISTR only changing the arches
[16:43] <cjohnston> ok, well its building
[16:44] <Laney> neat, thanks
[16:44] <Laney> I filed https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1256372 for you
[16:45] <cjohnston> ty
[16:45] <cjohnston> I'm not sure if policies changed or what the story is, so I'm not comfortable with making changes :-)
[16:46] <Laney> ok, well I described my ideal
[16:48] <cjohnston> ty
[16:49] <cjohnston> cyphermox: ping
[16:49] <cyphermox> pong
[16:50] <cjohnston> cyphermox: can you walk through updating the q-jenkins stack update stuff with me please?
[16:50] <cyphermox> what do you mean?
[16:50] <cjohnston> https://wiki.ubuntu.com/DailyRelease/FAQ#Adding.2BAC8-removing_components_to_a_stack
[16:51] <cyphermox> ok, what do you want to do?
[16:51] <cjohnston> cyphermox: I'm not really sure what I'm doing, so just make sure I don't kill things?
[16:51] <cyphermox> well, that's what I mean what are you trying to do?
[16:52] <cjohnston> applying https://code.launchpad.net/~dobey/cupstream2distro-config/u1creds-inline-packaging/+merge/197230
[16:53] <cyphermox> ah!
[16:53] <cyphermox> so since it's merged, just make sure you have the very latest revision
[16:54] <cyphermox> then you'll want to cd daily-release;  ./cu2d-update-stack -dUS ../stacks/head/webcred.cfg
[16:54] <cjohnston> cyphermox: do I do this locally or on the remote machine?
[16:54] <cyphermox> that will update the jenkins config in jenkins, and not touch
[16:54] <cyphermox> oh wait
[16:54] <cyphermox> cu2d-update-stack -dU
[16:55] <cyphermox> locally
[16:55] <cyphermox> you should have a .cu2d.cred file on your system that has your credentials for jenkins to be able to update the config remotely
[16:55] <cjohnston> hrm.. ok, I'll create oen
[16:55] <cjohnston> one
[16:55] <cyphermox> hmm
[16:55] <cyphermox> ok just a second
[16:59] <cyphermox> cjohnston: so yeah, all you need to do is get lp:cupstream2distro-config, cd daily-release and then run
[16:59] <cyphermox> ./cu2d-update-stack -dU ../stacks/head/webcred.cfg
[17:00] <cyphermox> note that this often requires you to be in the right teams to be able to update what trunk points to and things like that, so I'm not sure how well it's going to run
[17:00] <cjohnston> ack
[17:00] <cjohnston> its runnin, i guess we shall see
[17:01] <cjohnston> read only transport
[17:01] <cyphermox> right
[17:01] <cyphermox> we also need https://code.launchpad.net/~dobey/ubuntuone-credentials/daily-release/+merge/197222 to get merged though
[17:01] <cyphermox> let me see if I can run it
[17:02] <dobey> cyphermox: no we don't
[17:02] <dobey> cyphermox: the purpose of the previous change was so that this can merge
[17:03] <cyphermox> in that case this is not the same process
[17:03] <dobey> eh? jenkins needs config that doesn't include pulling in the external package branch, to be able to run tests in this branch, because they conflict
[17:03] <cyphermox> cjohnston: then you'll likely want fginther or alesage or some other person to fix up CI rather than daily-release
[17:04] <cjohnston> dunno.. this is what didrocks said was needed
[17:04] <cyphermox> I expect there was a misunderstanding
[17:04] <cyphermox> packaging_branch: may be used in more than one place
[17:05] <cyphermox> the cu2d-update-stack stuff is really mostly going to change q-jenkins for the cu2d jobs, not the merge proposal build stuff
[17:05] <cyphermox> anyway, AFAIK
[17:05] <didrocks> cyphermox: I think cjohnston did the upstream merger part
[17:05] <cyphermox> then the proposal should be able to merge fine
[17:06] <cyphermox> I'm not denying that the second part is necessary, just that it's not what's blocking the merge request
[17:06] <cyphermox> didrocks: do you happen to have magic ubuntuone access to be able to update the packaging branch for ubuntuone-credentials?
[17:06] <dobey> cyphermox: what are you suggesting?
[17:07] <cjohnston> I did deploy-cupstream2distro-config
[17:07] <cyphermox> cjohnston: ok
[17:07] <cyphermox> in this case, the merge should be good to land
[17:07] <didrocks> cyphermox: ah, I don't
[17:07] <cyphermox> then we still need to do cu2d-update-stack for the actual daily build
[17:08] <cyphermox> didrocks: actually
[17:08] <cyphermox> I think I might have the right access, going to try
[17:08] <dobey> cyphermox: what are you "going to try" exactly?
[17:08] <dobey> please don't touch any ubuntuone branches
[17:09] <cyphermox> updating the config
[17:10] <cyphermox> ah, that oneś daily-release false too
[17:10] <cyphermox> It's already good
[17:11] <dobey> yes, the change was just to remove the packaging branch, so ps jenkins would pass the tests again
[17:11] <cyphermox> cjohnston: you should jsut be able to kick the merge proposal to try the build again, but I don't know how you do that
[17:12] <dobey> http://s-jenkins.ubuntu-ci:8080/job/ubuntuone-credentials-ci/69/rebuild
[17:12] <dobey> someone just needs to rebuild it, if the live config is updated now
[17:12] <cjohnston> rebuilding
[17:15] <dobey> looks like it failed again with the same issue.
[17:15] <dobey> so i guess the liv config isn't updated
[17:15] <dobey> live even
[17:20] <cyphermox> cjohnston: you'll need to check the config in http://s-jenkins.ubuntu-ci:8080/job/ubuntuone-credentials-trusty-amd64-manual/14/console to see why it still tries to grab debian, I'm not sure if that's covered by packaging_branch but regardless, it's not a process I know about, it's not cu2d.
[17:21] <cjohnston> bzr branch $packaging_branch debian
[17:22] <dobey> maybe jenkins needs a restart to refresh the config or something?
[17:23] <dobey> not sure how that works
[17:23] <cjohnston> that would be very unfortunate
[17:23] <cjohnston> dobey: hrm
[17:23] <cjohnston> if I just did a rebuild, then that would still have the packaging branch
[17:24] <dobey> did the job config not change?
[17:25] <cjohnston> it has a packaging branch field, but it is blank
[17:26] <cjohnston> but on a rebuild, it takes the config of the build you are rebuilding
[17:26] <cjohnston> so I think it needs a new build
[17:26] <dobey> hmm, maybe. i guess trigger a new build of the job?
[17:26] <cjohnston> or the packaging branch to be removed when doing a rebuild
[17:27] <cjohnston> it still requires a packaging branch
[17:27] <dobey> i thought "rebuild" just triggered a new build of the same job
[17:28] <cjohnston> it does, but it carries all the env vars
[17:28] <cjohnston> https://code.launchpad.net/~dobey/cupstream2distro-config/u1creds-inline-packaging/+merge/197230 doesn't seem like the correct fix for the problem dobey
[17:28] <cjohnston> it still expects and external branch for the debian files
[17:30] <cyphermox> it's probably jsut carrying things over
[17:30] <dobey> why is it expecting one?
[17:30] <cyphermox> what if you resubmit the merge proposal?
[17:31] <cjohnston> cyphermox: dobey that wont work...
[17:31] <cjohnston> all that the MP did was take away the default packaging branch
[17:31] <cjohnston> it didn't remove the need for having a packaging branch
[17:32] <dobey> and what specifies that need?
[17:32] <cjohnston> your funny
[17:32] <cyphermox> cjohnston:        ubuntuone-credentials-trusty-amd64-manual: template: False ??
[17:32]  * cjohnston has no idea.. still looking
[17:32] <cyphermox> (just guessing)
[17:33] <cyphermox> I know fginther had a google doc about these things
[17:37] <cyphermox> cjohnston: do you need a link to the document?
[17:37] <cjohnston> cyphermox: the config in jenkins has:
[17:37] <cjohnston> # This project uses a packaging dir that is not compatible with pbuilderjenkins
[17:37] <cjohnston> bzr branch $packaging_branch debian
[17:37] <cjohnston> but I don't know where that comes from
[17:37] <cjohnston> yes please
[17:37] <cyphermox> right, that's because of the separate debian/ branch
[17:38] <cyphermox> cjohnston: from what I can see, you'd just need to remove that job in configurations and possibly also remove the part about trusty-amd64: False to have things use the standard process
[17:38] <cyphermox> https://docs.google.com/a/canonical.com/document/d/1vZf1jxnP0XYrVSoJF3UoTPNhZBYtX9oQufpR8bdaDzQ/edit#heading=h.c8d6w5jt4m60
[17:38] <Laney> cjohnston: Could you retry http://d-jenkins.ubuntu-ci:8080/view/Trusty/view/AutoPkgTest/job/trusty-adt-glib2.0/22/ one more time? There was some kind of bug in the job that made it pull the wrong version of the tests (pinged jibel about it already)
[17:38] <cyphermox> cjohnston: ^ it's not a very clear document though
[17:38]  * cyphermox goes to get lunch
[17:40] <cjohnston> Laney: done
[17:40] <Laney> thanks
[17:41] <Laney> silly infrastructure :-)
[17:42] <dobey> hmm, there is no indication in that document of what "template: False" actually means there
[17:47] <cjohnston> im wondering if you do template false if you are using a seperate packaging branch
[17:50] <cjohnston> dobey: cyphermox I'm at a complete loss
[17:50] <cjohnston> I'd say at this point we will need to wait for Monday
[17:50] <cyphermox> well, tbh I think it's just avoiding to use a template at all, and instead uses the job named whatever the title is there
[17:51] <cyphermox> in this case, ubuntuone-credentials-trusty-amd64-manual
[17:51] <cyphermox> cjohnston: you could just as well remove the config to try and put it back
[17:51] <cyphermox> if things don't work as you expected
[17:51] <dobey> cyphermox: but it's not clear to me if that should be removed exactly
[17:52] <cyphermox> dobey: most jobs don't need any of this configuration, and don't have a configuration: stanza at all
[17:52] <cyphermox> this was only required because you used merge mode for the bzr branches
[17:52] <dobey> cyphermox: right. and ubuntuone-credentials will still be merged by the u1 tarmac
[17:52] <dobey> cyphermox: which is why it's not clear if just removing that job is the right thing to do
[17:52] <cyphermox> tarmac is irrelevant there
[17:53] <cyphermox> anyway, the worst that can happen is that you'd have another message from jenkins on the merge proposal that says the attempt failed
[17:53] <dobey> cyphermox: only under the assumption that this config isn't what's preventing the CI autoland job from merging approved branches in that project
[17:53]  * cjohnston lunches
[17:53] <dobey> cyphermox: and i don't see any clear indication if that is true or not
[17:53] <dobey> anyway i also need to get lunch
[17:54] <dobey> bbiab
[17:54] <cyphermox> any branch approved that hasn't been merged yet would still need to be reviewed by jenkins first anyway
[18:10] <cjohnston> Laney: all better?
[18:13] <Laney> cjohnston: seems decent now, cheers
[18:13] <cjohnston> :-)
[18:22] <psivaa> seb128: btw with libglib2.0 (2.39.1-0ubuntu2) from -proposed the NetworkManager crash is not occurring anymore.
[18:23] <seb128> psivaa, I know, but thanks for confirming ;-)
[18:35] <seb128> ogra_, psivaa, asac: the fixed glib is in trusty proper btw
[18:35] <seb128> it just migrated there
[19:11] <dobey> back
[19:14] <dobey> cyphermox: right. what i want to avoid though, is two separate jenkins trying to merge/commit the same branch into trunk
[19:39] <dobey> i wonder if just changing this to use "autolanding: False" instead, would solve it
[19:52] <cyphermox> nope, that's something else
[19:52] <cyphermox> that will make the merge proposals not merged at all
[20:05] <dobey> how so?
[20:05] <dobey> and does not merged mean no ps jenkins running tests?
[20:21] <dobey> bah. i guess i'll just go all in, instead of trying to stage this migration in a reasonable way
[20:36] <asac> 19:35 < seb128> ogra_, psivaa, asac: the fixed glib is in trusty proper btw
[20:44] <ogra_> ok
[20:44] <ogra_> [20:44] <popey> \o/
[20:55] <asac> oh cool
[21:11] <dobey> cyphermox, cjohnston: https://code.launchpad.net/~dobey/cupstream2distro-config/u1creds-fix/+merge/197264 <- maybe we could get this merged and deployed now then? i've pulled the landing of that project's trunk out of the u1 tarmac setup now.
[21:26] <dobey> cihelp ^^
[21:58] <dobey> well, time for me to head off. guess this won't get merged/deployed today. :-/
[21:58] <dobey> later
[22:03] <ogra_> [22:03] <ogra_> (since a while)
[22:03] <asac> oh :)
[22:03] <asac> ogra_: thanks
[22:04] <ogra_> np :)
[22:05]  * ogra_ goes afk again ...
[22:13]  * popey flashes
[22:28] <asac> popey: is it any good?
[22:28] <asac> dashboard is still greenish :) at 11 pass


 Just noticed I miss a usb soundcard driver
[07:21] <lordievader> How are you doing?
[07:21] <lordievader> Ah, thanks :)
[07:22] <lordievader> Problem solved :)
[07:23] <ducasse> all good here, finally finished moving all the google auth keys, banking stuff etc over to the new phone, so now it's actually useful :)
[07:24] <lordievader> I moved my banking over to my phone last week.
[07:24] <lordievader> Quite handy.
[07:27] <ducasse> yep, it is. fortunately my bank lets me heavily limit what is possible via mobile, which makes me feel a bit better about it.
[07:28] <lordievader> I heared a talk from my banking the other week were they advocated that their mobile app was more secure than their website.
[07:30] <ducasse> possibly, it still feels good to know it's definitely not my problem if somebody manages to get a larger amount of money out of it :)
[07:32] <ducasse> i've been trying to help my elderly neighbors get a grip on online banking, as it would be really helpful to them. i think the whole 'material design' thing is very confusing to them, they have no idea what they can click and what they can't etc.
[07:32] <lotuspsychje> morning guys
[07:33] <ducasse> morning, lotus!
[07:33] <lotuspsychje> hey ducasse
[07:33]  * ducasse brings more coffee :)
[07:33] <lotuspsychje> yay
[07:35] <ducasse> jeez, so many updates on arch...
[07:35] <lotuspsychje> online banking via mobile i dont like
[07:37] <ducasse> the way i have things set up it can be very practical, but i still use the normal website for lots of stuff, though.
[07:38] <ducasse> how was your holiday btw, lotuspsychje?
[07:38] <lotuspsychje> great ducasse tnx
[07:38] <ducasse> go anywhere?
[07:38] <lotuspsychje> ducasse: had the chance to paint house some more
[07:38] <lotuspsychje> ducasse: yeah we did some relaxing too, shopping nearby city
[07:39] <ducasse> finished with the business room?
[07:39] <lotuspsychje> ducasse: the painting part yes
[07:39] <lotuspsychje> ducasse: still need more lil jobs around the house
[07:39] <ducasse> we'll want pictures when it's all done :)
[07:39] <lotuspsychje> you can count on it :p
[07:40] <oerheks> yes, and pancakes
[07:41] <ducasse> \o  oerheks
[07:41] <lotuspsychje> hey oerheks
[07:41] <oerheks> morning guys :-)
[07:41] <lotuspsychje> now 7 weeks work then 3 weeks xmass holiday
[07:44] <lotuspsychje> https://twitter.com/ubuntu
[07:45] <lotuspsychje> ubuntu all about Iot now
[07:48] <ducasse> lots of openstack stuff - *yawn*
[07:48] <lotuspsychje> yeah big yawn
[08:22] <lordievader> Hey lotuspsychje , oerheks . How are you guys?
[08:22] <lotuspsychje> great here lordievader
[08:24] <lotuspsychje> on the train lordievader ?
[08:25] <lordievader> Good to hear :)
[08:25] <lordievader> Nope.
[08:25] <lordievader> No need to go by train to work anymore ;)
[08:25] <lordievader> <10min on bike.
[08:37] <oerheks> hmmm https://it.slashdot.org/story/17/11/07/232234/flaw-crippling-millions-of-crypto-keys-is-worse-than-first-disclosed
[08:41]  * ducasse puts fingers in ears
[08:41] <ducasse> la-la-la-la-i-can't-hear-you!
[08:42]  * oerheks puts fingers in ducasses nose
[08:42] <oerheks> la-la-la-la-you-cannot-smell-me!
[08:42] <oerheks>  146 not upgraded... run sudo apt update && sudo apt full-upgrade
[08:43] <ducasse> not updated in a while, or are you on bionic?
[08:43] <oerheks> mister packet
[08:45] <ducasse> oh, right. yes, but how to get him updated with a busted apt/python? :)
[08:46] <oerheks> pip .. dunno :-(
[08:47] <ducasse> i'm not familiar enough with pip/python to dig him out of this hole, i'm afraid
[08:47] <lordievader> What is the issue?
[08:48] <ducasse> https://pastebin.com/K6QrYjfR
[08:49] <lordievader> That is a syntax error on python-samba's part.
[08:49] <lordievader> Unless necesarry, I'd remove the package.
[08:50] <ducasse> ok, let's try... thanks.
[09:16] <lotuspsychje> !info python-samba xenial
[10:57] <BluesKaj> Hi folks
[11:36] <ducasse> hi, BluesKaj - wb
[11:37] <ducasse> all going well?
[11:39] <BluesKaj> hi ducasse, yes, all good here, how about you?
[11:40] <ducasse> all good, thanks - playing with my new phone, moving stuff over from the old one etc. new toys are always good :)
[11:41] <ducasse> fine-tuned my backups setup, so i can sleep even better ;)
[11:53] <BluesKaj> ducasse, which new phone ?
[11:56] <ducasse> BluesKaj: moto g5 - cheap, but good enough for me.
[11:57] <ducasse> seems alternate roms etc generally are made available for these devices, which hasn't always been the case with my previous phones
[12:13] <BluesKaj> heh ducasse , i paid 100bucks cdn for my alcatel mini :-)
[14:39] <leftyfb> BluesKaj: pretty sure it's just a troll
[14:40] <BluesKaj> yup, not a female either
[14:40] <leftyfb> yup
[15:46]  * nacc is 99% sure there is a memory leak in firefox now (artful)
[15:46] <nacc> RSS spikes up to 2G and it becomes relatively unusable
[16:14] <lotuspsychje> good afternoon
[16:18] <lotuspsychje> hey Bashing-om
[16:18] <lotuspsychje> http://news.softpedia.com/news/ubuntu-18-04-lts-bionic-beaver-daily-builds-now-available-to-download-518451.shtml
[16:18] <lotuspsychje> yayy
[16:19] <Bashing-om> lotuspsychje: :) .. imagine your presence at this time of your day .
[16:19] <lotuspsychje> brb dinner :p
[16:45] <lotuspsychje> http://cdimage.ubuntu.com/daily-live/pending/
[16:49] <lotuspsychje> !info linux-image-generic beaver
[16:49] <lotuspsychje> !info linux-image-generic bionic
[16:50] <Bashing-om> !info linux-image-generic zesty
[16:52] <lotuspsychje> dax: too early to fill in 18.04 daily's?
[16:52] <nacc> lotuspsychje: still early for the kernel to move, i thinnk
[16:52] <lotuspsychje> ah tnx nacc
[16:52] <lotuspsychje> nacc: thats why its in pending?
[16:53] <lotuspsychje> wb ducasse
[16:53] <nacc> lotuspsychje: http://cdimage.ubuntu.com/daily-live/current/
[16:53] <nacc> lotuspsychje: you just happened to be looking at pending?
[16:53] <nacc> lotuspsychje: pending is, well, the pending one
[16:53] <ducasse> hiya lotuspsychje, been out for a while
[16:54] <lotuspsychje> ah
[16:59] <dax> lotuspsychje: nice, been waiting for those
[16:59] <lotuspsychje> dax: your welcome
[16:59] <nacc> still no cloud images, though :/
[17:00] <dax> topic'd
[17:00] <lotuspsychje> tnx
[17:00] <nacc> (e.g. lxc launch ubuntu-daily:bionic)
[17:05] <lotuspsychje> hey pauljw
[17:05] <pauljw> hi lotuspsychje :)
[17:22] <lotuspsychje> dax: do we have a trigger that refers to this https://help.ubuntu.com/community/UbuntuUpdates ? (to tell users to keep their system up to date)
[17:25] <dax> !search UbuntuUpdates
[18:09] <immu> hi all
[18:10] <lotuspsychje> hi
[18:11] <immu> so one is awake thats lotuspsychje :)
[18:18] <lotuspsychje> fts: hi
[18:19] <lotuspsychje> bbl movietime
[19:02] <lordievader> Hey immu
[19:08] <immu> hye lordievader
[19:08] <immu> whats upo
[19:08] <lordievader> Doing good here
[19:08] <lordievader> Playing a bit with mopidy
[19:09] <immu> mopidy?
[19:10] <daftykins> https://www.mopidy.com/
[19:14] <immu> cool
[19:14] <immu> https://www.youtube.com/watch?v=R_6NKlnc3Yg i want a super HD audio file for this song
[19:14] <immu> my fav
[19:21] <immu> lordievader,https://www.youtube.com/watch?v=R_6NKlnc3Yg
[19:25]  * Bashing-om away for  spell .
[19:26] <TJ-> Bashing-om is a magician?
[19:27] <Bashing-om> Only in those rare moments :)
[19:32] <lordievader> immu: ?
[19:33] <immu> lordievader, Moulin Rouge - https://youtu.be/5pzwj2THU8U
[19:34] <lordievader> Why are you sending me that?
[19:36] <ducasse> immu: what exactly do you mean by 'hd audio'?
[19:38] <immu> HD good quality
[19:39] <ducasse> and what do you call 'are you talking 44.1khz flac or what?
[19:39] <lordievader> Pff, 44.1kHz :P
[19:39] <ducasse> *and what do you call 'hd'?
[19:39] <lordievader> And 16bit I suppose ;)
[19:40] <ducasse> lordievader: that's why i ask :)
[19:40] <lordievader> I know, I'm just kidding around.
[19:41] <immu> i am not sure, but what would be classed as HD ? for audio?
[19:42] <ducasse> depends on who you're talking to
[19:42] <lordievader> For most people 44.1kHz/16bit is more than enough.
[19:43] <lordievader> Others find 192kHz/24bit lacking....
[19:44] <ducasse> if you want cd quality, there are plenty of places that will sell you lossless flac tracks of the soundtrack for moulin rouge, or get a cd somewhere and rip it yourself
[19:44] <immu> its being ages that i have ripped a CD i will check google music or someting
[19:45] <immu> what is good for linux
[19:45] <ducasse> good for ripping cds?
[19:45] <daftykins> i much prefer ripping from CD, i do it all the time for a client
[19:45] <daftykins> Exact Audio Copy configured for max reliability of the end result :D
[19:46] <lordievader> I had to rip a CD last week... had to boot up an old laptop which still had a cd-drive.
[19:47] <daftykins> :) i have one in my file server, just stroll upstairs then RDP to it to rip
[19:47] <immu> i wonder if i would find a cd for it or not will check tho
[19:47] <kostkon> the moulin rouge ost is on spotify and deezer, among others
[19:47] <lordievader> Amazon has lots of CD's ;)
[19:48] <lordievader> daftykins: My fileserver's sata ports are filled with drives.
[19:48] <daftykins> heh :P mine are on mines controller card :D
[19:48] <immu> do you have that track in your archines
[19:49] <kostkon> immu, you could, ahem, download the whole album, somehow
[19:50] <immu> yeah i know
[19:50] <kostkon> immu, that exact track included
[19:55] <immu> good nite all
[19:55] <lordievader> Sleep well immu
[23:09]  * Bashing-om Back on the job and getting caught up :)


[04:50] <h00k> Well, the testing wasn't a big blowout
[04:51] <h00k> Probably should have advertised earlier
[06:44] <locodir-user> login into postgres
[06:44] <locodir-user> on a server
[06:44] <locodir-user> please help me some one
[06:45] <locodir-user> I am using putty
[06:45] <locodir-user> to login
[06:45] <locodir-user> and got the sever and postgre details
[06:52] <YoBoY> hi locodir-user, no support on this channel, try on the #ubuntu channel (type "/join #ubuntu" without the "")
[06:53] <dholbach> good morning
[09:34] <czajkowski> aloha
[10:34] <HakanS> We are having a discussion in our LoCo about the LoCo Team Leader, and Team Contact role.
[10:35] <HakanS> One person is saying: "there is a hierarchy, and the TC is above TL, and can therefore take his own decisions."
[10:36] <HakanS> "A TL will also only be Team Leader, and nothing else. Neither more nor less."
[10:36] <HakanS> What do you thingk of this?
[10:37] <HakanS> *think
[10:40] <HakanS> Personally, I think he's wrong.
[10:41] <HakanS> !lococouncil
[10:41] <ubot4> lococouncil is The Loco Council is itnet7, czajkowski, paultag, huats, leogg, popey - they are there to help, just ask! :) You can send them an email at<EMAIL_ADDRESS>[10:44] <popey> hello
[10:44] <popey> I think it's different for every team
[10:44] <popey> You can build whatever structure in the team you wish
[10:44] <popey> I think personally that the structure should be "flat"
[10:44] <popey> no one person is 'above' or 'under' anyone else
[10:52] <czajkowski> indeed
[10:52] <czajkowski> HakanS: what team is this ?
[10:53] <czajkowski> a lot of teams have a team contact/leader same person one role
[10:53] <czajkowski> others have seperate ones, the TC passes on information and the TL organises meetings and gets people motivated
[11:09] <HakanS> czajkowski: It´s the Swedish team.
[11:14] <HakanS> popey: I also think that the loco structure should be flat.
[11:15] <czajkowski> HakanS: what has worked in some cases is a team of 3 leaders
[11:15] <czajkowski> where there is not one above the other but they work together
[11:15] <czajkowski> passing the information to the team, organising events and team reporting
[11:16] <czajkowski> california is a good example of this
[14:00] <akgraner> Up next for Ubuntu Open Week in #ubuntu-classroom and #ubuntu-classroom-chat at 1400 UTC is How to contribute translating Ubuntu -- David Planella (dpm)