[00:54] <cpete> Hello hello, would anyone be willing to look at my merge proposal against ubuntu-dev-tools? https://code.launchpad.net/~cpete/ubuntu-dev-tools/+git/ubuntu-dev-tools/+merge/459002 ? I addressed some of your feedback from last time LocutusOfBorg if you want to take a look again
[08:20] <adrien> xz switches its core components from PD to 0BSD: https://raw.githubusercontent.com/tukaani-project/xz/master/NEWS (not that I believe it affects us much, if at all)
[08:40] <dnegreira> Hi, I would like to take maintainership of a package - sosreport - as our colleague unfortunately passed away last year. What would be the best way to go about moving the maintainership?
[09:20] <ivoks> dnegreira: see https://wiki.ubuntu.com/nkshirsagar/UbuntuPerPackageUploaderApplication as an example and https://wiki.ubuntu.com/UbuntuDevelopers#PerPackage
[09:30]  * sudip was also looking for PPU info.. thanks ivoks
[10:30] <LocutusOfBorg>  cpete fine for me now!
[10:33] <juliank> @pilot in
[10:34] <juliank> Please ping me if I forgot to pilot out :)
[10:34] <juliank> I am busy going through the 46 or whatever patches in the queue though
[10:57] <rbasak> juliank: could you check the apt version string in your jammy unapproved upload please?
[10:58] <juliank> rbasak: Did I mess stuff up? Sorry, I checked building and suite but did not check version string
[10:58] <juliank> rbasak: Oh the apt
[10:59] <juliank> rbasak: This is correct, it's an apt upstream branch targetted at jammy
[10:59] <juliank> All LTS branches follow upstream maintenance and also have other downstream users
[10:59] <rbasak> Hmm.
[10:59] <rbasak> This is very unusual :-/
[10:59] <juliank> You'll find going through the apt uploads it's always been this way since xenial
[10:59] <juliank> for lts
[11:00] <rbasak> What happens if Debian needs an upload with this version string?
[11:00] <rbasak> Then they'd mismatch in contents.
[11:00] <juliank> It doesn't
[11:00] <rbasak> Even if not this time, what about the pattern generally?
[11:01] <juliank> Debian is always off by 2 vs an LTS
[11:01] <rbasak> There are some other general assumptions this breaks
[11:01] <rbasak> Ubuntu developers might assume that '2.4.12' means that it was synced and therefore existed in Debian, but this won't.
[11:02] <rbasak> (though admittedly that situation does exist for some Ubuntu-only packages but that doesn't mean it's right, and this case is a different pattern to that one)
[11:02] <juliank> But it shows them this was an upstream apt upload
[11:02] <juliank> And it vastly simplifies the story when there's critical fixes to tell users upstream apt versions
[11:03] <juliank> And the other downstreams use the LTS branches too
[11:03] <rbasak> You could still do that - 2.4.12ubuntu0.1 would convey the upstream version
[11:03] <juliank> It would imply there is an Ubuntu specific delta when there isn't
[11:03] <rbasak> There is - in debian/changelog
[11:04] <rbasak> It says "jammy"
[11:04] <rbasak> That's Ubuntu-specific
[11:04] <juliank> I have purposefully aligned all apt versioning and branching schemes in 2016 to be able to directly deliver things like this
[11:05] <rbasak> This breaks Ubuntu's SRU versioning patterns though :-(
[11:05] <juliank> The versioning pattern is a suggestion, not a rule
[11:06] <juliank> snapd these days uploads all releases as <snapd release>+<ubuntu release>.1
[11:06] <rbasak> I agree that it's currently not a rule. But by varying from the suggestion, I now have to consider all the implications to understand if it's acceptable.
[11:07] <rbasak> snapd is covered by my "admittedly that situation does exist for some Ubuntu-only packages" above.
[11:07] <rbasak> Anyway, I think I understand your position and you understand mine. Let's get a wider opinion on this and we can do whatever the consensus is.
[11:07] <juliank> So noble will release with 2.8.x, and it may even then get 2.8.x+1 synced from Debian (via way of fakesync to make it SRU-reviewable)
[11:08] <juliank> (as in, we upload the changes so you get a source diff)
[11:08] <juliank> But it's more likely I'll bump Debian to 2.9.0 straight away
[11:08] <rbasak> If it's agreed to do it this way, then we should document SRU team agreement under https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases so this doesn't get delayed next time by another SRU team member surprised/confused by this.
[11:09] <juliank> I usually just ping sil2100 and he accepts it :D
[11:10] <juliank> But bdmurray also accepted apt SRUs
[11:11] <juliank> and possibly various others
[11:11] <juliank> RAOF accepted 1.6.17
[11:11] <rbasak> Fine, but new SRU team members aren't going to magically know.
[11:11] <rbasak> We need to get this stuff documented.
[11:11] <juliank> It's fine but you're the first one to raise this in 8 years
[11:14] <juliank> We also need to fix up a lot of SRU exception thingies for grub and fwupd and shim which all use signed UEFI binaries which can only ever land as binary copies from the UEFI proposed-public PPA
[11:14] <juliank> not to mention that those get binary copies of binaries built in latest stable release none of which has SRU team approval as a general practice
[11:14] <rbasak> I'm more sensitive to this kind of thing because of git-ubuntu. So many edge cases. *I* understand that version strings are more general than the simple view, but edge cases like this just makes it harder to onboard new people into packaging. It's no wonder many developers can never follow what's going on with package version strings. Sticking to established patterns would make things simpler for
[11:14] <rbasak> everybody, even if it's technically correct to vary it.
[11:15] <rbasak> s/correct/acceptable/
[11:16] <rbasak> I haven't raised it yet, but one day I'd like to for us switch to ubuntu<IP_ADDRESS> pattern always, instead of only when there could be two ubuntu0.1 for example. And stop doing ubuntu5 in an SRU, favouring ubuntu4.1 instead.
[11:16] <rbasak> That would just make simpler the rules new developers have to follow, even if the currently used system works fine.
[11:17] <rbasak> Part of that is to expect _everyone_ to stick to the pattern, even though the old ones work, because new developers also learn by observing what experienced people are doing.
[11:18] <juliank> And part of apt upstream versioning scheme is to discourage people from doing uploads themselves such that everything going into APT LTS uploads goes through APT LTS release process and QA
[11:18] <juliank> So if someone does do an ubuntu0.1 and I don't catch it you can see it does not have the APT team seal of approval
[11:19] <juliank> I'm running a very tight ship on the APT release pipeline :)
[11:20] <rbasak> We all know (or should know) it's preferable to avoid adding delta. That applies to every package. We should not damage/distort our versioning patterns for the sake of establishing that.
[11:22] <juliank> In python-apt you can see a mix of that, uploads from me go through the upstream release process and have the upstream version numbers, whereas the release team uploads ubuntu0.x uploads when doing point releases to refresh the mirror lists
[11:23] <juliank> Which is reasonable for us to not do an upstream release for because that's a data-only change
[11:24] <juliank> The separation was more meaningful when I was not biased by employment in what I accept in stable branches (I may be now I don't know :D)
[11:25] <rbasak> you're the first one to raise this in 8 years> IMHO, the SRU team is dying by a hundred papercuts like this. The old guard have this stuff in their heads; the newer members have to learn this obscure differences, for IMHO reasons that don't justify the edge cases. This doesn't scale. We should seek to find patterns that work for everyone, follow those, have fewer edge cases and document them all.
[11:25] <juliank> Now for most intents and purposes, APT pretty much is an in-house project
[11:25] <rbasak> *these
[11:28] <juliank> We should also get a better wiki
[11:29] <juliank> Anyhow can I do my patch pilot shift now?
[11:38] <juliank> rbasak: I wrote a wiki page to document it https://wiki.ubuntu.com/AptUpdates
[11:44] <rbasak> Thanks! Let's see what others' opinions are on this. Tha page will help.
[11:49] <juliank> rbasak: I forgot to do prepare-upload for https://code.launchpad.net/~vpa1977/ubuntu/+source/cava/+git/cava/+merge/460303 could you close that out for me?
[11:50]  * juliank uploaded non-git uploads in between and used wrong line in history
[12:01] <rbasak> Done
[12:12] <juliank> Thanks!
[12:12] <juliank> @pilot out
[12:13] <juliank> That's my pilot shift for today, 8 uploads done
[12:14] <juliank> So we should be down from 46 to 34 or so with the additional unsubscribe review work
[12:15] <juliank> I should have done the syncs maybe but I went in order :(
[12:38] <sudip> juliank: thanks for looking at all my bug reports. but I see you rejected LP: #2052836, rbasak asked for that one at https://bugs.launchpad.net/ubuntu/+source/lcov/+bug/2051166/comments/5
[12:38] -ubottu:#ubuntu-devel- Launchpad bug 2052836 in lcov (Ubuntu) "Enable tests during build" [Undecided, Won't Fix] https://launchpad.net/bugs/2052836
[12:38] -ubottu:#ubuntu-devel- Launchpad bug 2051166 in lcov (Ubuntu Mantic) "[SRU] lcov  2.0-1 FTBFS on Mantic" [Undecided, Fix Committed]
[14:18] <juliank> sudip: I believe in context with the SRU following Debian for the SRU is better than introducing a delta in devel that we continuously need to maintain when it offers little value
[14:19] <juliank> Optimally as I said, get the change in Debian landed then you can just do the SRU with test cases enabled and it will match noble and we avoid committing to endless work
[14:19] <juliank> If I were to see this in noble+1 it would be a delta I'd drop with a force sync
[14:23] <rbasak> juliank: you would *regress* Ubuntu by disabling tests in a force sync?!
[14:25] <juliank> Yes if the package shows high on the merges list and that's the only delta I'd absolutely do this
[14:25] <juliank> If there's a person regularly merging the package it won't come to my attention
[14:25] <rbasak> I think you're resisting a delta too hard.
[14:25] <rbasak> It would be trivial to merge.
[14:26] <juliank> Doesn't mean it happens though, if it does all is well, if it stagnates half the cycle then nobody cares and we drop it
[14:26] <juliank> Especially for a universe package it can be dangerous
[14:27] <rbasak> Then I think the right question to ask the sponsoree is: "are you prepared to maintain the delta, or who is?"
[14:27] <juliank> Possibly
[14:28] <tjaalton> re: standardized sru version numbers? yesplease
[14:31] <sudip> well, I dont mind maintaining the delta, there is a MR for this in salsa, so delta will be dropped as soon as the maintainer accepts that (or rejects with a reason)
[14:31] <rbasak> Thanks
[14:31] <rbasak> I'll sponsor your upload to Noble, and ask juliank to refer to sudip to merge it rather than drop it.
[14:31] <rbasak> Seeing as you've already done the work, and otherwise you're just stuck between two Ubuntu developers with different opinions.
[14:33] <sudip> thanks rbasak
[14:38] <rbasak> sudip: so the only thing I'd do there is say that you're re-enabling tests in the changelog. That's the crucial bit that isn't mentioned. So for example "Re-enable tests by disabling threads while building. Tests are failing with multiple threads. (LP: #XXX).
[14:38] <rbasak> Are you OK with me just changing that?
[14:39] <sudip> rbasak: yeah, sure. thanks
[14:39] <rbasak> Because enabling tests is the entire purpose of this delta that we're adding, and the future person merging it will need to know that.
[14:39] <rbasak> Thanks.
[14:39] <rbasak> Hopefully there will be no need to merge it though because the next Debian upload will include this ;)
[14:39] <sudip> hopefully
[14:45] <ginggs> sudip: I suggest filing a bug report in Debian too, unless you know the maintainer looks at MRs in Salsa
[14:46] <sudip> ginggs: I was expecting the maintainer looks after seeing https://salsa.debian.org/mckinstry/lcov/-/merge_requests/1
[14:46] -ubottu:#ubuntu-devel- Merge 1 in mckinstry/lcov "d/control: add Depends on libdatetime-perl, libcapture-tiny-perl" [Merged]
[14:46] <sudip> but I will open a bug today
[14:48] <rbasak> FWIW, I think my general rule is that we don't sit around in Ubuntu waiting for Debian to accept a patch *if* for some reason it's blocking progress in Ubuntu. Either we decide it's not worth it and don't do it at all (which in this case would correspond to not bothering with the SRU, but it seems worth doing the SRU given the package is completely unusable) or we should just add the delta.
[15:02] <juliank> I align with that rule but I'm 180° different on how that should work
[15:08] <juliank> SRU bug being solved by a different better approach than in devel is not necessarily enough grounds to change devel as well, that's clearly where I'd draw the line and say "let's submit it to Debian" but the bug is fixed in devel as required by SRU policy, so it's just annoying
[15:10] <rbasak> The sole purpose of the "fix in development release first" SRU policy is so that users won't face a regression on upgrade. Disabling tests seemed like something that is the opposite of that. I'm not sure if we can call any bug "fixed" if, to do so, we had to disable the entire test suite. That would mean that users still face a regression upgrading up to Noble - or at least we no longer even know if
[15:10] <rbasak> they do or not.
[15:10] <rbasak> The fact that the disabling of tests came as a sync from Debian is a complication, but from an SRU perspective I only care about the change that was applied to Noble, not who made it.
[15:11] <juliank> Also why do we disable threads for the entire build rather than just the tests
[15:11] <rbasak> Feel free to fix it better :)
[15:12] <rbasak> My philosophy here is that an incremental improvement is better than no improvement, so I'm not going to reject it just because we can imagine something better. Perfect is the enemy of the good.
[16:37] <cpete> LocutusOfBorg: Thank you for your review!
[21:28] <dbungert> LocutusOfBorg: I'm no perl expert but I'm looking at https://git.launchpad.net/ubuntu/+source/dpkg/commit/?id=b80bc1cb34e560281a030312eef7c16f4b0c2963 and I think it's logically equivalent?  Am I missing something?
[21:28] -ubottu:#ubuntu-devel- Commit b80bc1c in ubuntu/+source/dpkg "1.22.4ubuntu3 (patches unapplied) HEAD import/1.22.4ubuntu3 ubuntu/noble-proposed ubuntu/noble-devel ubuntu/devel"
[21:33] <dbungert> LocutusOfBorg: disregard, I get it
[22:46] <rbasak> Oops. Sorry about the lcov changelog wrapping fail when I edited it.


[00:00] <cobraeriko> leftyfb: ok, I get it. Thankfully the UID's for the users do match. It worked. Thanks
[00:08] <meingtsla> ravage: Thanks for confirming the torrent file to use, though I'm still encountering the same error.
[00:12] <natewrench> https://youtu.be/xjIGUo6Eiag its sad i use ubuntu yet its still looked down upon
[00:29] <marcopolo1_>  I installed some windows cursor on gnome tweaks and now nothing on my pc is responding
[00:29] <marcopolo1_> Terminal wont open files wont open
[00:29] <marcopolo1_> Reboot doesnt fix it
[00:30] <rbox> so delete whatever files you added
[00:32] <marcopolo1_> How
[00:32] <rbox> boot a live image
[00:32] <rbox> or boot into rescue mode
[00:33] <marcopolo1_> Is rescue mode in grub
[00:35] <rbox> yes
[00:38] <akik> EriC^: installing macos security updates resets the uefi boot order back to macos but i can live with that :)
[00:42] <EriC^> :)
[00:45] <akik> EriC^: woah
[00:46] <EriC^> ?
[00:46] <akik> EriC^: refind puts itself as 0080 in uefi boot order
[00:46] <EriC^> ah
[00:46] <akik> Boot0080* Mac OS Xard HD(1,GPT,00004a55-5b0c-0000-034e-0000fe360000,0x28,0x64000)/File(\EFI\refind\refind_x64.efi)
[00:46] <EriC^> so it was the culprit?
[00:47] <akik> i don't know what's the issue
[00:47] <akik> when it wasn't working, i didn't have it yet installed
[00:48] <akik> or maybe it was that i hadn't set the csrutil disable yet
[00:50] <akik> apple.stackexchange.com title is "ask different" :)
[00:53] <EriC^> heh :D
[00:54] <meingtsla> I enabled DHT in my torrent client, so we'll see if that allows me to seed the torrents...
[01:26] <Annoyed> Greetings. Ubuntu server MOTD has been suggesting their pro service as of late. Anyone have any feedfack regarding that? Also, can you remove it if Ubuntu does something nasty in the future, like wanting to charge for it?
[01:27] <rbox> what?
[01:31] <Annoyed> For server 22.04.2, ubuntu has been promoting their extended support program, 'ubuntu pro" for a while now. Just wondering if anyone has any feedback about it
[01:33] <rbox> feedback?
[01:40] <mybalzitch> I got my free account, registered my machine, and I no longer see the nag screen
[01:40] <akik> do you control the computer or does it control you?
[01:43] <Annoyed> I don't care about the nag screen; this is an important machine in my home. Just wondering if there are any major headaches with it
[01:44] <mybalzitch> if you want an extended period of updates for the 22.04 release, then you might want to get a free sub if the machine is used for non-commercial purposes
[01:45] <Annoyed> And control is shared. Damned thing needed two hours of nursing after a power failure Friday. It's on a UPS, so proper shutdown, but getting everything in the house working right again was a P.I.T.A.
[01:45] <mybalzitch> its likely not going to get any more broken w/ the updates enabled
[01:46] <Annoyed> Oh, it's a non-commercial use.. It's my head end/router/file server/media server box. Basically everything in the house uses it
[01:59] <Bashing-om> annexseven: May I direct your attention to https://discourse.ubuntu.com/t/ubuntu-pro-faq/34042 - for the full skinny :D
[02:00] <Bashing-om> annexseven: Opps - bad hilight - OP left :(
[02:50] <veronica_rojas> alguien para hablar de sexo?
[02:51] <wwwww> @mods ^^
[03:03] <cobraeriko> I am trying to get my host machine to ping my ubuntu server VM, for which I set a static IP address. My host machine has network interface enp0s25. Do I need to use this same network interface, enp0s25, in /etc/netplan/01-netcfg.yaml of the guest machine for my guest machine to be able to ping? (I am a bit new to networking)
[03:03] <wwwww> cobraeriko: you might try ##networking
[03:04] <wwwww> sorry #networking
[03:04] <cobraeriko> wwwww: will do thanks
[03:11] <arraybolt3> wwwww: "!ops" is probably the command you were looking for, in the event you're around when something like that happens next.
[03:11] <wwwww> arraybolt3: got it thanks
[03:15] <nacuk> g
[03:55] <jhutchins> wwwww: It's not really an offense for someone to ask somthing like that - once.
[03:55] <jhutchins> Polietely clarify the purpose of this channel, and if they don't vanish, then you can call the ops.
[03:56] <jhutchins> Actually, it's a pretty safe bet they have no interest in Ubuntu problems.
[03:56] <wwwww> jhutchins: i see
[03:56] <wwwww> jhutchins: yeah that was my thought
[06:14] <Johnblood> Hi
[06:14] <Johnblood> I need some help with my wifi
[06:24] <Johnblood> I'm connected to my wifi, but there is not internet. Also the status bar shows an ethernet logo instead of a wigi logo.
[06:35] <Peppi^> hello
[06:35] <Peppi^> does anyone know anything about controlling fans?
[06:36] <Peppi^> Like if you are using a PWM fan can the OS turn on / off the fan not only based on the cpu but also on the temperature of the hard drives?
[09:06] <Baphomet_> what is up my fellow nerds
[09:09] <confuseus> Hello Dunning-Kruger.
[09:18] <downeast> Baphomet_: hello :)
[09:37] <petaflot> hello!I'm wondering how can I fix the "Error loading new keyboard definition" when running `setxkbmap fr_CH-latin1`
[09:38] <ShaedS> what are some network diagnostic thjings i can do for this vpn problem
[09:38] <ShaedS> client is connecgted but no traffic is going across
[09:41] <Baphomet_> uwu
[09:43] <Baphomet_> anyone got some interesting irc channels to reccomend?
[09:43] <lotuspsychje> !alis | Baphomet_
[09:44] <Baphomet_> bro tried to take my alias lol
[10:47] <WilhelmII> offtopic question: is firefox support available anywhere other than discord
[10:48] <lotuspsychje> WilhelmII: there's a #firefox channel on libera
[10:48] <WilhelmII> its basically dead
[10:48] <lotuspsychje> WilhelmII: and if you encounter bugs on firefox snaps, you might wanna look upstream
[10:49] <lotuspsychje> WilhelmII: contact:   https://support.mozilla.org/kb/file-bug-report-or-feature-request-mozilla
[10:49] <WilhelmII> the bug really probably is Google's but sadly firefox might need to work around it
[12:33] <route-bee> hey guys and gals... can any of you tell me how to get around this problem... https://askubuntu.com/questions/1456783/i-want-to-share-virtualbox-v7-0-6-vms-between-users-on-ubuntu-22-04-lts-but-the
[13:33] <BluesKaj> Hi all
[13:50] <akik> where do i change the window titlebar colors so that the active window titlebar would be blue? (ubuntu 22.10 with gnome)
[13:50] <akik> now they are all grey
[13:51] <akik> except terminal is dark grey
[14:05] <jim> hi, what's the name of the app that shows the DSP connections? (maybe in jack?)
[14:09] <ioria> jim, have you tried pulseaudio-utils ?
[14:11] <jim> I'm looking at dpkg -L pulseaudio-utils
[14:13] <ioria>   jim /usr/bin/padsp maybe or another pkg , like oss4-base
[14:13] <jim> I didn't find anything that displays the connections
[14:13] <jim> looks like padsp does something else, starts a program and connects it
[14:14] <akik> jim: do you mean like jack connections?
[14:14] <ioria> oss4-gtk ?
[14:14] <jim> I'll look at oss4-gtk in a moment
[14:15] <jim> akik, is there something that displays jack connections? I remember a black rectangular window
[14:15] <akik> jim: catia
[14:16] <jim> do I have that
[14:16] <akik> jim: there's also two other apps for pipewire mentioned here: https://wiki.archlinux.org/title/PipeWire
[14:16] <akik> catia is good
[14:16] <jim> on the arch wiki?
[14:17] <jim> catia is part of cadence
[14:17] <jim> and yes it is good... I built a package of it (and the other pieces of cadence)
[14:18] <jim> but watch out for the cadence packages, the guy wasn't careful about the depends, and I ended up having to reinstall the entire os
[14:19] <akik> i think i used the kxstudio repository for them
[14:19] <jim> yeah
[14:20] <jim> I think the guy's name is falktx
[14:20] <akik> yes
[14:20] <akik> he's on #kxstudio and #ardour
[14:21] <jim> good programmer, but can't be convinced the deps are important
[14:23] <akik> https://kx.studio/Applications:Catia
[14:57] <Guest56> HI all, quick help please, my appImage applicattions have stopped working suddenly on 22.04 eg. Evernote - running one day, not running the next... no errors, no nothing, just doesn't run
[14:57] <Guest56> I have the fuse libreary installed, the properties on the appImage right but just don't run - any help appreciated
[14:58] <Jeremy31> Guest56: Try running the appimage from terminal
[14:58] <Guest56> Jeremy31any specific command to run an appImage
[14:58] <Guest56>  ?Jeremy31any specific command to run an appImage
[14:58] <Guest56> Jeremy31any specific command to run an appImage... ?
[15:00] <Guest56> hey finally some error messages :-)  Thanks Jeremy31
[15:00] <Guest56> I got the following:
[15:00] <Guest56> Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
[15:00] <Guest56> qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
[15:00] <Guest56> This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
[16:13] <sinvet> what does it mean when ubuntu apt upgrade says that some packages are kept back ? I dont remember seeing such things in the older days
[16:14] <leftyfb> !phasedupdates | sinvet
[16:17] <sinvet> leftyfb, cool way to answer, thanks
[16:39] <flataerth> does anyone if there's a channell about bmws or kar help?
[16:40] <flataerth> i'm locked out of my kar without the battery on lol
[16:40] <flataerth> never happened before
[16:40] <flataerth> so i can't get into anything
[16:40] <lotuspsychje> !alis | flataerth
[16:40] <flataerth> i understand but was wondering if anyone here had this happen to them
[16:40] <lotuspsychje> this is ubuntu support flataerth
[16:41] <leftyfb> flataerth: completely offtopic. Feel free to ask in another, more relevant channel.  Define your context
[17:22] <flataerth> my font kolor here whey i type
[17:22] <flataerth> it's always showign block?
[17:22] <flataerth> black
[17:22] <Menzador> Depends on your client
[17:23] <Menzador> Additionally some channels have colors disabled (+c)
[17:42] <jhutchins> flataerth: You appear to be using xchat.  This might interest you: http://xchat.org/themes.html
[17:50] <spinull> I have a situation where when i activate a VPN from my provider, my system becomes unresponsive for about 10-15 seconds, periodically.
[17:50] <spinull> Other VPNs don't cause the issue, and to be clear, its nothing to do with connectivity/speed
[17:54] <spinull> I don't see anything in syslog to indicate why its happening, except that when the system becomes unresponsive, i see a "systemd[1]: Starting Hostname Service..." message, but that also shows up when connecting another vpn that doesn't cause the issue
[17:58] <ni638629> How do I boot Linux from a specific partition on grub menu or boot option?  Which removing the MOTD message about ESM will do.
[18:19] <spinull> maybe he did
[18:19] <iconoclasthero> @ravage, no that command to modify /etc/update-motd did not fix it
[18:20] <iconoclasthero> I followed solution one at https://askubuntu.com/questions/1453749/inhibit-esm-messages-at-login and forced the motd to rebuild
[18:20] <iconoclasthero> that worked
[18:20] <ravage> great
[18:20] <iconoclasthero> why ua/pro didn't is a question f/the developers since i get an error with sudo ua disable esm
[18:21] <iconoclasthero> unless that isn't what ua actually dies
[18:21] <iconoclasthero> does
[18:21] <ravage> the disable command does not turn off any notifications
[18:21] <iconoclasthero> yeah
[18:21] <iconoclasthero> i'm coming to realize that
[18:22] <iconoclasthero> still, why is this the error message:
[18:22] <iconoclasthero> $ sudo ua disable esm
[18:22] <iconoclasthero> Cannot disable unknown service 'esm'.
[18:22] <iconoclasthero> if man ua states specifically, "disable [cc-eal|cis|esm|fips|fips-updates|livepatch|ros|ros-updates]"
[18:23] <spinull> poor coding
[18:23] <iconoclasthero> obviously esm is supposed to be a known servicw
[18:23] <iconoclasthero> e
[18:23] <ravage> "pro status" shows all services
[20:07] <Rythen> Hello, I'm using Ubuntu 20.04.  Today I just set up a KVM switch to toggle between two different computers (one has windows, one has Ubuntu).  However, when I switch back to my Ubuntu computer the displays keep flashing on and off as if it's trying to detect them or something and this keeps happening indefinitely until I unplug the display cables
[20:07] <Rythen> and plug them back in, at which point the displays will work.  However my windows computer detects the displays just fine when I toggle back to Windows.  This makes me think it's an OS type problem in Ubuntu.  Does anyone know what type of things I could check?  I've googled around a bit but not had a lot of luck so far.
[20:09] <Rythen> And when I say flashing I mean the monitors will keep turning off and on as if they keep picking up a signal but then losing it again.  Sometimes a desktop will appear on one of the screens momentarily before it goes away again.
[20:11] <Rythen> Would this be something my xorg logs would shed light on?
[20:14] <spinull> anyone know why enabling a VPN connection that redirects all traffic through the vpn, would cause the system to become unresponsive?
[20:14] <spinull> not a connection problem, vpn works fine, but things like gnome/nautilus become unresponsive until i can kill the vpn
[20:15] <spinull> theres no mounted remote shares, and the issue stops when i don't use the vpn as the gateway
[20:16] <spinull> happens with openvpn, wireguard, open connect, with different servers/configs. ONLY when the vpn is the gateway
[20:22] <mwette> Rythen: I thought most all logging now goes to journal, which can be read using journalctl.
[20:22] <Rythen> mwette You are likely right... I'm not super experienced at debugging hardware type issues like this
[20:25] <Rythen> All I really see in the journalctl logs is messages that look like screens disconnecting and reconnecting but I'm not sure it's telling me much about the cause of that
[20:34] <Rythen> Seems like updating my intel GPU drivers may have solved the issue
[20:34] <Rythen> I didn't realize that updates for those had to come from a separate repository and wasn't in the base repo
[20:34] <Rythen> so I guess it hadn't been getting updates
[20:35] <mwette> great.   is 20.04 X11 or Wayland?
[20:39] <Rythen> mwette are you asking me?
[20:40] <mwette> Rythen: yep
[20:42] <mwette> does `ps -ef | grep wayland` give anything like gdm-wayland-session
[20:42] <mwette> I'm on 22.10, which is wayland.
[20:42] <Rythen> No it doesn't show anything
[20:43] <Rythen> Also my xorg.log file has stuff in it, would that be the case if it was wayland?
[20:43] <mwette> Thanks. Yes.  I have no xorg.log file.
[20:47] <Rythen> I wonder if I should upgrade to 22 at some point.  I went with 20.04 cause I use this computer for work and it's LTS.  I'm gunna have to do a reinstall at some point in the next month or 2 though so maybe I should consider upgrading.
[20:51] <jhutchins> Rythen: Might as well be solving new problems rather than old ones.
[21:03] <WeeBey98> Question: Is it normal that with Wayland, screenshot apps don't work or crash. And Guake also crashes ... And with Vmware or VirtualBox mouse input is erratic?
[21:06] <jhutchins> WeeBey98: Depends on what you mean by "normal".  Wayland is still under development..
[21:10] <Habbie> also, "wayland" is a protocol. Do you mean GNOME in wayland mode?
[21:11] <WeeBey98> jhutchins, Hmm. I see ... Ok. I thought it was more mature since it's selected as default, if I'm not mistaken.
[21:12] <mwette> Screenshot has worked for me. (and yes, this is GNOME in wayland mode)  -- using weston implementation?
[21:12] <jhutchins> WeeBey98: Pushing systems as defaults is a great way to get a lot of attention on them.  More bug reports, more people interested in finding and fixing them.
[21:12] <Habbie> i've been on gnome wayland on debian for years, with very little trouble
[21:12] <Habbie> gnome screenshot app has worked fine for me
[21:12] <Habbie> it wouldn't surprise me if some other screenshot apps aren't compatible yet though
[21:12] <jhutchins> Habbie: So you have no knowledge of problems with it, and no ideas how to fix it, right?
[21:13] <Habbie> oh i have a small list of problems, but no fixes, no
[21:15] <mwette> I've written a wayland protocol-level (i.e., using sendmsg, recvmsg) client toy.  It has one line of code that instantly crashes my session on 22.10.  On 22.04 it crashed the display manager.
[21:15] <Habbie> 'nice'
[21:16] <mwette> haha: right
[21:17] <WeeBey98> jhutchins, It's interesting because Gtk 42.something (can't remember) had a pretty awful bug when 22.04 shipped. But it was only on X11. So I tried Wayland but I had so many other issues, that I had to live with other bug until a patch came.
[21:19] <WeeBey98> and Habbie yes, the default screenshot app works but others don't. What I liked of others is that I could screenshot and I would get a preview and I could drag that to other apps. Or, with Flameshot, I can draw on them, copy to clipboard, then paste somewhere.
[23:29] <wanderson> hello
[23:35] <wanderson> hello
[23:35] <Habbie> !ask
[23:38] <wanderson> fuck you
[23:46] <esv_> sorry folks, I know it sounds silly but I just can't get to the download page for the live image for 22.04, pointers would be appreciated
[23:52] <krytarik> esv_: https://releases.ubuntu.com/jammy/
[23:56] <esv> guess there is no live desktop :D
[23:57] <esv> thanks, the file is on my pc, burning the usb key now
[23:57] <arraybolt3> esv: The main installation ISO offers the option of "Try Ubuntu" when you boot it.
[23:57] <arraybolt3> So it works as a live ISO too.
[23:58] <krytarik> As says the desciption on that page too.
[23:59] <esv> ya, I've been trying to get off a pickle, whenever I install ubuntu 20.04 I get a message


[08:34]  * smb yawns
[09:00]  * apw yawns more
[09:07]  * infinity yawns most
[09:08]  * smb steps back and watches apw and infinity duke out who has the biggest...
[09:08] <ogra_> kids these days
[09:42] <diwic> apw, thanks for your review yesterday - just a question, you mentioned I haven't signed off all patches, but all patches have at least one sign-off from me already, since I wrote the patches originally
[09:42] <diwic> apw, did you expect two sign-off lines from me?
[10:06] <apw> diwic, the original signed off the origina, for the ones which have conflicts and therefore (additionally) be converted from cherry-picked to backported, those i normally add a new one  for the backprot, so we know who did that backport
[10:06] <apw> if that makes sense at all
[10:06] <diwic> apw, ok, I can add a second sign-off where there are conflicts
[10:07] <diwic> apw, I hope to send out a second set today that can be applied
[10:07] <apw> otherwise it looks like i am the one who did it if you see what i mean
[11:35] <jcz> while decompressing, does the kernel use any additional memory besides the one the kernel is loaded on?
[12:04] <ppisati> kees: http://paste.ubuntu.com/6458162/
[12:04] <ppisati> kees: actually there's a reason why it doesn't compile
[12:10] <ppisati> kees: flag@flag-desktop:~/seccomp/tests$ gcc -dM -E  seccomp_bpf_tests.c  | grep EABI
[12:10] <ppisati> #define __ARM_EABI__ 1
[12:10] <ppisati> kees: can yo do the same on the box where you said you compiled that test?
[12:46] <TooLmaN> To show my age and lack of attention to source building, when did compiling start supporting multi-core processing  (-j4)?
[13:59] <brendand> TooLmaN, quite a long time
[13:59] <brendand> TooLmaN, i could look it up but at a guess i'd say 5-6 years
[14:08] <TooLmaN> brendand:  That shows how long it's been since I compiled anything lol.  I'm back to rolling kernels for ARM devices like RPi and Beaglebone.
[14:35] <infinity> brendand: You're off by a decade or two.
[14:35] <infinity> TooLmaN: make's supported forking via -j for pretty much ever, but most people never used the option when they only had one CPU. :P
[14:36] <brendand> infinity, that explains why i only encountered it 5 years ago
[14:37] <TooLmaN> infinity: Interesting.  I guess I haven't delved deep enough into make's powers.  Thanks
[17:11] <backjlack> Hello!
[17:13] <backjlack> I've run into some problems with kernel 3.5 & 3.8 on 12.04 and with kernel 3.11 on 13.10. AR9462 is losing the state of the radios across boots, reboots and sleeps.
[17:14] <backjlack> fresh boot: bluetooth and wlan -> both active, press fn+F3 to cycle through the various states to get to WLAN ON, bluetooth OFF, sleep & wake -> bluetooth is active again
[17:14] <backjlack> reboot -> everything is active again
[17:15] <backjlack> This was running as expected on 12.04 with kernel 3.2.
[17:16] <chilicuil> hello, I'm trying to build an ubuntu kernel package with -ck patches, so far I'm able to do it by taking upstream sources, applying -ck patchset + ubuntu packaging stuff (http://kernel.ubuntu.com/~kernel-ppa/mainline), however I'd like also to include ubuntu sauces, is there any guide where I could see how to apply them or where to download them from?
[17:24]  * ppisati -> EOW
[20:15] <jtaylor> out of curiosity, why is swapaccounting not enabled in ubuntu by default? required for swap control in cgroups
[20:16] <jtaylor> can't find any downsides mentioned in the docs
[20:17] <jtaylor> CONFIG_CGROUP_MEM_RES_CTLR_SWAP I guess
[20:19] <jtaylor> nevermind found some downsides on http://cateee.net/lkddb/web-lkddb/CGROUP_MEM_RES_CTLR_SWAP.html


[00:00] <thumper> I added a constraint that a new environment should have the same provider type as the state server environment
[00:00] <thumper> well, default
[00:00] <thumper> not constraint
[01:37] <jw4> thumper: I've not been able to reproduce the bug 1412292 - are those errors happening consistently for you?
[01:37] <mup> Bug #1412292: Intermittent test failure in ActionSuite.TestActionsWatcherEmitsInitialChanges <action> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1412292>
[01:37] <thumper> jw4: about one time in three
[01:38] <jw4> thumper: hmm; do you have a fast machine, or a slow one - or is it PPC - or anything like that?
[01:38] <thumper> two year old fast i7, lots of ram and fast ssd
[01:38] <jw4> thumper: kk - I'll try picking apart the logic to see what I can find
[01:38] <thumper> ok
[01:59] <menn0> thumper: Fix it, then Ship it
[01:59] <jw4> thumper: two quick questions - 1) I assume the defect report has the full output of the test run. Is that true? 2) what version of go are you using?
[02:00] <jw4> thumper: fwiw I suspect the problem is the watcher isn't getting updated in time that the two actions were removed
[02:42] <thumper> menn0: ta
[02:42] <thumper> jw4: using what ever version is in trusty
[02:42] <thumper> jw4: I'm guessing it is a race condition
[02:43] <thumper> jw4: but I've not looked at the code
[03:20] <thumper> man...
[03:20] <thumper> getting endorsements on linked in by folk I don't remember linking to
[03:21] <thumper> oh... he is a juju gui peep
[03:25] <axw> wallyworld_: about to send an email to fwereade for some advice on the state model, I've CC'd you in case you have ideas on it
[03:25] <wallyworld_> ok
[03:26] <axw> the relations to units and services are feeling a bit messy
[03:26]  * thumper finishes the apiserver httphandler before enfixorating the branch menno reviewed
[03:50] <thumper> menn0: I have another branch that fixes the rest of the apiserver
[03:50] <thumper> menn0: I just need to write tests for each of the api end points to exercise the additional environment
[03:52] <menn0> thumper: sweet
[03:52] <menn0> thumper: i'm deep into integrating envWorkerManager into the machine agent
[03:52] <thumper> awesome
[03:52] <thumper> I feel the pieces are slowly coming together
[03:52] <menn0> thumper: lots of awkward details to figure out
[03:53] <thumper> menn0: yep, I know
[03:53] <thumper> menn0: so many fiddly bits
[03:53] <menn0> thumper: e.g the singular runner
[04:15] <thumper> boo... hiss...
[05:08] <thumper> damn
[05:08] <thumper> I bet that two line tweak might break something
[05:14] <thumper> I'm done
[05:14] <thumper> these tests are taking ages to write
[05:14] <thumper> laters
[07:05] <dimitern> morning all
[07:13] <anastasiamac> dimitern: morning :) 5pm here tho
[07:13] <dimitern> anastasiamac, afternoon then :)
[07:14] <anastasiamac> dimitern: thnx for consideration :)
[07:14] <anastasiamac> dimitern: one thing i miss about Nothern hemisphere - r long dusks in summer
[07:14] <dimitern> anastasiamac, oh, they're not so long there?
[07:15] <dimitern> anastasiamac, I'd have a hard time adjusting to summer in january :)
[07:16] <anastasiamac> dimitern: with +40 and an awful humidity, u will not mistake this for winter!
[07:16] <anastasiamac> dimitern: there is no dusk :(
[07:16] <dimitern> anastasiamac, *lol*
[07:16] <anastasiamac> dimitern: one minute it's day, the next night
[07:16] <anastasiamac> dimitern: there r millions of other advantages tho :)
[07:17] <dimitern> anastasiamac, that is a bit weird
[07:17] <anastasiamac> dimitern: k... to be fair it takes about 20 minutes for day to turn to night :D
[07:17] <dimitern> anastasiamac, I bet there are, although with all the creepy crawlers in AU..
[07:17] <anastasiamac> dimitern: and don't forget flying cockroaches :P
[07:18] <dimitern> anastasiamac, oh we have those as well - nasty creatures
[07:19] <anastasiamac> dimitern: certainly very exotic
[07:23] <wallyworld_> axw: i've made some changes; i was taking some shortcuts previously to try and get it done more quickly; tests should have better coverage now
[07:24] <dimitern> wallyworld_, axw, hey guys - can one of you review this goamz PR please? https://github.com/go-amz/amz/pull/20
[07:24] <axw> wallyworld_: ok cool
[07:24] <axw> wallyworld_: looking
[07:25] <axw> dimitern: will take a look in a bit
[07:25] <wallyworld_> dimitern: i'm about to get ready for soccer, but can look when i get back if not done
[07:25] <dimitern> axw, thank you
[07:25] <dimitern> wallyworld_, cheers
[07:25] <dimitern> wallyworld_, isn't it too hot for soccer? :)
[07:26] <wallyworld_> dimitern: inly if you're soft :-)
[07:26] <dimitern> wallyworld_, :D
[07:33] <wallyworld_> axw: i gotta dash, but i might next add some basic framework for registering storage provider types eg loop with a skeleton implementation. then the blanks can be filled in while work is done on making the loop storage available to env providers, and fallback logic implemented etc
[07:33] <wallyworld_> axw: tnks for review, i just used state in tests to get end-end tested for now, can mock out later
[07:33] <axw> wallyworld_: that SGTM
[07:33] <axw> thanks
[07:57] <axw> dimitern: reviewed
[07:57] <dimitern> axw, ta!
[10:03] <dimitern> voidspace, standup?
[10:03] <voidspace> dimitern: omw
[11:13] <axw> dimitern: when you're free, can you please review https://github.com/juju/names/pull/37 ?
[11:14] <dimitern> axw, sure thing
[11:20] <dimitern> axw, lgtm
[11:20] <axw> dimitern: do you mean vary the storage name? i.e. something other than "store"?
[11:21] <axw> thanks
[11:21] <dimitern> axw, yeah
[11:21] <axw> dimitern: okey dokey, will do
[11:21] <dimitern> axw, I only later read the description of what it is :)
[11:50] <perrito666> morning
[11:51] <anastasiamac> perrito666: morning...
[12:00] <axw> dimitern: another small one http://reviews.vapour.ws/r/766/
[12:02] <dimitern> axw, ship it! :)
[12:02] <axw> dimitern: thanks
[12:21] <perrito666> bogdanteleaga: there is something wrong with http://reviews.vapour.ws/r/632/
[12:21] <perrito666> it lacks code
[12:21] <perrito666> jam2: inet problems?
[12:22] <jam2> perrito666: its been happening for a couple of days now. They "upgraded" my local router in preparation for changing something about the networking to the building, and now every 15-30min I get a SSL session negotiation failure.
[12:23] <bogdanteleaga> perrito666: hmm, it hasn't been created automatically so I tried to do it manually, apparently it didn't work
[12:23] <bogdanteleaga> perrito666: the code is on github however can I update it from the web interface?
[12:25] <perrito666> bogdanteleaga: if you did the post manually probably it worked but you need to go to reviewboard and publish it
[14:04] <dimitern> voidspace, maas meeting?
[14:07]  * perrito666 actually had to prepare a brew to review fwereade's branches
[14:07] <fwereade> perrito666, oh dear, is it that bad?
[14:08] <perrito666> nope, I just checked the lenght and decided that i better prepare my brew before and not after
[14:08] <fwereade> perrito666, good thinking :)
[14:08] <fwereade> perrito666, if it helps, I think the test changes outweigh the code in both of them
[14:12] <perrito666> abentley: this was the failing test of the last cursed email I got http://juju-ci.vapour.ws:8080/job/win-client-deploy/1319/console that is the test right?
[14:13] <abentley> perrito666: That looks like a problem with the machine running the test.
[14:14]  * perrito666 stops peeking at the local newspaper before getting an ulcera
[14:26] <natefinch> Morning everybody
[14:26] <dimitern> hey natefinch!
[14:27] <natefinch> dimitern: howdy :)
[14:27] <perrito666> hey natefinch back?
[14:27] <natefinch> perrito666: back, yes
[14:27] <natefinch> 058524
[14:27] <perrito666> natefinch: we wherent expecting you for a couple of weeks
[14:28] <perrito666> natefinch: tx nice pass
[14:28] <natefinch> lol
[14:28] <natefinch> just my google authenticator number
[14:28] <natefinch> yeah, this is about when I expected to be back.... 2 weeks after the company shutdown
[14:39] <voidspace> dimitern: damn!
[14:39] <voidspace> dimitern: sorry
[14:40] <dimitern> voidspace, :) np
[14:40] <voidspace> dimitern: just forgot :-(
[14:40] <voidspace> dimitern: I need to tattoo it to my hand or something
[14:40] <dimitern> voidspace, *lol*
[14:41] <dimitern> voidspace, nothing major - non-installable nodes can be tested very soon - check the minutes doc if you like
[14:41] <sinzui> natefinch, perrito666 dimitern : I don't see any 1.21-beta5 specific issues in play in the this bug. I don't think it should block the release of 1.21-rc1 https://bugs.launchpad.net/juju-core/+bug/1410876
[14:41] <mup> Bug #1410876: Error executing lxc-clone: lxc_container: utils.c: mkdir_p 220 Not a directory - Could not destroy  snapshot %s - failed to allocate a pty; Insufficent privileges to control  juju-trusty-lxc-template <lxc> <oil> <trusty> <juju-core:Incomplete> <juju-core 1.21:Incomplete> <juju-core
[14:41] <mup> 1.22:Incomplete> <https://launchpad.net/bugs/1410876>
[14:41] <voidspace> dimitern: I will do, cool
[14:41] <voidspace> dimitern: sounds good
[14:42] <dimitern> sinzui, looking
[14:42] <voidspace> dimitern: we need an api to assign resources (like ip addresses) to them for non-installable nodes to be directly useful to us
[14:42] <perrito666> sinzui: I agree thumper and Í documented our findings there and it seems it is outside juju
[14:43] <sinzui> thank you perrito666 . I will try to remove the bug from rc1
[14:52] <dimitern> sinzui, yep, I was just checking the code - it seems 1.21-rc1 shouldn't be affected
[14:53] <sinzui> fab
[15:06] <wwitzel3> perrito666: ping
[15:22] <sinzui> natefinch, dimitern:do you have a moment to review this branch http://reviews.vapour.ws/r/768/
[15:26] <natefinch> sinzui: ship it!
[15:26] <sinzui> thank you natefinch
[15:44] <jw4> OCR PTAL http://reviews.vapour.ws/r/769/ - fix for bug 1412292
[15:44] <mup> Bug #1412292: Intermittent test failure in ActionSuite.TestActionsWatcherEmitsInitialChanges <action> <intermittent-failure> <test-failure> <juju-core:Triaged by johnweldon4> <https://launchpad.net/bugs/1412292>
[15:44] <dimitern> jw4, looking
[15:45] <jw4> dimitern: thanks
[15:46] <dimitern> jw4, if the issue is with the watcher, why not fix it there?
[15:50] <jw4> dimitern: 1) I'm not sure it's a problem with the watcher 2) making a change there would have widespread effect
[15:50] <jw4> dimitern: the issue in the watcher is that it waits up to 10 ms every time after a change to see if there are more changes before returning
[15:50] <jw4> dimitern: that's probably not bad in real life, but in the tests we were expecting it to be a bit more deterministic
[15:51] <dimitern> jw4, right, there might be an issue lurking in there, but the fix seems fine - almost ready with the review
[15:51] <jw4> dimitern: tx
[15:55] <dimitern> jw4, done
[15:55] <jw4> dimitern: ta
[18:29] <voidspace> just spent about an hour trying to work out if I can get the MACAddress out of a network definition in lshw
[18:29] <voidspace> only to realise a few minutes ago that it's there, it's just called "serial" instead of mac address
[18:29] <voidspace> d'oh...
[18:30] <voidspace> at least I have it
[18:36] <hazmat> is usermanagement so to be functional
[18:38] <hazmat> nevermind
[19:10] <voidspace> right
[19:10] <voidspace> g'night all
[19:10] <voidspace> EOD
[19:44] <katco> when we create our lxc templates for cloning, we start them and then wait for them to stop. what causes them to eventually stop so cloning can continue?
[19:51] <natefinch> katco: not sure
[19:52] <katco> for reference: https://github.com/juju/juju/blob/1.20/container/lxc/clonetemplate.go#L162
[19:52] <katco> trying to dx https://bugs.launchpad.net/juju-core/+bug/1348386
[19:52] <mup> Bug #1348386: lxc template fails to stop <clone> <lxc> <oil> <juju-core:Fix Released by cox-katherine-e> <juju-core 1.20:Fix Released by cox-katherine-e> <https://launchpad.net/bugs/1348386>
[19:56] <hazmat> are tags supposed to leak through the api?
[19:57] <katco> hazmat: they are not
[19:57] <hazmat> cause it seems like we started off without doing that, but now their leaking all over the place
[19:57] <hazmat> actions, usermanager, etc
[19:58] <hazmat> ssh key manager.. basically anything using Entities is expecting tags.
[19:58] <hazmat> param.Entities that is
[19:58] <katco> hazmat: in the api/* packages? or apiserver/*?
[19:59] <hazmat> katco, in apiserver
[19:59] <katco> hazmat: ah. that is designed to take tags
[19:59] <katco> hazmat: tags are OtW format, api/* is what is client-facing
[19:59] <hazmat> well that is the exposed api
[19:59] <katco> hazmat: as i understand it anyway
[20:00] <hazmat> api/* is an implementation of a client.. server is the api so we have a rather unfortunate situation on server that things are a mix of tags and not tags.
[20:00] <jw4> hazmat, katco as I recall from discussion w/fwereade the apiserver takes string representations of tags
[20:01] <katco> hazmat: this could be wrong, but how it was explained to me is that tags are OtW format and so as jw4 said we pass the string-representation of tags into apiserver/*
[20:01] <jw4> hazmat: there was some confusion about tags vs. string representation of tags - are you referring to the string representation or the type names.Tag ?
[20:01] <katco> hazmat: i.e.: tags are how clients communicate with the RPC server
[20:02] <hazmat> none of the core api does (deploy/add-machine/remove-machine/add-units/remove-units/setcharm/etc), but all the things that have been added recently are using tags heavily
[20:02] <hazmat> so we now have proper mismash of different ids in the api
[20:03] <jw4> hazmat: as I recall it that is because of a shift in focus too - the intent being that all ids are internal only and string representation of tags used ubiquitously
[20:03] <jw4> hazmat: we just haven't migrated everything yet
[20:03] <hazmat> or maybe its just client facade shouldn't use tags
[20:03] <hazmat> and other facades are all tag centric
[20:04] <jw4> hazmat: but I could be wrong - hoping fwereade notices and weighs in
[20:04] <fwereade> hazmat, all facades should be tag centric -- but the client ones were mostly written before tags were a thing, and many have not been (needed to be) updated yet
[20:04] <fwereade> hazmat, tags were introduced as a way to encode id and type for things like the annotations api
[20:04] <hazmat> tags have been around a while, we just never exposed them through to client facade consumers
[20:05] <hazmat> fwereade, which means they were in the first release of the api really.. ie ever since gui supported juju-core
[20:05] <fwereade> hazmat, so we didn't need to ensure that every entity namespace was disjoint from every other
[20:05] <fwereade> hazmat, near enough, yes, it was specifically for annotations that we added them iirc
[20:07] <hazmat> okay.. i guess i'm going to just keep with other client impl not forcing users to care about tags, just automatically append per appropriate call
[20:08] <hazmat> the only place there was ever a need for tag disambiguation was the annotations (and perhaps not there), i'd rather not have api consumers actually have to concern themselves with it unless by  choice.
[20:52] <natefinch> morning thumper
[21:01] <natefinch> wwitzel3, ericsnow: can you guys post a review for the GCE stuff so I can get started on it?
[21:02] <ericsnow> natefinch: almost there
[21:02] <natefinch> ericsnow: cool... feel free to make a PR with a big WIP on the front of it if that's helpful.
[21:11] <aznashwan> ericsnow: have a moment?
[21:11] <ericsnow> aznashwan: almost :)
[21:11] <ericsnow> aznashwan: gimme a minute
[21:12]  * thumper headdesks
[21:12] <thumper> damn... damn... damn....
[21:13] <katco> thumper: good morning
[21:13] <thumper> I've just realised that although the tests pass, this will fail under real load
[21:13] <thumper> hi katco
[21:17] <ericsnow> aznashwan: what's up?
[21:18] <aznashwan> ericsnow: i was the loonie with the systemd service management PR from Christmas Eve (namely this one: http://reviews.vapour.ws/r/671/)
[21:19] <ericsnow> aznashwan: yep :)
[21:19] <aznashwan> ericsnow: the thing is it's done exactly as upstart (namely I used exec calls to systemctl for managing the services), and since have been told that a more native approach would be more favorable...
[21:21] <aznashwan> I've recently been show this package from the coreOS guys: https://github.com/coreos/go-systemd which might be exactly what we're looking for.
[21:21] <ericsnow> aznashwan: yeah, that is what we were planning on using
[21:22] <aznashwan> It would not take too long to adapt my PR to use that, however i'm in the middle of exam season right now, and am not able to get to it sooner than this weekend
[21:23] <aznashwan> plus however much time responding to review requests and etc... would take
[21:23] <aznashwan> is that timeline ok for you guys?
[21:24] <ericsnow> aznashwan: it depends on what we end up getting done this week with regards to systemd
[21:24] <ericsnow> aznashwan: I expect that we will already have take care of things by this weekend
[21:25] <ericsnow> aznashwan: we were planning on incorporating changes from your patch in whatever we did
[21:26] <wwitzel3> natefinch: http://reviews.vapour.ws/r/771/
[21:27] <aznashwan> ericsnow: as you will, apart from changing the exec calls and (sadly) having to redo the tests, my patch is pretty much on par with the upstart one
[21:27] <ericsnow> aznashwan: cool
[21:28] <aznashwan> ericsnow: are you guys also planning to do anything about how the service management system is selected in the (very) near future?
[21:29] <ericsnow> aznashwan: yeah, that will be a part of what we are working on
[21:30] <ericsnow> aznashwan: we also have to refactor various bits of upstart-specific code throughout juju core to be init-system agnostic :(
[21:31] <aznashwan> ericsnow: yes, the places were services were used seemed very upstart-specific in the first place...
[21:31] <ericsnow> \me gears up for paying off some technical debt
[21:32] <ericsnow> natefinch: for fun take a look at the list of commits on that PR
[21:32] <aznashwan> ericsnow: well, best of luck to you guys. as i've said, I would be more than happy to do it on Saturday of you don't get around to it by then
[21:33] <ericsnow> aznashwan: sounds great :)
[21:33] <aznashwan> ericsnow: keep in touch. godspeed :D
[21:34] <natefinch> ericsnow, wwitzel3: cool, looking
[21:54] <katco> /
[22:15] <menn0> axw: i'm currently reviewing your charm storage PR
[22:37] <thumper> menn0: where is the statesuite that you created?
[22:38] <thumper> state/testing
[22:38] <thumper> nm
[22:39] <menn0> thumper: :)
[22:40] <jw4> thumper: I'm pretty sure I've fixed the watcher test - fyi :)
[23:06] <wwitzel3> ericsnow: ping
[23:07] <ericsnow> wwitzel3: present
[23:07] <wwitzel3> ericsnow: going to jump in to moonstone for a bit
[23:07] <ericsnow> k
[23:47] <anastasiamac> thumper: super command of super command..
[23:47] <anastasiamac> thumper: for eg. juju storage pool list....
[23:47] <anastasiamac> thumper: is there a precedence?..


[15:43] <ChinnoDog> What command line editor has the best syntax highlighting?
[15:48] <ChinnoDog> I might have to learn vim. :-(
[16:39] <swift110> hey ChinnoDog
[16:49] <ChinnoDog> heya
[17:19] <swift110> how are oy


[10:50] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3070 Diff missing
[12:31] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3070 Diff missing
[14:33] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3071 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[14:51] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3071 Pending binary packages
[15:11] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3071 Diff missing
[15:31] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3071 Needs rebuild due to burned version number
[15:58] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3072 Preparing packages
[16:34] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3072 Pending binary packages
[16:54] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3072 Successfully built
[22:38] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3072 Publishing packages
[22:54] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3072 Proposed pocket


[03:54] <hallyn> bug 1292234
[03:55] <hallyn> arges: yeah, sure, that'd be good.  if you end up giving up you can alwyas assign it back to me.
[03:55] <hallyn> ogra_: wedensday is my only day on keyboard this week.  what's up?
[04:33] <arges> hallyn: yea, i ran 15 iterations of the reproducer today on my x220 with ext3/lvm and no luck, will try some other approaches here soon
[04:37] <arges> hallyn: assigned myself
[04:38] <hallyn> arges: gah!
[04:38] <hallyn> arges: thanks
[05:27] <ScottK> Nice to see Randall's blog given over to advertising now.
[05:58] <darkxst> mitya57, http://pastebin.com/ayU04vHz
[07:52] <dholbach> good morning
[08:22] <LocutusOfBorg1> hi dholbach :)
[08:22] <dholbach> hi LocutusOfBorg1
[08:24] <MasterPiece> !help
[08:36] <darkxst> MasterPiece, sometimes people say hi to others they know ;) guess it a social thing ;)
[08:37] <MasterPiece> darkxst, I know, my purpose of command was detecting the bot
[08:37] <MasterPiece> Hi all :)
[08:38] <darkxst> the bot is always here, except when he breaks ;)
[08:43] <LocutusOfBorg1> I like to say "hi" to dholbach, because I should never stop to thank him for all the merges he does for me :)
[08:50]  * dholbach hugs LocutusOfBorg1
[08:50] <dholbach> thanks a lot for all your hard work!
[08:51] <LocutusOfBorg1> s/hard/easy :)
[08:51] <LocutusOfBorg1> I hope to become soon a DD, to become after an ubuntu developer :)
[08:57] <dholbach> all the best! :)
[09:15] <xnox> Guten Morgen!
[09:20] <highvoltage> guten morgen xnox
[09:24] <LocutusOfBorg1> xnox, too difficult :) morning to you too :D
[09:24] <frechdachs69> anyone who knows how to check for installed Qt5 plugins using cmake with Ubuntu 14.04? e.g. Qt5Gui_PLUGINS is just empty
[09:26] <frechdachs69> according to cmake no plugins are available at all
[09:27] <LocutusOfBorg1> frechdachs69, do you have your find_package issued correctly?
[09:27] <LocutusOfBorg1> sorry I usually use .pro files with qt
[09:28] <LocutusOfBorg1> anyway, I encoundered some cmake 3.0 problems about a bad "find_package"
[09:28] <LocutusOfBorg1> http://qt-project.org/doc/qt-5/cmake-manual.html
[09:41] <frechdachs69> LocutusOfBorg1: I've checked the installed cmake files: the referenced Qt5Gui_*.cmake files are missing inside package 'qtbase5-dev'
[09:44] <frechdachs69> which package do I have to install to get 'Qt5Gui_QGifPlugin.cmake' ?
[09:48] <LocutusOfBorg1> I don't think you need it, why you think you should have one?
[09:48] <LocutusOfBorg1> you use the find_package and it fills the vars for you
[09:53] <pitti> stgraber: I'm confused by bug 1346734 -- I now have the cgroups writable for "ubuntu" in all controllers, but it still complains with some weird rmdir errors
[09:54] <pitti> stgraber: I followed up to the bug with some details; would be nice if you could have a look?
[09:58] <pitti> stgraber: ah, the old "got the solution only after asking" effect again, unping
[09:58] <pitti> stgraber: yay, I have my first user container running under systemd :)
[09:58] <ogra_> crazy talk
[10:36] <mitya57> darkxst, thanks, I got it. Will try to include this in Debian upload.
[10:41] <mitya57> darkxst, or, maybe it'll be better to just depend on mutter-common.
[10:42] <darkxst> mitya57, don't add dependencies for retarded code
[10:43] <mitya57> Well, mutter-common is just 4MB and doesn't depend on anything else
[10:46] <darkxst> mitya57, it really should be fixed upstream, but apparently they don't care
[10:47] <mitya57> I still think that it would be better to add dependency than carry a patch never-accepted-upstream
[10:54] <darkxst> mitya57, sure, and I am still shocked how that code could make it into a release
[10:55] <darkxst> its up there with the most convulted piece of python code I have ever seen in a real project
[10:55] <darkxst> convoluted
[10:57] <darkxst> and certainly my intention of patching was for them to fix it, not ignore it
[10:57] <pitti> doko: wrt. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#binutils, the new binutils indeed changes/breaks the lintian test for "apparently-corrupted-elf-binary"; I suppose the lintian test needs to be adjusted
[10:59] <doko> pitti, have't looked yet, wasn't that eager to get it migrated
[10:59] <pitti> doko: there's no change in Debian's git yet (http://anonscm.debian.org/cgit/lintian/lintian.git/log/t/tests/binaries-from-other-arch)
[10:59] <pitti> doko: oh, ok, I thought you were; I'll file a Debian bug then, the lintian guys are usually very fast
[10:59] <mitya57> darkxst, I have seen Python code that is a *lot* worse
[11:00] <mitya57> So, for now I'll add the mutter-common dependency in Debian, and will remove it when/if they accept your patch
[11:00] <darkxst> mitya57, I have as well, but not under the GNOME umbrella, although admittly  not much python there
[11:00] <mitya57> (and I am going to upload it when debian #770969 is approved)
[11:02] <darkxst> mitya57, ok, doubt it will ever be approved anyway
[11:05] <darkxst> I was never able to even get a review, even after pinging relevent people on IRC
[11:06] <mitya57> :-(
[11:07] <jamespage> didrocks, apologies - I thought I'd covered you update to docker but apparently not
[11:10] <didrocks> jamespage: no worry, I was just wondering if this was on purpose. Once your package moves out from -proposed, I'll readd this :)
[11:11] <jamespage> didrocks, let me sort that out now so next time I merge it I know what I'm mean't to be doing
[11:13] <didrocks> jamespage: sure!
[11:15] <jamespage> didrocks, you fix was the ensure_socket_activation_only.patch right?
[11:16] <didrocks> jamespage: yeah
[11:16] <didrocks> jamespage: newer packages ships a WantedBy= target
[11:16] <didrocks> you need to remove it
[11:17] <didrocks> (in docker.service)
[11:17] <didrocks> as the pointed targeted (multi-user.target) is started as part of the boot process
[11:17] <didrocks> and so, this is starting docker.io at boot
[11:18] <jamespage> didrocks, sorry for the dumb questions but why don't we want it to start on boot?
[11:19] <didrocks> jamespage: because it's socket activatable
[11:20] <didrocks> jamespage: so, if you call docker <something>, it will start the service
[11:20] <didrocks> only when needed then
[11:22] <jamespage> didrocks, that seems related to https://github.com/docker/docker/commit/053c3557b3198466ecfbe066fefdbab2a78771d5
[11:22] <jamespage> if we don't start it on boot, the --restart=always flag can't be obeyed?
[11:24] <cjwatson> rbasak: \o/ I tracked down bug 1393832
[11:24] <cjwatson> will update bug shortly :)
[11:24] <didrocks> jamespage: hum, indeed, that one seems sensible (the second should be fixed with something else)
[11:25] <didrocks> jamespage: is there any flags on the file system to know which containers have --restart=always flag?
[11:28] <jamespage> didrocks, hostconfig.json contains the restart policy for a container
[11:28] <jamespage> /var/lib/docker/containers/uuid/hostconfig.json
[11:29] <didrocks> jamespage: ok, let it that way then, but I think we should investigate to only start the unit if there are some with those flags
[11:30] <jamespage> didrocks, that sounds efficient
[11:30] <didrocks> thanks for digging in!
[11:30] <jamespage> np
[11:37] <pitti> doko: I sent debian bug 771054 FYI
[12:19] <doko> pitti, did you have a look which input file has this warning emitted?
[12:22] <pitti> doko: it's generated by "sh t/tests/binaries-from-other-arch/debian/debian/dumpobj > /tmp/elfobj"
[12:23] <pitti> doko: the binary-from-other-architecture is correctly determined, and "file" confirms that it's an ARM binary; not sure why it's a "corrupted" binary (it's just a base64 dump of something)
[12:52] <fabbione> ivoks: ping
[12:53] <fabbione> ivoks: not sure who is in charge of pcmk your side, but if you are not looking at the upstream ml, we will have a HA Summit in Feb in brno
[12:53] <fabbione> ivoks: might want to consider having your maintainer there
[12:53] <ogra_> hey, the godfather is around ...
[12:54] <fabbione> hey ogra_
[12:54] <ogra_> how is life ?
[12:54] <fabbione> yeah they didn't kill me yet
[12:54] <fabbione> not too bad, you?
[12:54] <ogra_> great ... phones everywhere
[12:54] <ogra_> :)
[12:55] <fabbione> nerd :)
[12:55] <ogra_> haha
[12:59] <ivoks> fabbione: hey, how are you? :)
[13:00] <fabbione> ivoks: usual man, usual :)
[13:01] <ivoks> fabbione: i'll pass on the information, thanks
[13:01] <ivoks> i'm personally not that much invovled anymore
[13:02] <fabbione> ivoks: wfm
[13:48] <cjwatson> rbasak: ... and that fixed the broken autopkgtests that I noticed (mod-wsgi and puppet); excellent
[14:15] <pitti> stgraber: I added some debugging, and attaching a process to /user.slice/user-1000.slice in the "cpuset" controller fails with "No space left on device"; does that happen to ring a bell?
[14:15] <pitti> hallyn: ^ or to you, from your cgmanager work? I get that when trying to attach a pid to a cgroup in cpuset; it works for all other controllers
[14:16] <pitti> but it seems LXC is quite insistant on getting that controller, too
[14:17] <pitti> in the interwebs I found "Cpuset always require initializing cpuset.cpus and cpuset.mems,
[14:17] <pitti> because they are empty by default, this fact block task attaching with -ENOSPC"
[14:18] <pitti> indeed /sys/fs/cgroup/cpuset/cpuset.mems is "0-3" on my workstation (where it works), and "0" in my test VM (where it fails)
[14:20] <hallyn> pitti: if you get no space left ondevice, it sounds like your cpuset.cpus or cpuset.mems is unset
[14:20] <hallyn> pitti: '0' would be ok.  that means you get '0'.
[14:20] <hallyn> (cpu 0, not 0 cpus)
[14:20] <pitti> hallyn: cpuset.mems is "0" in both situations, so I guess it's the "0" in cpuset.cpus?
[14:20] <hallyn> what is cpuset.cpus?
[14:21] <hallyn> no that sounds fine actually
[14:22] <pitti> hallyn: oh, but /sys/fs/cgroup/cpuset/user.slice/user-1000.slice/cpuset.cpus is indeed empty
[14:22] <pitti> (where I want to attach to)
[14:23] <hallyn> pitti: oh, ok, then yes that needs to be initialized.  if you set clone_children=1 you'll be fine
[14:23] <hallyn> cgmangaer would do that for you, but doesn't when systemd is running
[14:24] <pitti> hallyn: ah, thanks
[14:25] <pitti> hallyn: indeed /sys/fs/cgroup/cpuset/cgroup.clone_children is "1" on my workstation and "0" in my VM
[14:25] <pitti> hallyn: I don't know what set that, might that be LXC or so? I don't have cgmanager running, and systemd doesn't touch it either
[14:26] <hallyn> lxc does also set it
[14:26] <hallyn> just on /lxc
[14:26] <hallyn> hm, or maybe not just on lcx, but i thought so
[14:26] <pitti> the fun thing is that lxc-checkconfig says "Cgroup clone_children flag: enabled" when it's not
[14:26] <pitti> that's the only hit that grep find
[14:27] <pitti> hallyn: anyway, so in order to do that "attach to all controllers" thing, I need to set clone_children to 1 during startup; do you know if that could negatively affect anything else?
[14:27] <pitti> according to what https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt says about it it seems fairly harmless
[14:28] <pitti> hallyn: and I guess that's what we've done until now anyway, so it wouldn't be a regression either way, right?
[14:30] <hallyn> pitti: rihgt, the only thing i tmight do is upset systemd at some point
[14:30] <hallyn> pitti: i know of nothing that depends on those not being initialized
[14:31] <hallyn> anything that does, could set it lcoally for the workloads it's trying ot confine
[14:31] <pitti> hallyn: not really; systemd upstream does not touch any controller except the custom "systemd" one
[14:31] <pitti> I'm just patching all that in :)
[14:32] <hallyn> doesn't it handle other controllers contingent on a /etc/systemd/logind.conf setting?
[14:32] <didrocks> pitti: yeah, cpu controller is 0 by default, it's weird because lennart's blog post told that he's using at least the cpu one by default
[14:32] <pitti> hallyn: that was <= 204
[14:32] <pitti> didrocks: indeed, "0" is the first one; empty file means "none"
[14:32] <hallyn> oh.  i'm behind the times as usual
[14:33] <pitti> hallyn: and indeed my login shell is now in all controllers including cpuset \o/
[14:33] <pitti> blimey! my container starts!
[14:33] <pitti> ♩ rock'n'roll tune ♪ ♫
[14:33] <pitti> hallyn: thanks for your help!
[14:34]  * pitti aims a spear towards bug 1346734
[14:34] <hallyn> np - hopefully we get al lthis straightened out this cycle
[14:34] <hallyn> excellent
[14:34] <hallyn> thanks - ttyl
[14:57] <xnox> doko++ hammerhead - BOOM! =)
[15:25] <stgraber> pitti: actually, it does
[15:26] <pitti> stgraber: hallyn already responded, we figured it out (cpuset's cgroup.clone_children)
[15:26] <stgraber> pitti: oh, looks like hallyn answered
[15:26] <pitti> stgraber: it's working now with the patch set in http://people.canonical.com/~pitti/tmp/systemd-unpriv-lxc/
[15:26] <pitti> stgraber: I'm backporting them to our 215 package as we speak
[15:47] <cjwatson> Could somebody have a look at https://launchpad.net/ubuntu/+source/glib2.0/2.43.1-1/+build/6596956 ?  It's causing collateral damage further up the build stack.
[15:47] <cjwatson> I've already retried it once.
[15:47] <pitti> Laney: ^ that's the thing you are currently discussing with desrt in #u-desktop, right?
[15:47] <Laney> yes
[15:47] <cjwatson> OK, cool, thanks
[15:47] <Laney> He's about to pop up in #is to get porter access, so if you want it fixed get them to action it quickly ;-)
[15:59] <stgraber> pitti: on the other side of the story, I just sent an e-mail to lxc-devel detailling our plan for systemd container support. I actually got an almost working container here using a very hackish prototype.
[15:59] <pitti> stgraber: oh, nice! you mean for systemd as pid 1 in the guest? what's actually missing there?
[16:00] <pitti> stgraber: or do you mean for unprivileged containers?
[16:00] <pitti> stgraber: as they seem to work reasonably well with root containers
[16:00] <stgraber> pitti: systemd as pid1 in a lxc container, both privileged and unprivileged
[16:00] <stgraber> and without having to turn off any crazy apparmor option (like allowing cgroupfs mounts or anything like that)
[16:01] <pitti> stgraber: hm, that's bug 1347020?
[16:01] <stgraber> I guess so
[16:01] <stgraber> we also have a dozen more on github
[16:01] <pitti> stgraber: ah right, I had to weaken apparmor for the cgroup mounting
[16:02] <stgraber> so the current plan is to write lxfs (fuse filesystem) to take care of the cgroup part, implement unprivileged lxc.autodev, implement init system detection code so we can turn on autodev, turn off kmsg redirect and set lxc.mount.auto appropriately if the container's init system is systemd and also add a new lxc.init_cmd option so you can set a different init path in there.
[16:03] <cjwatson> bdmurray: Where's the best place to get package-team-mapping in a machine-readable form?
[16:11] <cjwatson> bdmurray: I've found https://bazaar.launchpad.net/~bryce/arsenal/2.x/view/head:/reports/package-team-mapping.csv, but not exactly current
[16:12] <cjwatson> bdmurray: Or is there a version that comes out of bug subscriptions now?
[16:13] <bdmurray> cjwatson: there are teams that should be subscribd to packages for which they are responsible, although I haven't looked at it in a bit, e.g. foundations-bugs, desktop-packages, ...
[16:14] <cjwatson> bdmurray: Right, so what I'm trying to do is work out how we might generate subdivided reports from things like proposed-migration, component-mismatches, etc. that are divided down by teams
[16:14] <bdmurray> cjwatson: this report should cover most of teams - http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-u-tracking-bug-tasks.html
[16:14] <cjwatson> bdmurray: Intersecting those with the team mapping seems like the right first step
[16:14] <cjwatson> bdmurray: But I don't really want to have to scan through for the mapping every time
[16:16] <bdmurray> cjwatson: I'm looking around. fwiw unsubscribed-packages in ubuntu-archive-tools has the team names
[16:16] <cjwatson> bdmurray: I guess I kind of want https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/package-sub-json/+merge/193321 except not limited to main and restricted?
[16:17] <bdmurray> cjwatson: oh yeah, that'd make sense
[16:18] <cjwatson> bdmurray: Are you particularly attached to that being limited to main/restricted (and the output file prefixed with m-r-)?  I know you probably don't want to scan through every source package in the archive, but it should be possible to just dump out the subscriptions of those teams
[16:19] <bdmurray> cjwatson: No, having it include the archive seems fine.
[16:20] <cjwatson> bdmurray: cool, I'll sort that out and have it dump regularly to somewhere under ~ubuntu-archive, then
[16:21] <cjwatson> thanks
[16:22] <bdmurray> no problem
[16:23] <cjwatson> "unsubscribed" will still just be main and restricted, I guess that's OK
[16:23] <cjwatson> it's the other entries I care about :)
[16:30] <pitti> bdmurray: I salvaged the ddebs tarball for now; indeed the two binary packges don't get published for some reason, I'll investigate this more closely tomorrow morning
[16:47] <cjwatson> bdmurray: http://people.canonical.com/~ubuntu-archive/package-team-mapping.json is now updated hourly
[18:34] <rbasak> cjwatson: thanks! I had just assumed that not matching the grep meant it was not installed and never considered actually checking the output.
[18:35] <rbasak> Nice one :)
[20:40] <mdeslaur> xnox: I could have wrapped it with a few gtk version checks, but then would have had to modify autoconf to support being called with the gtk version as a parameter
[20:40] <mdeslaur> and then being built twice
[20:40] <ScottK> Much better.  Thanks.
[20:40] <xnox> mdeslaur: yeah yeah.
[20:41] <xnox> mdeslaur: i'll twiddle with it a bit and check things.
[20:44] <mdeslaur> xnox: and it sucks to have to test it twice for every gtk3 fix :P
[20:45] <mdeslaur> in fact, I wonder why we package this separately at all, maybe we should just add the plugin to the xchat/xchat-gnome packages directly
[20:45] <mdeslaur> hrm, dependencies on non-unity desktops maybe
[20:55] <xnox> mdeslaur: upstream build-system supports drop-in plugins, however that would make it non-syncable package (w.r.t. new upstream releases)
[20:56] <xnox> mdeslaur: i ponder if indicator plugin would be accepted e.g. hexchat upstream.
[20:56] <xnox> jdstrand: slangasek: i would like to build ia32 & x64 OVMF images, from that same package
[20:56]  * xnox rolls up his sleeves.
[20:56] <mdeslaur> xnox: oh, maybe
[21:02] <slangasek> xnox: yes; I'm not sure the right way to do this, fwiw I've already received requests for ARM OVMF images to be installable on x86 which makes it more fun to figure out multiarch co-installability vs. cross-build all-in-one
[21:02] <slangasek> xnox: would native-build-everywhere, apt-get install ovmf:i386 ovmf:amd64 work, you think?
[21:02] <xnox> slangasek: i believe the current procedure to resolve that is to open more bug reports for technical comittee.
[21:03] <xnox> slangasek: i think "apt-get install ovmf:i386 ovmf:amd64 " etc is an excellent idea!
[21:03] <xnox> slangasek: and makes the build machinery so much easier.
[21:04] <slangasek> xnox: what's the right way to arch-qualify the filenames on disk? have you worked that part out?
[21:04] <slangasek> for compatibility I guess amd64 should keep /usr/share/ovmf/OVMF.fd and /usr/share/qemu/OVMF.fd
[21:05] <xnox> slangasek: yes. I'd follow the UEFI boot/ naming convention that is suffix the name with the uefi-arch tag?
[21:05] <xnox> and then OVMF.fd can become a symlink to OVMFX64.fd or some such.
[21:06] <slangasek> can we put some separator char in there too, please? :)
[21:06] <stgraber> please
[21:06] <stgraber> otherwise I'm going to get very very confused when I've got both X64 and AARCH64 (or whatever abreviation we end up with) :)
[21:06] <slangasek> xnox: and yeah, that's a reasonable convention, but I'm more concerned that the things which consume ovmf know about it
[21:06] <xnox> because you'll sick of grubx64.efi & shimx64.efi ?! =)
[21:07] <slangasek> no, because having it in all caps makes it hard to read
[21:07] <xnox> for a long time, i though it was "shim - mex" rather than just "shim"
[21:08] <jrwren> is anyone aware of an sbuild like tool which uses cloudimg as its base and lxc ?
[21:15] <xnox> jrwren: you can boot cloudimages in lxc, in the cloud-init config preseed to install sbuild & mk-sbuild, and make post-script setup chroots you want.
[21:16] <xnox> jrwren: you still want to jump into lxc -> jump into sbuild chroot. As cloud-image has more things installed, than a minimal build chroot.
[21:16] <xnox> jrwren: we have juju charms to deploy "sbuild" ready units -> but after deployment these are ready for interractive use.
[21:17] <xnox> jrwren: rather than spin up, build this dsc, copy artifacts / buildlog & tear down.
[21:18] <xnox> slangasek: hallyn: edk2 git repository is behind packaging.....
[21:18] <xnox> hm....
[21:19] <xnox> maybe this is not repository i'm looking for
[21:21] <xnox> slangasek: $ git ls-remote git://anonscm.debian.org/pkg-qemu/edk2.git HEAD
[21:21] <xnox> cc8fa1208f3e4e945c2549658fb40aa745c62aee	HEAD
[21:21] <xnox> $ git ls-remote https://anonscm.debian.org/git/pkg-qemu/edk2.git HEAD
[21:21] <xnox> 4e443c07ba6f2c7f4363e30ff8b3699ce1126f1e	HEAD
[21:22] <xnox> ... the two hashes no match....
[21:24] <jrwren> xnox: thanks. I'm going to have to study what you just wrote for a bit :)
[21:32] <xnox> jrwren: ok =)
[21:57] <hallyn> xnox: with apologies to slangasek, i've horribly neglected edk2
[22:05] <jrwren> xnox: my thought was more to use lxc instead of schroot.
[22:06] <xnox> jrwren: ok, but why cloud-image as well?
[22:06] <jrwren> xnox: no reason. its my go to minimal.
[22:07] <xnox> jrwren: you'd then want to construct lxc container with (a) unpacked debian source package (b) build-dependencies installed (c) do something like lxc-start -- dpkg-buildpackage -b
[22:07] <jrwren> xnox: I was trying sbuild-createchroot and having issues and hence thinking of alternatives. Now that I've switched to mk-sbuild and not having issues, I think I'll be fine with the schroot
[22:07] <xnox> jrwren: cloud-image is small, but it's huge compared to a minimal build-chroot as used for official builds.
[22:07] <xnox> jrwren: yeah, mk-sbuild is awesome.
[22:08] <xnox> jrwren: schroot is enough protection.
[22:08] <jrwren> xnox: I'll keep using mk-sbuild and sbuild and forget what I said about lxc :)
[22:08] <xnox> stgraber: have you though of making launchpad-sbuild thing use lxc containers? or possibly does it already do that?
[22:08] <xnox> jrwren: ;-)
[22:09] <stgraber> xnox: thought of it, yes, had time to do it, no
[22:11] <jrwren> calling sbuild-createchroot directly complained about debootstrap, and had a warning mounting proc. I think the proc warning was a red herring. It made me think lxc wouldn't have the proc mount issue.
[22:11] <jrwren> now that I've moved passed that, by using mk-sbuild, I no longer think I need lxc  :)
[22:11] <jrwren> xnox: huge thanks for the quick response.
[23:33] <xnox> doko: edk2 writes crazy c which no longer builds with gcc-4.9 =(
[23:33] <xnox> doko: do you want to see crazy C or do you want an extra package hard-code using gcc-4.8?
[23:34] <sarnold> my curiosity is piqued to discover what kind of crazy C won't build with newer gcc but builds fine with newish gcc... :)
[23:36] <robert_ancell> blr, hey, nice to have another person online in the quiet timezone!
[23:37] <slangasek> xnox: is that true for upstream trunk as well?
[23:38] <xnox> slangasek: i believe so, yes. I'll test that out.
[23:40] <blr> robert_ancell: hi from Dunedin! thanks :)
[23:41] <xnox> slangasek: and EfiShellLib fails to build for 32bit =(
[23:44] <slangasek> well, that's fun
[23:55] <xnox> slangasek: i think build machinery expects "Ia32" subdirs for arch specific things, and it's using "IA32" in a couple of places.
[23:56] <xnox> slangasek: clearly this all just works on case-agnostic filesystems.....
[23:56] <slangasek> xnox: no problem, please build depend on mtools + lxc
[23:57] <xnox> slangasek: i'll try to fudge it.
[23:57] <slangasek> xnox: I think I hit a similar problem before for the amd64 build, that got fixed upstream before it became a problem for me
[23:58] <slangasek> unless I'm still carrying bletcherous case-fixing patches somewhere