[00:36] <jlava> Hi all, question about wireless USB adapters for Xubuntu... I've looked at the documentation and am curious which ones you're using that are truly out of the box plug and play? I've tried several and have not succeeded in getting any of them to work :/
[03:38] <winbabby> hello xubuntites
[03:38] <cfhowlett> !details | winbabby
[03:40] <winbabby> anyone know how to fix a login loop? I can login with terminal but the same password just takes me back to
[03:40] <winbabby> the promp
[03:40] <winbabby> t
[03:40] <winbabby> and startx doesn't work to bring up the gui
[11:28] <dreamercz> Hello folks.
[11:36] <dreamercz> Anyone knows how to log the shutdown process? I feel like there is something that slows it down but I can't figure out what it is.
[15:26] <vista__> Hello, I am having some trouble with my Xubuntu install ever since I upgraded to 15.04
[15:26] <vista__> (from 14.10)
[15:28] <vista__> The trouble I am having is that during particularly intensive traffic - say, watching a video stream or a YouTube video in high resolution, sometimes the WLAN connection just... gives out.
[15:28] <vista__> A sudden loss of connectivity, I no longer see my SSID in the list of APs
[15:28] <vista__> I can attempt to connect to other APs, even properly connect to another one just fine
[15:29] <vista__> however, my SSID only comes back after a restart, or if I toggle the hardware WiFi switch and do ifconfig wlan0 down && ifconfig wlan0 up
[15:29] <vista__> Simply toggling the hardware switch on and off does not work either.
[15:30] <mrkramps> vista__, which wifi chipset is in use?
[15:31] <vista__> Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)
[15:32] <vista__> dmesg says [592429.321635] wlan0: disassociated from f8:xx:67:xx:f6:xx (Reason: 7)
[15:33] <mrkramps> vista__, https://askubuntu.com/questions/675352/wireless-disconnects-intermittently-with-intel-corporation-centrino-advanced-n-6
[15:36] <vista__> I'd rather not disable .11n on my adapter
[19:34]  * m3n3chm0 nasZ
[21:14] <drc1>  /msg NickServ help
[21:19] <spykgb> hi
[21:19] <knome> hello
[21:19] <spykgb> is anybody using 15.10
[21:20] <knome> just ask the real question
[21:20] <drc1> a few
[21:20] <spykgb> i like it
[21:20] <drc1> That's not a question...for general chatting, see #xubuntu-offtopic
[21:22] <spykgb> exit


[00:37] <Ranger5> Hi, I'm running Lubuntu 19.04 on a laptop, can anyone tell me if there is a Night Light feature available for the lxqt desktop? Thanks.
[00:38] <wxl> Ranger5: a blue light filteR?????
[00:40] <Ranger5> yes, that's right.
[00:40] <wxl> try redshift http://jonls.dk/redshift/
[00:40] <wxl> it's in the repos
[00:40] <wxl> !info redshift cosmic
[00:41] <wxl> see also the almighty arch wiki on the subject https://wiki.archlinux.org/index.php/Redshift
[00:42] <Ranger5> Ok, thanks a lot for the assist:] (y)
[00:43] <guiverc> Ranger5, I use redshift myself, and the redshift-gtk (optional) does work to add control on panel
[00:43] <Ranger5> Oh, that might be helpful too, cheers!
 I'm trying to upgrade from Lubuntu 19.04 to 19.10 Beta. I've added 'deb http://us.archive.ubuntu.com/ubuntu/ disco-proposed main universe multiverse restricted ' to 'sources.list', have execeuted 'apt-get update&&apt-get upgrade&&apt-get dist-upgrade' and 'do-release-upgrade', but no upgrade occurs. How do I upgrade to Beta in
[11:21] <tomreyn> !ubuntu+1 | martinmcmillan
[11:21] <tomreyn> but i don't think there's an upgrade path, yet
 @martinmcmillan [I'm trying to upgrade from Lubuntu 19.04 to 19.10 Beta. I've added 'deb http://u …], The way I do it is to changes sources from disco to eon
 in /etc/apt/sources.list
 other have done "sudo do-release-upgrade -d"
 Thank you for your help. Changed 'disco-proposed' to 'eoan-proposed' . This change seems to be working.
 I hope this is on a test machine^  You should be careful with proposed.
 Thank you for the warning. It is a test machine. I'll give a status update using in-place upgrade later today.


[09:30] <davmor2> morning all
[22:34] <persia> So, regarding SRU validation: There's a reporter in #ubuntu-bugs that says that upgrade for https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/508173 renders GPT hardware unbootable.
[22:34] <ubot4> Launchpad bug 508173 in grub2 (Ubuntu Lucid) (and 2 other projects) "postinst has errors with grub-probe that cause the system to stop booting (affects: 1) (heat: 16)" [Medium,Fix released]
[22:35] <persia> Could anyone remind me how we're supposed to respond?  This mostly affects Apple hardware, but there's bundles of that around.
[22:37] <sbeattie> persia: mark the bug as verification-failed, have the reporter open a new bug about the regression and refer to the regression bug report in a followup comment to 508173
[22:37] <persia> So, the reporter is having a bit of trouble opening a new bug using any automation.  Do we care?
[22:37] <persia> Should it be an unautomated bug?
[22:38] <persia> Also, do we know any regular testers with Apple hardware that could do verification testing?  I worry that we may want to take some significant action to avoid making Ubuntu not work there.
[22:39] <sbeattie> an automated bug would be preferred, but an unautomated bug is fine.
[22:40] <persia> OK, cool.  Unfortunately, this sort of hardware can't USB-boot, and the reporter doesn't have a blank CD about.
[22:40] <sbeattie> Bugger, looks like the update made it out of SRU, and into -updates?
[22:40] <persia> So there's no means to get back into Ubuntu until a shop can get visited, or there's some grub manipulation tool that can run inside OS X.
[22:41] <persia> Unfortunately.
[22:41] <persia> I'm not sure we test GPT heavily.
[22:42]  * sbeattie doesn't know what GPT is.
[22:43] <persia> It's "GUID Partition Table", used on many EFI-booting systems.
[22:43] <persia> EFI is the Extensible Firmware Interface.  GUID might be Globally Unique Identifier, but that doesn't make sense to me.
[22:44] <persia> Anyway, it's how Apple Intel machines get partitioned, rather than using a DOS disklabel.
[22:45] <persia> So testing would involve a (newer) Mac
[22:45] <persia> (but note that at least some newer Macs have issues getting installed, making this tricky)
[22:47] <sbeattie> Does our installer support EFI/GPT?
[22:48] <sbeattie> virtualbox-ose claims to support EFI booting, and the next version coming is supposedly going to support OSX installs.
[22:48] <sbeattie> (just wondering if virtualbox can be used as an accurate test environment)
[22:53] <persia> It kinda does, for some sorts of installs.
[22:54] <persia> At least for my hardware, default selections for desktop works and default selections for server fails.
[22:54] <persia> But I think mine differs from lots of stuff out there, or there would be more complaints, as default selections for desktop failed prior to Beta2 in lucid.
[22:55] <persia> (and my hardware is very new)
[23:10] <persia> sbeattie: I think I've gotten 508173 in the right state.  Could you confirm?
[23:13] <sbeattie> persia: yeah, looks okay. Probably best to get cjwatson looking at bug 576662
[23:13] <ubot4> Launchpad bug 576662 in grub2 (Ubuntu) "latest grub2 renders gpt based system unbootable (affects: 1)" [Undecided,New] https://launchpad.net/bugs/576662
[23:15] <persia> Bad time-of-day, and even time-of-year (elections/UDS), but yeah.


[00:15] <falcojr> IIRC most warnings come from the dependencies rather than the code itself, but if there's some easy ones to remove, sure! It'd be best to do as a separate commit in a separate PR though
[14:51] <Odd_Bloke> falcojr: Would you be able to take a look at https://github.com/canonical/cloud-init/pull/837 ?  It sounds like we may have regressed vendor-data?
[15:01] <falcojr> yep, I'll take a look
[16:04] <falcojr> I commented on the PR, but I don't think this is a regression. Same behavior happens if I jump to (much) older releases of cloud-init
[16:13] <Odd_Bloke> falcojr: Would any code set vendordata_raw to a list in those older versions?
[16:15] <falcojr> I inserted a `self.vendordata_raw = ['#cloud-config\n']` on line 185 of DataSourceNoCloud.py
[16:16] <falcojr> s/185/186
[16:24] <stevenm> has 'cloud-init' (not as a bit of software, but as a specification) ever been immortalised as an RFC or some equivalent?
[16:25] <stevenm> because whenever someone says 'cloud-init' I've no idea if they mean the feature (of communication between host and guest) or the package
[16:48] <Odd_Bloke> stevenm: I'm not really aware of people using it as a generic descriptor: cloud-init (the package) is present in almost every distribution, so it's usually the case that "cloud-init" is cloud-init.  There have been others, cloudbase-init works on Windows too, and CoreOS' Ignition performs similar actions but in quite different ways (it runs in the initramfs, not in the booted system).
[16:49] <Odd_Bloke> (I feel like I'm missing another one, but I may just be getting mixed up because CoreOS got acquired.)


[04:07] <Bashing-om> guiverc: One to add - clear to edit Discoure ?
[04:08] <guiverc> yep...
[04:08]  * guiverc has some stuff in mousepad here; but not enough there yet to open & add
[04:13] <Bashing-om> guiverc: I add to the load then :P
[04:16] <Bashing-om> guiverc: https://discourse.ubuntu.com/t/modern-communication-platforms-matrix-testing/40313 added . saving and exiting.
[04:16] <guiverc> :)  thanks Bashing-om
[04:17] <guiverc> I'd have probably added that anyway (if not there; I noted it earlier this morning... currently what little focus i have is on summaries.. so useful in case I forget...
[04:19] <Bashing-om> guiverc: First I had deen it - wonder how I missed it on my eralier perusal of the Discourse site :(
[04:19] <Bashing-om> seen*
[04:21] <guiverc> you're out i take it Bashing-om , I'll add one summary I'm not really happy with...
[04:23] <Bashing-om> guiverc: Yup - I out.
[04:25] <guiverc> thanks, i just added the one summary (first in planet)... I've been fight with ~two hours now.. (not continuous, I get annoyed & thus walk off & go elsewhere..)   it maybe needs a check
[04:25]  * guiverc didn't paste lxqt or further ones
[04:26] <Bashing-om> guiverc: I do UWN freshening when I am fresh in the morrow :D
[04:26] <guiverc> ack
[04:26] <guiverc> & thanks
[04:28] <Bashing-om> guiverc: Note my comments that I do not know how to indent properly ;(
[04:29] <guiverc> ack..   I've not seen any  (viewing the page when doing summaries as normal user sees it; not raw) as I usually only grab links so I can bash-keys into mousepad...
[04:30] <Bashing-om> guiverc: I note my indent failure with ">>" .
[04:30] <guiverc> do you want me to look now?
[04:32] <Bashing-om> guiverc: No not that pressing - if easy can leave me instruction in that comment.
[04:33] <guiverc> how did you want to indent it?   further than prio?
[04:33] <guiverc> s/prio/prior
[04:34] <Bashing-om> guiverc: Yeah - as we did in Gdoc - for a following item under a leading article.
[04:36] <guiverc> Bashing-om, have a look (four extra spaces added to one)
[04:36] <Bashing-om> looking
[04:36] <guiverc> adjust/tweak to get what you want... "Canonical Launches MicroCloud To Deploy" was changed SLIGHTLY
[04:39] <Bashing-om> guiverc: Gonna see how 4 spaces work out for the Cloud section articcle :)
[04:41] <guiverc> not sure if it's exactly four, but we have a preview window so you can experiment until you get something that matches what you want.. at worst the extra formatting may make it harder for scripts
[04:47] <Bashing-om> guiverc: 4 spaces makes it look good to me.
[04:48] <guiverc> :)
[04:52] <Bashing-om> guiverc: I make a note to check 4 space formatting in the M/L and the Forum post.
[04:52] <guiverc> :)
[05:02]  * guiverc adding some summaries
[05:07] <Bashing-om> guiverc: Gonna look and see if I see an indication that you are editig at this time.
[06:02] <guiverc> I wasn't in for long, click edit; search for area; paste; scroll down to next; copy & paste, scroll then copy & paste & save..
[06:08] <Bashing-om> guiverc: When yer good - man yer good! :P backing out of Discourse - seen no indication other was editng :(
[06:09] <guiverc> if you wanna try again, give me a few mins & I'll add another
[06:10]  * guiverc still writing; mild headache so loads of breaks
[06:10] <Bashing-om> guiverc: Not at thos time - taken my night meds abd heading off to bed soonest.
[06:11] <guiverc> ack & perfectly understood
[06:11] <Bashing-om> later :)
[06:11] <guiverc> i'm not surprised you didn't see anything, I've experienced it before with discourse...
[06:12] <guiverc> i believe the 'edit' click causes current page to be read without checks to see if already being edited..
[06:17] <Bashing-om> guiverc: Be nice if there were a safty guard in place there.
[23:31]  * guiverc is editing (on occasion) uwn 814  (comments; bits are irking me)
[23:41]  * guiverc out & done
[23:51] <Bashing-om> guiverc: Caught up on 814 and out of Discourse - until next time :D


[04:59] <pitti> Good morning
[05:00] <pitti> xnox: I'll look at the xdg runtime dir bug ASAP, thanks
[05:00] <pitti> slangasek: looking at binutils
[05:02] <pitti> I didn't notice anything weird after upgrading udev yesterday (and I did it a lot of times), hmm
[05:12] <pitti> slangasek: binutils> ah, same problem as with libc; an absent "Depends:" field means "Depends: @" which means "all binaries from this source
[05:12] <pitti> slangasek: but adt-run parses debian/control and then tries to install binutils-hppa64
[05:12] <pitti> slangasek: I'll upload a fix
[05:33] <pitti> meh,  I just got the new qemu, and it seems to be totally broken for me now
[05:34] <pitti> key/mouse grabbing doesn't work any more, I cannot start anything from the dash nor press alt+f2 (due to missing screen grab), and when I change the resolution it crashes
[05:36] <pitti> and with default vga it's losing my mouse cursor *sigh*
[05:55] <pitti> xnox: followed up to the bug with some questions which might help with debugging
[06:29] <dholbach> good morning
[07:13] <Versable> Hey, I am trying to package a little script but get complie errors when I try to debuild
[07:13] <Versable> libwnck/libwnck.h not found
[07:14] <Versable> I have got it in the cmakelist though set(DEPS_PACKAGES     glib-2.0     granite     libwnck-3.0 )
[07:15] <geser> have you also the -dev package for it installed?
[07:15] <Versable> yes, it compiles fine when I do it manually
[07:15] <Versable> valac --pkg libwnck-3.0 -X -DWNCK_I_KNOW_THIS_IS_UNSTABLE showdesktop.vala
[07:15] <Versable> with that
[07:18] <Versable> http://pastebin.com/E3EbQp3k
[07:19] <geser> are you building with pbuilder/schroot or similar? then you also need to have the package listed in Build-Depends so it get installed for the build
[07:21] <Versable> Also in thereIt's also in there
[07:21] <Versable> Build-Depends: cmake (>= 2.8),                debhelper (>= 8.0.0),                valac-0.16 | valac (>= 0.16),                libgranite-dev,                libwnck-3-dev,
[07:30] <geser> Versable: looking at your pastebin it's not the valac call failing but the following gcc call, there seems to be a -I/usr/include/libwnck-3.0 missing
[07:31] <dholbach> I have a funny problem with (I believe) resolvconf - etc/resolv.conf is a link to /run/resolvconf/resolv.conf - my wifi seems to have <IP_ADDRESS> set as its primary DNS, but resolv.conf says it's <IP_ADDRESS> - and I can't get it to change it (and don't want to edit resolv.conf manually) - did anyone else ever run into this?
[07:32] <Versable> Where/how do I define it, my cmakelist.txt: http://pastebin.com/q9r8PSUK
[07:38] <geser> Versable: I'm not very familiar with cmake but try to add "libwnck-3.0" to DEPS_PKG (those get passed to pkg-config and I hope cmake passes all those CFLAGS in ${DEPS_CFLAGS})
[07:40] <Versable> geser: That almost worked, it's giving me "#error "libwnck should only be used if you understand that it's subject to frequent change, and is not supported as a fixed API/ABI or as part of the platform"
[07:41] <Versable> geser: I think I have to pass  -X -DWNCK_I_KNOW_THIS_IS_UNSTABLE to gcc too
[07:43] <Versable> geser: where would i define global gcc compiler options/arguments
[07:47] <seb128> dholbach, hey, /etc/resolv.conf isn't a symlink for me
[07:47] <seb128> but I didn't update/restart yet this morning
[07:47] <dholbach> this machine is still on raring
[07:48] <dholbach> hum... for some reason it wasn't auto-updated for me in the past and I think in some manpage I read that it was supposed to be (or can be) a symlink - either way it's not updated
[07:49] <pitti> seb128: oh, you don't have resolvconf installed?
[07:49] <seb128> pitti, no, I don't
[07:49] <dholbach> or rather /run/resolvconf/resolv.conf was updated when I reconnected to my wifi, but it still has <IP_ADDRESS> instead of <IP_ADDRESS> as the nameserver
[07:49] <seb128> dholbach, seems like your config is normal then, not mine ... not sure why you have a wrong DNS in there though
[07:50] <seb128> did that start recently?
[07:50] <pitti> Task: minimal
[07:50] <dholbach> seb128, in the last few weeks I noticed problems - at the sprint too
[07:50] <seb128> dholbach, it might be that the dns info is sent by the dhcp, are you on a new network?
[07:50] <dholbach> seb128, no, my home network
[07:50] <pitti> seb128: missing ubuntu-minimal then?
[07:50] <dholbach> and I rebooted the machine last night
[07:51] <seb128> pitti, indeed, that install is over 3 years, I probably got it removed at some point ... installing, thenks ;-)
[07:51] <geser> Versable: try changing the add_definitions line to : add_definitions(${DEPS_CFLAGS} -DWNCK_I_KNOW_THIS_IS_UNSTABLE)
[07:51] <seb128> pitti, do you have any idea about how resolvconf works otherwise? dholbach gets a wrong DNS info in there
[07:52] <pitti> roughly
[07:52] <dholbach> in the past I would have just edited resolv.conf manually and put a nameserver I know in there, but I figured it's be good if it just worked and took the information from DHCP :)(
[07:53] <pitti> so, NM calls dhclient, dhclient calls some script when it's done
[07:53] <Versable> geser: Awesome, that did it, you are my hero of the day :D
[07:53] <pitti> and /etc/resolvconf/update.d/*
[07:54] <pitti> /etc/resolvconf/update.d/libc writes the new nameserver to /run/resolvconf/resolv.conf
[07:54] <dholbach> pitti, /run/resolvconf/resolv.conf seems to have been updated when I reconnected to the wifi
[07:54] <pitti> or rather, to /run/resolvconf/interface/ first, and update-resolvconf then builds /run/resolvconf/resolv.conf
[07:54] <pitti> dholbach: ah, so /run/resolvconf/resolv.conf is fine?
[07:54] <dholbach> no, it has the wrong dns
[07:54] <pitti> dholbach: /etc/resolv.conf -> ../run/resolvconf/resolv.conf
[07:54] <dholbach> pitti, yes
[07:54] <pitti> dholbach: do you have that?
[07:54] <dholbach> ah, where's update-resolvconf from?
[07:55] <seb128> dholbach, forums suggests that <IP_ADDRESS> is dnsmasq
[07:55] <pitti> dholbach: sorry, resolvconf -u
[07:55] <seb128> dholbach, do you have that installed?
[07:55] <dholbach> seb128, dnsmasq is not installed
[07:55] <seb128> k, not that then :p
[07:55] <pitti> dholbach: you can check /var/log/syslog for the NetworkMangaer log which address dhclient got from your router
[07:56] <pitti> dholbach: dnsmasq-base
[07:56] <dholbach> Jun  5 09:22:57 daydream NetworkManager[877]: <info>   nameserver '<IP_ADDRESS>'
[07:56] <pitti> and that's required by NM, you ought to have it
[07:57] <pitti> hmm
[07:57] <pitti> dholbach: so what's actually wrong?
[07:57] <pitti> /etc/resolv.conf is supposed to only have <IP_ADDRESS>
[07:57] <dholbach> ahhhh ok
[07:57] <pitti> dholbach: so your computer cannot resolve DNS names?
[07:57] <pitti> i. e. what is the actual problem?
[07:57] <pitti> dnsmasq isn't working?
[07:58] <dholbach> I thought it was supposed to be what dhcp told it to be
[07:58] <dholbach> a red herring then - it might be some other networking problems
[07:58] <pitti> I think NM moved to dnsmasq to better support things like tethering (but I don't know details -> cyphermox)
[07:59] <dholbach> ok
[07:59] <seb128> dholbach, is your system failing to resolv names to ips?
[08:00] <dholbach> strange, I just did a "wget http://reqorts.qa.ubuntu.com/reports/sponsoring/" which worked fine, but loading the page in firefox seems stuck at the "looking up ...." stage
[08:01] <dholbach> it works fine in chromium
[08:01] <dholbach> sorry for all the confusion
[08:02] <seb128> dholbach, ok, that's when you go find chrisccoulson ;-)
[08:02] <dholbach> thanks everyone
[08:02] <seb128> dholbach, yw ;-)
[08:04] <dholbach> thanks pitti as well
[08:04] <pitti> kein Problem
[08:04] <dholbach> and I learned a few more new things now - great :)
[08:11] <chrisccoulson> my ears are burning
[08:11] <chrisccoulson> firefox is nothing to do with me now ;)
[08:37] <pitti> xnox: FTR, I tried to open extra sessions after the upgrade, and none of them killed my runtime dir
[08:39] <xnox> pitti: yeah, tested same quickly here. I'm not sure anymore what else I had going on at the time.
[08:40]  * pitti reads the user_stop() code which calls user_remove_runtime_path()
[08:40] <pitti> but that would kill your whole session, cgroup etc, too
[08:40] <pitti> and ther are no other relevant unlinks/rmdir/rm_rf
[08:41] <pitti> (and even then, logind isn't even supposed to restart during dist-upgrade, I disabled that as the cgroup layout changed in 204)
[08:42] <pitti> xnox: so what could happen: you dist-upgrade, then you or something kills systemd-logind, then you start some new session, the new logind gets spawned
[08:42] <pitti> and that doesn't have any sessions (due to the changed cgroup layout); but then I still don't see why it should call user_stop() as it doesn't have any sessions
[08:42] <pitti> but perhaps something along that line
[08:43] <pitti> xnox: perhaps that upgrade to 204 should just trigger a reboot notification?
[08:43] <seb128> bdmurray, slangasek: I restored the "auto-launch" key in the update-notifier schemas (just there, not the feature in the code), it's being used by update-manager and it was aborting on start with the new update-notifier (gsettings abort on broken schemas/missing keys)
[08:43] <seb128> bdmurray, slangasek: that's a FYI
[08:43] <seb128> bdmurray, slangasek: update-manager should probably be taught about not using that key if it's deprecated
[08:44] <xnox> pitti: That seems reasonable. Given that we only have people who reboot when asked, and otherwise keep their sessions suspended.
[08:45] <pitti> xnox: ok, doing that then; do you think you can squeeze out anything else from this bug?
[08:46] <xnox> pitti: don't think so.
[08:48] <pitti> xnox: ok, doing that then; thanks!
[08:58] <OdyX`> tkamppeter_: It would be very nice to have you comment on http://bugs.debian.org/711169 as I'm really at loss in all that change.
[09:02] <pitti> xnox: hm, I called /usr/share/update-notifier/notify-reboot-required, and /var/run/reboot-required is there now, but I don't get an actual reboot notification
[09:03] <pitti> seb128: ^ do you know whether that moved from update-notifier to the indicator, and might not actually work?
[09:03] <seb128> pitti, update-manager is supposed to have a reboot required banner
[09:04] <pitti> oh, we don't make the session indicator red for that any more? ISTR that this was the case
[09:04] <seb128> pitti, let me check for the indicator, I'm not sure if they didn't drop the feature
[09:04] <mitya57> do we want new git in saucy? (bug 1187662)
[09:05] <anon^_^> pitti, sorry to bother you
[09:05] <anon^_^> Has there been any movement internally to bring ubiquity up to parity with manual partitioning features lost by discontinutation of alternate cds?
[09:05] <anon^_^> As of Ubiquity 2.14.6 (raring release) it is still not possible to manually create/configure lvm within an encrypted physical volume
[09:05] <infinity> mitya57: autosync would pick it up anywya.
[09:05] <anon^_^> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1187660
[09:05] <pitti> infinity: not from experimental
[09:05] <infinity> Oh.
[09:05] <infinity> Right.
[09:05] <infinity> Just saw that.
[09:06] <infinity> Then yes, I want a new git, and I'm syncing it. :P
[09:06] <pitti> anon^_^: hm, I'm not working on ubiquity; I haven't heard of plans to extend that, maybe xnox or stgraber know
[09:07] <xnox> anon^_^: there are wireframes done, and I did start implementing it, but it wasn't finished and it isn't a priority to complete at the moment.
[09:07] <pitti> seb128: ah right, u-m tells me to reboot; but that doesn't really help for apt-get
[09:07] <xnox> anon^_^: thus I marked your bug as a duplicate of an earlier one.
[09:07] <anon^_^> xnox any sort of timeline?
[09:07] <anon^_^> sorry i just noticed, logged out awhile back
[09:07] <seb128> pitti, the indicator is still supposed to turn red afact but better to check with larsu/ted/charles
[09:08] <seb128> pitti, src/dialog.c:	return g_file_test("/var/run/reboot-required", G_FILE_TEST_EXISTS);
[09:08] <pitti> -rw-r--r-- 1 root root 42 Jun  5 11:06 /var/run/reboot-required
[09:08] <pitti> yep, definitively
[09:08] <pitti> seb128: err, is that from the indicator? it's hardly a dialog
[09:08] <seb128> pitti, if you pick shutdown, does the dialog tell you that restart is needed?
[09:09] <pitti> no
[09:09] <seb128> it should
[09:09] <pitti> also, why would I pick shutdown
[09:09] <seb128> oh, but we replaced those dialog by unity ones
[09:09] <tkamppeter> OdyX, the only way to replace the removed broadcasting/browsing in CUPS is to use avahi-daemon and cups-browsed and use package dependencies to get the smooth transition for the user.
[09:09] <pitti> well, I would, but it seems xnox doesn't, he always just suspends
[09:09] <seb128> pitti, sorry, logout
[09:09] <pitti> seb128: same thing though; it's the other way around, people wouldn't log out until they see that they need to reboot
[09:10] <pitti> hence the nice "turn indicator red for reboot"
[09:10] <seb128> pitti, to check with larsu/ted/charles, I'm sorry but I'm unsure of the details, I seem to remember that mpt/design told them to drop the red entry but I'm not sure now
[09:10] <pitti> ack
[09:10] <seb128> pitti, well, update-manager tell you to reboot after upgrade
[09:10] <seb128> so users should see it
[09:11] <infinity> I'm not sure the red was all that intuitive, but we need *something* to inform people who aren't using update-manager.
[09:11] <seb128> it even don't let you a choice, they removed the close button from that dialog
[09:11] <pitti> yeah, that's nasty, too
[09:11] <infinity> My motd doesn't even seem to be yelling at me about /var/run/reboot-required anymore.
[09:11] <infinity> Hrm.
[09:11] <seb128> infinity, if people are smart enough to not use our provided tools they should be smart enough to know when to reboot :op
[09:12] <infinity> Maybe.
[09:12] <infinity> I like the nag.  I forget after a while.
[09:12] <infinity> Like, I'll upgrade and know I needed to reboot, but then work for another two days and forget. :P
[09:12] <pitti> yeah, that's why I liked the red indicator
[09:14] <infinity> The following packages have been kept back:
[09:14] <infinity>   gcc-4.8-base:i386 libgcc1:i386 libstdc++6:i386
[09:14]  * infinity looks sideways at apt.
[09:19] <seb128> infinity, pitti, xnox: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-session/trunk.13.10/revision/275
[09:19] <seb128> ok, found it back
[09:19] <pitti> *sniff*
[09:20] <infinity> Sadness.
[09:20] <pitti> slangasek: yay, binutils succeeds now \o/
[09:20] <pitti> (the autopkgtest)
[09:21] <infinity> hallyn: Grr.  You dropped my qemu change.  Again.
[09:21] <infinity> hallyn: Are you merging in a way that ignores the archive?  Should I be committing somewhere magical?
[09:33] <OdyX`> tkamppeter: IPP doesn't work anymore ? Also, could you comment on the bug, it would be very helpful.
[09:48] <Laney> mardy: hey, subscribed you to a couple of uoa/eds bugs that I found if you've time to look at them some time :-)
[09:56] <ogra> pitti, slangasek, uuuh ... with bug 1187616 you need to be super duper careful, we already load all firmware in android, some devices really dont like if it gets loaded twice
[09:57] <dholbach> @pilot in
[09:57] <pitti> ogra: do drivers issue a firmware uevent if they already have the fw loaded?
[09:58] <pitti> ogra: if this gets in the way, it's fine to revert of course; it just sounded to me like something which is needed
[09:58] <ogra> (preferably you leave it to the binary driver to use it's hardcoded path (which means you need to have the right mountpoints) and dont have udev intervene at all here)
[09:58] <ogra> pitti, well, it will help for some drivers, but definitely break some too
[09:58] <pitti> ogra: OK, I leave it to you and slangasek to figure out what needs to happen :)
[09:58] <pitti> ogra: but drivers definitively shouldn't ask for firmware if they already have it
[09:59] <ogra> normally the android driver has a hardcoded firmware path and probably a fallback ... that is the reason why we need to have the android mountpoints in ubuntu at the right places
[10:00] <ogra> pitti, well, depends, the drivers load their stuff inside an lxc container we probably dont have the info that it is loaded outside of that container
[10:01] <pitti> lxc containers don't have their own drivers/kernels
[10:01] <ogra> preferably we dont want to handle drivers under ubuntu at all if they are alreayd set up in the container ... *but* we want udev to provide the same interfaces in /dev that the container has
[10:02] <ogra> no, but their own userspace that acts completely different from ours
[10:02] <pitti> firmware information isn't in /dev, it's in /sys (and uevents); those should be shared across all containers
[10:02] <ogra> theoretically all deviCes should be handled in the container and our userspace only talks to them through the platform-api sockets and /dev
[10:02] <pitti> ogra: alright; as I said, if you figure out how it ought to be, feel free to upload or poke me to upload
[10:03] <ogra> yeah, i'lll need to talk to steve for sure ... and i guess that needs some deep testing
[10:04] <ogra> i think we ratrher want an option to ignore device initialization and just some rules that mimic the android /dev for us
[10:04] <pitti> ogra: would be interesting to see if there is actually a driver which we need to handle that way
[10:05] <ogra> lxc-android-config already ships a bunch of rules ...
[10:22] <pitti> ev<EMAIL_ADDRESS>says "no such user", and https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=pitti&period=month has "no data to display"; is that not the LP user ~pitti, but something else perhaps?
[10:22] <pitti> ev: or not the packages I'm subscribed to in LP?
[10:23]  * ev looks
[10:23] <ev> user=pitti is definitely correct, by the way
[10:24] <pitti> ev: well, in the very best case there just are no crash reports in my packages, but I wouldn't trust that yet :)
[10:24] <ev> no, there should be
[10:24] <ev> if you take your name out, there are apport crashes in that list
[10:24]  * pitti tries https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=seb128&period=month
[10:24] <ev> and I would assume you're at least subscribed to that :)
[10:24] <ev> bdmurray: ^ thoughts? The API call is definitely returning the empty set: https://errors.ubuntu.com/api/1.0/most-common-problems/?format=json&limit=100&release=Ubuntu%2013.10&user=pitti&period=month
[10:24] <pitti> yes, I'm sub'ed to like two dozen
[10:25] <seb128> pitti, is that a "pitti haz no bog but seb does"? ;-)
[10:25] <pitti> "An error occurred while trying to load the most common problems"
[10:25] <pitti> seems seb128 is oversubscribed and over-bugged :)
[10:26] <seb128> lol
[10:26] <seb128> works here
[10:26] <seb128> but 13.10 has very few users
[10:26] <seb128> those stats are not very useful
[10:26] <ev> filed https://bugs.launchpad.net/errors/+bug/1187723 to track it
[10:27] <ev> bdmurray: if you don't have time for that one, let me know and I'll have a look
[10:28] <pitti> https://errors.ubuntu.com/?release=Ubuntu%2013.10&user=cjwatson&period=month
[10:28] <pitti> that just has one bug
[10:28] <pitti> presumably wrong, too
[10:30] <seb128> pitti, well, as said the numbers are low, see https://errors.ubuntu.com/?release=Ubuntu%2013.10&period=month
[10:30] <seb128> pitti, entry 16 is down to 4 reports in a month
[10:30] <pitti> yeah, that's right
[10:31] <seb128> that seems buggy low though
[10:31] <pitti> yes, I meant "right, it's too low and looks wrong"
[10:34] <seb128> ev, how long does it take between submit and datas supposed to be listed on e.g https://errors.ubuntu.com/?release=Ubuntu%2013.10&period=day ?
[10:34] <ev> seb128: it's instantaneous
[10:34] <ev> well
[10:34] <ev> if it's Python :)
[10:34] <ev> for binary crashes that haven't already been retraced, it needs to go through that process first
[10:35] <ev> and that can take some time - we're having issues at the moment around the Swift backend storage we use for the core dumps
[10:35] <ev> in that it's not accepting them
[10:35] <seb128> ev, pitti and Laney reported some issues earlier today on evolution-data-server and signon-ui and the report has 0 entry for those components today, is that normal?
[10:35] <ev> but we're also in the middle of a move to oops.canonical.com, which makes debugging that tricky
[10:36] <seb128> ok
[10:36] <ev> yes, because e-d-s is a binary and the retracers are having difficulty due to the problem mentioned above
[10:36] <ev> working to resolve it as quickly as I can
[10:36] <seb128> no worry
[10:37] <seb128> it's not a today problem, but the 13.10 number of reports seem low (that's not new) and I was wondering if that's just low number of users or if there is a bug and we loose datas on the way
[10:39] <ev> seb128: sure, and thanks for making me aware of it. I suspect it's a combination of the two. We don't get a lot of users this early in the release, but there's also the bug preventing retracing from happening. We're not losing data per-se, as we're just dropping core submissions on the ground. We still have all the metadata for each crash that comes in, and when a matching core file is submitted from a different user and its finally retraced, those
[10:39] <ev>  crashes will be bucketed.
[10:40] <seb128> ev, ok, good to know that the datas are not lost, thanks for the status update
[10:41] <ev> seb128: yeah, it's a big thing of mine that we try as hard as we can to never drop the actual reports or ever remove them from the DB
[10:41] <ev> we often need to iterate back over them as we learn how to do things better or add new features
[10:41] <ev> and big gaps would make future calculations of "are we doing better?" look weird
[10:42] <ev> sure thing though. As always, let me know if anything else is broken
[10:43] <mardy> Laney: thanks! I asked help from the Evolution maintainer, in turn :-)
[10:43] <Laney> :D
[10:47] <mardy> Laney: did you try killing evolution-calendar-factory?
[10:47] <Laney> mardy: for the indicator one?
[10:47] <Laney> (no, but can do)
[10:48] <mardy> Laney: I'd say for both
[10:48] <Laney> ok, let me re-add the account and try
[10:48] <mardy> Laney: I guess they are very strictly related
[10:48] <Laney> yes, I think so
[10:49] <Laney> hm, straight after adding it I get told it's not authorised and then "Grant access" takes me to a page with standard Username/Password entries instead of the usual webview
[10:51] <mardy> Laney: weird... you are talking about the Google account?
[10:51] <Laney> yes
[10:51] <mardy> Laney: ah, maybe it's not that weird; I think that for the calendar EDS is using a plain username/password authentication
[10:52] <Laney> so it could be choking on my 2fa then?
[10:52] <Laney> killing the calendar factory made me get the same not authorised thing
[10:53] <Laney> mardy: didn't make it work though
[10:53] <Laney> but I suppose this is more information
[10:54] <mardy> Laney: yes, it looks like the username/password is invalid, or anyway not enough to authenticate
[10:54] <mardy> Laney: is that a 2-factor-auth enabled account?
[10:54] <Laney> yep, both are (canonical and personal)
[10:55] <Laney> well, canonical is 2 factor through Ubuntu SSO; don't know how that interacts with this
[10:55]  * Laney tries adding that one
[10:56] <dholbach> @pilot out
[10:57]  * Laney remembers that he has an old google account without 2fa
[10:57] <Laney> now, what are the details for that?
[10:58] <xnox> Laney: despite 2fa/SSO on the google-account, for e.g. plain access (webdav, ical, smtp, imap, etc) you need "normal bog-standard google password" for canonical accounts or the "static application specific" passwords for personal accounts.
[10:58] <xnox> Laney: if you don't remember it, #is can reset it for you. (there is no web ui to do it)
[10:59] <Laney> I have the Google account password, but giving that on the "plain" page didn't make it succeed
[10:59] <xnox> =(
[11:01] <ogra> the touch images need all android groups in the system on the ubuntu side with fixed GIDs ... currently we create them at build time with a live-build hook script, i'm planning to move all this into a postinst of the lxc-android-config package, does anymone know what happens if a group with a GID i need already exists ?
[11:02] <Laney> mardy: Aha — I added another, non 2fa, account and that seems to work beautifully.
[11:03] <cjwatson> ogra: If you need fixed GIDs then you must coordinate with the Debian base-passwd maintainer
[11:03] <cjwatson> ogra: (i.e. me)
[11:03] <Laney> at least email and calendar in evo, and I got loads of spam friend requests on empathy
[11:04] <cjwatson> ogra: Send mail to<EMAIL_ADDRESS>with your requirements and we can talk through them
[11:04] <ogra> cjwatson, i think they are all above 1000, i'm just wondering
[11:04] <Laney> so it seems like the altenate authentication workflow needs more work (even if that's to fail better for now)
[11:04] <cjwatson> ogra: Please send me mail since it sounds like you're doing bad things and I want to help you do good things instead. :-)
[11:04] <ogra> and i dont have a complete list yet ... only know the wones we use already ... perferably we want them alll though
[11:04] <ogra> cjwatson, well, we dont have much choice ... the GIDs are hardcoded in the kernel
[11:05] <ogra> android is doing bad things here
[11:05] <ogra> but yeah, let me get a full list and i'll mail
[11:05] <cjwatson> Oh, they're specific fixed GIDs forced on you by external forces
[11:05] <cjwatson> That's ... not ideal
[11:05] <ogra> yeah
[11:05] <ogra> thats android :)
[11:06] <ogra> and binary daemons might rely on it
[11:06] <cjwatson> Still, I'd like to have a mail record of what's going on here, even if we can't do anything about it
[11:06] <ogra> right, i'll first discuss that with rsalveti
[11:06] <ogra> in any case i want it in a package postinst instead of having a build script
[11:10] <asac> ogra: dont do bad things - i told you before :-P
[11:10] <ogra> haha
[11:10] <asac> not sure why the good ogra is always doing such things
[11:10] <tkamppeter> OdyX`, I have commented on the bug now.
[11:11] <cjwatson> I don't suppose there's any hope of libhybris doing whizzy GID mapping for us so that we don't have to know about the Android GIDs on the Ubuntu side?
[11:11] <cjwatson> For that matter, shouldn't this be handled by running the Android binary daemons in a container?  Container GIDs don't have to match the host ones
[11:12] <ogra> the issue is that the kernel refuses device access for some bits if the GID doesnt match exactly
[11:12] <cjwatson> Mm.  I thought this was the kind of thing libhybris was supposed to be able to help with.
[11:13] <ogra> i.e. network access is only allowed for GID 3002 3003 3004
[11:13] <ogra> so if we access devices on the ubuntu side they need to be owned by the right group and the user needs to be part of them
[11:13] <ogra> radio is similar ...
[11:14] <ogra> live-build/ubuntu-touch/hooks/02-add_user_to_groups.chroot has the current list we use
[11:16] <ogra> (but there are a lot more)
[11:23] <ogra> aha
[11:23] <ogra> found the mapping in the android tree
[11:23] <ogra> http://paste.ubuntu.com/5735451/ should be the full list
[11:23] <ogra> seems to be all above 1000
[11:24] <cjwatson> The whole thing is based on fundamentally different assumptions about how things are laid out though; e.g. the system user at 1000
[11:24] <ogra> yeah, well
[11:24] <ogra> dont tell me :)
[11:24] <cjwatson> I kind of think we're going to get ourselves into trouble if we assume that the only way to address this is to create matching groups on the Ubuntu side
[11:24] <ogra> we cant hack binary daemons ro drivers that are linked against this
[11:25] <ogra> we could change thee kernel, but that wont fix bianry blobs
[11:25] <ogra> *binary
[11:25] <cjwatson> We could, for example, punt certain kinds of device access behind the scenes through the Android container
[11:25] <ogra> depends if you access stuff directly through a socket or not
[11:26] <cjwatson> You use the C library to create the socket, so ...
[11:26] <ogra> i.e. ofono attaches to the binary vendor rild via a socket
[11:26] <ogra> which has to be the original one from android
[11:26] <ogra> (linked into /dev from the android /dev)
[11:27] <ogra> might be possible to have a wrapper or some such
[11:27] <ogra> but i dont think anyone even throught about GID remapping yet
[11:27] <cjwatson> Somebody might have to :)
[11:27] <ogra> definitely ...
[11:27] <cjwatson> Anyway, if you do create these groups, please create only the minimal set you absolutely need so that any future cleanup is kept to a minimum and there's the lowest probability of clashes
[11:28] <ogra> yeah, indeed
[11:28] <ogra> the above live-build script has the minimal set we need atm
[11:29] <ogra> (only 10 groups with fixed GID in there atm)
[11:30] <cjwatson> You'll have to just use 'getent group GROUP_NAME >/dev/null || addgroup --gid NEW_GID GROUP_NAME', I think, or similar, and if it fails there's nothing you can do
[11:30] <cjwatson> You can't even use --system since these aren't in the system range
[11:30] <ogra> yeah
[11:31] <cjwatson> Do please use addgroup rather than the low-level groupadd stuff you're doing right now though
[11:31] <cjwatson> And OMG what is all that madness adding global static groups
[11:31] <cjwatson> Most of that script desperately needs to be deleted
[11:32] <ogra> will do, i need to discuss that with sergiusens  and rsalveti anyway before i do anything ... looking at the script it seems to not care about GIDs at all if for example a group already exists
[11:32]  * doko watches cjwatson's blood pressure going up ...
[11:32] <cjwatson> Heh
[11:32]  * mlankhorst puts cjwatson in AID_UNUSED1
[11:33]  * ogra points out that he is just the messenger ... not my script
[11:33] <ogra> i just want to clean that up and not have it in the build scripts
[11:33] <cjwatson> Sure, I know, but you can be a messenger in the other direction too :P
[11:33] <ogra> thats what i plan
[11:33] <cjwatson> There might be an argument for it creating admin (but it MUST use 'addgroup --system' to do it, if it does); there is absolutely no justification for it creating any of the groups listed in /usr/share/base-passwd/group.master
[11:33] <cjwatson> Especially not in that invalid way
[11:33] <ogra> i consider sanitizing this part of the container flip
[11:34] <ogra> which as i said above, has no real planning at all yet
[11:34] <cjwatson> And it should use adduser to add the user to that set of groups, not usermod
[11:34] <ogra> yeah
[11:34]  * cjwatson attempts to haul this up to saner levels of the stack
[11:35] <ogra> let me discuss with our android heads first, before we take any action ...
[11:36] <ogra> i think *if* we have such s script it definitely belongs into the android container package though ... not in the build scripts (i.e. on x86 you most likely would want that stuff at all)
[11:36] <ogra> *wouldn't
[11:59] <hallyn> infinity: I woulda held off but there was a cve fix in there too.  As for the sources, I keep them at github.com/hallyn/qemu, and I rebase against debian-unstable from git://anonscm.debian.org/pkg-qemu/qemu.git
[11:59] <hallyn> infinity: if you prefer i can ping you before a next update - though i'm hoping i'm done for awhile
[12:02] <hallyn> infinity: i swear i checked for later updates!  but i guess i did that before rebasing - sorry
[12:03] <hallyn> won't happen again
[12:06] <hallyn> (pushing your change to github for good measure0
[12:06] <ogra> bug 1187750
[12:06] <ogra> cjwatson, ^^^
[12:07] <cjwatson> ogra: Independent of that, can I just go ahead and delete the spurious attempts to create global static groups (the ones base-passwd ships on all systems)?
[12:07] <ogra> cjwatson, definitely
[12:08] <cjwatson> Whoa, what the heck is that stuff with the audio gid :-(
[12:08] <cjwatson> That's going to break as soon as base-passwd is upgraded
[12:08] <ogra> yeah
[12:09] <ogra> thats why the touch images are not officially supporting apt based upgrades i guess :)
[12:10] <cjwatson> Well it's just plain wrong
[12:10] <cjwatson> If you need a fixed gid for audio handling that doesn't match the one in base-passwd then it must be called something else
[12:11] <ogra> android_audio then ... though that will obsolete the normal audio group
[12:12] <cjwatson> Better to obsolete it than to screw it over
[12:12] <ogra> indeed
[12:19] <ogra> asac, you might want to monitor the ablve bug too probably
[12:19] <ogra> *above
[12:19]  * ogra ponders to file the same thing about the environemnt setup ... live-build currently overwrites /etc/environment and fills it with a ton of stuff
[12:21] <ogra> (in live-build/ubuntu-touch/hooks/48-setup-env.chroot )
[12:23] <cjwatson> mm, that seems like it should be set by a session script or something
[12:23] <cjwatson> SHLVL=1 ???
[12:23] <cjwatson> Did somebody run env and copy and paste, or something?
[12:24] <ogra> could be
[12:24] <sergiusens> cjwatson: ogra I already removed some gid checking which you never saw, like access to surfaceflinger or sensors
[12:24] <ogra> i have no idea how these scripts were developed initially
[12:24] <ogra> it predates my involvement
[12:25] <sergiusens> for audio, I'm guessing most of it will go away once jim finishes up his native ubuntu audio integration
[12:25] <ogra> sergiusens, well, the question is what do we really need
[12:25] <sergiusens> rild is a pain though
[12:25] <ogra> i assume for everything that talks directly to an android socket like rild we wont get around having the groups
[12:25] <ogra> yeah
[12:26] <ogra> but for all other stuff we might be able to find a better solution
[12:26] <cjwatson> depends, as I say, what interface android is using to find out the group id of its peer, and whether that can be fooled
[12:26] <ogra> or even have a wrapper on the ubuntu side that does some re-mapping or so
[12:27] <ogra> cjwatson, well, android obviously uses its header files ... but i know that the kernel also uses some of this
[12:27] <ogra> the prob are really the binary bits we dont have contol over ... though only if we talk to them directly
[12:27] <sergiusens> cjwatson: ogra I'll take this one and start on Monday if rsalveti isn't eager to (I'm off tomorrow and the day after)
[12:28] <ogra> sergiusens, whats your solution ?
[12:28] <sergiusens> ogra: let me look at it first and then propose something ;-)
[12:28] <ogra> is anything else but ofono talking directly to rild ? we might be able to have a wrapper in there that does the remapping
[12:29] <sergiusens> ogra: so gps creates an IPC socket on manta on /data
[12:29] <sergiusens> the binary blob that is
[12:30] <sergiusens> so let me consolidate all the cases we have and see if I can factor something common for all
[12:33] <infinity> hallyn: S'all good, was just mildly annoyed when I saw component-mismatches explode again.
[12:35] <ogra> though i dont know if there is more than rild .... i guess there is a reason why we have 10 groups already ... they are definitely not all rild related
[12:43] <cjwatson> mitya57,seb128,xnox: the insighttoolkit4 build failure isn't making a lot of sense to me, partly because I don't know cmake that well.  Can any of you help?  At first glance I thought it was basically a missing build-dep on libvtkgdcm2-dev, but I don't think that's right - insighttoolkit4 doesn't really need it, and if you compare with e.g. ...
[12:43] <cjwatson> ... https://buildd.debian.org/status/fetch.php?pkg=insighttoolkit4&arch=sparc&ver=4.3.2-1&stamp=1367450169 (yes, it fails later, but ignoring that), there's the same message about /usr/lib/libvtkgdcm.so.2.2.3 but it's non-fatal
[12:44] <cjwatson> indeed even building insighttoolkit4 on current unstable seems to succeed, or at least get well past the configuration step
[12:44] <cjwatson> so I don't understand what's different between Debian and Ubuntu here
[12:45] <cjwatson> cmake is identical, and neither the gdcm nor insighttoolkit4 changes seem relevant
[12:46] <zul> cjwatson: hi can you promote python-mimeparse python-testtools is in dep wait because of it (mir https://bugs.launchpad.net/ubuntu/+source/python-mimeparse/+bug/1187527)
[12:48] <cjwatson> zul: done
[12:48] <zul> cjwatson:  thanks
[12:59] <ion> mvo: Hi. Are you around?
[13:01] <mvo> hey ion, yes
[13:02] <ion> mvo: Does this look okay? ttps://github.com/ion1/apt/commits/debian/sid
[13:02] <ion> Err. https://github.com/ion1/apt/commits/debian/sid
[13:05] <wzssyqa> doko: hi, any idea about howto get multilib bootstrap?
[13:06] <doko> context?
[13:06] <mvo> ion: from a first look yes, thanks! will you propose it for merging?
[13:07] <seb128> mvo, hey, how are you?
[13:07] <ion> mvo: Do i need to do something special to get it merged or can you just do it?
[13:07] <seb128> mvo, do you plan to merge apt on the current Debian version at some point?
[13:07] <mvo> seb128: can do, sure! I'm well, thanks
[13:08] <seb128> mvo, thanks ;-)
[13:08] <seb128> mvo, glatzor: do you know if anyone is porting aptdaemon to the pkgkit 0.8 interfaces?
[13:11] <mvo> ion: I can just do it, there is a small "send pull request" or something that you can use to make it easier for me to not forget about it
[13:15] <glatzor> hello seb128, mvo. Actually yes: me :)
[13:15] <seb128> glatzor, hey, how are you?
[13:15] <glatzor> seb128, mvo I am currently on vacations and hopefully will find some time tomorrow or the day after to continue the work. I already started the port. But the interface changed really a lot.
[13:16] <seb128> glatzor, great, are you still working on it (the vcs pointed on the blueprint we found didn't get any commit this year) ... do you have an estimate on how much work that is/when it will be ready?
[13:16] <glatzor> seb128, I am fine!
[13:16] <glatzor> seb128, perhaps end of month to get it stable.
[13:17] <glatzor> seb128, do you need the packagekit 0.8 client library?
[13:17] <seb128> glatzor, I'm asking because we got the new packagekit uploaded and we were wondering if we should revert that or try to go through the transition
[13:17] <glatzor> seb128, revert it for the moment
[13:17] <seb128> glatzor, it's currently blocked in saucy-proposed
[13:17] <seb128> Laney, pitti, cjwatson: ^
[13:17] <glatzor> seb128, that is my suggestion
[13:18] <pitti> right, so same conclusion that we had yesterday
[13:18] <pitti> hey glatzor, wie gehts?
[13:18] <seb128> cjwatson, btw saw your ping about cmake, I'm not really fluent in cmake either but I can try having a look a bit later if mitya57/xnox don't ping back/have a clue about the issue
[13:18] <glatzor> pitti, supi! could not be better. The sun is shining here in Bavaria!
[13:19] <glatzor> pitti, and even in Scotland we only had one hour of rain in a whole week
[13:19] <pitti> glatzor: I know, at last! I'm enjoying it since yesterday, too (Augsburg)
[13:21] <doko> wzssyqa, context?
[13:21]  * rsalveti checking backlog
[13:26] <ion> mvo: I actually tried making a pull request to you when i noticed you have a github account, but since my repo isn’t already a fork of yours, github doesn’t seem to allow that. Let me delete the repo, fork yours and push again, a moment…
[13:27] <wzssyqa1> doko: I am working on mips64(el) ports, and the system can bootstrap now, while I have no idea about how to break the cycle of eglibc and gcc to enable multilib
[13:27] <rsalveti> cjwatson: ogra: sergiusens: I believe we can come up with a mix of disabling group/user id checking and handling weird setups (and binary blobs) via libhybris
[13:27] <rsalveti> in a way we could indeed have a better setup than just matching user and group ids
[13:27] <rsalveti> it's just that we never really spent any time on that
[13:27] <ogra> rsalveti, yeah, i was guessing so, but waht about stuff that talks directly to i.e. rild ?
[13:27] <rsalveti> I can take a better look in more details later today and see what can be done on the android side
[13:28] <ion> mvo: mvo5, correct?
[13:28] <mvo> ion: yeah
[13:28] <rsalveti> ogra: that's fine, we just need to change the permission for the sockets
[13:28] <rsalveti> for sockets we'd need a script or something anyway as we'd need to either link or bindmount the /dev/socket from android
[13:28] <ogra> well, we only get the sockets by linking the /dev/socket dir from android to /dev
[13:28] <rsalveti> as that's created by android
[13:28] <ogra> if we chjange them on our side it might break
[13:29] <rsalveti> right, and we can probably do something smart there to change the default permission as well
[13:29] <rsalveti> I don't think so
[13:29] <doko> wzssyqa, is this for Ubuntu?
[13:29] <ogra> lxc-android-config already links /dev/socket
[13:29] <rsalveti> ogra: also, we might need to create a group for modem or such anyway (if we don't have it already)
[13:29] <ogra> but indeed doesnt change any permissions yet
[13:29] <ogra> we have dip and dialout iirc
[13:29] <rsalveti> I'm not worried about that at all, after all they are just sockets
[13:30] <ogra> well, if rild gets along with it
[13:30] <rsalveti> and we can hook up functions to check group and user id in hybris
[13:30] <wzssyqa1> doko: ubuntu and debian share the same eglibc and gcc, right?
[13:30] <ogra> tony got mew scared with his complaining over the last weeks :)
[13:30] <rsalveti> and do the matching there if really needed
[13:31] <rsalveti> ogra: well, I believe we should be fine, I'll be checking ril/ofono support with todays image later today
[13:31]  * ogra reboots into todays flipped image and prays the shell will come up automatically
[13:31] <rsalveti> with the flip container, just to be sure it works
[13:31] <ogra> sigh
[13:31] <ogra> seems it doesnt :(
[13:31] <mitya57> cjwatson: "internal compiler error: Segmentation fault" on powerpc? not a pleasure to debug...
[13:31] <rsalveti> ogra: I can easily test ofono without the shell :-)
[13:31] <ogra> hah, but having adbd use bash is so much cooler ... thanks stgraber
[13:32] <ogra> hmm, seems everything butt the shell came up
[13:35] <ogra> bah ... was just missing an rm
[13:35] <doko> yes
[13:35] <ogra> sigh
[13:41]  * mitya57 realized that he was looking at wrong log
[13:42] <teolemon> Hi, I was wondering in which channel I could contact somebody from the ubuntu.com infrastructure (to install a webapp on ubuntu.com)
[13:45] <cjwatson> mitya57: meh, I was thinking of the i386 failure
[13:45] <mitya57> cjwatson: "* mitya57 realized that he was looking at wrong log"
[13:46] <cjwatson> ah
[13:48] <wzssyqa1> doko: then, I tried to cross build eglibc with clang. I also tried to build it with the gcc-multlib from mipsel.  all of them failed
[13:54] <doko> wzssyqa1, sorry, can't help you with that. bootstrapping, not much time. you may want to look at the powerpc-cross-toolchain-base and gcc-4.8-powerpc-cross packages in ubuntu
[13:54] <wzssyqa1> doko: thanks
[14:07] <ev> bdmurray: https://oops.canonical.com/reports/WHOOPSIE-PROD/
[14:07] <ev> ^ that's the new home of the OOPS reports. /oops-local is dead.
[14:07] <ev> (though it's remains for hysterical raisins
[14:08] <mitya57> cjwatson: GDCMTargets.cmake hasn't changed since raring, so it looks like new CMake made missing files cause an error instead of warning
[14:09] <mitya57> cjwatson: does it build in sid with new CMake?
[14:09] <mitya57> Let me test myself
[14:09] <cjwatson> it builds in current sid
[14:09] <cjwatson> with whatever's default there
[14:10]  * xnox is somehow guessing that vtk needs rebuild against python2.7.5 and I'm not sure how gdcm managed to build correctly without a rebuilt vtk.
[14:10] <cjwatson> may be true but I'm not sure how it relates to this cmake weirdness?
[14:10] <xnox> (that rebuild needs to happen regardless, but it might not help insighttoolkit at all)
[14:17] <mitya57> cjwatson: yes, it is really a change in cmake: http://paste.ubuntu.com/5735889/
[14:18] <mitya57> so my suggestion will be to add that B-D
[14:19] <xnox> mitya57: but with that b-d installed, it still FTBFS.
[14:19] <mitya57> it adds: 'message(FATAL_ERROR "The imported target \"${target}\" references the file \"${file}\"'
[14:19] <Laney> what's that a diff of?
[14:20] <mitya57> Laney: a diff between usr/lib/gdcm-2.2/GDCMTargets.cmake in sid and saucy
[14:20] <mitya57> xnox: with the same error?
[14:20] <xnox> mitya57: hm? the diff between saucy-proposed and sid is none: http://paste.ubuntu.com/5735895/
[14:21] <xnox> damn, nothing in saucy-proposed.
[14:21] <xnox> i mean between: libgdcm2-dev_2.2.3-1_amd64.deb in sid, and        libgdcm2-dev_2.2.3-1ubuntu2_amd64.deb in ubuntu
[14:24] <Laney> actually it seems it is different
[14:24] <Laney> the first change in the diff is probably the clue
[14:25] <xnox> Laney: hmm. true.
[14:25]  * xnox thought debdiff did recursive diff as well, I guess not.
[14:25] <bdmurray> seb128: ah, thanks I'll have a look
[14:26] <Laney> doesn't diff the files inside, no
[14:26] <mitya57> xnox: do you have a build log of that in saucy with the b-d added?
[14:26] <bdmurray> ev: the oops report is great
[14:27] <xnox> Laney: gdcm should get binNMU in Debian then.
[14:27] <seb128> bdmurray, hey, thank you
[14:27] <bdmurray> ev: oh, but the links don't work?
[14:30] <ev> bdmurray: the ones up top don't yet, but the ones on the far right do
[14:31] <ev> and then there are the urls in the middle for the request itself which will never work (though maybe we can fix that, even though it doesnt make sense clicking them for daisy.ubuntu.com)
[14:31] <ev> it would for errors.u.c though
[14:37] <mitya57> there's something wrong with freenode today...
[14:38] <Laney> mitya57: CMake Error at /usr/lib/gdcm-2.2/GDCMTargets.cmake:155 (message):
[14:38] <Laney>   The imported target "php_vtkgdcm" references the file
[14:38] <Laney>      "/usr/lib/vtkgdcm.so"
[14:38] <Laney>   but this file does not exist.  Possible reasons include:
[14:39] <cjwatson> right, but the same thing is a warning in an unstable build
[14:39] <Laney> yes, we established that gdcm's rebuild in Ubuntu caused it to regenerate its .cmake file which upgraded such things to errors
[14:40] <pitti> cjwatson: with just the two removals and two rebuilds in -proposed for reverting PackageKit, do you think we need any particular magic there? (the rebuilds will just be -0ubuntu2)
[14:40]  * pitti bbl
[14:41] <mitya57> ... because we have only /usr/lib/libvtkgdcm.so.2.2
[14:41] <Laney> libvtkgdcm.so -> that, yes
[14:41] <cjwatson> pitti: I think that's OK - just make sure the removal has been published before uploading the reverts
[14:41] <mitya57> Laney: should we add that symlink?
[14:41] <cjwatson> pitti: and you might want to sync-blacklist or something so it stops showing up on merges.u.c
[14:41] <Laney> I don't know
[14:41] <Laney> why is it looking for the wrong file?
[14:42] <bdmurray> pitti, ev: re bug 1187723 it works for releases other than 13.10
[14:42] <ev> hmm
[14:42] <bdmurray> https://errors.ubuntu.com/?user=pitti&period=month
[14:42] <cjwatson> Laney: I think it's a cmake file that has basically a bunch of optional imports
[14:43] <cjwatson> use these if they're here
[14:43] <Laney> see mitya57's earlier pastebin
[14:43] <Laney> it's the diff of the relevant .cmake file between sid and saucy showing that some things were upgraded to errors
[14:44] <Laney> at least that's how my cmake-stupid brain reads it
[14:44] <slangasek> seb128: update-manager gsettings> ack
[14:44] <slangasek> bdmurray: will you take care of fixing update-manager too, then?
[14:44] <slangasek> pitti: binutils> sweet :)
[14:45] <bdmurray> slangasek: yes
[14:51] <mitya57> Laney: err, libvtkgdcm2-dev does ship that symlink (proof: http://packages.ubuntu.com/raring/i386/libvtkgdcm2-dev/filelist), how can it happen that that file is missing?
[14:52] <Laney> note the 'lib'
[14:52] <mitya57> oh
[14:55] <cjwatson> and libgdcm2-dev doesn't depend on libvtkgdcm2-dev, but vice versa
[14:56] <Laney> php5-vtkgdcm installs -rw-r--r-- root/root<PHONE_NUMBER>-06-03 09:27 ./usr/lib/php5/20100525+lfs/vtkgdcm.so
[14:56] <Laney> xnox is trying his best to get this stuff removed from testing ;-)
[14:56] <mitya57> :)
[14:57]  * mitya57 's cmake knowledge ends here
[15:00]  * Laney glares at freenode
[15:00] <xnox> slangasek: what's your value of /proc/sys/vm/dirty_ratio ?
[15:03] <mitya57> I think it's a bad idea to have /usr/lib/vtkgdcm.so -> /usr/lib/php5/20100525+lfs/vtkgdcm.so symlink, as it's a php-specific library and shouldn't be exposed to the system
[15:04] <mitya57> so we need to add more search paths to cmake instead
[15:05] <slangasek> xnox: so based on that side conversation... I guess you don't have /tmp on tmpfs?
[15:07] <xnox> slangasek: no, since I was affected by "it takes to long to clear /tmp" bug which you weren't affected by.
[15:07] <Laney> mitya57: gdcm's rules file manually moves it out of /usr/lib/ to that location
[15:08] <mitya57> ... so we can't blame upstream
[15:08] <Laney> At this point you probably need some cmake to get php5-vtkgdcm to leave the right trail behind for its consumers
[15:09] <Laney> Might just be sensible to take these findings to debian-med and let them deal with it...
[15:10] <mitya57> Let's file a bug then?
[15:10] <slangasek> xnox: ah right :)
[15:10] <Laney> please do
[15:10] <Laney> maybe confirm it breaks rdeps after a rebuild though
[15:19] <doko> infinity, https://launchpadlibrarian.net/141721049/buildlog_ubuntu-quantal-amd64.gcc-4.8_4.8.1-2ubuntu1~12.10_FAILEDTOBUILD.txt.gz
[15:19] <doko> In file included from /usr/include/fenv.h:58:0,
[15:19] <doko>                  from ../../../../src/libquadmath/math/ccoshq.c:23:
[15:19] <doko> ../../../../src/libquadmath/math/ccoshq.c: In function 'ccoshq':
[15:19] <doko> /usr/include/bits/fenv.h:116:4: error: impossible constraint in 'asm'
[15:19] <doko>     __asm__ __volatile__ ("divss %0, %0 " : : "x" (__f));
[15:19] <doko>     ^
[15:19] <doko> /usr/include/bits/fenv.h:116:4: error: impossible constraint in 'asm'
[15:19] <doko>     __asm__ __volatile__ ("divss %0, %0 " : : "x" (__f));
[15:19] <doko>     ^
[15:19] <doko> didn't we fix that in eglibc? or is it not yet there?
[15:23] <infinity> doko: SRU not uploaded for that yet, I should do that this week.  Was waiting to queue up a few things in one go.
[15:42] <bdmurray> barry: were you still going to have a look at bug 1094218?
[16:00] <slangasek> barry: yeah, meeting ended ;)
[16:28] <kenvandine> @pilot in
[17:20] <smoser> slangasek, around ?
[17:20] <smoser> i'm guessing that jodh is not
[17:20] <smoser> so you're the next best thing :)
[17:21] <slangasek> smoser: ohai
[17:21] <smoser> we're seeing an issue on raring upstart
[17:22] <smoser> cloud-config is not running
[17:22] <smoser> but it is : start on (filesystem and started rsyslog)
[17:22] <smoser> and rsyslog *is* started (rsyslog start/spawned, process 1656)
[17:23] <smoser> and it's start on is: start on filesystem
[17:23] <smoser> so it would appear to me that cloud-config should have started.
[17:31] <smoser> slangasek, ^
[17:32] <slangasek> smoser: ok; so is mountall still running?
[17:32] <smoser> stop/waiting
[17:32] <slangasek> smoser: and is there any chance this is still another problem with upstart getting re-execed or config-reloaded and dropping in-flight events?  The fix for that is just about to land in raring SRU, but it's not there yet
[17:34] <smoser> slangasek, i dont think so. as cloud-config would be the thing that would do an upgrade.
[17:34] <slangasek> hmm
[17:34] <smoser> and i dont see anything that cloud-inti woudl have done to initcitl reload
[17:34] <smoser> i can let you in
[17:34] <slangasek> ok
[17:46] <sil2100> jamesh: ping!
[17:50] <seb128> sil2100, it's like 2am for him, probably not the best time to have a pong
[17:50] <sil2100> seb128: ACK, thanks
[17:51] <smoser> slangasek, jamespage opened as bug 1187876
[17:53] <slangasek> smoser: and this failure is frequently reproducible on the affected machine?
[17:53] <smoser> http://lists.adiscon.net/pipermail/rsyslog/2012-January/029268.html maybe relevant.
[17:53] <smoser> jamespage, ^
[17:53] <smoser> how frequent is this ?
[17:57] <smoser> bah. that is reported fixed in 5.8.7 and we're 5.8.11 there.
[17:59] <smoser> slangasek, i say give it a try (reboot) and see.
[18:02] <jamespage> smoser, slangasek: 11/12 of the last first boots on the effected hardware
[18:02] <sil2100> barry: ping!
[18:07] <slangasek> smoser: rebooted, it seems to be taking its sweet time coming back up
[18:09] <slangasek> smoser, jamespage: ok, reproduced on reboot
[18:10] <smoser> slangasek, those systems take like 2 minutes to post
[18:10] <slangasek> cute
[18:12] <ion> Awesome, someone has made libappindicator bindings for Haskell.
[18:14] <infinity> ion: I'm not sure you're using that word correctly.
[18:14] <slangasek> because what indicators needed was greater uncertainty about how long things will take to display correctly
[18:15] <ion> infinity: “has”? “bindings”? “someone”?
[18:15] <infinity> ion: "awesome". :P
[18:16] <ion> infinity: Ok, let me rephrase it: “Excellent!”
[18:50] <slangasek> smoser: regression in the SRU from bug #1022545, which has an off-by-one error in its string handling.
[18:50] <slangasek> smoser: not sure yet this is the cause of the malloc failure, but it looks probable as this is the only complaint out of valgrind
[18:52] <cjwatson> ion: I think it would be a bad idea to upload Ubuntu-specific Haskell bindings, given how much we rely on Debian to keep that subsystem at all workable.
[18:52] <cjwatson> Although I see libappindicator is in Debian - but an old version I think
[18:53] <ion> I’m actually not using the system packages at all for Haskell development, i also cabal installed happindicator under ~. Seems to work fine.
[18:54] <slangasek> smoser: right, confirmed here that unapplying that patch fixes it.  So, critical SRU regression. :P  Thanks for raising this.
[18:59] <infinity> slangasek: Added precise and raring tasks to https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1187808 due to your above conversation.
[19:00] <slangasek> infinity: ack.
[19:00] <Laney> ion: Since you only got negative comments - COOL! :-)
[19:01] <ion> heh
[19:01] <infinity> slangasek: Want to prep the 1-char fixes, or review them if I do it (I'd rather not be on the hook for verification, since I haven't bothered to reproduce).
[19:01] <slangasek> caribou: please see above wrt the recent rsyslog SRU.  Do you happen to have the upstream git to hand, and is there a follow-up fix that we should take?
[19:02] <infinity> slangasek: http://git.adiscon.com/?p=rsyslog.git;a=commitdiff_plain;h=9c54bf41d02ba236137859ea5f12d6f048647349
[19:02] <infinity> slangasek: Referenced in the bug.
[19:02] <slangasek> ok
[19:02] <slangasek> infinity: I'll take care of the uploads
[19:03] <infinity> slangasek: Alright.  If you do 'em quick, I'll review before I head out for the afternoon.
[19:04] <infinity> slangasek: And this seems like a valid case for expediting the accept/verify/release turnaroud, if you can find someone to verify.
[19:05] <slangasek> I can verify it directly
[19:12] <dobey_> is there no easy way to fix broken package import branches?
[19:12] <slangasek> no.
[19:12] <slangasek> barry: ^^ do you know who, if anyone, is still minding the store on those?
[19:31] <cjwatson> slangasek: wgrant and xnox are the people I go to for those
[19:31] <slangasek> ok
[19:31] <slangasek> dobey: ^^ maybe that helps?
[19:32] <cjwatson> It has to some extent been borged into LP maintenance
[19:33] <dobey> hmm, ok
[19:34] <barry> slangasek: you can perhaps beg someone on #udd but otherwise, you will have a sad
[19:34] <barry> (maybe the udd mailing list too)
[19:34] <barry> but in general, nobody is
[19:35] <cjwatson> barry: I think it's better than that.  William in particular has been fixing a fair few problems AIUI.
[19:35] <barry> cjwatson: that is *great* news!  wgrant ftw
[19:35] <seb128> bdmurray, what's the need of dropping that key from the update-notifier schemas rather than marking it deprecated? did you grep the archive in case anything else is relying on it?
[19:36] <seb128> bdmurray, it's just 5 lines of text in a .xml, I though it would have been easier to keep it flagged as deprecated than dropping it, especially when missing key is abort() reason for gsettings
[19:36] <seb128> it's sort of an "abi" break for no real benefit
[19:37] <slangasek> infinity: rsyslog uploaded for saucyraringprecise
[19:37] <infinity> slangasek: Yeahp, queuebot told me.
[19:37] <slangasek> k
[19:38] <ogra> saucyraringprecise ? is that the new name for the rolling dev release ?
[19:38] <slangasek> seb128: well, nothing should be using that setting; the fact that things fail in its absence may have come as a surprise to us, but it's better to root out any references to that key and fix them all at once
[19:38] <ogra> :)
[19:38] <seb128> slangasek, ok, so you are archive greping for other users of the key if there is any?
[19:38] <infinity> I prefer presaucing.
[19:39] <dobey> infinity: one must sauce precisely.
[19:40] <infinity> Trying so hard to not say "that's what she said" right now.
[19:42] <slangasek> seb128: the likelihood of anything other than u-m and u-n using this key is so small that I'm not sure it's worth the time of doing that, vs. just letting any bugs be found and reported
[19:42] <seb128> slangasek, ok, wfm
[19:42]  * seb128 checks software-center and aptdaemon in case
[19:43] <seb128> slangasek, btw I tagged/pushed your upload to the vcs of update-notifier to be able to add my fix on top, hope it's ok ;-)
[19:43] <bdmurray> I'll check the archive just in case
[19:43] <glatzor> seb128, aptdaemon doesn't use it
[19:44] <seb128> glatzor, saw that, thanks
[19:44] <glatzor> seb128, but I don't know about s-c
[19:44] <seb128> neither does s-c
[19:44] <glatzor> ok
[19:44] <slangasek> seb128: which upload?  I think bdmurray did the last u-n upload
[19:44] <seb128> slangasek, the one from yesterday that dropped the key
[19:44]  * barry returns to the porch for some quality time with gpg
[19:45] <bdmurray> seb128: what branch are you using?
[19:45] <seb128> slangasek, oh, sorry, bdmurray uploaded it seems, I saw your name at the top of the changelog...
[19:45] <seb128> bdmurray, ~ubuntu-core-dev/update-notifier/ubuntu/
[19:45] <slangasek> ok, seriously, who broke 'bzr info'?
[19:45] <seb128> bdmurray, the one listed in debian/control
[19:45] <bdmurray> seb128: we've been using
[19:46] <bdmurray> er nevermind
[19:46] <seb128> bdmurray, well, this morning it was UNRELEASED, maybe you forgot to push the commit where you flagged it as a release?
[19:46] <seb128> everything else was current
[19:46] <bdmurray> seb128: yeah, I fixed that and merged your 0.137 changes
[19:46] <seb128> hum
[19:46] <seb128> I had pushed my changes to the vcs
[19:47] <seb128> did you overwrite?
[19:47] <seb128> bzr: ERROR: These branches have diverged. Use the missing command to see how.
[19:47] <seb128> Use the merge command to reconcile them.
[19:47] <seb128> shrug
[19:47] <bdmurray> hmm, I did an updated before pushing...
[19:47] <seb128> or maybe I forgot to push as well :p
[19:47] <seb128> anyway no worry
[19:47] <doko> seb128, on raring:
[19:47] <doko> Setting up libgtk2.0-0:armhf (2.24.17-0ubuntu2) ...
[19:47] <doko> /usr/lib/arm-linux-gnueabihf/libgtk2.0-0/gtk-query-immodules-2.0: 1: /usr/lib/arm-linux-gnueabihf/libgtk2.0-0/gtk-query-immodules-2.0: Syntax error: word unexpected (expecting ")")
[19:47] <seb128> seems to be alright now
[19:47] <seb128> bdmurray, thanks
[19:47] <doko> is this expected?
[19:48] <doko> armhf is the foreign arch
[19:48] <seb128> doko, no, and not seen before ... is that consistent or a one time error? the arm builders tends to have corrupted datas sometimes it seems
[19:49] <doko> no, that's a local install
[19:49] <slangasek> doko: that's the postinst trying to exec the foreign-arch indexer
[19:49] <slangasek> there's a || true after it in the postinst, but it'll still spit out errors
[19:49] <slangasek> I've never seen that particular error before fwiw
[19:49] <doko> ahh, yes I see
[19:49] <slangasek> but if you don't have armhf qemu support in place, errors of /some/ kind are expected
[19:51] <infinity> slangasek: Alright, acceptiferated, and I'm heading off for a bit.  Give me a nick highlight nudge when you're satisfied it's all verified.
[20:32] <smoser> cjwatson, are you around ?
[21:00] <cjwatson> smoser: not really, e-mail?
[21:00] <cjwatson> Unless it's really quick
[21:00] <smoser> sure.
[22:05] <xnox> dobey: i'm not an expert, but which package are you after? I can take a look.


[00:16] <belkinsa> skellat: thank you for connecting me to knome, we (and others) are making good head way to changing the wiki.
[00:29] <andygraybeal> i apologies.. i'm slow as anything around here... i'm still using sudo /etc/init.d/networking restart.... what is the proper way to do this?   i try: sudo service networking stop && sudo service networking start .... and it tells me unknown instance... grrrrrr.
[00:29] <andygraybeal> i'm in ubuntu 12.04
[00:31] <andygraybeal> sometimes i wonder to myself if i just should have stuck with bsd :)
[00:31] <Unit193> andygraybeal: Is this before or after you first use  /etc/init.d/networking action  ?
[00:32] <andygraybeal> hmm it's been after..
[00:32] <Unit193> So, my guess is that by using the first, well, first, upstart lost track of it. :P
[00:33] <andygraybeal> aah okay so i did a start and it didn't give me shizz
[00:33] <Unit193> Because it's already running, no?
[00:34] <andygraybeal> yes it is.. or something i'm confused.
[00:34] <andygraybeal> hold on, lemme just reboot the thing and try agian
[00:36] <andygraybeal> okay, i rebooted.. and run the command ....
[00:36] <andygraybeal> andy@redbud:~$ sudo service networking stop && sudo service networking start
[00:36] <andygraybeal> [sudo] password for andy:
[00:36] <andygraybeal> stop: Unknown instance:
[00:36] <andygraybeal> andy@redbud:~$
[00:37] <Unit193> Well then, I can tell you it works in Saucy, so when you upgrade to trusty it should work as well.  May as well use the old script, then. :P
[00:37] <Unit193> (Also, learn restart?)
[00:38] <andygraybeal> i figured restart was broken
[00:38] <andygraybeal> so that is why manual stop/start
[00:38] <andygraybeal> i'm used to sudo /etc/init.d/networking restart :)
[00:38] <Unit193> ALrighty.
[00:38] <Unit193> s/L/l/
[00:38] <jenni> Unit193 meant to say: Alrighty.
[00:38] <andygraybeal> you know  what i'm saying right?
[00:38] <Unit193> Yes.
[00:39] <andygraybeal> i'd like to stick with 12.04
[00:39] <andygraybeal> if i can
[00:39] <andygraybeal> i'm a fuddy duddy
[00:39] <belkinsa> Even up to the release of the next LTS?
[00:39] <Unit193> /etc/init.d/bleh commands can be more helpful, but generally more helpful in Debian.  Said trusty because it's the next LTS, figured you might update when it's out.
[00:39] <andygraybeal> aah yes, trusty ;)  id din't know that was next lts.
[00:40] <andygraybeal> belkinsa, no no, i'll move to next lts.
[00:40] <belkinsa> Okay.
[00:40] <andygraybeal> i didn't know what trusty was :)
[00:40] <Unit193> Ubuntu 14.04 "Trusty Thar"  (Or, codenamed twerking tiger.)
[00:40] <andygraybeal> hahahahahah twerky tiger....
[00:40] <andygraybeal> now i have to look up whta a that is...
[00:41] <andygraybeal> err.. thar is..
[00:42] <Unit193> Ahahaha! :D
[00:46] <andygraybeal> wow, found my prob on askubuntu.com : http://askubuntu.com/questions/345566/networking-stop-waiting-error
[00:46] <jenni> [ 12.04 - Networking stop/waiting error - Ask Ubuntu ] - https://j.mp/1knW0kl
[00:47] <andygraybeal> t's not exaclty the same cause i'm not using bridging and they talk about bridging..
[00:47] <andygraybeal> and they are using dhcp.. and i'm static... but anyways.. i'll keep searching
[00:49] <andygraybeal> ah maybe  i need to mention each interface per command
[00:49] <andygraybeal> err network-interface ...
[00:49] <andygraybeal> nevermind i'll stop posting my stupid thoughts here.
[00:50] <Unit193> I generally post mine in another channel.
[00:51] <andygraybeal> :)
[00:51] <andygraybeal> where where???
[00:51] <Unit193> #xubuntu-offtopic tends to get a few. :P
[00:52] <andygraybeal> nice
[00:52] <andygraybeal> you like xfce ?
[00:52] <andygraybeal> i like the mousey mascot :)
[00:53] <Unit193> Yes, I do like Xfce quite well.
[00:54] <andygraybeal> it is very pretty
[00:54] <Unit193> If you don't use the default Xfce theme, yes.  Default Xubuntu is quite nice though.
[00:54] <Unit193> Not what I use, of course, but still nice.
[00:55] <Unit193> Oh hey, you aren't on TWC, is http://rbx.proof.ovh.net/files/100Mio.dat slow for you as well?
[00:56] <andygraybeal> estimated 4 minutes... i'm 3mbit down dsl from .. in a very rural area
[00:56] <andygraybeal> my service provider is windstream
[00:56] <Unit193> Yeah, I saw.
[00:57] <Unit193> Hrm, looks like sbg is the slower one (right now, normally much faster.  Nights tend to kill it.)
[00:57] <andygraybeal> says it's moving at 200K/s avg
[00:57] <andygraybeal> which is good fo rme... it's spiking up to 300K/s
[00:58] <andygraybeal> which seems normal
[00:58] <andygraybeal> sbg?
[00:58] <Unit193> Heh, not for me, that's not far off where it is for me, which isn't great.
[00:58] <Unit193> http://sbg.proof.ovh.net/files/100Mio.dat
[00:58] <andygraybeal> ah
[00:58] <andygraybeal> ah it's up into 400K/s
[00:59] <andygraybeal> holding sgtrong in 300K/s
[00:59] <Unit193> Average was 355 KB/s - in 4m 49s
[00:59] <andygraybeal> yea, remeber i'm rural.. and windstream :)
[00:59] <andygraybeal> and adsl :)
[01:00] <andygraybeal> i'm happy with 200/300K/s :)
[01:00] <andygraybeal> are you doing wget ?
[01:00] <Unit193> Compare to their Canadaian DC: ~1.87 MB/s in 53s  My upspeed is crappy though, 120KB/s.  Yes, of course.
[01:02] <andygraybeal> my up is 756k :)
[01:02] <andygraybeal> so it's a crawlin'
[01:02] <andygraybeal> but this is the best we can do down here next to cellyphone or old school dialup.
[01:03] <Unit193> Doesn't matter much if you don't upload much.  Are you capped too?  My cousins in the middle of _nohere_ have wireless, not stable but it's uncapped.
[01:03] <andygraybeal> 5m 22s 318K/s avg
[01:03] <andygraybeal> i don't think we are capped
[01:03] <andygraybeal> wirelesS??  what?  like celly?
[01:04] <Unit193> No, I think they have wireless tower internet, not 100% sure.
[01:04] <Unit193> (Not 3/4G)
[01:04] <andygraybeal> that is weird to me!
[01:05] <andygraybeal> that is neat it exists though
[01:05] <andygraybeal> what part of the world?
[01:05] <Unit193> Indiana. :D
[01:05] <andygraybeal> ah different country
[01:06] <Unit193> I can walk from there to the next county, and have done it.
[01:06] <andygraybeal> i'm on the far side other side of the state in the south, next to parkersburg
[01:08] <Unit193> Hah, their ASN is "Indiana Fiber Network", so it's some unnamed reseller even. :D
[01:12] <Unit193> I tend to notice the slowdown in connection to OVH France because that's, knowing my luck, when I want to download a ~700MB file. >_<
[01:12] <andygraybeal> why you using france network?
[01:13] <andygraybeal> what is this ovh?
[01:14] <Unit193> Servers, downloading http://unit193.net/openbox/ last time.
[01:14] <jenni> [ Openbox desktop! ] - https://j.mp/1knYZt2
[01:14] <Unit193> (Though of course there's other things I'd pull too.)
[01:15] <andygraybeal> ah.. is this your own desktop ?
[01:15] <andygraybeal> this is neat!
[01:17] <Unit193> It's not the best of course, but I have this in my PXE setup.  14.04 based one should be better since I got some fixes upstreamed.
[01:18] <andygraybeal> pxe, boot over network?  i've done that locally, are you doing it remotely?
[01:19] <Unit193> Nope, it's locally.  I've got the squashfs so it doesn't go over tftp too, causing slowdowns.
[01:20] <andygraybeal> hmmmmmmmm
[01:20] <andygraybeal> i never did the squashfs thing i believe.. i did use tftp
[01:21] <andygraybeal> i cannot think of such things :)  ... is it locally butting off a partition.. via PXE ... i apologize for my idiocy
[01:22] <Unit193> http://paste.openstack.org/show/UlOENlCo3dB48IcdcX7p That's about the structure.
[01:22] <jenni> [ Paste #UlOENlCo3dB48IcdcX7p | LodgeIt! ] - https://j.mp/1knZZgA
[01:23] <Unit193> (I'm too lazy to set up nfs, I'm using cifs. :P )
[01:23] <andygraybeal> this is a menu...
[01:23] <andygraybeal> a boot menu yes?
[01:23] <Unit193> Yes.
[01:24] <andygraybeal> i see
[01:24] <andygraybeal> how do you boot pxe off of squashfs?
[01:26] <andygraybeal> don't worry about explaining.. i do not have the mind for this right now ;)
[01:26] <andygraybeal> i was happy to figure out tftp / pxe booting years ago.
[01:27] <Unit193> http://unit193.net/pxe.png - http://unit193.net/pxe2.png  Squashfs is a filesystem, compressed one at that, it's what's used in the live system.  I just transfer it over cifs since casper supports that.
[01:28] <andygraybeal> hmmmm okay
[01:30] <Unit193> Am I crazy?  Yes.  Do I need PXE?  Not really. :P
[01:32] <andygraybeal> okay
[01:32] <andygraybeal> i get confused easily
[01:33] <andygraybeal> i watch that linux action show :)  do you like it?
[01:33] <andygraybeal> i mean, not religiously, but when i have some time.. they make me laugh
[01:33] <andygraybeal> it also makes me drool over system76 :)
[01:35] <andygraybeal> but i get a strange edgy feeling from both of them also.. i'm not sure why...
[01:35] <andygraybeal> other than irc, i don't interact with people talking about computers.. so LAS is all i have :)
[01:36] <Unit193> Not seen it.
[01:36] <andygraybeal> well.. talking to people about computers around here is like.. just nodding my head about how windows8 sucks and how the guys who at staples who work on everyones computers are awesome.... i kind of just say yea.. that's cool man.
[01:37] <andygraybeal> i mention anything with the word ... linux and they are like.. what?  is that a database thing?
[01:37] <andygraybeal> and i'm like.. yea a database thing.
[01:42] <Unit193> Hrm, don't think there's really many here either, but it's bigger and of course I don't know everyone.  One person in this channel isn't _too_ far away.  I know/kind of talk to a Mac fan, and there's a Windows geek I know too, but he likes Winders8. :P
[01:43] <andygraybeal> ya, i'm sure windows8 is fine if that is what your into.. just more fud as far as i'm concerned..  i'm just happy to stick with the NT line of machines as far as i care.
[01:43] <andygraybeal> NT heritage line...
[01:44] <Unit193> Win 2K, XP, and 7 is usable I suppose.
[01:44] <andygraybeal> but i don't think there is the 9x/dos heritage existing anymore, so as far as i care it's all good.
[01:44] <Unit193> I have a exported win 3.1 vm. :D
[01:44] <andygraybeal> i don't want to touch any of this shit with even if it was to help a poor soul.
[01:44] <andygraybeal> you are sadistic.
[01:44] <Unit193> I don't use it...
[01:45] <andygraybeal> sorry for cussing.. i forget about rules.
[01:45] <Unit193> I got networking working in it. :P
[01:45] <andygraybeal> i had a group of users who would not switch from 98 to NT to save their lives because Filemaker Pro wasn't NT compatible.. and i wanted to die a slow death every day i worked there.
[01:46] <andygraybeal> this was years and years ago.... 80 users... i hated myself
[01:46] <andygraybeal> i was the poor tech.. they wouldn't let me make overarching decisions.. i was just collision control.
[01:46] <Unit193> Well, that's fun.
[01:47] <andygraybeal> yea.. i swore never to put myself into a position like that ever again.
[01:47] <andygraybeal> even if it means i go poor.
[01:47] <andygraybeal> and lose my house.. etc.
[01:48] <Unit193> http://unit193.net/dump/ wait, it's actually in there!    Cygwin is quite nice, then drop a ssh server in there for ease of use. :D
[01:53] <andygraybeal> exactly.. BOOOM
[01:53] <andygraybeal> now i can actually use this goddamn box
[01:53] <Unit193> (Keyfiles only, if you would. :P )
[01:53] <andygraybeal> omg.. and instant putty install...
[01:54] <andygraybeal> oh yes, keyfiles are godsend
[01:54] <Unit193> PuTTY is nice and all, but xfce4-terminal just feels better.  :P
[02:01] <jenni> [ Debian Package Tracking System -	gsimplecal ] - https://j.mp/18seEVS
[02:01] <Unit193> Also watched another vid on something, and it's annoying because they don't stop talking...
[02:04] <Unit193> http://www.youtube.com/watch?v=gRsNdIYeyPk OH GOSH MAKE IT STAP!
[02:04] <jenni> [ Dora and Barney twerk team dance - YouTube ] - https://j.mp/18sf0M9
[02:06] <andygraybeal> you are evil.
[02:06] <Unit193> So I've been told.
[02:07] <andygraybeal> do you use tmux?
[02:07] <Unit193> screen
[02:08] <andygraybeal> i'm used more used to screen.. i'm trying out tmux
[02:08] <Unit193> I like it, using 2.1 now.  Tried tmux for a while, some querks didn't take well to me. :P
[02:11] <andygraybeal> hmm... 2.1 is new version of screen... or is it still ancient?
[02:11] <andygraybeal> i thought they abandoned screen
[02:11] <andygraybeal> i will google
[02:12] <andygraybeal> it still looks ancient
[02:13] <Unit193> It's in git http://ftp-master.metadata.debian.org/changelogs/main/s/screen/unstable_changelog
[02:13] <jenni> https://j.mp/18sfUbJ
[02:13] <Unit193> http://packages.qa.debian.org/s/screen.html - Trusty will have it too, finally.
[02:13] <jenni> [ Debian Package Tracking System -	screen ] - https://j.mp/18sfX7h
[02:15] <andygraybeal> you use ldap for auth anywhere?
[02:15] <Unit193> Nope.
[02:15] <andygraybeal> k
[02:26] <Unit193> FWIW, I've used screen from Debian in Ubuntu now for a while with no issues.
[02:33] <andygraybeal> k
[02:33] <Unit193> o
[04:30] <andygraybeal> can someone hold my hand .... i'm trying to understand how to configure ssl.  i purchased a domain from gandi, and i get a free ssl certificate... totally legit.  now.. when i go to download this stuff from their site i get a .crt file and a .pem file.  Apache appears to want a SSLCertificate file and a SSLCertificateKeyfile  ... please help explain this to me.  I assume the .crt file is the SSLCertificate file... how
[04:30] <andygraybeal> does the .pem fit?  and how do i get a .key file?
[04:32] <Unit193> pem is cert and key.
[04:33] <andygraybeal> okay.
[04:35] <andygraybeal> so i assume that the .pem file which appears to be generic it is titled: GandiStandardSSLCA.pem is the SSLCertificateKeyFile ?
[04:36] <andygraybeal> and the .crt file which i think is generated just for me is the .SSLCertificateFIle ?
[04:39] <andygraybeal> i guess i'm still in the dark.. i apologize.
[04:39] <Unit193> The one is the "parent" cert, the crt file should be your private one.
[04:39] <andygraybeal> okay, cool.  how do i get apache to be happy with these guys?
[04:40] <Unit193> I don't use apache.
[04:41] <andygraybeal> cools.  thanks for your help.  i'll keep futzing with it.
[04:41] <andygraybeal> it will eventually succumb.
[04:41] <andygraybeal> ive done this with self signed stuff
[04:47] <andygraybeal> so when people talk about a .key file... are they talking about the .pem file?
[04:49] <Ukiks> Key file should be the private key, pem is both private and public,  IIRC.
[04:49] <andygraybeal> ok.... so do i create a key file from the .crt file?
[04:49] <andygraybeal> i got two files from gandi, .crt and .pem.
[04:51] <Unit193> http://www.flatmtn.com/article/setting-ssl-certificates-apache ?
[04:51] <jenni> [ Setting up SSL Certificates on Apache | Flat Mountain ] - https://j.mp/1hFEgDZ
[04:51] <andygraybeal> thanks, i'lll read
[04:51] <Unit193> http://wiki.gandi.net/en/hosting/using-linux/tutorials/ubuntu/ssl better, is my guess since it's exact, one would hope.
[04:51] <jenni> [ Configuring Apache to use your Gandi SSL Certificate - Welcome to Gandi's Online Documentation Wiki - Gandi Docs ] - https://j.mp/1hFEivs
[04:52] <andygraybeal> ah rad thanks
[04:55] <andygraybeal> aah the gandi .pem file is a chainfile
[04:55] <andygraybeal> rad :)
[05:00] <andygraybeal> intermedieate chain file :)
[05:08] <andygraybeal> okay i think i have to regnerate the certs because i lost the .key file
[05:08] <andygraybeal> or something like that.
[05:12] <andygraybeal> okay i got it, cert request, cert, key, and chain file.. rock on.
[05:12] <andygraybeal> good to learn new things.
[05:13] <Unit193> :D
[05:14] <andygraybeal> and it looks like the certificate request has nothing to do with apache config.
[05:14] <andygraybeal> just the cert, key and pem.
[05:19] <andygraybeal> rockin, it fired up now.
[05:27] <andygraybeal> this is a pretty awesome ssl checker: http://www.digicert.com/help/
[05:27] <jenni> [ SSL Certificate Checker - Installation Diagnostic Tool | DigiCert.com ] - https://j.mp/1hFGqDA
[05:34] <Unit193> https://www.ssllabs.com/ssltest/
[05:34] <jenni> [ Qualys SSL Labs - Projects / SSL Server Test ] - https://j.mp/1hFGNOq
[05:41] <andygraybeal> neat, i'll try that one too
[05:46] <andygraybeal> hmm mine doesn't support Forward Secrecy with any of the microsoft browsers in the simulatoin.
[05:51] <andygraybeal> it's a rabbit hole for sure.
[06:32] <Unit193> It's MS, no problem. :P
[06:33] <Unit193> Though hear the rendering of 11 is better, even if they went retard with UA.
[06:39] <andygraybeal> :)
[06:39] <andygraybeal> UA ... never heard of it yet. should i bother to google it?
[06:48] <Unit193> user agent.
[06:48] <andygraybeal> ah ok
[17:40] <cid420> http://upload.wikimedia.org/wikipedia/commons/1/1b/Linux_Distribution_Timeline.svg
[17:40] <jenni> https://j.mp/RCLaPc
[17:40] <belkinsa> Fail.
[17:42] <cid420> what is
[17:43] <belkinsa> Jenni not showing what it is
[17:44] <jenni> belkinsa: Do you know what Eigen Vectors are?
[17:44] <belkinsa> Then again, it was just a image not a page
[17:55] <cid420> yea
[17:55] <cid420> got the link off a newsgroup
[17:56] <cid420> http://linuxcounter.net/distributions/stats.html
[17:56] <jenni> [ LiCo - The New LinuxCounter Project - Get counted as a linux user ] - https://j.mp/1bqcaaG
[18:29] <Unit193> DVL is dead?  And Backtrack rebased to Debian with Kali.
[18:30] <Unit193> #! is Debian now too.
[18:33] <Unit193> Heh, so I don't quite agree with that graphic.  Seen it before and it is nice though.
[19:21] <jrgifford> #! has been debian for a long time though... isn't it?
[19:23] <Unit193> Yep.
[21:38] <belkinsa> skellat: what is your feed url to your blog
[23:18] <skellat>  belkinsa: Just got back from visiting kin in Cleveland.  What do you need the feed URL for?  It should be listed on planet.ubuntu.com for use...
[23:18] <belkinsa> Okay, i will check
[23:33] <belkinsa> My feed reader is giving me a format error


[15:16] <philballew> kdub, If someone hands you a shirt at uds and you bring in to sd and I snag it from you sometime in the future?
[15:17] <philballew> near future = whenever I run into you again or you get tired of it.
[15:17] <philballew> unless I already asked you that.
[15:21] <philballew> I dont get enough sleep to remember these things.
[15:28] <philballew> Gareth, think you could get back to me by the end of the week if possible?
[15:30] <kdub> philballew, i'm sure i can root out an extra shirt.... Medium?
[15:30] <philballew> yes, medium!
[15:30] <philballew> thanks kdub
[16:22] <Gareth> philballew: yup.  will respond today.
[16:22] <philballew> alright. No worries.
[16:31] <Gareth> have a lot of emails to send out today, but i shall respond to you first.
[16:37] <philballew> sound/me feels special
[16:37]  * philballew feels special
[16:37]  * philballew feels like he is really bad at talking on several channels at the same time
[19:54] <Gareth> bkerensa: ping
[19:57] <bkerensa> Gareth: hello
[20:04] <Gareth> bkerensa: hey.  Just touching base.  Did you hear anything from Mozilla re: SCALE?
[20:43] <bkerensa> Gareth: I put the info up on our mailing list and someone said they would check to see who our closest rep is and decide on sending them.... I will follow up
[20:44] <bkerensa> Gareth: What is the deadline so I can let them know
[22:04] <Gareth> bkerensa: no deadline at the moment.  booths are on a first come, first given basis.  When they're gone, they're done.
[22:04] <Gareth> s/done/gone/


[04:26] <manchicken> shadeslayer: The new iPhone is 64-bit, no?
[06:40] <Riddell> https://launchpad.net/~kubuntu-active/+archive/ppa/+build/5035122  awooga, pykde compiled!
[08:02] <lordievader> Good morning.
[12:21] <BluesKaj_> 'Morning folks
[13:18] <smartboyhw> LP down
[13:18] <smartboyhw> (London DC issues)
[13:23] <ari-tczew> seems to whole Ubuntu serves are crashed down
[13:23] <ari-tczew> From eth0.lutin.canonical.com (<IP_ADDRESS>) icmp_seq=8 Destination Host Unreachable
[13:24] <smartboyhw> ari-tczew, yes it is
[13:24] <smartboyhw> Datacentre down
[13:24] <smartboyhw> one of them in London
[13:24] <smartboyhw> * One of the datacentres in London is down (clearer)
[13:34] <BluesKaj_> ubuntuwiki is still up, or was the last time I checked , but I suppose that's linked to the central server center anyway
[13:35] <smartboyhw> ubuntu.com is down itself
[13:35] <smartboyhw> And I seem to find difficulty connecting to kubuntu.org
[14:03] <debfx> does anyone else have the problem that quassel crashes on startup on saucy?
[14:09] <debfx> aha apparmor is mediating dbus now
[15:18] <ScottK> smartboyhw: kubuntu.org is in the same data center.
[15:18] <smartboyhw> ScottK, I know, telling everybody that
[15:18] <smartboyhw> is my purpose of writing it
[15:21] <smartboyhw> Interesting http://tsdgeos.blogspot.com/2013/09/dine-with-kde-ev-board-this-saturday.html
[18:39] <jussi> sssssssssssssssssssssssssssssaaucy!!!!!!!!! come on down.... :D
[19:18] <shadeslayer> manchicken: huh?
[19:18] <shadeslayer> manchicken: kinda
[19:18] <manchicken> ?


[13:28] <tjaalton> and my audio issue was caused by not having snapd snap installed
[13:51] <ogra_> tjaalton, sounds like a bug ... the first "snap install" call you do should actually install the snapd snap alongside
[13:53] <ogra_> oh, thats on noble and FF was indeed pre-seeded in the image ... seems the bug is in out image building then ...
[13:53] <ogra_> s/out/our/
[13:53] <tjaalton> I've installed this over 2y ago
[13:54] <tjaalton> Rastersoft will take it further ;)
[13:54] <ogra_> ah, i thought you said above you installed noble ... still a bug somehwere though
[13:54] <ogra_> yes, i see him talking internally 🙂
[13:55] <tjaalton> it was dist-upgraded to noble some time ago, then upgraded again and once wireplumber enabled snap permissions, things broke