[00:01] <ochosi> brainwash: bleh, i made a mistake, s/none/transparent/
[00:06] <ochosi> Unit193: also feel free to give this a shot if you can ^
[00:06] <ochosi> will take another week until i get trusty
[00:06] <brainwash> nope
[00:06] <ochosi> doesn't work?
[00:06] <brainwash> not for me
[00:07] <brainwash> setting the background of .menu to "none" does kinda work
[00:07] <ochosi> a-ha?
[00:08] <brainwash> background stays completely blue, but font won't turn white
[00:08] <brainwash> changes to the *hover thingy don't seem to have any effect
[00:09] <brainwash> *:hover
[00:09] <ochosi> you can add "color: @panel-fg-color;"
[00:09] <ochosi> to *:hover
[00:09] <ochosi> or the label/image hover
[00:11] <brainwash> *:hover is ignored completely I think
[00:11] <ochosi> no, at least in your screenshot the whole area around the label is drawn by *:hover
[00:12] <ochosi> it just seems like the "background-color: transparent;" is broken or something
[00:14] <brainwash> removed *:hover -> no changes at all
[00:15] <ochosi> ok, then try to remove all the menu code and see what happens
[00:16] <brainwash> ochosi: another funny thing: when I move the cursor between the panel and the opened indicator menu, icons in the menu get slightly brighter
[00:17] <ochosi> yeah, that's a gtk3 feature
[00:17] <ochosi> it's the same in toolbars
[00:17] <brainwash> oh
[00:19] <brainwash> removed the menu code, highlighting works now, background + font... but the font has an ugly shadow effect now
[00:21] <brainwash> but wait a minute, you still did not setup a trusty test environment? :)
[00:22] <Unit193> What do you think you're for?
[00:23] <ochosi> brainwash: i have a 100gb ssd atm, which holds all my data, so no, i don't have free space
[00:23] <ochosi> and +1 Unit193
[00:24] <brainwash> 100gb
[00:24] <brainwash> that's huge
[00:26] <ochosi> only if you're used to chromebooks
[00:31] <ochosi> brainwash: apart from the text-shadow, which should be straightforward to fix, do multi-line hovers look ok as well?
[00:31] <ochosi> e.g. when you use the soundmenu and have a track running in some musicplayer
[00:31] <ochosi> you should get a hover effect spanning 3 lines
[00:32] <ali1234> works with orion :)
[00:33] <ochosi> cool
[00:33] <ochosi> well nice, less code is better then
[00:33] <ochosi> i'll see whether i can put that together so that it works in both saucy and trusty
[00:33] <ali1234> less code = fewer bugs, always
[00:33] <ochosi> yeah, pretty much
[00:34] <ochosi> actually we've been adding new stuff to the greeter (i'm about to merge a branch that'll fix nouveau), so if you wanna look for leaks... ;)
[00:34] <sergio-br2> ochosi, i did:  git pull origin master
[00:35] <sergio-br2> is it right?
[00:35] <ochosi> yeah, if master is the branch you want
[00:35] <sergio-br2> but there is nothing related to me in github
[00:36] <sergio-br2> how can i see the commit?
[00:36] <ochosi> related to you? if you want to push something, then pull isn't the correct command
[00:36] <sergio-br2> humm
[00:37] <ali1234> what are you actually trying to do?
[00:37] <sergio-br2> but i can't push to shimmerproject
[00:37] <sergio-br2> i'm trying to send a commit at elementary-xfce
[00:37] <ali1234> there's multiple ways to do that
[00:37] <ali1234> pull is not one of them though
[00:37] <sergio-br2> haha ok
[00:38] <ochosi> you can't push to the shimmerproject directly
[00:38] <ochosi> the best way to get this to work is to create your own github account
[00:38] <ochosi> then fork elementary-xfce (if that's what you wanna work on)
[00:38] <ochosi> and then push the changes to your own repo
[00:39] <Unit193> Or, git diff | pastebinit and send to ochosi. :D
[00:39] <sergio-br2> hum ok. I have an account at github
[00:39] <ali1234> not
[00:40] <ochosi> Unit193: thanks, advocatus diavoli!
[00:40] <brainwash> ochosi: looks ok, multi-line hove
[00:40] <ali1234> Unit193: no, you can't do that. output of git diff cannot be applied. use git format-patch HEAD^ (after commiting) for this :)
[00:41] <Unit193> Seems to work for me, but yeah, I was kidding.  It works for the code, but not attribution.
[00:42] <ochosi> brainwash: ok, so removing those lines fixes everything apart from the text-shadow. i'll try to patch that after i'm done with my merge
[00:43] <ali1234> hmm... well it didn't used to :)
[00:43] <brainwash> ochosi: text-shadow and most likely the background color, it's a bit lighter than the blue used in whisker menu and other panel items I think
[00:43] <ali1234> git diff was deliberately crippled to prevent it
[00:43] <ochosi> brainwash: could you show me a screenshot of that please?
[00:44] <ali1234> format-patch has the advantage of keeping the commit message and attribution
[00:44] <brainwash> let me just get the color codes
[00:44] <ochosi> brainwash: it's a gradient...
[00:45] <ali1234> sergio-br2: https://help.github.com/articles/using-pull-requests
[00:47] <ochosi> brainwash: ok, please pull from git, that should sort out most things now
[00:47] <sergio-br2> ok
[00:48] <ochosi> brainwash: fwiw, here whiskermenu and the indicators (and all other menus) look the same. also: whiskermenu isn't really a gtkmenu, so it's bound to look a little different...
[00:49] <brainwash> ochosi: http://en.zimagez.com/zimage/lelel.php
[00:49] <Unit193> ali1234: Then what was even the point of git diff??
[00:49] <ali1234> Unit193: it's for interactive display of changes only
[00:49] <Unit193> Bleh.
[00:50] <Unit193> patch -p1
[00:51] <ochosi> brainwash: that looks fine. the text-shadow is already fixed in git master now
[00:52] <ali1234> sergio-br2: also you may want to consider uploading a ssh key to github, it makes pushing much easier
[00:53] <brainwash> ochosi: ok, the color difference is minimal
[00:53] <brainwash> nobody will notice that
[00:54] <ochosi> it might be the same color-diff as between gtk2 and gtk3 menus (not noticeable)
[00:54] <ochosi> but yeah, whiskermenu is a different widget, so it's not impossible it looks slightly different
[00:55] <brainwash> places menu also
[00:55] <brainwash> I mean places menu highlight looks like the whisker one
[00:55] <brainwash> it's a darker, stronger blue
[00:56] <brainwash> but whatever... done :)
[00:57] <ochosi> feel free to propose a patch ;)
[00:57] <brainwash> no
[00:57] <brainwash> but what about the other shimmer themes?
[00:57] <brainwash> already patched?
[00:58] <ochosi> nope, will do that another time
[00:58] <ochosi> too tired now
[00:58] <brainwash> ok
[00:59] <brainwash> now we only need to solve the this remaining mystery: why do some indicators occupy 2 rows in deskbar mode?
[02:31] <sergio-br2> i did the request, but just now i realized that 64 icons are a little bit different from 128 icons :D
[02:32] <sergio-br2> subtle difference, i need my glasses
[07:18] <elfy> ochosi: saw a greeter update this morning - not sure what it was for - but if it was for login corruption it didn't work here - either cold boot nor restart
[07:19] <elfy><PHONE_NUMBER>48~ubuntu14.04.1
[08:29] <ochosi> elfy: no, greeter was built 10hrs ago, branch was merged 8-9hrs ago
[08:33] <ochosi> elfy: i can ask for a new build now though, then you can test the fix today
[08:38] <ochosi> elfy: just requested a new build now, so whenever it's ready...
[08:38] <ochosi> https://code.launchpad.net/~lightdm-gtk-greeter-team/+archive/daily/+recipebuild/630903
[08:38] <ochosi> in case you wanna monitor it
[08:40] <ochosi> (but don't go crazy: http://xkcd.com/281/ )
[08:49] <elfy> ochosi: LOL
[08:50] <knome> hah
[08:50] <christoffer> haha
[08:50] <elfy> ochosi: I said to someone the other day I'm so laid back I'm a reflex angle - I'll not be doing that :p
[08:50] <ochosi> :]
[08:50] <knome> reminds me of the a-ha song 'move to memphis'
[08:51] <ochosi> reminds me of the song "bakerman" (by laid back)
[08:51] <elfy> knome: they had more than one song?
[08:51] <knome> elfy, sure, many *albums* worth of songs :)
[09:45] <elfy> ochosi: that works then - more or less, still get the cold boot corruption - but just for a short while after login, the bit I was most concerned about - the fragments of and old session don't show at all - thanks :)
[09:55] <ochosi> elfy: cold boot corruption? could you elaborate that a bit?
[09:57] <elfy> https://launchpadlibrarian.net/162094730/CAM00034.jpg
[09:57] <ochosi> oh, after login, that means that it happens when the root-pixmap gets displayed for a short while between the greeter and xfdesktop loading
[09:57] <elfy> yea - that's all
[09:57] <ochosi> weird
[09:57] <ochosi> that looks bad though
[09:57] <ochosi> and shouldn't really happen
[09:57] <ochosi> have you rebooted once or twice
[09:57] <elfy> the other one - the bit I was really worried about doesn't happen
[09:57] <ochosi> just to be sure
[09:58] <elfy> upgraded/rebooted/shutdown/reboot/shutdown and then a restart
[09:59] <elfy> I agree it looks bad - but of the two issues - I know which I'd rather see
[10:00] <elfy> ochosi: you want me to comment on the bug?
[10:00] <ochosi> please do so
[10:00] <ochosi> well i plan to fix that corruption as well, i just have to find a way to reproduce it first...
[10:01] <elfy> :)
[10:01] <elfy> often the hard bit I guess
[10:34] <ochosi> elfy: i can reproduce the corruption when logging in – and that part also makes sense to me, as i explained earlier (nouveau mistreating the root pixmap) – but what i can't reproduce is the scrambled background at the login window
[10:35] <ochosi> that one looks totally fine for me now
[10:45] <brainwash> ochosi: any idea how the highlight of the play button in the indicator menu is implemented?
[10:45] <ochosi> not really, feel free to look into that
[10:46] <brainwash> so I took the ubuntu themes, removed the gtk3 part... and it still gets highlighted when I hover over the button
[10:47] <brainwash> theme engine specific?
[10:48] <ochosi> not sure
[10:48] <elfy> ochosi: you've misunderstood me
[10:48] <ochosi> brainwash: first of all, i dont have any idea what weird custom widget they're using there (which would help enourmously for theming it)
[10:49] <elfy> the login screen is fine - you explained the thing I see between login and the desktop
[10:49] <brainwash> ochosi: ah got it, the glow is there by default, but gets overridden by greybird somewhere
[10:50] <brainwash> ochosi: maybe I'll find the right element, but those css files are huge =S
[10:50] <ochosi> elfy: oh, then the "screenshot" you linked to was misleading
[10:50] <ochosi> brainwash: better to read the source of the soundmenu, it's not that long
[10:50] <ochosi> brainwash: or even easier, use gtkparasite
[10:51] <brainwash> ochosi: thanks for the hints :)
[10:51] <elfy> ochosi: was just to show you what I seen between logging in and the desktop - sorry if it wasted your time
[10:51] <ochosi> elfy: hehe, no problem, i'm happy as long as the issue is fixed in the greeter (which it obviously is) :)
[10:51] <elfy> yep
[10:55] <ochosi> elfy: the other part has to be fixed in nouveau
[10:55] <elfy> k - that's fine with me
[10:55] <elfy> as far as I am concerned the most important issue is dealt with - the fragments of old sessions - not seeing them at all
[10:56] <elfy> I didn't really think about it till I saw someone's e-mail address and infraction record sitting there :)
[10:57] <elfy> so that's taken 250 out of the bugs heat lol
[11:00] <ochosi> :)
[11:00] <ochosi> well, happy i could fix it
[11:00] <elfy> so am I
[11:01] <elfy> bbl
[11:01] <elfy> ochosi: thanks :)
[11:02] <ochosi> np, yw :)
[11:05] <brainwash> does the settings manager ignore "always on top"?
[11:05] <ochosi> yeah, seems so
[11:06] <brainwash> ok, thanks for confirming
[11:06] <ochosi> probably because of its window-manager hints
[11:06] <ochosi> in fact, the label doesnt even change when you click it
[11:06] <ochosi> so it seems to be expected
[12:05] <brainwash> ochosi: gtkparasite is really a nice tool
[12:05] <ochosi> yup
[12:05] <ochosi> it is
[12:07] <brainwash> used it to identify gtkwidget for bug 1268243
[12:07] <brainwash> not sure how to use it for the sound menu
[12:07] <ochosi> run the panel from the terminal?
[12:08] <brainwash> mmh, worth a try
[12:08] <brainwash> https://github.com/shimmerproject/Greybird/blob/master/gtk-3.0/gtk-widgets.css#L2289
[12:09] <brainwash> can it be changed to the toolbar background color or even none?
[12:11] <brainwash> but I have no clue what this change might break :)
[12:13] <ochosi> well, test it :>
[12:13] <brainwash> this shade looks weird in synaptic anyway
[12:13] <ochosi> imo synaptic should be fixed
[12:14] <ochosi> but frankly i don't care too much as it's not installed by default anymore
[12:16] <Unit193> micahg: Guess you ended up without time?  Is there anything else I can do to make the process easier?
[12:18] <brainwash> ochosi: you could push the change, then we just wait until someone complains about it :D
[12:19] <ochosi> brainwash: anyway, the thing you propose doesn't make sense. it's basically switching styles to a flat toolbar look
[12:19] <ochosi> which would mean also changing gtk2
[12:19] <ochosi> and all because synaptic has some weird elements in its toolbar
[12:20] <ochosi> if you've found the widget structure, you can patch that single searchbox in synaptic, but the other way round isn't acceptable
[12:23] <brainwash> ochosi: ok, the difference in other gtk3 apps seems to be noticeable
[12:24] <brainwash> so the report is invalid then
[12:25] <micahg> Unit193: fell asleep, where's that bug
[12:25]  * knome pats micahg on the head
[12:26] <brainwash> ochosi: or better won't fix
[12:26] <Unit193> https://code.launchpad.net/~unit193/xubuntu-default-settings/session-fix/+merge/198177 thought knome ate it for a sec.
[12:26] <knome> mm, well i did eat quite some things today
[12:26] <knome> :d
[12:27] <Unit193> micahg: Built, tested.
[12:29] <micahg> I still wish it would clean up the old config, but I don't know offhand how it would do that
[12:29] <Unit193> Same, not without sed. :/
[12:39] <ochosi> micahg: you have until feature-freeze to improve the patch ;)
[12:39] <ochosi> but i think we need a live-session for the time being
[12:39] <micahg> yep, writing the same in my comments
[12:40] <Unit193> lightdm-set-defaults is gone, which could have been used.
[12:40] <ochosi> brainwash: add a synaptic-specific workaround that styles that searchbox like a toolbar is an option, but i won't do the work for that
[12:40] <ochosi> s/add/adding/
[12:43] <micahg> Unit193: One comment, LP: # closes bugs, not LP: unless something changed (I made the change to the main branch already)
[12:46] <Unit193> Thank you.  http://packaging.ubuntu.com/html/fixing-a-bug.html#documenting-the-fix agrees with you and I could have seen that by only looking at the last entry...
[12:49] <Unit193> Thanks for taking a look!
[12:50] <micahg> I'm also adding aline for automated translations updates to the changelog since those made their way in as well
[12:52] <micahg> Unit193: uploaded, please keep an eye on regressions and ping me if something comes up
[12:52] <micahg> I'll probably be hiding in -offtopic :)
[12:52] <Unit193> Sure thing, will do.
[12:52] <Unit193> Saaame. :P
[13:01] <brainwash> ochosi: lets ignore this "bug"
[13:01] <ochosi> brainwash: haha, this coming from you is just hillarious
[13:02] <ochosi> usually you like to nitpick about these tiny glitches, no?
[13:02] <brainwash> ochosi: any idea how to inspect the sound menu? once you've clicked the indicator, the inspector tool disappears
[13:02] <ochosi> afaik, the inspector opens a new window for each plugin
[13:02] <ochosi> but i haven't tested it personally in a longer time
[13:03] <brainwash> secretly I'm working on greybird-flat
[13:03] <ochosi> well, that's basically a merge of numix and greybird
[13:04] <brainwash> numbird or greyix
[13:04] <brainwash> so I get the parasite window for wrapper 2.0, but the sound menu needs to activated by mouse click
[13:05] <brainwash> so the inspector tool always captures the indicator icon in the panel and not the sound menu
[13:05] <ochosi> usually there were expanders to look down the widget structure (also of plugins that weren't open)
[13:06] <ochosi> bbl
[13:07] <brainwash> ochosi: it only captures the indicator alignment / image / label
[13:19] <brainwash> ochosi: did anything strange happen to the greeter drop down menus after the recent greybird changes? :)
[14:22] <brainwash> ochosi: strange icon highlighting eliminated (when cursor is moved from the opened sound menu back to the indicator icon in the panel) + play button glow http://lpaste.net/98529
[14:27] <jjfrv8> knome, ping
[15:02] <ochosi> brainwash: thanks for the soundmenu patch! if you wanna be in the commit-log as author, please do a merge-request on github
[15:02] <ochosi> i'm not 100% sure about my stance on the gtk-image-effect story
[15:02] <ochosi> so if you wanna do a merge-request, only do the menu:selected part
[15:03] <brainwash> the 2nd gtk-image-effect is causing the ugly effect
[15:05] <brainwash> leaving the gtk3 indicator menu and playing the cursor above the indicator highlights all icons in the menu
[15:05] <brainwash> so it needs to be addressed
[15:06] <brainwash> and just commit the changes you like, no need to list me as author
[15:09] <jjfrv8> bbiab
[15:14] <christoffer> knome, I must say that the application finder is pretty fantastic...have been missing that since Unity arrived.
[15:15] <christoffer> though it doesn't find the calculator for some reason
[15:16] <ochosi> christoffer: really? http://www.zimagez.com/zimage/screenshot-01152014-041600pm.php
[15:16] <christoffer> ochosi, I mean the <alt><f2>
[15:16] <christoffer> different gui
[15:17] <christoffer> but must be same application finder
[15:17] <christoffer> or?
[15:17] <ochosi> it only shows results as soon as they are unique
[15:17] <ochosi> hitting the "arrow-down" key expands the view
[15:17] <ochosi> (what you see in my screenshot)
[15:17] <christoffer> aha ok
[15:17] <ochosi> then you see the stuff filtered
[15:18] <christoffer> though typing "calculator" and pressing enter doesn't start the application
[15:18] <christoffer> even if it's unique
[15:18] <ochosi> because that's not the command
[15:18] <ochosi> as long as the searchglass is on the left (and no app-icon), you're executing a command
[15:18] <ochosi> and the command "calculator" doesn#t exist
[15:18] <christoffer> ok
[15:19] <ochosi> it's gnome-calculator
[15:19] <christoffer> can I expand the window with some key command?
[15:19] <ochosi> arrow-down
[15:19] <brainwash> christoffer: it's gnome-calculator
[15:19] <brainwash> oh
[15:19] <brainwash> tzzzz
[15:20] <christoffer> yea that is perhaps the fastest ...rebind arrow down to something better and press <alt><f2>calculator<arrow-down><enter><enter>
[15:32] <ochosi> brainwash: sound-indicator fix is pushed
[15:33] <slickymaster> afternoon all
[15:33] <brainwash> ochosi: and the icon thingy? any idea how to fix it properly?
[15:33] <ochosi> brainwash: i'm not sure yet i see the problem you're seeing, can you describe it again plz?
[15:33] <brainwash> ochosi: is the dim/highlight really needed?
[15:34] <ochosi> i think it can be helpful in some contexts
[15:34] <ochosi> but i don't see the problem in the indicators yet
[15:34] <brainwash> ochosi: uhm, let me try to make a screencast, brb
[16:24] <brainwash> ochosi: finally back, so here's the link http://www.youtube.com/watch?v=LgpWmS05iFA
[16:25] <brainwash> ochosi: and you need to fix the drop down menus in the greeter, they are broken after the recent removal of menu theme code
[16:26] <brainwash> text shadows once again
[16:33] <ochosi> brainwash: thanks for the screencast, i understand what you mean now
[16:33] <ochosi> i guess my current monitor is too bad, so i can't see it
[16:33] <ochosi> (although that's a bit odd, cause i can see it in the screencast)
[16:35] <ochosi> the greeter code is still in flux, so don't worry about glitches like that with daily
[16:35] <ochosi> i'm trying to finalize things for a release, then i'll release a greybird version that works with it alongside
[18:04] <brainwash> ochosi: did you try to load gtk3 indicators, so they are displayed in the greeter?
[18:04] <brainwash> I mean, does this actually work
[18:04] <brainwash> it did not for me
[18:28] <knome> jjfrv8, ping
[18:28] <knome> christoffer, iirc, gcalctool links to the calculator as well
[18:28] <knome> i guess you could add /home/user/.bin/ to PATH and then add a symlink for 'calculator' in that dir
[18:30] <christoffer> knome, gcalctool works in unity but not xubuntu
[18:30] <knome> hmm, right, seems it's dropped in 13.10...
[18:30] <knome> it used to work in xubuntu as well
[18:32] <christoffer> gno<enter>ca<enter> is the quickest way :)
[18:32] <christoffer> only adding a custom symlink for "calc" would be quicker I assume
[18:32] <christoffer> =)
[18:34] <christoffer> I'm actually thinking about remapping my caps-lock key...I see more and more people doing that. Not sure if it should be another <enter> or <backspace>
[18:34] <christoffer> backspace is far away but when you write text/code a left hand side <enter> would be nice.
[18:35] <christoffer> and just make sure you never mistype
[18:38] <knome> binding it to the "open right-click/application menu" might be useful
[18:40] <christoffer> yea that's another option...still leaning towards the symmetry of an extra enter key
[18:40] <knome> nah, i don't think one should replicate anything
[18:40] <knome> another good idea is binding it to ctrl+tab (changes tab in firefox and other apps)
[18:41] <christoffer> hmm <alt Gr> might be really good to rebind
[18:41] <christoffer> when writing code
[18:42] <brainwash> don't abuse the devel channel, join -offtopic :)
[18:51] <knome> brainwash, there's only one response to that...
[18:51] <knome> brainwash, please use -offtopic to advertise other channels
[18:51] <knome> ;)
[19:20] <brainwash> anyone familiar with SRU reports? we need one for bug 1222021
[19:21] <brainwash> it's issue #1 in saucy, affecting many many people
[19:22] <brainwash> a patched debian package won't be available anytime soon, so we will have to ship our own version in the meantime (currently available via noskcaj's PPA, link in the report)
[20:59] <elfy> bluesabre: any update on menulibre - if I've gone shout at piskie instead :p
[21:00] <knome> elfy, he said earlier today everything should be in debian in a week, and in ubuntu at the beginning of feb
[21:01] <elfy> oh right ok - missed that
[21:01] <elfy> knome: ty
[21:01] <Unit193> Hopefully two days worth of development until it's ready though.
[21:02] <knome> elfy, you couldn't have missed that; it wasn't on this channel
[21:02] <elfy> oh
[21:02] <elfy> should be in this channel as well then
[21:03] <knome> probably... but that happened in a middle of a different discussion
[21:38] <brainwash> bluesabre, ochosi: the new parole dev version uses the "play" icon as background picture, but it lacks the functionality of a "play" button
[21:38] <brainwash> people might get confused
[21:39] <brainwash> scenario: you watch a video and it ends, you want to watch it again and there is this play icon in the middle of the center.. you press it, just like you would do on youtube and co, but nothing happens
[22:04] <jjfrv8> knome, ping pong
[22:05] <knome> jjfrv8, hello :)
[22:05] <jjfrv8> Hi, a few questions?
[22:05] <knome> always
[22:05] <jjfrv8> about bug 1207493, I see it is marked as "fix released", does that mean it will make it into the SRU next month with no other changes?
[22:06] <knome> yep
[22:06] <knome> well,
[22:06] <knome> there's a problem with that; the SRU is broken
[22:06] <knome> we need to look at it
[22:07] <knome> i will do that when i have time and then adjust the bug as needed
[22:07] <jjfrv8> the problem with the initial page missing the graphics, you mean?
[22:07] <knome> i guess that was it
[22:07] <knome> it's probably a trivial thing to fix
[22:08] <jjfrv8> skellat was stumped on how to fix it last I checked
[22:08] <knome> i guess i know more of that then ;)
[22:08] <jjfrv8> his PPA works but the version in -proposed does not
[22:08] <knome> for me, it looks pretty straightforward (disclaimer: i haven't really looked at the package)
[22:09] <jjfrv8> ok, but if you can't fix it, will it go in the way it is now?
[22:09] <jjfrv8> at least the content would be correct finally
[22:10] <knome> as long as we have done a new upload with the fixed package
[22:10] <knome> yes, even if we didn't fix the graphical glitch, the content will be up-to-date
[22:10] <jjfrv8> I can live with that
[22:11] <jjfrv8> next question: no one has responded to your call on the ML yet but there were two guys who volunteered a while back
[22:11] <jjfrv8> both said they had web design experience
[22:11] <knome> that's barely needed, but if they are willing to help with the docs, that's good
[22:11] <jjfrv8> do you think I should contact them directly to ask if they're interested in helping out with the tour and about stuff
[22:11] <knome> slickymaster replied on the channel and will be working on the mugshot documentation
[22:12] <knome> i've already talked with bluesabre about it as well
[22:12] <knome> i also asked david to send a mail to the list to notify he's starting with that
[22:12] <knome> contacting directly is good
[22:12] <knome> if you do that, you can optionally CC me
[22:13] <jjfrv8> will do
[22:13] <jjfrv8> is whiskermenu still under consideration to replace alacarte by default?
[22:13] <knome> whiskermenu is not a replacement for alacarte
[22:14] <knome> menulibre is a replacement for alacarte, and as long as it is ready and landed before the feature freeze, we will be using it
[22:14] <knome> whiskermenu is an optional replacement for the applications menu on the panel
[22:14] <jjfrv8> I thought that was alacarte
[22:15] <knome> nope :)
[22:15] <knome> alacarte is a menu editor like menulibre
[22:15] <knome> so that's why whiskermenu is somewhat tied to the panel layout change
[22:15] <jjfrv8> but is it going to stay optional?
[22:16] <knome> that's to be decided
[22:17] <jjfrv8> reason I ask is that there are a lot of references to the applications menu in the current docs
[22:17] <knome> if it's optional, then we need no changes in the documentation whatsoever
[22:17] <jjfrv8> right
[22:17] <knome> yes, i'm aware of that...
[22:17] <knome> fortunately, we are using the xubuntu icon to denote the menu
[22:17] <knome> so we don't need to change the wording in *too* many places
[22:18] <jjfrv8> yup
[22:18] <knome> as long as the categories are the same, and we use the xubuntu icon as the menu button
[22:18] <knome> but the reality is
[22:18] <knome> we will most probably change the panel layout anyway
[22:18] <knome> with that being done, i think updating relevant parts to say whiskermenu is easy enough
[22:18] <jjfrv8> any idea when it will be firmed up?
[22:19] <knome> once ochosi gets a final proposal up, and we've discussed/voted on it on a team meeting
[22:19] <knome> we probably should try to do that at the latest in two weeks
[22:19] <jjfrv8> sounds good
[22:20] <jjfrv8> is there a trusty branch yet for the docs to start working on?
[22:20] <knome> yep
[22:20] <knome> it's what is now lp:xubuntu-docs
[22:20] <jjfrv8> I'll go ahead and pull that then
[22:22] <jjfrv8> that's it for now, thanks
[22:22] <knome> np :(
[22:22] <knome> :) that is
[22:22] <knome> tell me if you have any problems with anything
[22:22] <jjfrv8> sure
[22:22] <knome> or if you are concerned about running out of time to prepare docs for something, poke me and i'll try to hurry things up
[22:23] <jjfrv8> k
[23:10] <bluesabre> ochosi, brainwash: so much scrollback, any luck with the gtk3.10 menuitems?
[23:10] <bluesabre> it also affects Numix
[23:18] <brainwash> bluesabre: the gtk3 indicator menus look fine now (greybird git)
[23:18] <brainwash> in trusty
[23:18] <bluesabre> great!
[23:18] <brainwash> just some strange icon highlighting issue remaining
[23:19] <brainwash> but the recent changes to fix the indicator menus broke the drop down menus in lightdm-gtk-greeter :)
[23:20] <brainwash> "broke" might be the wrong word, the fix added text shadows
[23:21] <brainwash> bluesabre: did you read my concern regarding parole's background picture?
[23:21] <brainwash> the "non functional" play button
[23:27] <ochosi> brainwash: it's just a logo in parole. it was never intended as a playbutton (and it would be a useless duplication anyway
[23:28] <brainwash> ochosi: but it looks like a play button..
[23:28] <ochosi> i haven't tested the gtk3 indicators
[23:29] <brainwash> ok, I'll try to debug this
[23:30] <brainwash> I really want to get the gtk3 indicator menus completely fixed, do you think that the icon highlight effect can be solved differently?
[23:31] <ochosi> not sure yet, i was away until now, so no new insights ;)
[23:31] <brainwash> the unity themes do not use these dim/highlight effects
[23:32] <ochosi> it's possible that the indicators don't work in the greeter anymore because their loading mechanism was changed
[23:32] <ochosi> so basically the changes of the indicator-plugin would have to be ported to the greeter, i suppose (if they're not working now)
[23:32] <ochosi> not sure i wanna open that pandora's box
[23:33] <ochosi> still have lots of other things to fix in the greeter, e.g. fix wallpaper drawing in gtk2
[23:33] <brainwash> mmh, true.. they removed the dbus activation and switched to upstart magic
[23:38] <brainwash> ochosi: mmh, I got some more stuff to share, but I better don't bother you with more greeter glitches :)
[23:40] <brainwash> so I'll try to fix it myself and provide patches or report it eventually
[23:41] <ochosi> :}
[23:41] <ochosi> well my todo-list for the greeter looks like this:
[23:41] <ochosi> 1) fix gtk2 wallpapers (so that we're in release-ready state again)
[23:41] <ochosi> 2) finish language-menu patch
[23:42] <ochosi> and anyway, according to someone on the ML, the greeter's biggest glitch is that its "ascetics"(sic!) look "ugy"(sic!)
[23:42] <brainwash> -> 2) really show "en_US" or just "en"?
[23:43] <ochosi> "en_US" ofc
[23:43] <brainwash> ok
[23:43] <ochosi> it already works, it just doesn't get updated properly when switching users via the combobox
[23:44] <brainwash> yeah, nothing bad about the full string "en_US", but usually it gets shortened to just "en" (gnome-screensaver,..)
[23:48] <knome> do you think there is any reason why we couldn't just show the two first letters?
[23:49] <knome> (eg. drop the countrycode)
[23:49] <ochosi> knome: well since the menu offers all of those choices, it seems weird not to show them
[23:50] <ochosi> e.g. if you only have english installed, you still get 4 or 5 options
[23:50] <knome> sure... but isn't the menu also able to show the selected one?
[23:50] <ochosi> and in case you care about using en_AU for some reason, it'd be quite the usability loss to cut those two chars
[23:50] <knome> i rather see "fi" than "fi_FI"
[23:50] <ochosi> the menu always shows the selected one
[23:50] <ochosi> yeah, but the default is "fi"
[23:50] <ochosi> or "en"
[23:50] <knome> (because, being honest, there is no "fi" outside "FI")
[23:51] <knome> aha
[23:51] <ochosi> only variants get country-codes
[23:51] <ochosi> so normally, it'd say "en" or "de" or "fi", unless you use a specific variant
[23:51] <ochosi> and then i think it's ok to show them
[23:51] <knome> i'm still not sure why the countrycode is really important
[23:51] <ochosi> currency and units
[23:51] <ochosi> (for the more international languages)
[23:52] <knome> right, but it's a selection you pretty much do once
[23:52] <knome> and then forget about it
[23:52] <knome> example: jackson uses en_AU, and keeps on using it.
[23:52] <knome> also, what if all of my locale strings aren't fi?
[23:52] <knome> or, en
[23:53] <knome> don't seem to have that setup on the laptop, but on my desktop, the main locale is en, but some units are fi
[23:53] <knome> the greeter is failing to show me that anyway!
[23:53] <knome> (and no, i don't think that's a completely rare setup, many people want the interface in english but units in other language)
[23:54] <knome> so basically, that item is only able to show, what, LANG/LANGUAGE
[23:54] <knome> so your argument on "being able to know which units are in use" is faulty
[23:54] <knome> because that tells nothing about the units
[23:55] <knome> feel free to prove me wrong.
[23:55] <brainwash> how about a vote in the next meeting
[23:56] <knome> i don't think we need a vote, we need a sane choice
[23:56] <bluesabre> sane choice is whatever the language code is specified as
[23:56] <brainwash> both are valid options
[23:57] <bluesabre> we should take what we get and pass it along
[23:57] <bluesabre> en_US -> en_US
[23:57] <bluesabre> (my opinion anyway) ;)
[23:58] <knome> bluesabre, from my pov, the problem with that thinking is that it implies more things than it possibly may be
[23:58] <knome> in my desktop, example using en_GB would imply i'm using british units
[23:58] <brainwash> make it configurable :P
[23:58] <knome> even if in fact, i'm using finnish
[23:59] <knome> bluesabre, what can we learn from this?
[23:59] <knome> bluesabre, we can be sure the shown string can only imply the *language*
[23:59] <bluesabre> knome does not like his native toungue
[23:59] <knome> do you need an example why?


[07:08] <alfredo> hola
 @wxl [<wxl> well, i mean there's plenty of people that still use them. it's still comm …], oh i see. so it just me. anyway its easy to install/uninstall. no complains. :)
[10:14] <jack123> Hello, I am wondering why Firefox is not updating to the latest version using the software updater in Lubuntu 18.04. It is still on version 69.02 Firefox which is 2 versions behind.
[10:15] <ubuking> jack123 what operating System are you using?
[10:16] <jack123> Lubuntu version 18.04 LTS
[10:16] <ubuking> tHANKS
[10:16] <ubuking> thats right
[10:16] <ubuking> 69.0.2 for Lubuntu 18.04.3
[10:17] <ubuking> latest Firefox stable is, 69.0.3
[10:17] <ubuking> it
[10:17] <ubuking> it is in ubuntu 19.10
[10:17] <jack123> Yes but there has been version 69.03 and now 70.0 released by Mozilla and the version 69.02 is buggy. Firefox made a fix in 69.03 specifically for Linux
[10:17] <ubuking> not packaged until now
[10:17] <ubuking> Maybe until Friday ?
[10:17] <ubuking> or saturday
[10:18] <jack123> Ok....thanks. Not trying to be critical but why so long since 69.03 has been out for awhile.
[10:18] <ubuking> not sure :(
[10:18] <ubuking> How Comes that you are using LXQT ?:)
[10:18] <ubuking> or LXDE
[10:19] <jack123> It is one that has worked well
[10:19] <ubuking> cool :)
[10:19] <ubuking> Hardware is old or ?
[10:20] <jack123> It is older yes but not terrible
[10:20] <ubuking> hehe  mine too
[10:20] <ubuking> I have Intel E8400 4 GB
[10:20] <ubuking> Memory
[10:20] <ubuking> and SSD :)
[10:21] <jack123> Ok. Well I guess I will just wait until Fri/Sat to see if things get updated. Very frustrating that it is taking so long to update FF. Used to be relatively quick
[10:22] <ubuking> you can Change to
[10:22] <ubuking> Chrome :)
[10:22] <ubuking> hehe like me did  before :D
[10:22] <ubuking> its nicer
[10:22] <jack123> Yuck
 Is anyone running 18.04 on a RPi ?
 not recently but I had been for a while
 What made you change, and to what?
 the rpi died :P
 that's why it changed 😔
 @teward001 [the rpi died :P], out of ordeR?
 it got shorted out by a power surge a while ago yes
 otherwise was running fine
 HERE complain abt low voltage
 but still on 16.04
[22:01] <eamonn> Is there anywhere I can drop a script so that it gets run after/on desktop init? Or a way to configure a systemd service as such? I just wanna run `xmodmap ~/.Xmodmap` whenever I log in.
[22:02] <wxl> yeah just use the autostart system.. systemd would be appropriate iff you wanted to start on system start rather than login
 how to autostart system wxl ?
[22:05] <wxl> https://manual.lubuntu.me/stable/3/3.2/3.2.13/session_settings.html?highlight=autostart
[22:17] <eamonn> Thanks, I'll check that out
[22:18] <eamonn> Oh man, I could probably make this autostart my whole dev env on login. Cool!
[22:18] <wxl> yep
[22:19] <wxl> you could make a script to do the whole thing and just autostart that or you could autostart individual components
 @wxl [<wxl> https://manual.lubuntu.me/stable/3/3.2/3.2.13/session_settings.html?highli …], noted, ~/.config/autostart/*
[22:20] <wxl> @ctisme if you want to be more general about it https://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.html
[22:26] <chieta> afaik on the current release on the wiki lubuntu will replace openbox functionality... CMIIW?
[22:27] <wxl> that is probably a better question for the dev channel
[22:27] <wxl> !devel
[22:28] <chieta> Noted, wxl
[22:29] <chieta> as far as the replacement is more superior then it's a good news :D


[00:44] -queuebot:#ubuntu-release- Unapproved: gtksourceview2 (zesty-proposed/universe) [2.10.5-2ubuntu2 => 2.10.5-2ubuntu3] (ubuntu-desktop)
[02:33] <handsome_feng> Hi, Could someone there can help check the two update request: bug: #1677432 bug: #1677157 Thank you!
[04:56] -queuebot:#ubuntu-release- Unapproved: ubuntukylin-theme (zesty-proposed/universe) [1.6.2 => 1.7.0] (ubuntukylin)
[05:01] -queuebot:#ubuntu-release- Unapproved: ubuntukylin-wallpapers (zesty-proposed/universe) [16.10.1 => 17.04.0] (ubuntukylin)
[05:04] -queuebot:#ubuntu-release- Unapproved: rpi.gpio (zesty-proposed/universe) [0.6.3-1 => 0.6.3-1ubuntu1] (no packageset)
[05:04] -queuebot:#ubuntu-release- Unapproved: accepted rpi.gpio [source] (zesty-proposed) [0.6.3-1ubuntu1]
[05:08] -queuebot:#ubuntu-release- New binary: rpi.gpio [arm64] (zesty-proposed/universe) [0.6.3-1ubuntu1] (no packageset)
[05:09] -queuebot:#ubuntu-release- New binary: rpi.gpio [armhf] (zesty-proposed/universe) [0.6.3-1ubuntu1] (no packageset)
[05:43] -queuebot:#ubuntu-release- Unapproved: squid3 (zesty-proposed/main) [3.5.23-1ubuntu1 => 3.5.23-1ubuntu2] (ubuntu-server)
[07:43] <Saviq> hi all, could someone please approve the packages coming from https://bileto.ubuntu.com/#/ticket/2626? thanks!
[07:54] -queuebot:#ubuntu-release- Unapproved: imagemagick (zesty-proposed/main) [8:<IP_ADDRESS>+dfsg-2ubuntu1 => 8:<IP_ADDRESS>+dfsg-2ubuntu1] (desktop-core, ubuntu-server)
[07:58] -queuebot:#ubuntu-release- Unapproved: kdevelop (zesty-proposed/universe) [4:5.0.4-0ubuntu1 => 4:5.0.4-0ubuntu2] (kubuntu, ubuntu-desktop)
[08:04] -queuebot:#ubuntu-release- Unapproved: mate-control-center (zesty-proposed/universe) [1.18.0-0ubuntu1 => 1.18.0-0ubuntu2] (ubuntu-mate, ubuntukylin)
[08:06] <tjaalton> Laney: added debug notes on #1671799
[08:06] <tjaalton> bug #1671799
[08:13] <LocutusOfBorg> hello release team, feature request: is it possible when receiving the "your package is stuck in proposed since foo days", to have also the changelog of the latest upload attached? this way I can understand if this was a transition, a no change rebuild, or a bad merge
[08:32] -queuebot:#ubuntu-release- Unapproved: brisk-menu (zesty-proposed/universe) [0.3.0-0ubuntu1 => 0.3.5-0ubuntu1] (ubuntu-mate)
[08:38] -queuebot:#ubuntu-release- Unapproved: mate-themes (zesty-proposed/universe) [3.22.7-0ubuntu1 => 3.22.8-0ubuntu1] (ubuntu-mate)
[08:41] <LocutusOfBorg> (I can open a bug if needed, just I don't know where that service is located)
[09:28] -queuebot:#ubuntu-release- Unapproved: unity-greeter-session-broadcast (zesty-proposed/main) [0.1+14.10.20140601-0ubuntu4 => 0.1+14.10.20140601-0ubuntu5] (ubuntu-desktop)
[09:46] -queuebot:#ubuntu-release- Unapproved: aethercast (zesty-proposed/universe) [0.1+16.10.20160808-0ubuntu4 => 0.1+17.04.20170328.1-0ubuntu1] (no packageset) (sync)
[09:46] -queuebot:#ubuntu-release- Unapproved: accepted aethercast [sync] (zesty-proposed) [0.1+17.04.20170328.1-0ubuntu1]
[10:50] -queuebot:#ubuntu-release- Unapproved: bluez (xenial-proposed/main) [5.37-0ubuntu5 => 5.37-0ubuntu6] (ubuntu-desktop)
[11:24] -queuebot:#ubuntu-release- New: accepted ldns [amd64] (zesty-proposed) [1.7.0-1ubuntu1]
[11:24] -queuebot:#ubuntu-release- New: accepted ldns [armhf] (zesty-proposed) [1.7.0-1ubuntu1]
[11:24] -queuebot:#ubuntu-release- New: accepted ldns [ppc64el] (zesty-proposed) [1.7.0-1ubuntu1]
[11:24] -queuebot:#ubuntu-release- New: accepted ldns [arm64] (zesty-proposed) [1.7.0-1ubuntu1]
[11:24] -queuebot:#ubuntu-release- New: accepted ldns [s390x] (zesty-proposed) [1.7.0-1ubuntu1]
[11:24] -queuebot:#ubuntu-release- New: accepted ldns [i386] (zesty-proposed) [1.7.0-1ubuntu1]
[12:08] <cpaelzer> Hi, could one please reject squid3 3.5.23-1ubuntu2 from zesty unapproved queue?
[12:08] <cpaelzer> While technically correct on the work with Debian we spottet some licence things that should be sorted out before.
[12:08] <apw> cpaelzer, looking
[12:10] -queuebot:#ubuntu-release- Unapproved: rejected squid3 [source] (zesty-proposed) [3.5.23-1ubuntu2]
[12:14] <cpaelzer> thanks apw
[13:24] <smoser> hey. can someone NACK a cloud-init upload for me ?
[13:24] <smoser> the one in the queue is missing a bug reference.
[13:25] <Saviq> hi release team, any chance of approving the packages synced from this silo https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2626/+packages?field.series_filter=zesty ?
[13:25] -queuebot:#ubuntu-release- Unapproved: parallax (zesty-proposed/universe) [1.0.1-2 => 1.0.1-3] (no packageset) (sync)
[13:27] -queuebot:#ubuntu-release- Unapproved: accepted parallax [sync] (zesty-proposed) [1.0.1-3]
[14:22] <apw> smoser: looking
[14:31] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (zesty-proposed) [0.7.9-82-g0e2030ca-0ubuntu1]
[14:47] -queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-77-g4a2b2f87-0ubuntu1 => 0.7.9-82-g0e2030ca-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
[14:58] -queuebot:#ubuntu-release- Unapproved: vulkan (zesty-proposed/universe) [<IP_ADDRESS>+dfsg1-1 => <IP_ADDRESS>+dfsg1-1ubuntu1] (no packageset)
[14:59] -queuebot:#ubuntu-release- Unapproved: accepted vulkan [source] (zesty-proposed) [<IP_ADDRESS>+dfsg1-1ubuntu1]
[15:02] -queuebot:#ubuntu-release- Unapproved: python-xkcd (zesty-proposed/universe) [2.4.1-1 => 2.4.2-1] (no packageset) (sync)
[15:02] -queuebot:#ubuntu-release- Unapproved: accepted python-xkcd [sync] (zesty-proposed) [2.4.2-1]
[15:13] <rbasak> Do I need an FFe to drop something from a seed?
[15:13] <rbasak> bug 1667195
[15:13] -queuebot:#ubuntu-release- Unapproved: lttng-modules (xenial-proposed/universe) [2.8.0-1ubuntu1~16.04.1 => 2.8.0-1ubuntu1~16.04.2] (no packageset)
[15:13] <rbasak> If unsure, can a release team member give me an ack on it at least please?
[15:21] <rbasak> 16:15 <jbicha> my opinion is that since it wasn't shipped but only listed as "supported" that it wouldn't need a FFe
[15:21] <rbasak> 16:15 <rbasak> Good point. It wouldn't make any changes to an image.
[15:21] <rbasak> So I did it.
[15:22] <flexiondotorg> Ubuntu MATE would like to run a testathon this weekend, we've got a few packages pending, could someone eye them over please?
[15:22] <flexiondotorg> brisk-menu, mate-menu, mate-control-center, ubuntu-mate-artwork, mate-themes
[15:50] <maclin> hi, release team,  Ubuntu Kylin image building was failed yesterday. The build log shows there was a conflict of dependencies:   "libmagickwand-6.q16-2 : Depends: imagemagick-6-common (= 8:<IP_ADDRESS>+dfsg-1ubuntu3) but 8:<IP_ADDRESS>+dfsg-2ubuntu1 is to be installed"  Could someone help to check the problem?
[15:55] <maclin> This package was not directly depend by our packages. There were only some "oxideqt" related packages update  yesterday, but we can't confirm the relation.  So I am afraid other image building may face this problem today?
[16:02] <maclin> If this is a problem only affecting Ubuntu Kylin, could someone help to confirm it?  thanks :)
[16:03] <nacc> maclin: it might be from the transition as we finally got imagemagick migrated yesterday and there was a ABI bump
[16:08] <nacc> maclin: ah i see, i think we need to do some NBS cleanup too
[16:10] <maclin> nacc,  is there anything we have to change?
[16:11] <nacc> maclin: no i think it's my cleanup to resolve
[16:12] <maclin> nacc, I got it, thanks:)
[16:15] <nacc> maclin: can you paste me a link to the build log?
[16:15] <maclin> https://launchpadlibrarian.net/313471764/buildlog_ubuntu_zesty_amd64_ubuntukylin_BUILDING.txt.gz
[16:16] <nacc> maclin: thanks!
[16:16] <nacc> maclin: probably need to some no change rebuilds as well
[16:16] <nacc> maclin: will work on that now
[16:21] <maclin> nacc: ok, we will wait for the new image tomorrow, thanks:)
[16:27] <nacc> slangasek: confused by something: http://people.canonical.com/~ubuntu-archive/nbs.html says sunflow and usbview depend on specific older binaries, but looking at those packages, i don't see the deps? What am I missig?
[16:48] <infinity> nacc: Probably dependencies on virtual packages.
[16:49] <infinity> nacc: Also, it's referring to build-depends, not depends.
[16:50] <nacc> infinity: "Packages which depend on NBS packages" refers to build depends?
[16:50] <infinity> nacc: And, indeed, sunflow build-depends on libmagickcore-6.q16-2-extra
[16:50] <infinity> nacc: It does, if you read the whole line. :P
[16:51] <bdmurray> infinity: I typed the wrong i package name and released initramfs-tools for trusty. Can anything be done?
[16:51] <infinity> nacc: The last column helpfully tells you which arch's binaries have the issue.  When it's build-depends instead of binary, it says "build".
[16:51] <nacc> infinity: ah i see it now!
[16:51] <nacc> infinity: sorry for the noise, will fix
[16:52] <bdmurray> infinity: its verified but has linux-lts autopkgtest failures
[16:52] <infinity> bdmurray: Like, JUST now?
[16:52] <bdmurray> infinity: yes JUST now
[16:52] <infinity> Yeah, we can just delete it.  It hasn't published yet.
[16:52] <infinity> And then copy the old version back.
[16:52] <infinity> I'll sort that.
[16:53] <bdmurray> Great, thanks.
[16:53] <infinity> bdmurray: Although, the linux autopkgtest failures, do they really have anything to do with initramfs-tools?  They're not exactly known for their stability.
[16:54] <bdmurray> infinity: I didn't look at them so can't say
[16:54] <bdmurray> they certainly do look flakey
[16:54] <infinity> I'm more inclined to say "hey kernel people, fix your tests" than hold off the SRU indefinitely. :P
[16:54] <infinity> I'll spot check a few of these before I do the delete and copy thing.
[16:55] <infinity> Oh, in fact, these are failing for entirely other reasons.
[16:55] <infinity> So, yeah.
[16:56] <infinity> bdmurray: Not reverting.
[16:56] <bdmurray> infinity: okay
[16:56] <infinity> bdmurray: I'll have some chats at the kernel sprint next week about how we can get a green baseline on all these kernel tests.
[16:56] <bdmurray> where's that?
[16:56] <infinity> (And then maybe actually implement the results of said chats)
[16:56] <infinity> Londres.
[17:03] -queuebot:#ubuntu-release- Unapproved: libdrm (zesty-proposed/main) [2.4.75-2 => 2.4.76-1] (core, xorg) (sync)
[17:04] <infinity> nacc: Were/are you driving this imagemagick transition?
[17:05] <nacc> infinity: yeah i suppose so
[17:05] <nacc> infinity: by virtue of keeping it migrating recently
[17:06] <infinity> nacc: Pretty sure that https://bugs.launchpad.net/ubuntu/+source/jxrlib/+bug/1666687 isn't going to get resolved by release, so that Recommends should drop to a Suggests, IMO.
[17:06] <nacc> infinity: ack, on my list too
[17:06] <nacc> infinity: i plan on uploading those three after breakfast :)
[17:07] <infinity> nacc: Arguably, it should be a suggests anyway, and the code should actually TEST for the binary and suggest installing libjxr-tools, rather than just throwing ugly errors.
[17:07] <nacc> infinity: ack
[17:11] <infinity> nacc: Or, to be more verbose about my reasoning there, the fact that it throws hard errors makes it a Depends, per policy, not Recommends.  If it didn't throw errors, it would be a Suggests, because one would only call it a Recommends if a major/common use-case of imagemagick was converting that specific file type, which seems like quite a stretch to argue.
[17:11] <infinity> nacc: But, for now, an incorrect Suggests will do, unless you have the time to also fix the hard error.
[17:12] <nacc> infinity: yep, understood -- i think there are a number of things like this in the imagemagick code. I will take a look but probably just drop it to a suggests for  now
[17:12]  * infinity nods.
[17:16] <infinity> Also, the docs depending on some random JS library is kinda fun.  But if that's a hard dep for a good reason, we can just blacklist the docs from main.
[17:16] <infinity> nacc: ^-- Lemme know on that score, and I'll adjust the seeds if appropriate.
[17:20] <nacc> infinity: will do
[17:21] -queuebot:#ubuntu-release- Unapproved: usbview (zesty-proposed/universe) [2.0-21-g6fe2f4f-1 => 2.0-21-g6fe2f4f-1ubuntu1] (no packageset)
[17:21] <slangasek> infinity: tzdata required->important as discussed
[17:21] -queuebot:#ubuntu-release- Unapproved: accepted usbview [source] (zesty-proposed) [2.0-21-g6fe2f4f-1ubuntu1]
[17:22] <infinity> slangasek: Fun, fnu.
[17:22] <infinity> fnu!
[17:24] <infinity> slangasek: Thanks for changing the archive as well this time. ;)
[17:25] -queuebot:#ubuntu-release- Unapproved: sunflow (zesty-proposed/universe) [0.07.2.svn396+dfsg-14 => 0.07.2.svn396+dfsg-14ubuntu1] (no packageset)
[17:26] -queuebot:#ubuntu-release- Unapproved: accepted sunflow [source] (zesty-proposed) [0.07.2.svn396+dfsg-14ubuntu1]
[17:39] <nacc> infinity: can you reject the imagemagick in the unapproved queue? then i'll upload the same version with the fixed component mismatch
[17:39] <flexiondotorg> infinity Any chance I can ask for some reviews of zesty uploads?
[17:40] <flexiondotorg> Would like to get the last bits in for an Ubuntu MATE testathon this weekend.
[17:40] <flexiondotorg> ubuntu-mate-artwork, brisk-menu, mate-menu, mate-control-center, mate-themes
[17:51] <infinity> nacc: Oh just upload ubuntu2 with your changes, so you're not mangling history?
[17:51] <infinity> nacc: s/Oh/Or/
[17:51] <nacc> infinity: yeah i'm happy to do that too
[17:51] <nacc> infinity: will upload shortly then
[17:51] <infinity> nacc: Yeah. Just grab the one from the queue and build on it.
[17:52] <infinity> flexiondotorg: The queue will be empty by my EOD, either by accepting or rejecting.
[17:52] <infinity> flexiondotorg: History went wonky in mate-menu.  Expected?
[17:53] <flexiondotorg> infinity I'm checking mate-menu...
[17:53] <infinity> flexiondotorg: http://launchpadlibrarian.net/313265955/mate-menu_17.04.2-0ubuntu2_17.04.3-0ubuntu1.diff.gz
[17:54] <nacc> infinity: oh i see the docs reference, sorry -- will examine it now
[17:54] <flexiondotorg> infinity wtf. Reject that, their is a glitch in the matrix.  (response) "And how did that make you feel?"
[17:57] <infinity> "I'm not sure what you mean by 'Just upload the friggin package, can you elaborate?"
[17:57] <infinity> s/package/package'/
[18:00] <nacc> infinity: it would appear the doc dep is a real one, rather than using the version bundled with the source so i think a blacklist may be appropriate
[18:00] <nacc> infinity: would you like a bug filed to refer to?
[18:03] <wxl> infinity: s/\(package\)/\1'/ would have been shorter ;)
[18:03] <infinity> nacc: Nah, I'll just refer to the MIR.
[18:03] <nacc> infinity: ok, thanks
[18:03] <infinity> wxl: My regular expressions in IRC are usually written for readability, not length.
[18:04] <wxl> infinity: well you get points for that :)
[18:04] <flexiondotorg> infinity Thanks for the reject, correct upload for mate-menu incoming.
[18:04] -queuebot:#ubuntu-release- Unapproved: mate-menu (zesty-proposed/universe) [17.04.2-0ubuntu2 => 17.04.3-0ubuntu1] (ubuntu-mate)
[18:14] -queuebot:#ubuntu-release- Unapproved: imagemagick (zesty-proposed/main) [8:<IP_ADDRESS>+dfsg-2ubuntu1 => 8:<IP_ADDRESS>+dfsg-2ubuntu2] (desktop-core, ubuntu-server)
[18:37] <infinity> nacc: Err, why did you change the previous changelog entry?
[18:38] <infinity> nacc: Or was it a lie that it was locutusofborg's upload, and you're correcting that? :P
[18:39] <nacc> infinity: um, strange
[18:39] <nacc> so i also uploaded 8:<IP_ADDRESS>+dfsg-2ubuntu1 to the queue
[18:39] <infinity> nacc: Not the one I downloaded from the queue...
[18:39] <infinity> Oh!
[18:39] <infinity> You both uploaded one.
[18:39] <nacc> infinity: right, i didn't realize it had been superseded
[18:40] <nacc> well 'superseded' :)
[18:40] <nacc> infinity: totally my fault, as i thought it was my upload that i was looking for the ubuntu1
[18:40] <infinity> Okay, to be fair, they're basically identical.
[18:40] <nacc> yeah, contentfully the same
[18:40] <nacc> infinity: you can reject and i can refresh from the queue
[18:40] <infinity> nacc: Nah, all good.
[18:40] <nacc> infinity: ok, sorry about that!
[18:40] <infinity> nacc: Your upload beat his.  So, if it wasn't a freeze, you would have won. :P
[18:41] <nacc> heh
[18:41] <infinity> nacc: queue fetch just got me the newer one.
[18:41] <nacc> also, mine closes the bug filed for the FFe :)
[18:41] <infinity> nacc: Not that it'll make a big difference (since the bug has no imagemagick task), but his bug ref with the intentional parse error is more correct for referencing a bug, rather than closing it.
[18:41] <infinity> nacc: (The MIR bug, not the FFe bug)
[18:43] -queuebot:#ubuntu-release- Unapproved: rejected imagemagick [source] (zesty-proposed) [8:<IP_ADDRESS>+dfsg-2ubuntu1]
[18:43] -queuebot:#ubuntu-release- Unapproved: accepted imagemagick [source] (zesty-proposed) [8:<IP_ADDRESS>+dfsg-2ubuntu2]
[18:43] -queuebot:#ubuntu-release- Unapproved: rejected imagemagick [source] (zesty-proposed) [8:<IP_ADDRESS>+dfsg-2ubuntu1]
[18:44] <nacc> infinity: ah yes, sorry about that!
[18:51] <nacc> infinity: regardless, sorry for the noise with all that
[19:15] <tjaalton> slangasek, infinity: Laney seems absent, so could you check if my analysis of the onscripter test failures are enough to let xserver enter zesty https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1671799/comments/37
[19:18] <infinity> tjaalton: Any idea what's up with the yorick/s390x regression?
[19:19] <tjaalton> infinity: no.. not the most important platform for X anyway
[19:19] <infinity> No, but regressions still point to bugs somewhere.
[19:20] <tjaalton> I don't know how to debug that one
[19:20] <infinity> xnox: ^
[19:23] <infinity> tjaalton: As for your onscripter analysis, it sort of creates more questions than it answers.
[19:23] <infinity> tjaalton: I was hoping it was a simple "qemu sucks, and we're detecting CPU features that get masked" bug, but your indication that it works from other shells in the same VM throws that out.
[19:27] <infinity> error: ("/usr/lib/powerpc64le-linux-gnu/ada/adalib/gmpada/gnu_multiple_precision.ali" is obsolete and read-only)
[19:27] <infinity> doko: ^-- Are we supposed to be doing gnat transitions of some sort, and did we fail to do one properly?
[19:29] <wxl> new xorg would be nice
[19:31] <tjaalton> infinity: yeah it's a weird issue.. real hw is fine, lxc is fine
[19:34] <Saviq> hi release team, can we please have the packages from this silo https://bileto.ubuntu.com/#/ticket/2626 approved to zesty?
[19:34] <infinity> tjaalton: On a hunch, does "kvm -cpu host" work?  I mean, that might confirm my original claim, though makes your findings even more bizarre. :P
[19:38] <infinity> Saviq: I'll have a look at that bunch after lunch.
[19:40] <Saviq> infinity, thanks
[19:42] <tjaalton> infinity: what exactly do you mean? running just that does run qemu but doesn't boot anything
[19:43] <tjaalton> oh you mean running the qemu image with host cpu model?
[19:43] <infinity> tjaalton: I mean using "-cpu host" as the cpu spec for the test, rather than whatever the default is.
[19:44] <tjaalton> got it, trying..
[19:59] <tjaalton> infinity: heh, I get a segfault instead
[19:59] <tjaalton> (EE) Floating point exception at address 0x7fdb9a9e2d19
[19:59] <tjaalton> this is from swrast_dri.so
[20:00] <tjaalton> so now Xvfb crashes
[20:03] <tjaalton> I'll try again after dist-upgrade..
[20:04] <tjaalton> had to use another instance that has working network
[20:29] <tjaalton> right, fails the same way after upgrade, so -cpu host didn't change anything
[20:51] -queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-77-g4a2b2f87-0ubuntu1 => 0.7.9-87-gd23543eb-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)
[21:21] <nacc> infinity: i think the imagemagick packages that are NBS can all be removed now
[21:22] <nacc> and looks like once the tests finish the component-mismatch should go away
[21:31] -queuebot:#ubuntu-release- Unapproved: accepted qtmir-gles [sync] (zesty-proposed) [0.5.1+17.04.20170328-0ubuntu1]
[21:31] -queuebot:#ubuntu-release- Unapproved: accepted qtubuntu-gles [sync] (zesty-proposed) [0.64+17.04.20170328.1-0ubuntu1]
[21:31] -queuebot:#ubuntu-release- Unapproved: accepted unity8 [sync] (zesty-proposed) [8.15+17.04.20170328.3-0ubuntu1]
[21:31] -queuebot:#ubuntu-release- Unapproved: accepted qtmir [sync] (zesty-proposed) [0.5.1+17.04.20170328-0ubuntu1]
[21:31] -queuebot:#ubuntu-release- Unapproved: accepted qtubuntu [sync] (zesty-proposed) [0.64+17.04.20170328.1-0ubuntu1]
[21:32] <slangasek> infinity, apw: so I want to give you both a heads-up regarding a discussion cyphermox and I are having about how to make available a grub that enforces kernel signatures, before we're ready to turn that on for the distro as a whole
[21:32] -queuebot:#ubuntu-release- Unapproved: accepted libertine [sync] (zesty-proposed) [1.7.1+17.04.20170328-0ubuntu1]
[21:32] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-app-launch [sync] (zesty-proposed) [0.11+17.04.20170328-0ubuntu1]
[21:33] <slangasek> infinity, apw: we /could/ be ready to turn it on for the distro as a whole, except that I think we need some upgrade logic around detecting systems where the currently-configured kernel is not signed and warn instead of leaving the system unbootable. :P
[21:33] <apw> slangasek: sounds like a great idea
[21:34] <infinity> s/upgrade logic/preinst logic/
[21:34] <infinity> So, how are we going to prevent people from shooting themselves in the foot by removing linux-signed?
[21:35] <infinity> Other than going back in time and agreeing that linux-signed is a silly idea, and linux-image should just be signed by default. :P
[21:35] <slangasek> infinity, apw: so of the many options on the table, we think that the most straightforward option that gives us what we need - namely, *a* signed (with Ubuntu key) grub.efi that doesn't allow fallback to unsigned kernels, that we can put in a gadget snap for a customer (doesn't need to be in a grub-signed .deb at the moment) is to just build two grub.efi, one with the linux module, one without,
[21:35] <slangasek> and let them be accepted into the archive
[21:36] <infinity> slangasek: Sure, seems reasonable.  Put them both in the efi tarball, sign both, but have grub-signed pick up the non-enforcing one.
[21:36] <infinity> slangasek: Which, if you name the new one something else, happens by default.
[21:36] <slangasek> UX for the one without the 'linux' grub module is probably going to be a weird 'missing module' message rather than a 'security failed' message, but we mostly don't care for the present use case, because this is for a product that's SB-enforcing and anybody managing to point grub at an unsigned kernel can keep both pieces anyway
[21:37] <apw> infinity: could we use a provides: kernel-signed to ensure you have at least one bootable kernel
[21:37] <slangasek> and the policy of this new binary isn't special, it's the next step along our path of turning on enforcement, we're just not ready to do it yet
[21:37] <infinity> slangasek: So, I might be unfamiliar with the process here, but why remove a module?  Isn't there just an "enforce or not" option at build time?
[21:37] <slangasek> so I don't feel like we're signing an artifact we shouldn't be
[21:38] <slangasek> infinity: we would have to build the grub source twice with different patches; there's no build time flag in the patchset
[21:38] <slangasek> oh
[21:38] <slangasek> shoot
[21:38] <infinity> You're building it twice anyway, no?
[21:38] <slangasek> infinity: the idea would be we wouldn't need to build it twice, only run the build-efi-image script twice
[21:38] <cyphermox> not twice for efi.
[21:38] <infinity> Or just linking it twice, I guess.  But same-same, it's just machine time.
[21:39] <cyphermox> slangasek: not even run build-efi-image twice, I can just add a grub-mkimage.
[21:39] <slangasek> right
[21:39] <cyphermox> it's very nearly a one-liner.
[21:39] <slangasek> infinity: setting aside the implementation details of how this gets done in the grub package - no objections to having two signed .efi binaries for grub starting now-ish in zesty?
[21:40] <infinity> slangasek: Nope.
[21:40] <slangasek> and yes, the fact that you can currently get your signed kernel removed on a SB system and be none the wiser is something we also need to tackle
[21:40] <infinity> slangasek: Perfectly fine with that idea, so long as the one we're shipping in grub-signed doesn't regress in any way.
[21:40] <slangasek> ack
[21:41] <cyphermox> infinity: the grub$arch.efi we ship would be exactly as it was, untouched. I'd add a "enfore_grubx64.efi" or something like that
[21:41] <infinity> apw: Depending on kernels works really poorly, which is why we almost always try to avoid it.
[21:41] <infinity> cyphermox: *nod*
[21:41] <infinity> cyphermox: Well, surely not exactly, as it sounds like there's patches involved here.
[21:42] <cyphermox> infinity: nah, I think I can circumvent that
[21:42] <cyphermox> ie. removing the 'linux' module breaks the fallback to loading unsigned.
[21:42] <infinity> Maybe it would help if I knew what "remove the linux module" actually means.
[21:42] <cyphermox> (if it works)
[21:42] <cyphermox> grub is modular, every command (or nearly) is a "module"
[21:42] <infinity> Sure, I know that.
[21:43] <cyphermox> obviously, this is what I'm about to test
[21:43] <infinity> But the implication here is that the efi module requires SB chaining, while the linux module doesn't, and it's that fallback we currently rely on?
[21:43] <apw> infinity: would it serve us well to switch linux-image to install signed
[21:43] <infinity> apw: Yes, that's what we should have done years ago.
[21:43] <infinity> apw: But we never got around to implementing our discussions.
[21:44] <apw> on everything, now in advance
[21:44] <cyphermox> infinity: yeah, currently if linuxefi fails to validate the signature, it silently goes to start the kernel using the 'linux' command.
[21:44] <infinity> apw: Basically, we should do what Ben was doing, where the buildds upload foo-unsigned.deb, and then we package it as foo.deb.
[21:44] <apw> so if they upgrade it gets reinstalled
[21:44] <infinity> apw: The inverse of the current status quo.
[21:44] <apw> we can likely retrofit that
[21:44] <apw> discussion for now+4?
[21:45] <infinity> apw: Sure, we can.  The only problem is that old kernels won't have it.  So, if we intend to enforce in old stables, we'll still need to think of a way forward.  But maybe just a preinst guard and grub that just refuses to upgrade unless you're on a kernel that's packaged the New Way would suffice, cause once you're on that track, accidentally removing your signed kernel is kinda a "duh, don't do that" thing, instead of an honest mistake.
[21:46] <infinity> apw: Discussion for the sprint, but probably we should carve out some pair programming time to *implement* at the sprint.  Given we've discussed this literally for years, more talk won't help us much. ;)
[21:47] <infinity> apw: Err, of course, the immediate path forward, if we were in a hurry, is much simpler.  Given we rely on meta for upgrades anyway (derp), we should just make linux-image point to linux-signed.
[21:48] <infinity> apw: It's not like anyone will get an upgrade to a new packaging method without meta installed anyway, so...
[21:49] <infinity> I really wish I could understant the paranoia that originally led to us thinking there was a reason to have an unsigned option.
[21:49] <infinity> Other than for testing, I suppose.
[21:49] <infinity> apw: So, yeah.  linux-image-flavour Depends linux-signed-image-flavour, done.
[21:49] <infinity> apw: Much simpler than reworking all the packaging. :P
[21:49] <infinity> (Throw an [amd64] in there)
[21:51] <infinity> apw: Belt and bracers that with linux-image-$abi-flavour Depends linux-signed-image-$abi-flavour, and even people who install individual linux-image packages can't screw themselves.
[21:51] <infinity> The latter would actually remove the need for the former.
[21:51] <infinity> And the linux-signed metas could just go away.
[21:51] <infinity> Oh.  But that has a chicken and egg issue where you (incorrectly) build-depend on linux-image to create linux-signed. ;)
[21:51] <infinity> Meh.
[21:52] <infinity> apw: Okay, shutting up.  Put it on the agenda for next week please.
[21:52] <slangasek> cyphermox: hurr, not building in the 'linux' module means we also don't have the 'linux' command; makes our grub.cfgs a bit broken
[21:52] <cyphermox> doh.
[21:52] <infinity> alias linux linuxefi?
[21:52] <infinity> Doubt that grub.cfg allows aliases, mind you. :P
[21:52] <slangasek> that sounds like something requiring a change to grub.cfg also :)
[21:53] <slangasek> we *can* work around that by changing grub.cfg
[21:53] <slangasek> but that means it's not just a drop-in replacement
[21:53] <infinity> Well, that could go in grub.d, if it was a thing.
[21:53] <slangasek> ... not on ubuntu-core
[21:53] <apw> infinity: yep
[21:53] <infinity> Heh.  Right.
[21:57] <infinity> cyphermox: BUILD_PACKAGES += grub-efi-enforce, REAL_PACKAGES += grub-efi-enforce, and add configure and build stamps, applying patchset in the latter?
[21:59] <infinity> Perhaps after copying the source around, so you can (a) avoid parallelism issues with applying a patch mid-build and (b) rm -rf the patched source when done with it.
[22:02] <cyphermox> or I could maybe cheat and really alias linux to linuxefi in the binary itself.
[22:08] <slangasek> infinity: so then you're build-time-applying patches in a 3.0 (quilt) package, WIN :)
[22:26] <infinity> slangasek: Hey, what could possibly go wrong?
[22:56] -queuebot:#ubuntu-release- Unapproved: clutter-gst-3.0 (zesty-proposed/main) [3.0.22-1 => 3.0.24-1] (kubuntu, ubuntu-desktop) (sync)
[23:08] -queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (yakkety-proposed) [0.5.0+git1.656f8865-5ubuntu7.3]
[23:11] -queuebot:#ubuntu-release- Unapproved: ubuntu-docs (zesty-proposed/main) [17.04.2 => 17.04.3] (personal-gunnarhj, ubuntu-desktop)
[23:12] -queuebot:#ubuntu-release- Unapproved: accepted multipath-tools [source] (xenial-proposed) [0.5.0+git1.656f8865-5ubuntu2.5]
[23:21] -queuebot:#ubuntu-release- Unapproved: accepted dnsmasq [source] (yakkety-proposed) [2.76-4ubuntu0.1]
[23:22] -queuebot:#ubuntu-release- Unapproved: accepted dnsmasq [source] (xenial-proposed) [2.75-1ubuntu<IP_ADDRESS>]
[23:29] -queuebot:#ubuntu-release- Unapproved: accepted sane-backends [source] (yakkety-proposed) [1.0.25+git20150528-1ubuntu<IP_ADDRESS>]
[23:31] -queuebot:#ubuntu-release- Unapproved: accepted sane-backends [source] (xenial-proposed) [1.0.25+git20150528-1ubuntu<IP_ADDRESS>]
[23:35] -queuebot:#ubuntu-release- Unapproved: accepted rabbitmq-server [source] (yakkety-proposed) [3.5.7-1ubuntu<IP_ADDRESS>]
[23:36] -queuebot:#ubuntu-release- Unapproved: accepted rabbitmq-server [source] (xenial-proposed) [3.5.7-1ubuntu<IP_ADDRESS>]
[23:38] -queuebot:#ubuntu-release- Unapproved: imagemagick (zesty-proposed/main) [8:<IP_ADDRESS>+dfsg-2ubuntu2 => 8:<IP_ADDRESS>+dfsg-2ubuntu3] (desktop-core, ubuntu-server)
[23:39] <nacc> infinity: urgh, sorry, i missed one more component mismatch for the libjxr-tools change (another binary package from src:imagemagick). Just uploaded ubuntu3 --^
[23:48] -queuebot:#ubuntu-release- Unapproved: asterisk (xenial-proposed/universe) [1:13.1.0~dfsg-1.1ubuntu4 => 1:13.1.0~dfsg-1.1ubuntu4.1] (no packageset)
[23:56] -queuebot:#ubuntu-release- Unapproved: accepted nfs-utils [source] (yakkety-proposed) [1:1.2.8-9.2ubuntu1.1]
[23:57] -queuebot:#ubuntu-release- Unapproved: accepted nfs-utils [source] (xenial-proposed) [1:1.2.8-9ubuntu12.1]


[11:23] <CIA-33> ubiquity: cjwatson * r3363 ubiquity/ (11 files in 2 dirs):
[11:23] <CIA-33> ubiquity: Upgrade to debhelper v7. There's still some fairly significant ugliness
[11:23] <CIA-33> ubiquity: in our debian/rules, but this is a slight improvement.
[11:26] <CIA-33> ubiquity: cjwatson * r3364 ubiquity/.bzrignore: ignore debian/ubiquity-frontend-debconf
[14:02] <CIA-33> ubiquity: mterry * r3365 trunk/ (5 files in 5 dirs): kde: merge translated timezones from lp:~mterry/ubiquity/translated-timezones
[14:03] <dpm> mterry: thanks for the detailed e-mail with the info on the translated timezones!
[14:04] <mterry> dpm, np :)
[14:05] <mterry> dpm, sorry the translations are all over the place, but that's just how it ended up :)
[14:14] <CIA-33> ubiquity: mterry * r3366 trunk/ (debian/changelog gui/glade/ubiquity.glade): gtk: remove separators from dialogs
[14:30] <dpm> mterry: np :)
[15:24] <StevenK> mterry: Did you see bug 412832?
[15:24] <mterry> StevenK, hrm, no.  looking
[15:26] <mterry> StevenK, from what I can see, it never had an icon.  This bug just showed up because UNR displays like it does..  Interesting.  Easy enough to assign one
[15:33] <CIA-33> ubiquity: mterry * r3367 trunk/ (3 files in 2 dirs): add icons for oem-config-prepare menu entries
[16:22] <CIA-33> ubiquity: mterry * r3368 trunk/ (24 files in 5 dirs): gtk: convert glade to GtkBuilder
[16:40] <superm1> mterry, by making change r3367, keep in mind that the "prepare shipping to end user icon" will remain on the installed system after oem-config runs still
[16:41] <mterry> superm1, why would my change make that happen?
[16:41] <superm1> mterry, well at least in standard ubuntu now it would.  it wasn't showing up in the menus before i dont think
[16:42] <mterry> superm1, eww, you mean that oem-config-prepare is somehow sticking around?  that's a separate bug from showing an icon, but also should be fixed
[16:42] <superm1> mterry, yeah that's what i was getting at, just reminding that since oem-config and ubiquity remain installed...
[16:43] <mterry> superm1, how was this handled in the past?
[16:44] <superm1> mterry, in the past oem-config has just remained installed since it didn't have any way to clean up itself
[16:44] <mterry> superm1, but then the menu items would have also stuck around before.  that doesn't seem right
[16:44] <superm1> mterry, previously i thought the menu item was not put in the system menu, it was just on the 'oem' user's desktop
[16:45] <mterry> superm1, hmm, maybe?  I don't remember seeing that code when I merged the codebases, but I'll check how oem-config used those .desktop files
[16:46] <superm1> hmm. maybe i'm wrong though.  'Categories=GTK;System;Settings;' in the old ./desktop/oem-config-prepare-gtk.desktop.in
[16:48] <superm1> so my mistake, the behavior should be the same.  nonetheless, it cleaning itself up is the proper solution :)
[16:49] <mterry> superm1, so you're saying you think the current behavior is the same as before?  i.e. we aren't regressing?
[16:49] <superm1> mterry, i'll need to look at a fresh 9.04 install to be sure.
[16:55] <mterry> superm1, hrm, it looks like old oem-config and ubiquity do the same thing.  but it doesn't make sense to me.  oem-config installs a .desktop file to a private location, then copies it the system during postinst.  then when the oem user is created, it copies it over to the oem user's desktop.  i just don't know why it bothers copying it to the system so everyone sees it
[16:56] <superm1> mterry, i'd guess it's in a bunch of place to ensure that it's seen no matter what
[16:57] <cjwatson> the reason I never arranged for oem-config to be removed is that I was being cautious about the possibility that oem-config might need to be rerun afterwards
[16:57] <cjwatson> but it may be that that was more useful during debugging than in reality
[16:57] <cjwatson> it's probably ok not to put the .desktop file in the menus
[16:59] <mterry> cjwatson, hmm, OK.  The change to not install into the main menus is probably not disruptive.  i can do that
[18:06] <superm1> mterry, i should be able to convert most of the mythbuntu stuff over to gtkbuilder too over the weekend, i just need to make sure i dont fully break glade because we have third parties that ship mythbuntu control centre plugins in glade currently
[18:15] <mterry> superm1, there's no rush
[18:15] <mterry> superm1, but cool, thx
[23:42] <CIA-33> os-prober: cjwatson * r235 ubuntu/ (9 files in 7 dirs): merge from Debian 1.30
[23:47] <CIA-33> os-prober: cjwatson * r236 ubuntu/debian/changelog: releasing version 1.30ubuntu1