[12:34] <reynir> Hello. I'm trying to set up an upstart session for a user using this guide http://upstart.ubuntu.com/cookbook/#non-graphical-sessions-ubuntu-specific
[12:34] <reynir> I am having some problems, though. My own jobs are not starting and upstart-file-bridge gives an error:  Unable to write pid file: Permission denied
[12:34] <reynir> I have checked the syntax with init-checkconf on my own files
[22:05] <CharlieSu> How can I run a single command in my upstart script as root and the other as my 'setuid' user?  I'm trying to create a directory in my pre-start stanza


[00:13] <Trevinho> c-lobrano: hey, about the pngs, how did you generate those?
[01:23] <Trevinho> duflu: hey, could you review some theme MPs I've?
[01:24] <Trevinho> otherwise I'm self-approving as they're there since some time xD
[01:24] <duflu> Trevinho, I'll try to have a look today
[01:24] <Trevinho> hey btw :)
[01:35] <duflu> Trevinho, btw if you're marking bugs Fix Released then it's best to include the changelog entry showing where it's fixed. Or a comment mentioning where
[01:36] <Trevinho> duflu: for some of them they where already mentioned (I closed the upstream bug only)
[01:36] <Trevinho> while for one I didn't really know when xD
[01:39] <Trevinho> duflu: as for https://bugs.launchpad.net/ubuntu-themes/+bug/1762465 I should only change the code involving selection and mouse hover, right?
[01:39] <ubot5`> Ubuntu bug 1762465 in ubuntu-themes (Ubuntu) "Nautilus sidebar theming is confusing" [Medium,Confirmed]
[01:40] <duflu> Trevinho, not mouse hover. I think the goal is to make the label backgrounds always match the icon backgrounds
[01:41] <duflu> Because they look like tabs
[01:41] <duflu> which is incorrect
[01:42] <Trevinho> mh, I think is too late for such change. it might break screenshots or such
[01:43] <Trevinho> I'm fine with changing the hover effect, but that was approved by design
[01:45] <duflu> Trevinho, yeah I understand
[01:45] <Trevinho> I'll revisit it a bit, but not everything probably
[01:48] <duflu> I know it's too late to change 18.04, but suspect we'll hear a few duplicate bug reports after release so think about it for 18.10
[02:26] <duflu> Trevinho, heh. I noticed bionic felt smoother... didn't know you got the master clock change in
[06:03] <tjaalton> is it a known bug where some gtk windows seem as somewhat transparent, and when they're moved the contents get messy
[06:04] <tjaalton> gedit for one
[06:04] <tjaalton> I just upgraded and rebooted, thought this would've been fixed but no
[06:05] <tjaalton> hm, doesn't happen on my laptop
[06:08] <tjaalton> huh, it's some user setting messing things up
[06:19] <didrocks> good morning
[06:25] <jibel> Good morning
[06:25] <jibel> salut didrocks
[06:32] <oSoMoN> good morning desktoppesr
[06:32] <oSoMoN> desktoppers*
[06:32] <oSoMoN> and happy Friday!
[06:45] <didrocks> hey jibel, oSoMoN!
[06:47] <oSoMoN> salut didrocks, jib
[06:47] <oSoMoN> jibel*
[06:47] <oSoMoN> slow fingers today…
[06:49] <duflu> tjaalton, yeah Saviq reported that bug. Lemme find it
[06:50] <duflu> tjaalton, bug 1760818
[06:50] <ubot5`> bug 1760818 in ubuntu-themes (Ubuntu) "gedit and gnome-calculator transparency/graphics corruption issue" [Undecided,New] https://launchpad.net/bugs/1760818
[06:50] <tjaalton> ooh, thanks
[06:50] <duflu> Morning didrocks, jibel, oSoMoN
[06:54] <seb128> good morning desktopers
[06:55] <jibel> During the 1st run wizard I tried to setup livepatch but I couldn't authenticate. It kept asking for the 2nd factor. Is it a known issue?
[06:56] <seb128> not reported on https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setup/+bugs at least
[06:56] <seb128> and andyrock is off today
[06:56] <seb128> if that helps to feel better about the issue only canonical accounts are configured to use 2fa so it's not going to hit "normal users"
[06:57] <seb128> but the code is supposed to handle the 2fa, unsure why it doesn't work for you
[06:58] <jibel> and the only message is a successful authentication
[06:59] <jibel> didrocks, where do you store the telemetry data?
[06:59] <seb128> :/
[06:59] <seb128> is there anything interesting in the journal? warnings/errors?
[07:00] <jibel> no
[07:00] <jibel> didrocks, I've this message for my gpu "couldn't get GPU info: couldn't find any line matching ^.* 0300: (.*) \\(rev .*\\)$"
[07:14] <didrocks> jibel: ~/.cache/ubuntu-report/ubuntu.18.04
[07:15] <didrocks> if it's ignore, you shouldn't have the field
[07:15] <didrocks> the question is what is your lspci -n output?
[07:16] <c-lobrano> Trevinho: hi :), no I didn't generate the .pngs, Mads did that, but I said it won't probably been able to generate the svg from there :(
[07:17] <c-lobrano> and, good morning to all :)
[07:18] <didrocks> hey c-lobrano!
[07:18] <c-lobrano> hi didrocks :)
[07:20] <jibel> didrocks, I filed bug 1765614
[07:20] <ubot5`> bug 1765614 in ubuntu-report (Ubuntu) "Incorrect regex for GPU info" [Undecided,New] https://launchpad.net/bugs/1765614
[07:20] <didrocks> jibel: ah perfect! I guess that will wait for a SRU, correct?
[07:20] <didrocks> I'll add a test case for this in the tests as well
[07:22] <jibel> didrocks, sure it can wait
[07:22] <didrocks> jibel: thanks for debugging!
[07:23] <duflu> Morning seb128
[07:23] <seb128> Hey duflu, how are you?
[07:23] <seb128> I spent more time on ubiquity and understand things even less :/
[07:23] <seb128> https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/ubiquity/frontend/gtk_ui.py#L736
[07:24] <seb128> the gtk frontend does set some gsettings using the python bindings
[07:24] <duflu> seb128, I'm not feeling great today, but I think I am making some real progress on totem performance. Only a day after I said I was giving up
[07:24] <duflu> You seb128?
[07:24] <seb128> duflu, I'm tired, stayed up too late looking at ubiquity :/
[07:25] <seb128> the frontend does gsettings call to disable e.g screensaver or power management from gsd
[07:25] <seb128> but the code is root
[07:25] <seb128> and those services are user ones
[07:25] <seb128> so I don't understand how that can work
[07:25] <didrocks> seb128: check for the euid to get under what user this part of code is running: print(os.geteuid())
[07:25] <seb128> also if I gsettings get they seem to have the correct value
[07:25] <didrocks> as ubiquity is doing a lot of raise/drop priviledges
[07:25] <seb128> but like I use the session 15s/try activate the screen reader
[07:25] <seb128> and they all are back to the default value
[07:26] <seb128> not the ones set from ubiquity
[07:26] <didrocks> hum
[07:26] <didrocks> are they delayed keys by any chance?
[07:26] <seb128> delayed?
[07:26] <didrocks> (and not committed for any reason?)
[07:26] <didrocks> seb128: https://developer.gnome.org/gio/stable/GSettings.html#g-settings-delay
[07:27] <seb128> there is no mention of "delay" in the file
[07:27] <seb128> didrocks, code is like https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/ubiquity/frontend/gtk_ui.py#L589
[07:28] <seb128> I also don't understand why those previous/etc checks
[07:28] <seb128> if the function is disable why not just set to false?
[07:30] <didrocks> yeah, this looks cryptic :/
[07:30] <didrocks> can you attach some dbus monitor, or maybe a shell watching for the key?
[07:30] <didrocks> to see when it's set/unset
[07:33] <seb128> yeah, I can try
[07:34] <seb128> that diff http://paste.ubuntu.com/p/fMSsYjYWDv/ is
[07:34] <seb128> - boot in installer mode
[07:34] <seb128> - go to a vt
[07:34] <seb128> - gsettings list-recursively > boot
[07:34] <seb128> - go back to vt1/ubiquity
[07:34] <seb128> - super,alt,s to try to activate the screen reader
[07:35] <seb128> - back to vt, gsettings list-recursively > screen
[07:35] <seb128> diff the 2 files
[07:36] <didrocks> so, all keys are set to what you expect, correct?
[07:36] <didrocks> shortcuts, toolkit-accessibility to true…
[07:37] <seb128> well it's resetting all the changes ubiquity is doing
[07:38] <jibel> org.gnome.settings-daemon.plugins.media-keys screenreader should still be ''
[07:38] <jibel> it's disabled explicitly in ubiquity
[07:38] <jibel> same for the terminal
[07:38] <seb128> well, that's what that diff is
[07:39] <seb128> all the things ubiquity set are reverted to their default
[07:39] <jibel> yeah, is gnome-shell resetting the keys somehow?
[07:40] <didrocks> ahhhhhhhh, got you know
[07:40] <didrocks> now*
[07:42] <jibel> seb128, at the end of run in bin/ubiquity-dm there is this
[07:42] <jibel>             for gs_schema, gs_key, gs_value in gsettings_keys:
[07:42] <jibel>                 subprocess.call(
[07:42] <jibel>                     ['gsettings', 'reset', gs_schema, gs_key],
[07:43] <seb128> that's after the greeter exit though
[07:45] <jibel> the other reset is in unset() of gsettings.py but it is never called
[07:47] <Nafallo> morning
[07:48] <seb128> jibel, didrocks, it's not ubiquity, in fact those get reset on first gsettings write
[07:48] <seb128> I did a gsettings set of the screen-reader key manually
[07:48] <seb128> and everything did reset
[07:49] <didrocks> hey Nafallo
[07:49] <didrocks> hum… this is weird
[07:49] <didrocks> so
[07:49] <didrocks> better doing your gsettings set manually
[07:49] <seb128> hey Nafallo
[07:49] <didrocks> you should maybe try a dconf dump?
[07:50] <seb128> yes
[07:50] <seb128> I tried to strings ~/.config/dconf/user
[07:50] <seb128> the changes are in the db
[07:50] <didrocks> similar :)
[07:50] <didrocks> in the db before being reverted?
[07:50] <seb128> at least it references the keys that are modified
[07:50] <seb128> yes
[07:50] <didrocks> even more surprising…
[07:50] <seb128> I though that maybe it has in memory status not commited on disk or something
[07:50] <seb128> but no :/
[07:50] <didrocks> yeah, exactly…
[07:50] <didrocks> hence my question on dconf dump
[07:50] <didrocks> brrrr
[07:51] <seb128> also there are 2 dconf-service active for the user with different dbus session address
[07:51] <seb128> but I tried to kill the 2 and it's not making a difference
[07:51] <didrocks> can you try gsettings set on something completely unrelated to GNOME?
[07:51] <didrocks> like a key for one of our service
[07:51] <didrocks> to see if that still reverts
[07:51] <seb128> let me see
[07:51] <didrocks> can be something listening on GNOME schemas and reverting on any :change
[07:56] <willcooke> morning all
[07:56] <willcooke> how is it Friday already?
[07:56] <seb128> hey willcooke
[07:56] <seb128> puzzling friday it is
[07:57] <seb128> trying to understand the ubiquity ways
[07:57] <willcooke> jibel, have you test UEFI installs recently?
[07:58] <didrocks> hey willcooke
[07:58] <Nafallo> hi willcooke
[07:58] <willcooke> jibel, ignore, this laptop is in UEFI mode, and works fine
[08:00] <seb128> didrocks, it's any key, I tried settings com.ubuntu.update-notifier something
[08:00] <seb128> didrocks, it doesn't revert if I kill dconf-service :/
[08:01] <seb128> and let a new one be spawned
[08:01] <didrocks> well, that makes sense at least
[08:01] <Laney> moin
[08:01] <didrocks> you have the two trying to write, and one with the old memory mapping
[08:01] <didrocks> hey Laney
[08:01] <didrocks> so, the question is why 2 are launched I guess
[08:02] <teeramisu> Hello, 12 days ago I created Bug 1762200, nobody answered yet. I think it's important before final release. can you take a look at this?
[08:02] <ubot5`> bug 1762200 in xorg (Ubuntu) "[xorg.conf missing]nvidia detects 2 screen but there is no 2 screen" [Undecided,New] https://launchpad.net/bugs/1762200
[08:02] <didrocks> or do you only have an old one? You told that 2 were running, but that was maybe after you set the key already?
[08:02] <didrocks> (so maybe 2 session bus or address?)
[08:03] <seb128> it doesn't make sense
[08:03] <didrocks> seb128: why? my guess is that:
[08:04] <seb128> the second one from the env is a sudo process on a gsettings set command to set volumes-visible
[08:04] <seb128> I guess the ubiquity code is just fucked
[08:04] <seb128> it try to do set with the wrong context
[08:04] <seb128> already in the existant code
[08:04] <didrocks> seb128: look at /proc/$pid/environ for the 2 dconf process
[08:05] <seb128> I did
[08:05] <didrocks> to see what env is incorrect and why a second is spawn
[08:05] <didrocks> same?
[08:05] <seb128> no, what I just wrote
[08:05] <seb128> there is the normal one
[08:05] <seb128> and one resulting from a sudo gsettings set on that nautilus key
[08:05] <didrocks> but env variables are exactly the same in the 2?
[08:05] <didrocks> (which was my question)
[08:05] <seb128> no, the normal has the right address
[08:05] <seb128> the run/uid from the user
[08:06] <seb128> the other one has a random long checksum
[08:06] <seb128> let me pastebin those
[08:07] <didrocks> yeah, have you tried to simply remove the code where ubiquity spawn that second process? (from line 406 in bin/ubiquity-dm)
[08:07] <seb128> http://paste.ubuntu.com/p/bNQRS6MMmt/
[08:08] <seb128> vs
[08:08] <seb128> http://paste.ubuntu.com/p/rY8Tyk89St/
[08:08] <seb128> SUDO_COMMAND=/usr/bin/gsettings set org.gnome.nautilus.desktop volumes-visible false
[08:08] <seb128> DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-B1qg1YXAql,guid=24adb17fe5a37f790451a8405ad99f91
[08:08] <didrocks> indeed, different session bus
[08:09] <didrocks> yeah, so I think what happens:
[08:09] <didrocks> - gsettings from ubiquity contact one of the 2, it writes the settings -> ok
[08:09] <seb128> good idea for the ubiquity-dm dconf spawn
[08:09] <didrocks> - something else set a key outside, contact the first one -> it doesn't have the new key -> write what he has in memory
[08:10] <seb128> right
[08:10] <jibel> willcooke, morning, yes on a real laptop and it worked why?
[08:10] <seb128> the second one shouldn't exist
[08:10] <didrocks> I'm worrying that actually ubiquity-dm is trying to only contact dconf-write on this "private bus"
[08:10] <didrocks> yeah
[08:10] <didrocks> but worth a try
[08:10] <jibel> willcooke, the only thing that doesn't work is users installing in bios mode on uefi hardware
[08:11] <seb128> the only code that writes that key is https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/ubiquity/frontend/gtk_ui.py#L636
[08:11] <jibel> well, "only" ...
[08:11] <didrocks> seb128: oh, it seems ubiquity tries to reuse the session bus
[08:11] <didrocks> so, it's weird it's setting a new one
[08:11] <seb128> didrocks, I'm going to check some uid checks as well, thanks for the help, I'm coming back once I get a bit more debug info/context
[08:11] <didrocks> do you have the process hanging around?
[08:11] <seb128> no, I just closed, I need to reboot
[08:11] <didrocks> seb128: yeah, just try to check ubiquity proc environ
[08:11] <didrocks> ok
[08:11] <didrocks> next time :)
[08:11] <seb128> I'm going to add debug prints and restart
[08:11] <didrocks> line 398 FYI
[08:11] <Laney> this sounds like fun
[08:12] <seb128> thx
[08:12] <seb128> Laney, it is :p
[08:13] <seb128> k, on that note I'm moving back to my desk, no point starting a new debug session from here and my battery is almost empty
[08:13] <seb128> be back in 10 min or so
[08:15] <willcooke> jibel, I saw someone on the hub saying it was broken, but in my testing it wasn't.  What's the use case for bios mode on UEFI?  Is that something people actually need to do, or are they holding it wrong?
[08:17] <jibel> willcooke, they don't need to and there is a warning when they try to do so but if they continue grub installation fails
[08:17] <willcooke> jibel, not a release blocker then?
[08:17] <jibel> willcooke, IIRC there is a bug report to completely block this path because it cannot work
[08:17] <jibel> willcooke, no
[08:18] <willcooke> jibel, thx
[08:18] <juliank> who fixed google calendar online account integration? thanks for that. it's so useful to see my meetings again in shell :)
[08:19] <jibel> willcooke, this post https://community.ubuntu.com/t/grub-efi-amd64-signed-failed-to-install/5274 ?
[08:19] <jibel> there is not much info
[08:20] <jibel> I'll check anyway to make sure nothing broke
[08:22] <willcooke> jibel, yeah that's the one.  It's fine, I just tested it, it worked
[08:22] <willcooke> it = normal install on UEFI
[08:29] <seb128> back
[08:54] <GunnarHj> Good morning all!
[08:54] <seb128> hey GunnarHj
[08:54] <seb128> how are you?
[08:54] <GunnarHj> A question, since I'd like to understand: The seeded snaps, are they on the ISO?
[08:54] <seb128> yes
[08:54] <Laney> seb128: have you seen that misc.py only looks at PKEXEC_UID and gsettings.py only looks at SUDO_USER?
[08:54] <Laney> hey GunnarHj
[08:55] <didrocks> hey GunnarHj
[08:55] <GunnarHj> seb128: The purpose is not ISO space optimizing, I suppose. ;)
[08:55] <seb128> GunnarHj, no, it's to get on with modern technologies
[08:56] <seb128> Laney, no, I didn't, in fact I didn't notice before now that gsettings.py was changing user/using sudo, that explains things
[08:57] <Laney> that part seems unusual to say the least
[08:57] <Laney> I'd think that dropping privs alone should be enough
[08:57] <seb128> yeah
[08:58] <Laney> but misc.py needs to use SUDO_UID too otherwise it doesn't work from the live session
[08:58] <Laney> that desktop file uses sudo not pkexec
[08:59] <Laney> well or change that part I guess
[08:59] <juliank> Is it intentional that gnome-initial-setup runs after initial install and relogin?
[08:59] <seb128> I wonder if we could just        misc.drop_privileges_save() and use the gsettings binding rather than the wrapper?
[08:59] <seb128> juliank, what do you mean "and relogin"?
[08:59] <juliank> seb128: Installed upgrades, logged out, and back in again.
[08:59] <seb128> you go in 2 sessions in a row?
[08:59] <seb128> got it*
[09:00] <juliank> Ran through gnome-initial-setup, it picked up my current keymap and deleted the others.
[09:00] <juliank> apart from that it did not seem harmful
[09:00] <Laney> seb128: probably apart from keeping the API
[09:00] <Laney> like this one lets you just try setting keys on schemas that aren't installed
[09:00] <Laney> gsettings is a bit opinionated about you trying that :-)
[09:01] <seb128> haha
[09:01] <seb128> juliank, you had a screen about locale/keyboard?
[09:01] <didrocks> "a bit"
[09:01] <seb128> juliank, what session do you use?
[09:01] <GunnarHj> juliank: Thought that the keymap part of gnome-initial-setup was hidden.
[09:02] <jibel> I didn't see any locale/keyboard page when I upgraded this morning
[09:02] <seb128> they are not displayed in Ubuntu sessions
[09:02] <seb128> but maybe juliank is using a GNOME session
[09:03] <juliank> oh yes I am
[09:03] <Laney> are we supposed to show g-i-s there?
[09:03]  * juliank thinks it makes sense on first install, but not on upgrades
[09:03] <seb128> robert didn't change the behaviour for !Ubuntu
[09:04] <seb128> well, even on first install
[09:04] <seb128> I guess it could be called upstream experience :p
[09:04] <juliank> well upgrades would be fine too if it did not delete additional keymaps
[09:04] <Laney> it needs integrating with the upstream install experience then
[09:04] <seb128> I don't have really an opinion on that, out of that fact that it duplicates ubiquity questions
[09:04] <Laney> I have an opinion that it shouldn't be run
[09:05] <seb128> sounds fair enough
[09:05] <seb128> we need to fix that then
[09:06] <GunnarHj> Laney, seb128: Selecting language from g-i-s won't reasonably not work well, if the code hasn't been tweaked similar to g-c-c.
[09:06] <Laney> now you have to break the upstream g-i-s experience :/
[09:06] <seb128> well we don't have the installer side so it's broken anyway on Ubuntu
[09:07] <Laney> If someone's using our g-i-s package
[09:07] <jibel> sil2100, kbd pre-selection is fixed on today's iso. Thanks!
[09:07] <seb128> Laney, you mean?
[09:07] <Laney> We remove the desktop file or whatever
[09:07] <seb128> it is in any case, it duplicates ubiquity questions
[09:08] <Laney> Some derivative that is using g-i-s gets that update
[09:08] <Laney> oh look, their gis is now broken
[09:08] <didrocks> as we have per-session XDG_CONFIG_DIRS, we can maybe ship the autostart there? (but it means, shipping for xorg, wayland, communitheme xorg, communitheme wayland)
[09:09] <Laney> it's about turning it off for other sessions though
[09:10] <Laney> Basically it's taking a package which was working if you wanted to use it and making it not work
[09:10] <Laney> Can't see another way though
[09:10] <seb128> well, hypotetical derivative needs an override then, that's part of being a derivate to need to adapt
[09:10] <seb128> for what it's worth I don't know of any using it atm
[09:10] <seb128> so I don't think it's a big deal
[09:11] <Laney> ok, Ubuntu archive Ubuntu packages to do whatever we want with
[09:11] <seb128> for what it's worth I don't think it is/was in a working state
[09:11] <seb128> as GunnarHj said that needs at least to be made to work with how we do translations
[09:12] <seb128> anyway, I agree it's suboptimal
[09:12] <seb128> and wrong in theory
[09:12] <seb128> I'm just saying that in practice it shouldn't be a disaster
[09:13] <Laney> juliank: would you mind filing a bug please?
[09:13] <Laney> I'll probably get this too if I restart but I didn't yet
[09:14] <seb128> Laney, so going back to ubiquity, I'm a bit lost
[09:14] <Laney> sure
[09:15] <seb128> Laney, you think that gsettings.py is doing something wrong with SUDO handling?
[09:15] <Laney> In the ubiquity-dm session as far as I know ubiquity is started via pkexec
[09:15] <Laney> in the *live* session it is started by sudo
[09:15] <Laney> you get PKEXEC_* variables in the first case and SUDO_* ones in the second
[09:15] <Laney> which tell you which user you came from
[09:15] <Laney> that's what ubiquity is using to know who to drop back down to
[09:16] <seb128> I'm in ubiquity-only and I dump the env from gtk_ui.py around the gsettings calls to disable screensaver
[09:16] <Laney> but the code is checking different ones in different places
[09:16] <seb128> and the env has SUDO_USER=ubuntu
[09:16] <seb128> and no PK env
[09:16] <Laney> so if it's using SUDO then the misc.drop_all_privileges thing doesn't work
[09:17] <seb128> it doesn't make sense why it's not creating issues in other places if that's the case :/
[09:18] <juliank> Laney: https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setup/+bug/1765644
[09:18] <ubot5`> Ubuntu bug 1765644 in gnome-initial-setup (Ubuntu) "After install, runs in gnome session after logging in again, deletes alternate keymaps" [Undecided,New]
[09:19] <juliank> the title is too long
[09:19] <Laney> thx
[09:19] <juliank> I must say I liked the experience of g-i-s
[09:19] <seb128> Laney, http://paste.ubuntu.com/p/vn4tKc9S73/ is a print(os.environ) after         self.disable_screen_reader() in gtk_ui.py
[09:20] <juliank> apart from that thing
[09:20] <seb128> juliank, we don't intend to use it
[09:20] <juliank> it looked nice
[09:20] <juliank> :)
[09:20] <seb128> at least not this cycle
[09:20] <seb128> we built on it for the ubuntu welcome wizard in ubuntu session
[09:20] <seb128> we are going to look at include some of the upstream screens next though
[09:20] <seb128> like online accounts config
[09:20] <juliank> that one seemed actually useful
[09:21] <juliank> keyboard setting not so much :)
[09:21] <juliank> though just having a Welcome screen is kind of nice too :)
[09:22] <seb128> Laney, oh, there is a PKEXEC_UID as well which I didn't notice earlier, I guess pkexec just set SUDO_USER as well
[09:23] <seb128> k, I think I'm going to do the same as yesterday, early lunch and then I try to rip off that sudo use see if it's really needed
[09:24] <Laney> alright
[09:24] <Laney> how do you get a tty from the only ubiquity sessions?
[09:24] <Laney> thought that was fixed
[09:24] <seb128> it is
[09:24] <Laney> oh yeah
[09:24] <seb128> I can switch to a vt using the normal ctrl-alt-fn
[09:24] <Laney> it just takes like 10 seconds
[09:24] <seb128> right
[09:28] <Laney> seb128: https://paste.ubuntu.com/p/TBPv8pD254/ that's what I can see from /proc/ubi/environ
[09:48] <jibel> bug 1765651 should probably be fixed for the release ?
[09:48] <ubot5`> bug 1765651 in gnome-initial-setup (Ubuntu) "Do not run gnome-initial-setup during OEM preparation stage" [Undecided,New] https://launchpad.net/bugs/1765651
[09:49] <Laney> probably fixing julian_k's would fix that too
[09:49] <Laney> IMHO they could be nominated / assigned but it's not really up to me :-)
[09:50] <jibel> seb128, willcooke ^^ WDYT?
[09:53] <jibel> didrocks, I think telemetry data should include information about OEM installation and the end user setup. For example if I do an OEM install in English and the end user setup in French, it just tells me the installation is in english not the settings selected by the end user.
[09:58] <willcooke> jibel, yeah, sounds sensible
[10:00] <tseliot> Wimpress, mwilson-e: can you test the new nvidia-prime, please? (when it's built) https://launchpad.net/~albertomilone/+archive/ubuntu/deleteme-nvidia
[10:02] <mwilson-e> tseliot: Will do.
[10:02] <tseliot> thanks
[10:19] <mwilson-e> tseliot: Tested on 1 unit so far with MATE and it works. :D
[10:21] <tseliot> mwilson-e: that's good. I can't reproduce the problem here either with the new package
[10:21] <tseliot> I suppose all the other Ubuntu flavours use lightdm, that's why it was failing
[10:22] <Wimpress> tseliot: Sure thing.
[10:22] <tseliot> thanks
[10:51] <Wimpress> tseliot: I'm encountering some issues here.
[10:52] <Wimpress> I've purged all *nivia* paackages from the system.
[10:52] <Wimpress> *nvidia packages
[10:53] <Wimpress> Which also mean nvidia-prime is not installed. But your testing ppa is enabled.
[10:54] <Wimpress> Ah, found the issue.
[10:54] <Wimpress> I still had the graphics-drivers PPA enabled.
[10:58] <tseliot> Wimpress: issues with nvidia-prime?
[10:58] <Wimpress> I'm retesting again now.
[11:01] <Wimpress> I purge all nvidia packages, which means nvidia-prime is not installed and rebooted.
[11:01] <Wimpress> Install nvidia 390 drivers via Additional Drivers UI. Rebooted.
[11:02] <Wimpress> The display manager still works, but nvidia-prime was not installed and libnvidia-compute-390:i386 is a broken package.
[11:03] <tseliot> did you purge libnvidia-compute-390:i386 manually before reinstalling?
[11:03] <Wimpress> Yep
[11:04] <tseliot> neither ginggs nor I managed to reproduce that
[11:04] <tseliot> maybe try reinstalling libnvidia-compute-390:i386
[11:05] <Wimpress> I'm going to test again and make sure no cached packages exist.
[11:08] <didrocks> jibel: good point! g-i-s is runing after the OEM welcome user session, correct?
[11:08] <didrocks> jibel: so, using the current user language can be an option, no?
[11:08] <didrocks> (current == session)
[11:09] <didrocks> the location isn't an issue I guess as we are taking the user's session one
[11:18] <jibel> didrocks, yes it does. current user settings would work
[11:18] <jibel> didrocks, I reported bug 1765672
[11:18] <ubot5`> bug 1765672 in ubuntu-report (Ubuntu) "Add information about OEM installation and end user setup" [Undecided,New] https://launchpad.net/bugs/1765672
[11:21] <seb128> jibel, Laney, robert_ancell is off next week so better not count on him to fix those issues before release
[11:21] <ricotz> hey desktopers
[11:21] <seb128> hey ricotz
[11:21] <ricotz> is someone able to test a firefox package on s390x?
[11:21] <ricotz> seb128, hey
[11:22] <seb128> ricotz, try asking xnox maybe
[11:22] <seb128> Laney, right, your pastebin env is similar to the one I pastebined a bit earlier
[11:23] <Laney> wb seb128
[11:23] <Laney> yes no SUDO stuff there
[11:23] <seb128> thx
[11:23] <seb128> oh, that's a difference
[11:23] <ricotz> xnox, hi, would you like to test a firefox 60 beta build for s390x? available in https://launchpad.net/%7Emozillateam/+archive/ubuntu/firefox-next
[11:23] <seb128> Laney, http://paste.ubuntu.com/p/vn4tKc9S73/ was mine from the gtk_ui code with a print(os.environ)
[11:24] <seb128> that has PKEXEC_UID but also SUDO_USER
[11:25] <didrocks> jibel: many thanks! I'll move them to github as a reminder and this starts to build a list for the first update :)
[11:27] <didrocks> jibel: so, just to sum up, TZ shouldn't be an issue, correct? Only language
[11:27] <didrocks> (you used TZ as well in the bug report)
[11:30] <jibel> didrocks, TZ too. The end user selects his own TZ
[11:30] <jibel> didrocks, and maybe screen resolution too
[11:30] <didrocks> jibel: well, TZ and screen resolutions are taken during the session
[11:30] <didrocks> so it's already the end user selection if g-i-s runs after oem-setup second stage
[11:31] <didrocks> The only part which are OEM (taken from the install) is what is under the "Install" section
[11:31] <jibel> didrocks, it's fine then
[11:31] <didrocks> Install has Media, Type, PartitionMethod, DownloadUpdates, Language, Minimal, RestrictiedAddons,Stages
[11:32] <didrocks> I think only Language should be moved out to session, indeed
[11:32] <jibel> right, looking at the data file, only the language
[11:32] <didrocks> (I guess we can even remove it from ubiquity in the long term)
[11:32] <didrocks> yep, thanks for confirming!
[11:41] <jbicha> juliank: yes, it's intentional that gnome-initial-setup runs for upgraders who have never run it before. Ubuntu GNOME included g-i-s in 17.04 & vanilla-gnome-desktop still pulls it in
[11:41] <juliank> jbicha: well you want to talk to Laney then so he does not disable it?
[11:42] <juliank> or somebody else
[11:42] <jbicha> juliank: do you want to file a bug upstream about your particular issue (the keymap thing not that it runs on upgrades)
[11:43] <juliank> yes I can do that in an hour or so
[11:43]  * juliank goes on lunch walk
[11:47] <jibel> if I want to restart the wizard what do I reset?
[11:47] <jbicha> juliank: hmm, Fedora 28 doesn't show the keyboard page for existing users, we could possibly do that too but we'd have to take their patch and rewrite our vendor.conf
[11:48] <jbicha> jibel:    rm ~/.config/gnome-initial-setup-done
[11:48] <jbicha> (g-i-s-done is an empty file)
[11:48] <jibel> jbicha, thanks
[11:49] <jbicha> it won't ask you about livepatch if you've already configured that
[11:49] <jibel> I cannot configure it anyway. It fails on 2FA
[11:50] <jbicha> oSoMoN: congratulations 🎉
[11:53] <didrocks> worth checking livepatch is set immediately
[11:53] <didrocks> so that the report reports the enablement status :)
[11:53] <didrocks> I thought we want as well to show the report on upgrade, having a non versioned g-i-s-done stamp file will need to be revisited
[11:57] <jbicha> didrocks: oh if we want to ensure it runs for upgraders, even for those who installed g-i-s before (like those upgrading from UG 17.04), maybe we need to adjust that stamp file name *now*
[11:58] <didrocks> jbicha: oh correct…
[11:58] <didrocks> well, it's for .1 maybe at this stage
[11:58] <didrocks> but still worth considering
[11:58] <jbicha> it might be awkward to actually fix that for .1 …
[11:58] <didrocks> willcooke: seb128: thoughts? ^
[11:59] <seb128> I don't think many users installed g-i-s
[11:59] <jbicha> currently implementation is just an empty file ~/.config/gnome-initial-setup-done so it doesn't tell you what GNOME or Ubuntu version was used
[11:59] <seb128> so I don't think it matters much
[12:00] <didrocks> jbicha: was it installed by default on UB?
[12:00] <didrocks> UG*
[12:00] <seb128> I don't think many people installed UG
[12:00] <seb128> and those likely want to use a GNOME session not an Ubuntu one
[12:00] <didrocks> ok, so not having them ~ not important
[12:00] <seb128> and the wizard is not displayed there
[12:00] <jbicha> didrocks: just for 17.04; it wasn't even pacakged for xenial
[12:00] <didrocks> seb128: +1
[12:00] <didrocks> ok, so sounds we can keep it like that
[12:01] <seb128> wfm
[12:01] <didrocks> and then, for next cycle, let's put the version in the file
[12:01] <didrocks> (instead of piling up a lot of empty timestamp files)
[12:01] <Laney> you won't be able to use the AutostartCondition then
[12:01] <didrocks> we can even have different behaviors between "was it already displayed before on a previous release or not?"
[12:01] <didrocks> correct
[12:01] <didrocks> you feel piling empty files are better thus?
[12:02] <didrocks> don't really like it, but yeah, AutostartCondition worths it…
[12:02] <Laney> why piling?
[12:02] <Laney> clean up the old ones
[12:02] <didrocks> shared home between install? :p
[12:02] <didrocks> otherwise, you will keep flip-flap
[12:02] <didrocks> (I know, something people shouldn't do)
[12:03] <Laney> come on
[12:03] <Laney> most applications don't have forwards compatibility in their databases
[12:04] <didrocks> we can give it a try and see if we have angry feedbacks ;)
[12:08] <jibel> didrocks, bug 1765693
[12:08] <ubot5`> bug 1765693 in ubiquity (Ubuntu) "[telemetry] Record OEM installation mode" [Undecided,New] https://launchpad.net/bugs/1765693
[12:09] <didrocks> jibel: thanks! :)
[12:09] <didrocks> waow, you even list the debconf key
[12:09] <didrocks> royal bug report! :)
[12:10]  * didrocks feels like upgraded to 1st class now
[12:13] <oSoMoN> thanks jbicha
[12:16] <juliank> jbicha: that sounds good to me
[12:16] <juliank> but I have not looked at the patch
[12:16] <juliank> The live patch stuff only shows up in the Ubuntu session, right?
[12:18] <juliank> I was like, "just because I want GNOME does not mean I don't want livepatch", but it actually makes no sense; as you'd login to an ubuntu session first thing after install
[12:32] <jbicha> juliank: we're interested in trying to merge the GNOME and Ubuntu versions of gnome-initial-setup a bit more in the future
[12:36] <jbicha> mpt: I filed some first-login-window bugs. Who can I ping for them to get looked at sooner? https://github.com/CanonicalLtd/desktop-design/issues/101 102 105
[12:36] <ubot5-ng> CanonicalLtd bug 101 in desktop-design "First login: What's new: wording suggestions" (comments: 2) [Open]
[12:36] <ubot5`> Error: Launchpad bug 101 could not be found
[12:39] <jdstrand> didrocks: you probably noticed, but if not, apparmor with your communitheme patch is now in bionic
[12:39] <Wimpress> tseliot: OK, I have mostly good news :-)
[12:39] <jdstrand> didrocks: if you need it for other releases, please comment in the bug
[12:40] <Wimpress> Installing the nvidia drivers via the Addition Drivers UI or via `apt install nvidia-driver-390 results in a successful install, nvidia is enabled and lightdm works.
[12:42] <Wimpress> However, I still experience https://pad.lv/1765053 when installing via `ubuntu-drivers autoinstall`
[12:42] <ubot5`> Launchpad bug 1765053 in nvidia-graphics-drivers-390 (Ubuntu) "Errors were encountered while processing: /tmp/apt-dpkg-install-x8YVfC/03-libnvidia-compute-390_390.48-0ubuntu2_i386.deb" [High,In progress]
[12:43] <didrocks> jdstrand: I did notice! I just made people eagerly waiting for it aware about it! Many thanks :) This is only needed starting from 18.04, all good!
[12:43] <jdstrand> didrocks: thanks for the patch. glad we squeezed it in
[12:44] <jibel> uh, looks like we have a problem when users upgrade with an encrypted swpa
[12:44] <jibel> swap*
[12:45] <jibel> system hangs on boot when it tries to activate it
[12:45] <seb128> urg :/
[12:46] <willcooke> jibel, swap file? rather than partition?
[12:48] <jibel> swap partition
[12:48] <jibel> I cannot even enter recovery mode
[12:50] <seb128> do you know why? sounds line something foundations might understand better than us
[12:53] <jibel> not yet, I'll file a bug once I've enough info, and indeed it's a foundations thing
[13:01] <jbicha> jibel: bug 1736072 was in my history
[13:01] <ubot5`> bug 1736072 in systemd (Ubuntu) "Encrypted swap does not work" [High,Incomplete] https://launchpad.net/bugs/1736072
[13:05] <jibel> jbicha, it's very similar but this bug report is really confusing, talking about ubiquity. In my case it's an upgrade from xenial with an encrypted home. I'll file a separate report and they can always duplicate
[13:52] <Wimpress> didrocks: Do you have a few minutes to discuss ubuntu-report?
[13:53] <seb128> Wimpress, don't ask to ask just ask?
[13:53] <Wimpress> I know people are busy :-)
[13:54] <Wimpress> Too British.
[13:55] <oSoMoN> please excuse me for begging your pardon :)
[13:57] <kenvandine> lol
[13:58] <Wimpress> didrocks: ubuntu-report send is only executed via the GNOME first run wizard, correct?
[14:02] <seb128> Wimpress, atm yes, but there is a cli utility and the api can be used by derivates who want to
[14:02] <tseliot> Wimpress: I'm not sure about that, to be honest
[14:03] <didrocks> Wimpress: so yes, you can either use the C lib or the Go one or the CLI
[14:03] <didrocks> but current integration is via GNOME first run wizard
[14:03] <didrocks> you have man pages on the CLI (automatically generated)
[14:03] <didrocks> the Go API if available at https://godoc.org/github.com/ubuntu/ubuntu-report/pkg/sysmetrics
[14:04] <didrocks> and the C is at https://godoc.org/github.com/ubuntu/ubuntu-report/pkg/sysmetrics/C
[14:04] <didrocks> check the README.md of the project: https://github.com/ubuntu/ubuntu-report
[14:04] <Wimpress> I just wanted to confirm that no reports are being sent via Ubiquity.
[14:04] <didrocks> nope!
[14:04] <didrocks> you will have it writing a file
[14:04] <didrocks> as /var/log/installer/telemetry
[14:05] <didrocks> but it's not used by anything
[14:05] <Wimpress> It is therefore the responsibility of each flavour to instruct users to submit, or not, their reports as the first run wizard does in Ubuntu.
[14:05] <didrocks> exactly!
[14:05] <Wimpress> Thanks.
[14:05] <didrocks> Wimpress: upgrade will also flesh out a file
[14:05] <didrocks> in /var/log/upgrade/telemetry
[14:05] <Wimpress> Should flavours send reports to the same URL as Ubuntu?
[14:05] <didrocks> but same than ubiquity, it won't be used
[14:06] <didrocks> I think they should
[14:06] <didrocks> there is the current running session sent as info
[14:06] <didrocks> but you can't really say something is xubuntu, ubuntu or ubuntu-mate
[14:06] <Wimpress> And install media, which includes the flavour.
[14:07] <didrocks> (well, we report the install media)
[14:07] <didrocks> yes
[14:07] <didrocks> but then, what would be about ubuntu-mate where I install ubuntu-desktop? :p
[14:07] <didrocks> or the contrary
[14:07] <didrocks> this is why current session is the best IMHO
[14:07] <didrocks> (and no different URL)
[14:07] <didrocks> making sense?
[14:07] <Wimpress> So perhaps sending to the same URL as Ubuntu is fine?
[14:07] <didrocks> yep!
[14:08] <Wimpress> Cool.
[14:08] <Wimpress> Well add something to Welcome to facilitate this.
[14:08] <didrocks> Wimpress: excellent! Do not hesitate if you have any integration question
[14:08] <didrocks> do you plan to use the API or wrapping the CLI?
[14:09] <Wimpress> Just the cli for now. Simplest thing possible.
[14:09] <didrocks> yeah, so look at the various command in the manpages to automate it
[14:09] <Wimpress> Well put a similar UI to GNOME first run in front of it.
[14:09] <didrocks> (they are in the README)
[14:09] <Wimpress> Yep, I've read it 🙂
[14:10] <didrocks> \o/ at least, it's been useful for one person! :)
[14:10] <didrocks> basically, I guess, you will do:
[14:10] <didrocks> $ ubuntu show <- get the json from here
[14:10] <didrocks> $ ubuntu send yes|no
[14:11] <didrocks> (no is the optout message, yes is to send the previous report)
[14:14] <kenvandine> jibel, irt bug 1765651
[14:14] <ubot5`> bug 1765651 in gnome-initial-setup (Ubuntu Bionic) "Do not run gnome-initial-setup during OEM preparation stage" [High,Triaged] https://launchpad.net/bugs/1765651
[14:14] <kenvandine> jibel, do you know how to detect if we're in the OEM preparation stage?
[14:14] <kenvandine> or anyone ^^
[14:15] <didrocks> probably some env var? /me doesn't know much about OEM
[14:15] <jibel> kenvandine, let me check
[14:32] <jibel> kenvandine, if really you want to be sure, current user is 'oem', set to log in automatically and /home/oem/Desktop/oem-config-prepare-gtk.desktop exists
[14:32] <jibel> this user is removed on first boot after the system is prepared
[14:32] <jibel> i'll document the bug report
[14:33] <kenvandine> oh... probably just check if the current user is oem
[14:33] <kenvandine> we should never want to run in that case
[14:33] <Laney> can't the file be touched for the oem user?
[14:34] <jibel> well if your username is 'oem' then you won't see the initial setup :)
[14:35] <jibel> right we could do that too in the ubiquity hook
[14:35] <jibel> much simpler actually
[14:35] <kenvandine> jibel, that's probably the best fix
[14:36] <jibel> moving to ubiquity then
[14:36] <kenvandine> jibel, great!
[14:38] <Laney> yes in plugininstall.py when it sets up the oem user
[14:43] <jibel> unrelated to the original bug I reported but slightly worrying for the initial setup https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1765724/comments/3
[14:43] <ubot5`> Ubuntu bug 1765724 in cryptsetup (Ubuntu) "Xenial -> Bionic - System fails to boot after upgrade - <email address hidden> fails to start" [Critical,New]
[14:56] <seb128> ok, I give up trying to understand why gsettings changes signal don't work in ubiquity
[14:57] <didrocks> seb128: fresh brain on Monday might help :)
[14:58] <seb128> didrocks, Laney, jibel, the keys unsettings themself I explained, the wrapper does that
[14:58] <seb128>     subp = subprocess.Popen(
[14:58] <seb128>         ['sudo', '-H', '-u', user, 'gsettings', 'get', schema, key],
[14:58] <seb128>         stdout=subprocess.PIPE, stderr=subprocess.PIPE,
[14:58] <seb128> or sudo empty the env so the DBUS_ADDRESS... is not set and a new bus is spawned
[14:58] <seb128> adding '-E' to the arguments fix that part
[14:58] <seb128> fixes
[14:58] <didrocks> making sense
[14:58] <seb128> no extra dconf-service anymore
[14:58] <seb128> no key unset
[14:59] <didrocks> so, at least, no double service, which is a win :)
[14:59] <seb128> but I can't get the gsettings changed signal to work
[14:59] <seb128> without or without dropping priviledge
[14:59] <seb128> the dbus env is correct
[14:59] <seb128> the gsettings api documentation states "Note that settings only emits this signal if you have read key at least once while a signal handler was already connected for key ."
[14:59] <seb128> which I though could have been the issue
[14:59] <seb128> but I added a get_boolean() call to the code after the connect, no luck
[14:59] <didrocks> yeah, I was going to mention that
[15:00] <didrocks> that would have been my bet for that issue :/
[15:00] <seb128> that's my current patch
[15:00] <seb128> http://people.canonical.com/~seb128/ubiquity-screen-reader.patch
[15:01] <jibel> Laney, do we care if the owner is root?
[15:01] <didrocks> seb128: I should be free on Monday for a peer looking into that issue if you want
[15:01] <Laney> want me to look in a bit?
[15:01] <didrocks> I would say, still get that in
[15:01] <Laney> jibel: umm, probably, can't you use 'install'?
[15:01] <seb128> didrocks, Laney, help would be welcome if you guys have some idea, as said my current work is on there ^
[15:02] <didrocks> seb128: I'll go off in the next minutes, hence proposing looking at that together at that time (but still push your changes, they are valid)
[15:03] <seb128> didrocks, I'm at least going to proposed the '-E' use
[15:03] <seb128> let's see on monday
[15:03] <didrocks> seb128: yeah, the -E is safe and needed anyway
[15:03] <seb128> maybe Laney pokes a bit still today and figure out something
[15:03] <didrocks> to connect to the right bus
[15:04] <seb128> I'm pondering cleaning the ubiquity-dm dbus activation/dconf-service code
[15:04] <seb128> I wonder if that could be useful for any other derivative
[15:04] <didrocks> seb128: the impact is on flavors…
[15:04] <seb128> probably not, but there is no need to change that at this point
[15:04] <didrocks> yeah
[15:04] <didrocks> correct :/
[15:04] <didrocks> if we avoid for us spawning it that way, I don't think it worths touching
[15:04] <didrocks> (that way == -E)
[15:06] <seb128> right
[15:07] <didrocks> I don't spot anything on the connect change signal from your diff…
[15:08] <seb128> anything wrong you mean?
[15:08] <didrocks> yeah, sorry
[15:08] <seb128> thx for looking
[15:08] <seb128> as said let's forget about it for this week
[15:08] <seb128> maybe Laney sees something
[15:08] <seb128> otherwise new round on monday
[15:08] <didrocks> yeah, let's do this! :)
[15:08] <seb128> thx didrocks!
[15:09] <seb128> at least we explained the dconf unset thing
[15:09] <didrocks> yw, and nice hunting, even if not yet completely resolved ;)
[15:09] <didrocks> yep
[15:09] <seb128> thx
[15:09] <didrocks> happy the theory was correct :)
[15:09] <seb128> :)
[15:10] <didrocks> seb128: just, ubiquity-dm is using the glib mainloop, correct?
[15:10] <didrocks> to deliver signals…
[15:10] <didrocks> I guess so, just asking ;)
[15:10] <seb128> good question
[15:10] <Laney> you mean ubiquity itself?
[15:10] <Laney> it's gtk ...
[15:11] <didrocks> Laney: well, the code is in ubiquity-dm which launch ubiquity UI as a subprocess, no?
[15:11] <seb128> the callback is in gtk_ui.py
[15:11] <didrocks> ah no, that part of the code is in gtk_ui.py
[15:11] <didrocks> yep
[15:11] <seb128> which is the frontend
[15:11] <didrocks> ok, so obviously not it
[15:11] <didrocks> well, let's sleep on that
[15:12] <didrocks> and enjoy the week-end and park+sun :)
[15:12] <seb128> right
[15:12] <seb128> thx, same to you!
[15:12] <didrocks> see you on Monday guys!
[15:12] <didrocks> thx :)
[15:32] <seb128> shrug, just did a nautilus upload that got rejected
[15:32] <seb128> jbicha, you forgot to commit/push your recent changes to the vcs :/
[15:34] <seb128> ok, I guess one less fix uploaded to bionic then, I need to step out, maybe later
[15:34] <seb128> jbicha, if you fix the vcs I can retry to include those, I uncommited/force pushed back
[15:34] <jbicha> seb128: pushed now. Sorry about that. I seem to be having lots more trouble remembering to push to bzr these days :|
[15:43] <seb128> jbicha, thx
[16:04] <seb128> k have a good w.e desktopers
[16:04] <seb128> I'm out for a bit, might deal with a bit of backlog still later
[16:05] <oSoMoN> have a good one seb128 !
[16:29] <Laney> this is some weird shit
[16:57] <Laney> I tried making the GSettings an instance variable in case it was going out of scope
[16:57] <Laney> NOPE
[16:58] <Laney> I made it so that gsettings.py wasn't making a new dconf-service process spawn (hacking DBUS_SESSION_BUS_ADDRESS in the child processes)
[16:58] <Laney> NOPE
[16:58] <Trevinho> Laney: looser :-D
[16:58] <Laney> the GSettings isn't getting connected to the right dconf daemon somehow
[16:59] <Laney> this is some messed up stuff
[16:59] <Laney> if you make it write then the callback is called
[16:59] <Laney> but then there's an error that it can't commit the change "the connection is closed"
[16:59] <Trevinho> you need to define the runtime dir too
[16:59]  * Laney slaps Trevinho
[16:59] <Trevinho> at least, not sure what you're trying though
[16:59] <Laney> why
[16:59] <Laney> dbus and dconf is already running
[16:59] <Laney> I just want to get on the existing ones
[17:00] <Trevinho> ah, yeah I mean the standard ones'
[17:00] <Trevinho> ?
[17:00] <Laney> probably XDG_RUNTIME_DIR isn't set
[17:00] <Laney> but I don't need to spawn anything new, and DBUS_SESSION_BUS_ADDRESS is ok
[17:00] <Laney> arghghghgh
[17:01] <Laney> this is the wurst
[17:01] <Laney> the bockwurst
[17:02] <Laney> I'm going
[17:02] <Laney> we're off to a pizza place for a friend's birthday
[17:02] <Laney> #trevinhocompliant
[17:02] <Trevinho> ahha
[17:03] <Trevinho> No, when it involves friends it's always ok
[17:03] <Trevinho> I even eat that horrible pizza with you guys in holland
[17:05] <oSoMoN> it's 5 past beer, I'm off to a micro-brewery
[17:05] <oSoMoN> have a good week-end everyone!
[17:30] <willcooke> righty ho, time for something else.  Happy weekend all
[18:35] <teeramisu> Hello, is this bug? should i report bug? https://gist.github.com/Parduk/790a233bbfa3b1f807c772089a671f85
[18:56] <jbicha> teeramisu: do not use sudo to run gnome-control-center
[19:04] <teeramisu> jbicha: so its not bug right?


[00:40] <mkanat> Is there some way to not receive bug emails for ~loggerhead-team, but still stay in the team, and still keep receiving other bugmails?
[00:41] <cody-somerville> mkanat, if a contact e-mail address is set for the team then notifications sent to the team will be sent to the contact e-mail address instead of each individual member.
[00:42] <persia> And if the contact address is the mailing list for the team, and you decide not to receive the mailing list, you're all set.
[00:44] <mkanat> Yeah, unfortunately there is no mailing list and I don't want to affect the other members.
[00:45] <wgrant> I think that bugmail subscriptions to non-list teams are insane.
[00:45] <wgrant> Members should subscribe individually.
[00:45] <maxb> You can probably cut down on the volume by subscribing to loggerhead bugmail personally, at the "new and fixed bugs only" level (why isn't there a "none" level?) ... though I believe levelled bugmail is only visible to ~malone-alpha members at present
[00:46] <persia> wgrant, I don't suppose you want to encode that opinion as policy through code?
[00:47] <maxb> Whilst I quite like receiving bzr bugmail, I agree that it shouldn't be a forced attribute of membership of ~bzrr
[00:48] <mkanat> I can just remove myself from ~loggerhead-team for now.
[00:49] <persia> mkanat, Or you could ask the team admins to do the sensible thing.
[00:49] <cody-somerville> mkanat, You could create a new team, create a mailing list for it, set the mailing list as the contact address, make yourself unsubscribed from that list, and then add your team to ~bzr :P
[00:51] <persia> maxb, "none" is expressed as "not subscribed".  It's just broken in terms of teams, especially indirect teams used for ACLs.
[00:51] <persia> (and inverse subscribtion doesn't work currently)
[00:51] <maxb> Other subscription areas in launchpad permit specific subscription with a notification level of "none"
[00:52] <wgrant> maxb: "Others" being branches, or is there something else?
[00:52] <persia> Odd.
[00:52] <poolie> maxb, we could probably remove ~bzr's subscription and get people to individually subscribe
[00:52] <cody-somerville> Its because subscriptions double as the ACL (which has been recognized as a mistake)
[00:52] <poolie> i don't see why that wouldn't work
[00:52] <poolie> oh, unless there's something annoying about it being coupled to access control, like being the bug supervisor
[00:53] <wgrant> cody-somerville: A mistake that my squad is scheduled to correct :)
[00:53] <persia> cody-somerville, meaning that recommended practice ought be two teams, one for ACL and one for subscription (with list)?
[00:53] <persia> wgrant, Thank you!!!!
[00:53] <cody-somerville> It really only affects private bugs and branches
[00:53] <persia> No, it affects public bugs and branches as well.
[00:53] <cody-somerville> not for ACL
[00:54] <poolie> maxb if in the interim you want to unsubscribe ~bzr, propose it on the list
[00:54] <persia> The number of times I've been spammed with uninteresting bugmail after adding a new team to be administered by the DMB is larger than zero.
[00:54] <poolie> i'm a bit busy to just do it atm
[00:55] <persia> bug view ACL is interesting, but branch-write ACL and repo-upload ACL are both interesting.
[00:55] <persia> s/both/also/
[00:55] <cody-somerville> persia, What I was trying to say is that the reason 'no e-mail' subscriptions exist is because they double as ACL for private bugs and branches so there is no need for two teams like you suggest unless you're dealing with private bugs and branches.
[00:56] <persia> Yes, there is, because there are other interesting cases of ACL.
[00:56] <cody-somerville> Sure... but those cases don't involve subscriptions
[00:56] <cody-somerville> and they won't ever because using subscriptions to double as ACL has been recognized as a mistake so won't be implemented as such for future things
[00:57] <persia> Depends.  For example, at one point kubuntu-dev (ACL to upload a packageset) was subscribed (as a group) to bugs on the packages in the packageset.  This made sense, except for the lack of unsubscription for uninterested folk.
[00:57] <cody-somerville> But the ACL wasn't tied to the subscription
[00:57] <persia> If you like, check your old mail logs: you should have gotten that bugmail as well.
[00:58] <persia> Ah, true, although it was tied to the group/.
[00:59] <cody-somerville> Indeed which makes sense. We shouldn't be a member of the kubuntu-dev team. We should instead be its owner. That gives us the privileges of admin membership without the bug mail :)
[01:00] <wgrant> Right. Ownership is more appropriate here.
[01:00] <persia> Well, looking at a more general case, consider branch commit ACLs.  I can imagine that the set of folk interested in watching bugs on a group of related projects is disjoint from the group with ACL to commit to the set of branches on those projects being monitored.
[01:00] <persia> (as the owner/upload thing only affects a very small number of people)
[01:01] <cody-somerville> Ideally, we wouldn't even have to be the owner. Instead, I think it would make sense to be able to associate objects like teams to 'domains' so that for example the DMB could be given admin like permissions for objects that belong to say ubuntu/development-teams domain (or something like that).
[01:01] <persia> My limited knowledge of LP data representation implies this isn't going to happen soon :)
[01:03] <wgrant> I've wanted for a while to do something similar to what cody-somerville suggests.
[01:03] <wgrant> It's not clear exactly how it would work, though.
[01:03] <wgrant> The upcoming privacy work will be somewhat related to that, though.
[01:03] <cody-somerville> persia, who knows... now that LP has a dedicated technical architect and some extra staff it might come sooner than we think. lifeless and wgrant are both very smart blokes with some fresh perspective and energy. :)
[01:04]  * persia isn't sure about "fresh", but otherwise is agreeable
[01:05]  * wgrant would agree with persia.
[01:05] <cody-somerville> If you're not hacking on the code everyday and then suddenly it becomes your day job, I'd say you're 'fresh'. working on the same thing day in and day out can make you dull. :)
[01:05] <james_w> I always find persia agreeable
[01:08] <persia> james_w, Thanks!
[01:09] <persia> cody-somerville, You may want to grep the Soyuz commit logs for "wgrant" over the past year or so then.
[01:51] <blackmoon-105> i've create a new project on launchpad, i've set the series in my project, but now i don't know how set the code for this series. a message say that i haven't yet told Launchpad where my source code is. the buggy source is already in the universe repo of ubuntu.
[01:57] <blackmoon-105> no one?
[02:03] <micahg> blackmoon-105: you should have an upstream code branch for upstream releases
[02:04] <wgrant> blackmoon-105: Which is the project?
[02:05] <blackmoon-105> micahg:  so i must download the source from ubuntu repoo fix it and upload it, right?
[02:05] <blackmoon-105> wgrant: greepops
[02:05] <blackmoon-105> wgrant: * freepops
[02:05] <micahg> blackmoon-105: well, where's upstream?
[02:07] <blackmoon-105> micahg: i don't have already upload my modified version of code..
[02:08] <micahg> blackmoon-105: sorry, I meant where is the current upstream for it
[02:09] <wgrant> Upstream seems to maintain a CVS repository on SourceForge.net.
[02:09] <wgrant> blackmoon-105: What are you actually trying to do here?
[02:09] <wgrant> You're trying to get a patch into Ubuntu?
[02:11] <blackmoon-105> micahg: the current upstream is on sourceforge, on debian repo, on ubuntu universe repo
[02:12] <blackmoon-105> wgrant: i've create a project because i maun keep this package update and fix all bugs
[02:12] <micahg> blackmoon-105: I think you should answer wgrant's question
[02:12] <blackmoon-105> maun --> want
[02:13] <wgrant> You want to keep the package up to date in Ubuntu?
[02:14] <blackmoon-105> wgrant: yes and fix bug
[02:14] <blackmoon-105> wgrant: i'd like to be a mantaner for this packege
[02:14] <wgrant> blackmoon-105: The package is in universe, so you probably want to header over to #ubuntu-motu and talk to them about how you can help.
[02:15] <wgrant> blackmoon-105: As for the Launchpad configuration issue, you probably want to ask Launchpad to import the FreePOPs CVS repository.
[02:15] <wgrant> You should see a 'Configure code hosting' link on https://launchpad.net/freepops
[02:17] <blackmoon-105> wgrant: ok, i'll ask #ubuntu-motu
[02:18] <blackmoon-105> wgrant: i can't find "Configure code hosting"
[02:18] <wgrant> blackmoon-105: Ah, maybe 'Configure project branch'
[02:20] <blackmoon-105> wgrant: yes, i've got it
[02:20] <wgrant> blackmoon-105: More directly, enter the CVS details on https://code.launchpad.net/launchpad/+new-import.
[02:20] <wgrant> Er.
[02:21] <wgrant> https://code.launchpad.net/freepops/+new-import
[02:22] <blackmoon-105> wgrant: but i must import from source forge cvs even if it's already in a debian /ubuntu repo?
[02:23] <maxb> Importing the upstream source into a Bazaar branch is a convenience to assist in creating the packaging. It's not a necessity, but keeping your packaging in a VCS is good, and bzr is Ubuntu's tool of choice.
[02:25] <blackmoon-105> maxb: yes, but my question was: if i import from externl cvs (like sourceforge) i'll lost all patches from ubuntu, right?
[02:34] <nhandler> wgrant: FYI, that email I tried sending yesterday through LP didn't end up going through.
[02:43] <maxb> blackmoon-105: freepops enters Ubuntu via Debian. It is preferred that in such cases you work directly with Debian, so that both distributions can have the benefit of work done, and Ubuntu does not unnecessarily diverge from Debian. For further help, proceed in #ubuntu-motu.
[02:50] <blackmoon-105> maxb: ok, i'm already talk with ubuntu-motu :)
[02:50] <persia> maxb, If someone is active enough with upstream, and there's some complication, we don't mind that much working in parallel to Debian, rather than through (e.g. GNOME)
[03:25] <maxb> Hrm... is it possible to contrive to get a UTF-8 locale on a buildd during a build?
[03:26] <wgrant> I'm not sure if the chroots have locales beyond C...
[03:27] <wgrant> You could grab the chroot and see.
[03:39] <mwhudson> mm, can you use launchpad branch privacy policies to only allow members of a certain team to create branches in a project but still have branches public by default?
[03:39] <mwhudson> thumper: ^ do you know?
[03:41] <thumper> mwhudson: yes, I think so
[03:41] <thumper> mwhudson: set default to forbidden, and team to public
[03:41] <mwhudson> ok cool
[03:49] <maxb> Hmm, I think I can do something eeeevil
[03:50] <maxb> localedef dynamically in the build process, and set LOCPATH
[03:52] <maxb> I am so tempted to define a POSIX.utf8 locale :-)
[03:56] <micahg> are b.g.o statuses disappearing a known bug?
[09:15] <nigelb> poolie: hi
[09:16] <poolie> hi nigelb
[09:16] <nigelb> poolie: do you folks have a conclusion on who would be helping with the session?
[09:16] <nigelb> poolie: The mail thread was a bit confusing :)
[09:16] <poolie> :)
[09:17] <poolie> i believe jelmer and vila were going to contact barry and guy-starting-with-o to offer help
[09:17] <poolie> there are two relevant sessions
[09:17] <poolie> do you want to add more
[09:17] <nigelb> no no
[09:17] <nigelb> I just wanted to figure out who was helping the guy-starting-with-q :p
[09:17] <wgrant> 3
[09:18] <nigelb> 3?
[09:18] <wgrant> I was rapidly window-switching and managed to forget the '/win '
[09:18] <nigelb> heh
[09:19] <poolie> it's nice when people just say 'win'
[09:19] <poolie> like a happy MIT form of tourettes
[09:19] <nigelb> lol
[09:19] <nigelb> IRC form of tourettes ;)
[09:20] <nigelb> poolie: I'll talk to jelmer and villa and figure out who's helping who so that we can confirm the schedule :)
[09:20] <poolie> thanks; at least vila should be online now
[09:21] <nigelb> ok, pinging.
[09:21] <nigelb> vila: ping?
[09:21] <vila> I'm here
[09:21]  * vila searches the relevant email :-/
[09:22] <vila> nigelb: unless you can refresh my declining memory ?
[09:22] <nigelb> vila: Heya, so, which session would you be helping at during UDW so I can help coordinate with whoever is leading that particular session
[09:22] <vila> nigelb: is there a wiki summary somewhere or should I propose a session ?
[09:23] <nigelb> there are 2 sessions that have already things to do with LP that could possible use help
[09:23] <nigelb> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable
[09:23] <nigelb> Quintasan is not sure about their session, so you can join in and help in that one
[09:24] <nigelb> Or, barry is going to talk about UDD, which should also be interesting from an LP POV
[09:24] <apw> is launchpad meant to be down this am, the last announcement i have said it was last night
[09:24] <vila> apw: it's down *now* in addition to the previous rollout which didn't go well
[09:25] <apw> for a roll back ?
[09:26] <vila> nigelb: meh, I didn't check the dates earlier but I'll be in vacations :-}
[09:26] <vila> nigelb: and offline
[09:27] <nigelb> vila: haha, ok
[09:27] <vila> nigelb: sorry about that :-/
[09:27] <nigelb> vila: I'll try jelmer and/or abently :)
[09:27] <nigelb> vila: We'll catch you next time :-P
[09:27] <vila> ley abentley ;)
[09:28] <poolie> apw, for another attempt at the same upgrade
[09:28] <poolie> see blog.launchpad.net
[09:28] <vila> nigelb: that's the second year in a row I missed that I think (well there was a bzr sprint last year IIRC)
[09:29] <nigelb> vila: one of these days, we'll catch you
[09:29] <vila> nigelb: I sure hope so !
[10:25] <lifeless> mm, lets get the priorities right :)
[11:07] <soren> I can't seem to bzr pull from Launchpad :(
[11:08] <soren> $ bzr branch lp:nova
[11:08] <soren> Connection closed by <IP_ADDRESS>
[11:08] <soren> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[11:08] <wgrant> soren: Indeed, just noticed that myself.
[11:08]  * soren runs around like a headless chicken
[11:09] <nigelb> I can confirm the same. /me joins soren in the runnning around.
[11:19] <mvo> is it known that bzr commits to LP are not working currently? I keep getting TooManyConcurrentRequests or simple hangs ( http://paste.ubuntu.com/565797/ ). or is that just me?
[11:19] <poolie> mvo, known issue
[11:20] <mvo> ta
[11:34] <jml> mvo: http://identi.ca/launchpadstatus always has the latest info on known issues.
[11:48] <nigelb> jml: might want to add the issue to /topic
[11:49] <wgrant> nigelb: It seems to be fixed now.
[11:49] <wgrant> We're just waiting to see if it shows up again.
[11:50] <nigelb> Ah!
[11:51] <wgrant> We rolled out a big codehosting change with 11.02, which we've since turned off. Everything is looking fine now.
[11:53] <nigelb> :)
[14:10] <jml> nigelb: yeah, it's part of our process to add things to the /topic, but it seems an easily forgotten part.
[14:10] <jml> nigelb: not sure how to make it harder to forget.
[14:15] <persia> jml, Add a bot to the channel with permission to change /topic that subscribes to the identi.ca feed?
[14:15] <jml> persia: not a bad idea
[14:16] <jml> persia: that might also be not too much work
[14:16] <persia> automation is key, until it begins to haunt you.
[14:23] <mgedmin> any ideas why curl won't download patches from launchpad?
[14:23] <mgedmin> curl https://bugs.launchpad.net/bugs/716257/+attachment/1840916/+files/gtimelog_hide_on_esc.diff | wc -l
[14:23] <mgedmin> says there are 0 lines
[14:23] <mgedmin> wget -O - on the same url works fine (14 lines)
[14:27] <benji> mgedmin: that's odd
[14:29] <deryck> mgedmin, benji -- curl won't follow redirects, right?
[14:29] <benji> mgedmin: it looks like curl isn't following the 301
[14:29] <benji> great minds
[14:29] <deryck> heh, jinx!
[14:30] <benji> mgedmin: use curl -L
[14:30] <mgedmin> thanks
[14:31] <benji> np
[14:54] <jml> persia: to paraphrase someone else,
[14:55] <jml> Sometimes someone looks at a problem and thinks, "I know, I'll write some software to solve it". Now they have two problems.
[14:58] <persia> jml, The difference between a procedure executed by a human and a procedure executed by a computer is that you have some chance at guessing how the computer will behave whilst executing the procedure.  Once you codify a procedure to address a problem, I'm unconvinced that aphorism continues to apply.
[16:35] <achiang> hello, i see a lot of idle armel builders in the build farm. is there a reason for that?
[16:36] <cody-somerville> achiang, because there are no armel jobs queued up for them
[16:37] <achiang> cody-somerville: uh
[16:38] <achiang> cody-somerville: i have about 20 builds that i'm blocked on
[16:38] <cody-somerville> achiang, Yes but your builds must use the armel builders in the ppa builder pool
[16:38] <cody-somerville> achiang, and the lone armel builder in that pool is indeed busy and that pool does indeed have a queue of about 12 jobs.
[16:39] <achiang> cody-somerville: currently, only 1 builder is in that pool. :(
[16:39] <cody-somerville> achiang, indeed. :(
[16:39] <cody-somerville> achiang, I've poked someone about it.
[16:39] <achiang> cody-somerville: ok, thanks
[16:40] <achiang> cody-somerville: if i see a job that i know shouldn't be running, could a losa help me cancel it?
[16:41] <mbarnett> achiang: what job is that?
[16:41] <achiang> cody-somerville: this job claims to be running, but a) i wonder if it actually is, and b) if it is, it shouldn't be -- https://launchpad.net/~oem-archive/+archive/charlotte/+buildjob/2253282
[16:42] <cody-somerville> achiang, it would appear that it actually is. But why shouldn't it be?
[16:42] <achiang> cody-somerville: because i've uploaded a newer package that supersedes it
[16:42] <cody-somerville> ah
[16:43] <achiang> cody-somerville: anyway, i'd like to kill that job and free up some resources
[16:43] <cody-somerville> achiang, Soyuz does not automatically kill a running build even if the build will be thrown away.
[16:43] <cody-somerville> achiang, Ack.
[16:43] <achiang> cody-somerville: i see; but maybe mbarnett can manually kill it for me. :)
[16:43] <mbarnett> achiang: i can't actually kill a running build.
[16:44] <cody-somerville> lamont, are you able to help?
[16:44] <bigjools> we're adding a feature to do that, until then you can't
[16:44] <mbarnett> yay!
[16:44] <achiang> what if you just use a big hammer and power cycle it? :)
[16:44]  * mbarnett will celebrate by killing everything!
[16:44] <mbarnett> achiang: i could try and cause a power outage in the datacenter..
[16:44] <bigjools> although it's a lot simpler if you already uploaded a newer one
[16:44] <bigjools> just restart the builder
[16:45] <cody-somerville> it looks like it actually might be stuck anyhow. Its been doing the same thing for awhile now.
[16:45] <achiang> right
[16:45] <achiang> chromium does take a long time to build, but i think it's been stuck there for a long time. :(
[16:46] <achiang> bigjools: i did upload a newer package about 18 hours ago
[16:47] <bigjools> I think on armel it takes a loooong time
[16:48] <achiang> mbarnett: you can't bounce an individual machine?
[16:48] <achiang> bigjools: i've been watching that build, and i claim it's stuck (independent of the fact that i made the upload and i don't need that build anyway)
[16:48] <bigjools> heh
[16:48] <bigjools> you need a buildd admin, like lamont
[16:50]  * achiang knows where lamont lives, ponders driving out there with a pointy stick
[16:53] <mbarnett> achiang: yeah, i can make it so no NEW jobs get sent there.. i can't cancel a current build though.
[16:59] <achiang> ah bugger, another chromium build just started on kaylaberry
[17:00] <achiang> that build, i actually do need, but i'd be willing to postpone it to let other smaller jobs through. :-/
[17:45] <nigelb> persia: Ilike how you keep thinking up how to automate :D
[19:47] <pmjdebruijn> hi
[19:47] <pmjdebruijn> I'm intermittently experiences "illegal instruction" problem when darktable gets built on the PPA build farm
[19:47] <pmjdebruijn> when building the same sources locally there is no issue
[20:46] <____rye> hello people, having read http://curtis.hovey.name/2010/11/01/launchpad-answers-at-uds-n/ and seeing "External" in Launchpad Answers configuration I was wondering whether it is possible to specify external URL now?
[23:01] <GrueMaster> Does anyone know if launchpad.distributions.searchTasks can take multiple parameters?  I am trying to replicate an advanced search from launchpad in a format similar to the reports generated by the ubuntu-qa-tools/bug-report-framework.
[23:04] <james_w> GrueMaster, it can
[23:09] <GrueMaster> Ok...how?   Maybe I am missing something but I am trying to refine a list to unassigned bugs for a team and tag.  But assignee_option='none' is giving me an error.
[23:11] <GrueMaster> I'm using that field based on the link of a successful query using launchpad's advanced search.
[23:45] <wgrant> sinzui: Ah, great, you noticed the new p-r-f log?
[23:45] <sinzui> Yes. I got a copy of it. Looks like loganberry cannot talk over ftp at the moment
[23:46] <wgrant> Excellent.
[23:46] <wgrant> Since it should be the only remaining script failure.
[23:46] <wgrant> Is the verbosity OK? I haven't actually looked at the log, and sort of guessed at which level would be appropriate.
[23:47] <wgrant> Seems OK.
[23:48] <wgrant> sinzui: It looks like it can't HTTP out either?
[23:48] <wgrant> But that at least doesn't crash it.
[23:48] <sinzui> It right. that is because http call pass in the open method