[06:54] <pitti> Good morning
[06:55] <pitti> superm1, hyperair: it's not the keys themselves that aren't working, it's the missing support for backligths in X (that wasn't converted to devkit-power)
[06:55] <pitti> superm1, hyperair: http://lists.freedesktop.org/archives/devkit-devel/2009-July/000268.html FYI
[06:55] <TheMuso> Morning pitti .
[06:55] <pitti> hey TheMuso
[06:55] <TheMuso> pitti: I'm attempting to debug that pulse mute volume issue, but haven't got very ar with it yet.
[06:56] <TheMuso> far
[06:57] <pitti> TheMuso: didn't you say it was a local problem only?
[06:57] <pitti> I still get it with every boot, haven't dug into that one so far
[06:57] <pitti> I plan to reinstall for alpha-3, so I don't care much
[06:59] <TheMuso> pitti: Well I did a fresh install ona machine today, and instaleld pulse from the PPA. THings seem to be muted until you play some sound, then adjust the volume. Not exactly sure whats going on yet, so I need to do more testing.
[07:37] <didrocks> morning o/
[07:37] <pitti> hey didrocks
[07:37] <didrocks> guten Tag pitti
[08:08] <hyperair> pitti: ah i thought it would be something of that kind =\
[08:08] <hyperair> pitti: thanks for telling
[08:09] <hyperair> pitti: but gpm seems pretty capable of changing the screen brightness when the power supply is disconnected or connected
[08:14] <pitti> hyperair: that sounds like a gpm bug then
[08:14] <pitti> if it just doesn't work with AC attached
[08:39] <pitti> bonjour seb128!
[08:39] <seb128> pitti, guten tag!
[08:40] <chrisccoulson> good morning everyone
[08:41] <pitti> hey chrisccoulson
[08:42] <didrocks> hey seb128 and chrisccoulson
[08:43] <pitti> seb128: FYI, I'll look at the two gpm sponsoring things
[08:45] <chrisccoulson> hey pitti and didrocks
[08:45] <chrisccoulson> did everyone have a good weekend?
[08:45] <pitti> quiet, but relaxing
[08:45] <chrisccoulson> that's what i like ;)
[08:46] <seb128> hello chrisccoulson didrocks
[08:46] <seb128> didrocks, thanks for the clutter upload
[08:46] <seb128> pitti, ok thanks
[08:46] <chrisccoulson> hey seb128
[08:47] <didrocks> seb128: y/w
[08:53] <pitti> seb128: taking libxklavier sponsoring, too (also affects gdm, will update my patch there in bzr)
[08:53] <seb128> pitti, ok
[08:53] <seb128> I didn't notice there was sponsoring yet, I'm looking at yet another gtk update
[08:54] <pitti> seb128: btw, new gtk working mostly fine here; only regression is the gtimelog panel applet, it's black now
[08:54] <seb128> wait for the new version and tell me if that's still an issue
[08:54] <seb128> we got reports about awn and lotus notes being broken
[08:54] <seb128> awn should be easy to test I had no clue lotus notes was still being used
[08:55] <pitti> chrisccoulson: re bug 398579, could you please send this to debian as well? Would be bad if they decide for a different -dev name
[08:55] <pitti> (sponsoring now)
[08:57] <chrisccoulson> pitti - no problem. did you see dholbach's comment though?
[08:57] <pitti> chrisccoulson: yes, just answered
[08:57] <chrisccoulson> it is missing a conflicts/replaces
[08:57] <chrisccoulson> ah
[08:57] <pitti> and having one too much :)
[08:59] <chrisccoulson> heh. i probably should have tried installing the -dev package too when testing it;)
[08:59] <pitti> chrisccoulson: it shouldn't have an actual effect
[08:59] <pitti> just looks weird
[09:00] <chrisccoulson> ah, ok
[09:00] <pitti> quite a few rdepends, so that needs a library transition
[09:00] <pitti> I'll fix gdm in bzr
[09:00] <chrisccoulson> i did the update quite late last night when i realised the g-c-c update needed it too
[09:00] <pitti> thanks for that
[09:01] <chrisccoulson> pitti - if there's no rush, i can help out fixing some of the rdepends, although it'll have to be when i finish work
[09:01] <pitti> uploaded; I'll beat it through NEW once it built
[09:01] <pitti> chrisccoulson: no rush; the gnome stuff will just fix itself with the next gnome update round
[09:01] <pitti> no need to do extra uploads for those, IMHO
[09:02] <chrisccoulson> that's ok then :)
[09:09] <seb128> new GNOME update round being for today
[09:09] <seb128> if people are back from gdcs to roll tarballs ;-)
[09:10] <crevette__> hey hey seb128
[09:10] <seb128> lut crevette___________________
[09:10] <crevette__> nto too much sunburns ?
[09:10] <crevette__> yeah, I should clean my ______
[09:10] <seb128> no, the weather was quite cloudy there
[09:12]  * pitti takes bug 390437
[09:13] <crevette__> seb128, I be happy to help doing some packaging tonight and tomorrow, if my work load duty is not too high
[09:13] <pitti> james_w: stop making package updates so much fun with bzr-bd! this is supopsed to be _work_ :)
[09:13] <seb128> crevette: cool
[09:14] <crevette__> it's been a long time I didn't do some ....
[09:14] <seb128> pitti, any clue about bug #398253?
[09:14] <pitti> seb128: haven't seen that yet
[09:14] <seb128> "** (gdm-binary:10980): WARNING ** : Failed to acquire org.gnome.DisplayManager: Connection ":1.23" is not allowed to own the service "org.gnome.DisplayManager" due to security policies in the configuration file"
[09:14] <pitti> huh, sounds like a wrong d-bus conf?
[09:15] <seb128> could be, but you said you had an issue similar to that when you first tried on karmic
[09:15] <seb128> I was wondering if you remember if you changed something to fix the issue
[09:15] <pitti> seb128: I rebooted, AFAIK
[09:16] <seb128> ok
[09:16] <crevette> pitti, did you had a look to the new policykit?
[09:17] <pitti> crevette: which kind of "look" are you interested in?
[09:17] <pitti> crevette: I plan to do some more migration, yes
[09:17] <pitti> I prepared a consolekit upload
[09:17] <pitti> but that needs to be done in lockstep with gnome-session and gdm, etc.
[09:17] <pitti> didn't manage to finish that last Friday
[09:17] <pitti> so far only dk-disks is using it, AFAIR
[09:18] <seb128> crevette, it's in karmic for a while now
[09:18] <crevette> pitti, from a patch I seen I seen a lot of code is removed in applications that use policy, so all the check is done within policykit now
[09:20] <pitti> Laney: gnome-menus merge> ugh, what a patch :)
[09:20] <pitti> crevette: exactly
[09:20] <pitti> apps don't need to talk to the auth agent directly any more
[09:26] <pitti> chrisccoulson: xklavier NEWed
[09:27] <chrisccoulson> pitti - thanks:)
[09:27]  * chrisccoulson hugs pitti
[09:29]  * pitti hugs back chrisccoulson
[09:30] <JonDoe297> :)
[09:33] <pitti> Laney: hm, with your gnome-menus, "Add/Remove" moved into the "Others.." submenu; does that need to be fixed in gnome-menus or in gnome-app-install?
[09:34] <pitti> Laney: perhaps in debian/patches/09_app_install_entry.patch?
[10:00] <huats> morning everyone !
[10:01] <coolbhavi> hi huats
[10:01] <huats> coolbhavi: hey
[10:04] <Laney> pitti: let me look
[10:04]  * Laney boots up pc
[10:04] <pitti> Laney: (sponsoring bug updated as well)
[10:04] <Laney> got the mail, thanks
[10:05] <seb128> lut huats
[10:05] <seb128> Laney, nothing like telepathy IRC before stating the computer ;-)
[10:05] <seb128> starting
[10:06] <Laney> I wish! (got a Macbook as my laptop)
[10:06] <seb128> ah ok ;-)
[10:07] <huats> seb128: o/
[10:07] <huats> seb128: so how was GCDS ?
[10:12] <Laney> huh
[10:13] <Laney> guess I need to test gnome-menus with a new user eh
[10:15] <seb128> huats, very good!
[10:16] <huats> seb128: and the ice cream contest ? do you participate ?
[10:17] <seb128> huats, no, I'm not crazy enough for that ;-)
[10:17] <huats> :)
[10:17] <pitti> yay, finally a working gdm keyboard selector
[10:17] <huats> (you were talking of icecreams before leaving so I guessed...)
[10:18] <crevette> pitti, one question, the keyboard layout in console since few days, I guess this is a know problem?
[10:18] <pitti> crevette: "... is wrong"?
[10:18] <crevette> ah yeah :)
[10:18] <pitti> crevette: yes, cjwatson mentioned that it's known-broken
[10:18] <pitti> nothing to do with gdm, though
[10:18] <Laney> ...
[10:19] <Laney> didn't add 09_app_install_menu to series
[10:19]  * Laney runs
[10:19] <crevette> yeah I know this is not related, but as you spoke about keybd
[10:19] <seb128> go quilt go
[10:19] <crevette> :)
[10:19] <Laney> indeed
[10:19]  * pitti wonders how many hours he spent on this gdm thing by now
[10:19]  * seb128 hugs pitti for the outstanding gdm work
[10:19] <crevette> seb128 is evil
[10:19]  * seb128 kicks crevette
[10:19] <seb128> no I'm not
[10:19] <pitti> seb128: bug 395324 is still unnerving, though
[10:20] <pitti> except that one, it's working pretty well now
[10:20] <seb128> pitti, it's mostly cosmetic though, did you try to catch the #gdm guys about it?
[10:20] <pitti> seb128: not yet, just spoke to mclasen last week
[10:20] <seb128> pitti, another issue is that it doesn't let you to log out if you use autologin
[10:20] <crevette> I had the same dialog appearing for empathy when I ended a session
[10:20] <seb128> right, I did read that, mclasen is not one of the gdm guys though
[10:20] <pitti> seb128: right, it doesn't fall back to timed login after logout, right?
[10:20] <seb128> he did some fixing for fedora but that's about it
[10:21] <seb128> pitti, indeed
[10:21]  * pitti sighs
[10:21] <seb128> pitti, the issue could be a gnome-session one
[10:21] <seb128> pitti, chriscoulson might be a good person to ping about that
[10:21] <seb128> he has been looking at gnome-session for a while
[10:22] <crevette> did seb128 updated to the latest gdm ?
[10:22] <crevette> :)
[10:22] <pitti> we do have the latest gdm
[10:22] <pitti> plus some three git cherrypicks
[10:22] <crevette> I mean, perhaps it was just kicked of its session
[10:23] <huats> hello pitti and crevette
[10:23] <crevette> salut huats
[10:24] <pitti> bonjour huats, comment vas-tu?
[10:27] <huats> pitti: very good ! since I am on holidays tonight... but I am sorry I can't say that in german :)
[10:27] <asac> chrisccoulson: hi ;)
[10:27] <chrisccoulson> hi
[10:28] <chrisccoulson> just saw your e-mail
[10:28] <asac> chrisccoulson: i commented on the bug
[10:28] <chrisccoulson> i've not seen that yet
[10:28] <asac> chrisccoulson: the --remove-all isnt redundant
[10:28] <asac> its there to workaround alternative bugs
[10:28] <asac> e.g. if you --remove the last one and dont do a --remove-all, the next --install will not get auto selected
[10:29] <chrisccoulson> ah, ok. i didn't realise that
[10:29] <asac> aka the user ends up with nothing
[10:29] <seb128> re
[10:29] <seb128> ok, so the new gtk doesn't solve the csw issues reported
[10:29] <asac> chrisccoulson: so please put the code back in and lets fix the return code ;)
[10:29] <asac> chrisccoulson: and please request a merge ;)
[10:29] <pitti> hey chrisccoulson
[10:29] <asac> chrisccoulson: isnt the bzr branch mentioned in control?
[10:29] <asac> if so we should add it there i guess
[10:30] <chrisccoulson> asac - no problem. i couldnt find any other packages which do this though (other than xulrunner), so i thought it was ok ;)
[10:30] <asac> chrisccoulson: do what? --remove-all?
[10:30] <chrisccoulson> asac - there is a bzr branch mentioned, but it is out of date
[10:30] <asac> really?
[10:30] <asac> let me check
[10:30] <chrisccoulson> yeah, i couldn't find any other package that did the --remove-all
[10:31] <asac> lp:~gnash/gnash/ubuntu
[10:31] <asac> chrisccoulson: yeah. but try it
[10:31] <asac> chrisccoulson: maybe its fixed in the meantime
[10:31] <chrisccoulson> i just did a "grep update-alternatives "\-\-remove\-all" /var/lib/dpkg/info" on my system, and the only other package that did it was xulrunner
[10:32] <chrisccoulson> hey pitti
[10:32] <asac> chrisccoulson: right. i think for most alternatives user never remove all providers
[10:32] <asac> so they dont end up there
[10:32] <chrisccoulson> ah, ok
[10:32] <asac> chrisccoulson: lp:~gnash/gnash/ubuntu
[10:33] <asac> is that the one mentioned?
[10:33] <chrisccoulson> asac - thanks. the one in debian/control is ubuntu-core-dev it think, which looks quite out of date
[10:33] <asac> yeah
[10:33] <chrisccoulson> also, doesn't update-alternatives --remove-all also fail with an error when there are no providers left?
[10:33] <asac> chrisccoulson: ok. i will drop that
[10:34] <asac> chrisccoulson: right .... you can do  || true
[10:34] <asac> chrisccoulson: i dont think that it fails
[10:34] <asac> chrisccoulson: unless the alternative doesnt exist at all
[10:35] <chrisccoulson> hmmm, i'll try it again. but i'm sure when i tried it on saturday, update-alternatives --remove-all failed with an error after removing the last provider with udpate-alternatives --remove
[10:37] <asac> chrisccoulson: seems that changed then. so either the underlying bug fixed or we are doomed
[10:37] <asac> ;)
[10:37] <chrisccoulson> asac - i'll take another look at it anyway, but it will have to be when i finish work
[10:37] <asac> chrisccoulson: sure thanks.
[10:38]  * pitti pokes bugzilla.gnome.org, wake up!
[10:38] <asac> hehe
[10:38] <chrisccoulson> pitti - perhaps it wants us to stop reporting bugs ;)
[10:39] <asac> chrisccoulson: so assuming its really fixes, we probably also need to change flashplugin-nonfree
[10:39] <asac> and swfdec
[10:40] <chrisccoulson> asac - probably, if it does the same thing then it will likely fail on removal in karmic at the moment anyway
[10:40] <chrisccoulson> i'll take a look at it in gnash first though
[10:40] <asac> thx
[10:40] <chrisccoulson> pitti - is bugzilla not working for you then? i can get on to it from here
[10:40] <asac> chrisccoulson: please use RELEASE 0.0-0...1 to ubuntu/karmic as the commit message for the release commits ;)
[10:41] <asac> thanks
[10:41] <asac> check out bzr log
[10:41] <chrisccoulson> no problem
[10:42] <pitti> chrisccoulson: seems to work again now
[10:43] <asac> chrisccoulson: you can commit directly to ~gnash team now
[10:43] <chrisccoulson> asac - thanks:)
[10:54] <crevette> seb128, bug related to csw should bet tagged with csw in whiteboard field in bugzilla
[10:55] <seb128> crevette, thanks but there is no way to set the whiteboard on the bug filing page is it?
[10:55] <seb128> crevette, ie I need to file the bug and then edit it
[10:55] <crevette> ah there is not?
[10:55]  * crevette pretend to file a bug
[10:56] <crevette> ah ture
[10:56] <crevette> true
[10:56] <seb128> grrrr
[10:57] <seb128> crevette, I get mid-air collisions now thanks to you, no need to jump on new bugs while I'm editing those and adding details ...
[11:18] <seb128> Laney, can tomboy be synced now?
[11:18] <seb128> Laney, do you want to do the 0.15.3 update? ;-)
[11:18] <Laney> seb128: yes from experimental. I didn't request as there are no changews yet
[11:19] <Laney> it's on my list ;)
[11:19] <seb128> Laney, also we need somebody to do a sru for the current 0.14 in jaunty, want to work on that one too?
[11:19] <Laney> yeah I was talking to lool about that
[11:19] <Laney> you want to sru 0.14.2?
[11:19] <seb128> yes
[11:19] <seb128> I just need to get pitti convinced ;-)
[11:20] <seb128> or 0.14.3 rather now
[11:20] <Laney> pff
[11:20] <Laney> I wish they'd update their homepage
[11:21] <laxmi> hello
[11:22] <Laney> seb128: do you have a script to watch ftp or something?
[11:22] <laxmi> r u listening me?
[11:22] <seb128> laxmi, hi, no
[11:22] <seb128> Laney, I'm subscribed to the ftp mailing list
[11:22] <Laney> oh
[11:22] <laxmi> I am facing a problem
[11:22] <Laney> didn't know it existed
[11:22] <seb128> laxmi, try #ubuntu
[11:22] <seb128> Laney, we also have http://people.ubuntu.com/~seb128/versions.html
[11:23] <Laney> good point
[11:23] <seb128> but it's not tracking stable
[11:23] <Laney> got it on the list anyways
[11:23] <Laney> just fighting with gnome-menus
[11:23] <Laney> somehow gnome-app-install doesn't get enabled
[11:29] <seb128> Laney, it's in applications.menu
[11:29] <Laney> seb128: I see it if I edit the menu
[11:29] <Laney> but it's disabled and if I enable it it just gets unset again
[11:29] <seb128> does it work on a stock config?
[11:30] <Laney> this is a new user
[11:31] <seb128> and it's not displayed by default?
[11:31] <Laney> no
[11:31] <seb128> weird
[11:31] <Laney> probably because it's being disabled for some reason
[11:31] <seb128> you applied 09_app_install_entry.patch?
[11:31] <Laney> yes
[11:31] <seb128> btw no need to merge the old ubuntu changelog entries
[11:32] <seb128> better to clean those they take space for no real benefit
[11:32] <Laney> alright
[11:32] <Laney> some people like to see them for merges
[11:33] <seb128> I don't see the point
[11:33] <seb128> especially for desktop updates where we copy the NEWS
[11:33] <seb128> it tends to be lot of extra text for no real benefit
[11:34] <Laney> I've looked at the changelog to see when/why changes were done before
[11:34] <Laney> or even who so you can ask the changer
[11:35] <Laney> LP does hold this information most of the time though
[11:35] <seb128> all the time I would say
[11:35] <seb128> and we summarize changes in the merge changelog entry
[11:35] <seb128> I tend to put references there or in the patch comment
[11:38] <Laney> the problem is when the merge changelogs are not as detailed
[11:38] <Laney> but it's nto a big deal
[11:40] <Laney> grr
[11:40] <Laney> does empathy have privacy settings? getting spammed now
[11:43] <pitti> seb128: FYI, I'm currently building polkit-1-ified gnome-{session,panel},gdm, consolekit; any objections against those?
[11:43] <pitti> i. e. would you rather wait until they are committed upstream?
[11:43] <pitti> (either way, I want them locally to test them)
[11:43] <seb128> pitti, not at all
[11:43] <seb128> go go go
[11:44]  * pitti moves the crack-o-meter up another notch
[11:44] <pitti> I like the polkit-1 patches
[11:44] <Nafallo> pitti: ...and crack
[11:44] <Nafallo> :-)
[11:44] <pitti>  gnome-session/gsm-consolekit.c |  612 ++++-------------------------------------
[11:44] <pitti>  3 files changed, 62 insertions(+), 570 deletions(-)
[11:45] <seb128> ;-)
[11:45] <chrisccoulson> pitti - the gnome-session / consolekit migration causes some wierd side-effects though doesn't it?
[11:45] <pitti> gdm is even better
[11:45] <pitti>  gui/simple-greeter/gdm-greeter-login-window.c |  237 --------------------------
[11:45] <pitti>  3 files changed, 4 insertions(+), 263 deletions(-)
[11:45] <pitti> chrisccoulson: yes, that's why the gnome-session one hasn't been sent upstream yet
[11:46] <Nafallo> oooh. is that the annoying dialog getting removed? :-)
[11:46] <pitti> Nafallo: which one?
[11:46] <pitti> (no, it's not meant to remove dialogs)
[11:46] <Nafallo> pitti: the one after the login
[11:46] <chrisccoulson> pitti - do you know if anyone is working on changing the consolekit API this cycle?
[11:46] <pitti> Nafallo: not the "cannot save session greeter blabla" thing
[11:46] <Nafallo> pitti: that one! :-)
[11:46] <pitti> chrisccoulson: I don't know
[11:46] <pitti> Nafallo: bug 395324, still needs looking into
[11:47] <Nafallo> pitti: think I'm subbed, and therefor saw you taking ownership ;-)
[11:47] <Nafallo> I think that's the one issue I have on the EeePC 701 4GB at the moment :-)
[11:48] <james_w> chrisccoulson: http://mail.gnome.org/archives/gdm-list/2009-June/msg00007.html <- that one?
[11:48] <chrisccoulson> james_w - yeah, thats the one
[11:48] <chrisccoulson> i was just wondering if anyone was working on that yet
[11:48] <james_w> mclasen would be the one to ask I get
[11:48] <james_w> guess
[11:49] <chrisccoulson> ah, ok. thanks
[11:49] <chrisccoulson> pitti - do you know what that dialog appears for yet?
[11:50] <chrisccoulson> it's displayed by metacity isn't it?
[11:50] <pitti> chrisccoulson: no, I still need to learn how session management works, and what goes wrong there
[11:50] <pitti> apparently the greeter doesn't properly register with the session
[11:51] <chrisccoulson> yeah, i don't understand what it means yet. the dialog is actually displayed by metacity, so i'm unsure of what it has to do with session management
[11:51] <chrisccoulson> it might be worth having a look at the metacity code though
[11:51] <pitti> oh, that's not gnome-session?
[11:51] <chrisccoulson> no, it seems the dialog is displayed be metacity. i noticed it when i was debugging another metacity issue last week
[11:51]  * pitti tests new PK crack, brb
[11:52] <chrisccoulson> that's why the dialog goes away if you don't start metacity in the greeter session
[11:53] <chrisccoulson> btw, there is still a metacity patch in the sponsor queue i think ;)
[11:54] <Nafallo> seb128: wb
[11:54] <seb128> ok, new gtk uploaded
[11:54] <seb128> re Nafallo
[11:55] <chrisccoulson> pitti - do you know if the greeter already registers with the session manager?
[11:56] <chrisccoulson> looking at the metacity code, it seems that it displays the error for any window not having a sm_client_id
[11:56] <chrisccoulson> so gdm probably needs to call gdk_set_sm_client_id somewhere
[11:56] <Nafallo> seb128: you should get a new computer! one that let's you be on irc at the same time as you dput :-)
[11:57] <seb128> Nafallo, that's rather that I do a full session restart before uploading gtk to make sure it does't break gdm, login, anything
[11:58] <Nafallo> seb128: meh. what's the fun in development version if it doesn't break? :-P
[11:59] <seb128> we have enough people breaking things already ;-)
[11:59] <pitti> chrisccoulson: latest upload of gdm added a patch to do that, but it didn't help
[12:00] <pitti> ugh, so consolekit/gdm work fine now, but restart in panel menu breaks completely
[12:00] <pitti> something to figure out after lunch
[12:00]  * pitti sighs
[12:00] <seb128> pitti, restart what?
[12:00] <pitti> seb128: reboot
[12:00] <seb128> ah the menu item you mean
[12:00] <seb128> weird
[12:01] <asac> seb128: so yelp to webkit migration is not going to happen this cycle, right?
[12:01] <seb128> asac, dunno, they will decide on new components this week
[12:01] <seb128> asac, it's still on the roadmap but I'm not sure they will declare all issues solved
[12:01] <asac> seb128: i mean codewise. is yelp ready for webkit?
[12:02] <seb128> yes, they have a webkit version in git for a while I think
[12:02] <seb128> over a cycle
[12:02] <asac> but not in tarball?
[12:02] <seb128> they just didn't make it official default
[12:02] <asac> maybe we can pull that in?
[12:02] <seb128> no, they just roll tarballs for the official mainstream version
[12:02] <asac> or would you feel bad about such a moveß
[12:02] <asac> ?
[12:02] <seb128> what is the rational to do it?
[12:03] <asac> oh i remember there are a11y
[12:03] <seb128> I would prefer to stay on a version translated, etc
[12:03] <asac> seb128: we want to get rid of as much xulrunner rdepends as possible
[12:03] <seb128> and supported by upstream guys
[12:03] <seb128> let's wait a week
[12:03] <seb128> I want to see how their discussion about webkit for this cycle go
[12:03] <asac> seb128: its here as a todo: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-firefox-3.5
[12:03] <asac> i can make it postponed and add a "port to 1.9.1 entry" instead
[12:04] <asac> its just that i want to finish all the main porting this week so we can swiftly move to 1.9.1
[12:04] <seb128> wait a few days and let's revisit that once GNOME has decided what to do for 2.28
[12:04] <asac> seb128: ok, but for ephy we can kick the epiphany-browser package out and migrate to epiphany-webkit?
[12:04] <seb128> vuntz, ^ any idea about webkit being used by GNOME for 2.28?
[12:05] <seb128> asac, I would like to keep both but we can move it to universe
[12:05] <asac> seb128: well. i wouldnt want to invest much time making it work on 1.9.1
[12:05] <asac> seb128: so if the port is easy we can keep it ... otherwise we can keep it if we keep 1.9 in universe
[12:06] <seb128> let somebody do that if they are interested and drop it if nobody does?
[12:06] <asac> i dont think anyone will do it, but ok
[12:06] <seb128> ie break it when you need and wait for somebody to fix it or not
[12:06] <asac> seb128: point is that if we dont drop it we cant migrate the gecko users to webkit
[12:06] <seb128> well maybe other distros do and we can grab the change ;-)
[12:06] <asac> hehe
[12:06] <seb128> well I'm not sure webkit is ready to be default yet
[12:07] <seb128> ie I need greasemonkey to work
[12:07] <seb128> I need to go for lunch now, bbl, we can continue this discussion after lunch if you want
[12:09] <asac> ok lets wait till we know whats up with webkit
[12:21] <Laney> oh
[12:21] <Laney> doesn't seem like I broke gnome-app-install
[12:21] <Laney> broken in a VM install too
[12:24] <crevette> does anyone noticed problem with volume slider in totem in karmic, the slider doesn't seems to move
[12:25] <crevette> ... but the volume is changed. I wonder if it a side effect of csw
[12:27] <Laney> crevette: weird the popout thing just seems to clise
[12:27] <Laney> close
[12:27] <seb128> works fine here
[12:27] <crevette> Laney, I can't recall the behavior as I back to windows, but it seems broken for me on 2 laptops
[12:28] <crevette> seb128, perhaps latest gtk fixed the issue
[12:28] <Laney> I click on the slider and the widget disappears
[12:28] <Laney> don't know if the volume changes, got the radio on
[12:28] <seb128> I doubt it
[12:28] <seb128> I played with it some days ago to try the "jump to 0" bug fix
[12:28] <seb128> and it was working correctly with 2.17.3 too
[12:29] <crevette> I noticed the behavior yesterday
[12:29] <crevette> and I tested on my professional laptop and got the same problem
[12:29]  * Laney has 2.17.3
[12:29]  * crevette has too
[12:30] <seb128> do you get the same issue in rhythmbox?
[12:30] <Laney> ~laney/+junk/gnome-menus needs a merge
[12:30] <Laney> seb128: no
[12:31] <seb128> weird
[12:31] <seb128> that's the same widget being used
[12:31] <Laney> if I don't let go of the mouse button then I can alter it
[13:17] <chrisccoulson> hey pitti - this dialog that metacity displays for the gdm greeter at the moment will appear for any application which doesn't connect to the session manager, including any non-native application and some proprietary ones. i'm just wondering whether we should disable the dialog completely and just turn it in to a g_warning or something (so it logs an error in xsession-errors)? the dialog was never there before, and it will prob
[13:17] <Laney> "will prob"
[13:17] <chrisccoulson> eg, the dialog always appears when logging it whilst you're running something like xterm
[13:18] <chrisccoulson> looging it -> logging out
[13:19] <Laney> (your line got cut off)
[13:19] <chrisccoulson> ah
[13:19] <chrisccoulson> will probably end up irritating users ;)
[13:19] <chrisccoulson> that was the end of it
[13:19] <Laney> yes, it already irritates me :)
[13:19] <chrisccoulson> me too. i think we should just turn it off ;)
[13:19] <Laney> you should at least be allowed to never see it again
[13:20] <chrisccoulson> yeah, i agree. a dialog that appears every time is overkill
[13:20] <chrisccoulson> if a user is really that bothered about the WM not restoring the window position, they will open a bug report
[13:20] <seb128> right
[13:21] <seb128> you might want to ping vuntz about it too though
[13:22] <chrisccoulson> seb128 - yeah, thanks. i'll wait and see if he responds
[13:22] <seb128> he might still be in gran canaria or travelling back
[13:22] <seb128> I know he said he would take some extra days there
[13:22] <chrisccoulson> ok, no problem
[13:22] <seb128> you might want to apply the change for karmic meanwhile so users don't get annoyed
[13:23] <chrisccoulson> seb128 - yeah, i can look at that. it shouldn't be difficult to do
[13:24] <pitti> chrisccoulson: I agree
[13:24] <pitti> chrisccoulson: especially since "session saving" is a joke anyway in current gnome
[13:25] <chrisccoulson> yeah, definately. and i'm not sure users will care about being notified every time they log out
[13:26] <pitti> *nod*
[13:26] <pitti> so, let's rip it out
[13:27] <chrisccoulson> yeah, i'll look at that. rather than ripping it out completely though, i think i'll just make it log a warning in xsession-errors instead. at least there's still a way to find buggy apps then
[13:27] <seb128> pitti, session saving is not a joke, it works fine when client applications do their job
[13:28] <pitti> seb128: I never ever got my session restored since feisty or so
[13:28] <chrisccoulson> yeah, we should still fix gdm as well though
[13:28] <seb128> pitti, well it's at least asking if you want to save work since jaunty before closing
[13:28] <pitti> right
[13:28] <pitti> but that's not session save/restore
[13:28] <seb128> which is the import part
[13:28] <seb128> important
[13:28] <seb128> right...
[13:29] <seb128> well open applications on a workspace seems to work there
[13:29] <seb128> at least with gedit and some other GNOME things I tried
[13:29] <seb128> the position is not part of the session storing though and applications should handle that
[13:29] <pitti> hm, not with gnome-terminal, empathy, and firefox then
[13:29] <pitti> I always get a clean desktop after logging in
[13:29] <pitti> is that supposed to work?
[13:30] <pitti> I thought that was ripped out from the old gnome-session and never put back in?
[13:30] <chrisccoulson> pitti - it depends whether you've enabled it in gnome-session-properties
[13:30] <seb128> well if you save your session
[13:30] <seb128> ie enable the key to save session at closing or use the save button in the capplet
[13:30] <pitti> oh, that works again?
[13:31] <seb128> since jaunty yes
[13:31] <Laney> does it remember workspaces?
[13:31] <seb128> worked when I tried with gedit
[13:31] <seb128> but many of the issues are buggy softwares
[13:32] <chrisccoulson> Laney - that is probably the responsibility of the WM - which is what this error dialog is about
[13:32] <Laney> alright
[13:32] <Laney> so I expect it not to work for claws and gwibber then ;)
[13:32] <chrisccoulson> the error dialog appears if a client doesn't tell the WM it's sm_client_id (at least that is my understanding of it from the metacity code)
[13:34] <chrisccoulson> thinking about it, the dialog shouldn't display at all unless you want the session saved when you exit, by explicitly enabling session saving
[13:36] <pitti> oh, indeed it restores gome-terminals now; nothing else, though :(
[13:36] <pitti> but that's good to know
[13:36] <chrisccoulson> pitti - if things don't work, then those are application bugs
[13:36] <pitti> right
[13:45] <pitti> ok, seems new polkit stuff works
[13:47] <didrocks> pitti: are you aware of any way to use distutils to make it install every date files in setup.py? I'm considering to write a function with os.walk returning every files…
[13:47] <pitti> didrocks: every date file?
[13:47] <didrocks> data*
[13:47] <pitti> didrocks: DistUtilsExtra.auto should already do that
[13:47] <pitti> didrocks: everything under data/ is copied verbatim
[13:48] <pitti> only data/icons/ are special
[13:48] <kenvandine> pitti, can you make it pick up files in media/ too?
[13:48] <kenvandine> quickly puts stuff in there
[13:48] <pitti> kenvandine: why not just put that into data/?
[13:48] <pitti> I don't want two directories
[13:48] <pitti> since that opens up the possibility of file conflicts
[13:48] <kenvandine> i think rick is getting annoyed i keep suggesting moving directories :)
[13:48] <pitti> data/foo and media/foo would both land in /usr/share/<appname>/foo
[13:48] <kenvandine> i think data makes more sense anyway
[13:48] <didrocks> pitti: pitti ok, thanks (I'm experiencing for quickly itself, not subproject currently) :)
[13:49] <pitti> well *shrug*, data/ is an established norm in GNOME and freedesktop packages, not just in distutils
[13:49] <kenvandine> yup
[13:49] <kenvandine> ok
[13:49] <maxb> This is a bit weird ... mouse-selecting text in xchat is now sending the selection to the X clipboard instead of the X primary selection - is this a "feature" or a bug?
[13:49] <kenvandine> i'll propose a branch moving it to data :)
[13:49] <pitti> you could use data/media/
[13:50] <seb128> maxb, is that specific to xchat?
[13:50] <maxb> So far I've only noticed it there, but that could just be a reflection of my usage pattern
[13:51] <maxb> gnome-terminal seems unaffected
[14:05]  * pitti uploads polkit-1 crack; let hell break loose!
[14:06] <Nafallo> who let pitti loose?
[14:07] <pitti> Nafallo: MUHAHAHA
[14:11]  * kenvandine is scared to update tomorrow :)
[14:12] <chrisccoulson> do it:-|
[14:12] <chrisccoulson> ;)
[14:13] <kenvandine> i'll forget to be scared by tomorrow morning, when i do my daily updates :)
[14:14] <pitti> hey, I was nice and triggered a "needs reboot" stamp
[14:14] <pitti> (you really need it)
[14:21] <kenvandine> morning rickspencer3
[14:21] <rickspencer3> hello kenvandine
[14:23] <pitti> hey rickspencer3
[14:23] <pitti> seb128, chrisccoulson, mvo: ugh, still way to go: https://wiki.ubuntu.com/DesktopTeam/PolicyKitOneMigration
[14:24] <seb128> pitti, your list is weird
[14:24] <pitti> it's checkrdepends policykit karmic
[14:24] <pitti> by and large
[14:24] <seb128> pitti, since when update-notifier uses policykit?
[14:24] <maxb> The weird xchat clipboard vs. primary issue I mentioned seems to have been resolved by gtk+ 2.17.4, ftr
[14:24] <mvo> is there a porting guide?
[14:25] <pitti> Depends: libpolkit2
[14:25] <pitti> seb128: might be libtool fuzz
[14:25] <seb128> pitti, indeed, that's funny I rebuilt it 25 minutes ago to look at GNOME3 things
[14:25] <pitti> mvo: I'll link it
[14:25] <seb128> pitti,
[14:25] <seb128> Depends: [-libatk1.0-0 (>= 1.20.0),-] libc6 (>= 2.4), [-libcairo2 (>= 1.2.4), libdbus-1-3 (>= 1.0.2),-] libdbus-glib-1-2 (>= 0.78), [-libfontconfig1 (>= 2.4.0), libfreetype6 (>= 2.2.1),-] libgconf2-4 (>= 2.23.2), libgdu0 (>= 0.2), libglib2.0-0 (>= 2.16.0), libgtk2.0-0 (>= [-2.17.0),-] {+2.17.3),+} libnotify1 (>= 0.4.5), libnotify1-gtk2.10, [-libpango1.0-0 (>= 1.14.0), libpolkit2 (>= 0.7),-] libx11-6, gconf2 (>= 2.10.1-2), update-notifier-com
[14:25] <seb128> mon (= [-0.85),-] {+0.85ubuntu1),+} python, update-manager, notification-daemon, gksu
[14:26] <seb128> mvo, ^ interested to cut some depends from update-notifier?
[14:26] <mvo> sure!
[14:26] <mvo> always
[14:26] <pitti> right, so probably just a -Wl,--as-needed or so?
[14:26] <pitti> .la files for the lose!
[14:26] <seb128> mvo, do you want me to upload?
[14:26] <seb128> pitti, yes, it's
[14:26] <seb128> +LDFLAGS += -Wl,-z,defs -Wl,-O1 -Wl,--as-needed
[14:26] <mvo> seb128: have you commited to bzr?
[14:26] <mvo> seb128: I may have some other changes pending, let me check first please
[14:27] <seb128> mvo, I've the bzr locally, didn't push yet which is what I'm asking, do you want me to push and upload?
[14:27] <mvo> seb128: just push please and add changelog etc (with UNRELEASED)
[14:27] <seb128> mvo, there is no pending change
[14:27] <seb128> ok
[14:28] <mvo> thanks (pending here in my local tree I mean)
[14:28] <seb128> mvo, debdiff between my building and karmic is
[14:28] <seb128>  changelog |    7 +++++++
[14:28] <seb128>  rules     |    1 +
[14:28] <pitti> mvo, seb128: page updated
[14:28] <seb128> oh ok
[14:28] <mvo> thanks
[14:30] <seb128> mvo, ok, pushed but I forgot to change the distro it's still karmic, do you want me to do another commit to change that?
[14:30] <mvo> seb128: its fine, thanks
[14:30] <seb128> good
[14:30]  * seb128 hugs mvo
[14:30]  * mvo says thanks and hugs seb128
[14:30] <seb128> ;-)
[14:30] <seb128> pitti, I'm wondering if I should do such pages for libglade and gnomevfs
[14:31] <pitti> seb128: hm, thinking about it I'll probably convert this page to bug reports
[14:31] <pitti> but for initial data collection this is easier
[14:31] <pitti> phone, brb
[14:34] <chrisccoulson> pitti - yeah, it looks like there's still quite a bit of work to do
[14:34] <chrisccoulson> it's a shame to have to spend time porting hal though
[14:37] <pitti> probably won't happen
[14:37] <pitti> chrisccoulson: we could disable pk support
[14:37] <chrisccoulson> possibly. what is HAL used for now?
[14:37] <pitti> but best would be to drop hal altogether :)
[14:37] <chrisccoulson> it doesn't do anything needing PK now does it?
[14:38] <pitti> it does, for KDE presumably
[14:46] <pitti> chrisccoulson, seb128: I updated the page again, now with links to patches, etc.
[14:47] <chrisccoulson> pitti - thanks:)
[14:47] <pitti> I'll port jockey now, I think
[14:48] <chrisccoulson> pitti - i'm updating g-c-c later, so i'll take that one, seeing as fedora already have a patch for that
[14:48] <pitti> cool, thanks
[14:48] <pitti> right, we can grab them as we touch the packages anyway
[14:48] <pitti> and for dk-power/g-p-m we should just wait on a new upstream release
[14:49] <pitti> but CK/gdm/g-session/panel was one major lockstep
[14:54] <pitti> Laney: so applying 09_app_install_entry.patch doesn't make any difference at all? why do we need the patch then?
[14:54] <Laney> pitti: I think there are two problems
[14:54] <Laney> the missing patch definitely doesn't help
[14:55] <Laney> as even if we fixed the underlying issue then it still wouldn't appear
[14:55] <pitti> well, it does appear, just in the Others/ submenu
[14:55] <pitti> (even without the patch)
[14:55] <Laney> I don't see it there
[14:55] <Laney> there's an unselectable version in alacarte though
[14:56] <pitti> weird
[14:56] <pitti> /usr/share/applications/gnome-app-install.desktop
[14:56] <Laney> well let me check in Others/ in my vm
[14:57] <kenvandine> hey didrocks
[14:57] <kenvandine> i am doing a merge with your changes from quickly
[14:57] <Laney> don't see it there
[14:57] <kenvandine> in save.py, -import os
[14:57] <kenvandine> -import sys
[14:57] <kenvandine> +import osimport sys
[14:58] <Laney> pitti: it's like this http://orangesquash.org.uk/~laney/alacarte.png
[14:58] <didrocks> kenvandine: do we really need to import those modules?
[14:58] <kenvandine> os yes
[14:58] <Laney> you can tick the checkbox but it just gets disabled again
[14:59] <Laney> ...and that's with 2.26.1-0ubuntu1
[14:59] <kenvandine> but looks like a missing carriage return
[14:59] <didrocks> ok, I can do it, I have still a lot of things to push
[15:00] <didrocks> indeed, you're right. Wait for 10 minutes. I first finish my setup.py :)
[15:00] <kenvandine> ok
[15:00] <kenvandine> didrocks, ping me when you are done with trunk so i can merge before pushing changes :)
[15:01] <didrocks> kenvandine: ok :) For you, where templates must be located?
[15:01] <kenvandine> you want to move the templates?
[15:01] <didrocks> kenvandine: when installed, yes
[15:02] <kenvandine> oh... humm
[15:02] <kenvandine>  /usr/share/quickly/templates perhaps?
[15:02] <pitti> kenvandine: do you know the current status of the pymsn fork and butterfly packaging?
[15:02] <kenvandine> they are getting it uploaded to debian
[15:02] <pitti> kenvandine: I wondered if we should move empathy to the default install now and temporarily drop butterfly
[15:02] <pitti> or wait until they are available
[15:02] <didrocks> kenvandine: ok, so, we agree :) I just have to see how to complete that in a smart way with distutils :/
[15:02] <pitti> I'd really like to have empathy in alpha-3
[15:02] <kenvandine> pitti, lets do that...
[15:03] <kenvandine> yeah
[15:03] <kenvandine> me too
[15:03] <kenvandine> it is an alpha... so no msn support isn't the end of the world
[15:03] <kenvandine> imho
[15:03] <pitti> right
[15:03] <pitti> it's just a recommends, isn't it?
[15:03] <kenvandine> pitti, did you split up libpurple?
[15:03] <kenvandine> i think so
[15:03] <pitti> kenvandine: no, I didn't; too much pain^Wfun with gdm
[15:03] <kenvandine> hehe
[15:04] <kenvandine> want me to split it up by protocol?
[15:04] <pitti> kenvandine: perhaps not for each protocol, just the ones we need to install by default perhaps?
[15:05] <seb128> urg
[15:05] <pitti> kenvandine: but I think that's the sort of stuff we can do after beta
[15:05] <pitti> it's not a blocker right now
[15:05] <seb128> why do you guys want to split libpurple now?
[15:05] <pitti> just for size optimization
[15:05] <seb128> how much potential win?
[15:05] <seb128> it seems lot of extra work and diff over debian for now real win
[15:05] <seb128> now -> no
[15:05] <pitti> seb128: right, that's why I woudln't like to do it now
[15:06] <pitti> just if we are despearate for space
[15:06] <kenvandine> ok
[15:06] <seb128> how much difference would that make?
[15:06] <pitti> probably ~ 1 MB, plus another MB if we drop pidgin-data from libpurple's dependencies
[15:11] <Amaranth> Laney: is your user in the admin group?
[15:12] <Laney> Amaranth: no
[15:12] <Laney> does it need to be for g-a-i to show up?
[15:12] <Laney> makes sense I guess
[15:12] <Amaranth> Laney: that's why you can't get gnome-app-install (or most of the things in the admin menu)
[15:12] <seb128> Laney, yes
[15:12] <Laney> ok let me try with another one
[15:12] <Laney> good catch
[15:14] <seb128> mvo, are you sure that import gobject issues are pygobject bugs and not due to all the debian packaging around rather?
[15:15]  * seb128 just noticed that you reassigned a bug to pygobject but if pygobject failed to import other users would have noticed
[15:15] <seb128> seems rather some local install or packaging system issue
[15:19] <Laney> pitti: yeah I just confirmed that it works if I use an admin user
[15:19] <Laney> sorry for confusino
[15:19] <Laney> on
[15:19] <pitti> aah
[15:19] <Laney> the patch just ensures it gets added to the root menu
[15:20] <Laney> I guess it lives in Others by default too
[15:20] <pitti> right, so it seems that patch doesn't work then
[15:20] <Laney> it does
[15:20] <Laney> I just forgot to put it in series
[15:20] <pitti> ah, right
[15:20] <Laney> pushed it up to my branch already
[15:20]  * pitti builds and tests
[15:21] <pitti> Laney: alrighty then; thanks, and sorry for the confusion
[15:21]  * Laney thinks it came more from this end
[15:21] <Laney> :)
[15:21] <mvo> seb128: pretty sure its the debian packaging around it, but its difficult to debug that :(
[15:23] <seb128> mvo, ok, I don't think bouncing it on pygobject will make it being solve though, I will bounce back on python*
[16:10] <didrocks> pitti: does distutils-extra update xx.po files? It seems to only update .pot file and xx.po -> xx.mo, but not running intltool-update xx
[16:10] <pitti> didrocks: ./setup.py build_i18n -m
[16:10] <pitti> it's not meant to do that automatically on build
[16:10] <pitti> since that creates noise in revision control, etc.
[16:10] <pitti> usually developers want to do this by hand only
[16:11] <didrocks> pitti: understood (and yes, it works ;)) Thanks.
[16:36] <statik> hi rickspencer3
[16:37] <statik> we'll happily merge CouchWidget into lp:desktopcouch if you propose a branch for merging :) i was ecstatic to hear that you were writing this
[16:39] <rickspencer3> hi statik
[16:39] <rickspencer3> ok
[16:39] <rickspencer3> I need to add a catalogue file and fix up a couple of thngs
[16:43] <seb128> hey rickspencer3
[16:43] <rickspencer3> hi seb128
[16:43]  * rickspencer3 is using empathy for irc
[16:44] <rickspencer3> hard to find messages and such from folks
[16:46] <seb128> rickspencer3, it doesn't highlight?
[16:46] <rickspencer3> seb128: it's hard to navigate to the correct window
[16:47] <rickspencer3> I get the notification, but then don't know from where I was pinged
[16:47] <rickspencer3> the tabs don't highlight to show I got a ping
[16:48] <rickspencer3> other than that, works pretty much the same as pidgin for irc
[16:48] <rickspencer3> seb128: would it be helpful if I logged a bug?
[16:50] <seb128> rickspencer3, yes, always good to have issues listed on the bug tracker, especially if that's not something we will look at immediately
[16:51]  * rickspencer3 takes not to log bug on empathy irc usage
[16:51]  * rickspencer3 has too much to do today
[17:00] <walters> Keybuk: working on that release, got a number of bugs done.  Feel like reviewing https://bugs.freedesktop.org/show_bug.cgi?id=896 ?
[17:01] <rickspencer3> seb128: I put in a blank dvd-rom disk, and there is no way to eject it
[17:01] <rickspencer3> where would you suggest I log a bug on that?
[17:01] <seb128> rickspencer3, you can't right click on it in the computer location?
[17:02] <rickspencer3> seb128: I can right click on it, but there is no "eject" option in the menu (as there is for my external hard drive connected via usb)
[17:02] <seb128> rickspencer3, just press the drive button?
[17:02] <rickspencer3> I can click the little eject icon in nautilus, but nothing happens
[17:02] <rickspencer3> seb128: I'm sure I can get it out, but it seems like a bug that I can't eject it
[17:03] <seb128> rickspencer3, karmic?
[17:03] <rickspencer3> seb128: yes
[17:03] <seb128> rickspencer3, I'm not sure but I think that should be fixed with the next gvfs and nautilus update
[17:03] <Keybuk> walters: reading now
[17:03] <seb128> rickspencer3, if you want to open a bug open it on gvfs I will track it there
[17:04] <seb128> rickspencer3, or wait for the next update before opening if you are lazy
[17:04] <rickspencer3> I'll hold off for a couple of days
[17:04] <seb128> lazy or busy ;-)
[17:04] <rickspencer3> busy and lazy ...
[17:04] <rickspencer3> the worst combination
[17:04] <seb128> hehe
[17:04] <seb128> I can confirm there with a blank CD, I've only unmount
[17:04] <seb128> I will check when I update gvfs and nautilus
[17:05] <seb128> mvo, do you know how to debug gksu?
[17:06] <seb128> mvo, it's broken with the new gtk apparently
[17:10] <Keybuk> walters: so basically defer error handling to the read() part of the transport
[17:11] <walters> Keybuk: yeah
[17:12] <mvo> seb128: I can have a look, let me quickly update my gtk
[17:14] <Keybuk> ack'd on bug
[17:15] <mvo> seb128: I can reproduce it here
[17:15] <seb128> mvo, me too, I'm just not sure where to start looking, any hint?
[17:15] <seb128> libgksu I guess?
[17:15] <mvo> seb128: yeah, the huge do_sudo_full function there
[17:16] <mvo> maybe a rebuild is enough?
[17:17] <seb128> mvo, would mean abi got broken on the way?
[17:17] <seb128> I don't really believe in rebuilds making things work
[17:19] <seb128> mvo, no, doesn't work
[17:28] <seb128> mvo, using   gtk_entry_set_visibility(GTK_ENTRY(gksuui_dialog->entry), TRUE); works
[17:28] <seb128> but it displays your password :-p
[17:28] <mvo> heh :)
[17:28] <seb128> I guess it's due to mclasen's changes
[17:29] <seb128> "* GtkEntry now has model-view separation, with GtkEntryBuffer.
[17:29] <seb128>   One intended use case for this is to support 'secure memory'
[17:29] <seb128>   for password entries."
[17:30] <mvo> heh, yeah - I can confirm that
[17:30] <mvo> I get as the password "*****" :)
[17:30] <mclasen> what does not work ?
[17:31] <seb128> mclasen, gksu
[17:31] <mclasen> a bit more specific, maybe ?
[17:31] <seb128> mclasen, the passwords are not accepted after the gtk 2.17.3 to 2.17.4 upgrade
[17:31] <seb128> mclasen, I'm trying to figure what happens exactly will give specifics when I've those
[17:32] <mclasen> ok
[17:32] <seb128> mvo, do you know what part of the code get the password from the entry?
[17:32] <mvo> yeah, it sues gtk_editable_get_chars()
[17:33] <mvo> in libgksuui/gksuui.c
[17:33] <mvo> eh
[17:33]  * mclasen has used password entries in Fedora after uploading 2.17.4, so it cannot be altogether broken...
[17:33] <mvo> gksuui-dialog.c
[17:33] <seb128> gksuui_dialog_get_password (GksuuiDialog *dialog)?
[17:33] <mvo> seb128: yes
[17:33] <seb128> ok, that's where I was looking
[17:34] <seb128> mclasen, is gtk_editable_get_chars() supposed to give the clear password or "*****"?
[17:34] <seb128> for a gtk_entry with gtk_entry_set_visibility FALSE
[17:34] <kenvandine> seb128, can you get evolution-indicator rebuilt against evo 2.27.x?
[17:35] <kenvandine> bug 390360
[17:35] <mclasen> whatever it did in previous releases
[17:35] <kenvandine> seb128, i confirmed a rebuild fixes it
[17:35] <seb128> kenvandine, ok
[17:35] <kenvandine> thx
[17:36] <seb128> mvo, mclasen: ok that's the issue, gtk_editable_get_chars() used to return the password in clear text and returns ******** now
[17:37] <mclasen> yeah, file a bug, I'll get that fixed
[17:37] <seb128> thanks
[17:37] <mvo> it seems like a workaround is to just use "gtk_entry_get_text()"
[17:38]  * mvo prepares the workaround
[17:40]  * seb128 waits on bugzilla to respond
[17:41] <seb128> mvo, if you do an upload bug #398849
[17:41] <mvo> thanks seb128
[17:42] <mvo> almost ready, just doing a final rebuild
[17:42]  * mvo hugs seb128 for finding the problem so quickly
[17:42]  * seb128 hugs mvo for doing a quick workaround ;-)
[17:42]  * charlie-tca thanks both mvo and seb128 for this one
[17:43]  * mclasen steps out of the hugging circle
[17:44] <walters> mclasen: free software, free love!  don't be a hater
[17:51] <seb128> mclasen, ok, bugzilla replied now, http://bugzilla.gnome.org/show_bug.cgi?id=588461
[17:56]  * Laney stabs empathy
[17:57] <Laney> why do I have to click on the notification icon for new conversations to come up?
[18:13] <pitti> Laney++
[18:13] <pitti> I think that already was discussed heavily in an upstream bug
[18:13] <seb128> where else would you expect to click?
[18:13] <pitti> I lamented there as well, but it got quiet unfortunately
[18:13] <Laney> nowhere
[18:13] <pitti> I want a window open, like in pidgin
[18:14] <seb128> you want jumping dialogs?
[18:14] <seb128> should the email client make emails jump on screen when they arrive too? ;-)
[18:14] <pitti> email is not "instant" messaging
[18:14] <pitti> seb128: email shouldn't blink in the notification bar either :)
[18:15] <seb128> right, nothing should "blink"
[18:15] <seb128> they should just be indicated by an icon there
[18:15] <pitti> but then I wouldn't notice it at all
[18:16] <seb128> good point
[18:16] <Laney> I *already* had a chat window open in this case anyway
[18:16] <seb128> I've no strong opinion about things jumping or blinking though
[18:16] <seb128> but I tend to dislike things autoopening
[18:16] <Laney> having to leave my keyboard just to open another tab was pretty obnoxious
[18:17] <seb128> those being im messages or updates
[18:17] <seb128> Laney, alt-tab and alt-n?
[18:17] <Laney> alt-n?
[18:17]  * Laney knows not of this
[18:17] <pitti> alt-tab> there is no window to alt-tab to
[18:17] <seb128> or whatever they use to switch tabs
[18:17] <seb128> pitti, <Laney> I *already* had a chat window open in this case anyway
[18:17] <Laney> there is no tab to switch to
[18:17] <Laney> you have to click to create the new tab
[18:18] <seb128> that's a different discussion
[18:18] <Laney> seems to be the same one
[18:18] <seb128> there is no reason tabs could not be added in the background
[18:18] <seb128> that's different from auto-opening things on your screen
[18:19] <Laney> we already created a precedent for auto opening things
[18:20] <seb128> Laney, the update autoopening you mean?
[18:20] <Laney> right, things the user wants to see right away :)
[18:20] <seb128> I'm trying to argue against that auto-opening too
[18:20] <seb128> kenvandine, evolution-indicator doesn't build on current karmic
[18:20] <pitti> right, for u-m
[18:21] <pitti> the difference is that update-manager doesn't get grumpy if ignore it for two hours
[18:21] <pitti> unlike my wife :)
[18:21] <seb128> ;-)
[18:22] <seb128> good reason to get a blinking icon rather than a dialog in the background you will not notice
[18:23] <Laney> I noticed the icon; just didn't want to have to move my hands off the keyboard to respond to it
[18:23] <Laney> two issues here - icon behaviour (shouldn't it be using indicator-applet anyway?) and spawning of dialogs
[18:25] <asac> seb128: latest gtk+ breaks mozilla dailies http://launchpadlibrarian.net/28975448/buildlog_ubuntu-karmic-lpia.xulrunner-1.9.1_<IP_ADDRESS>~hg20090713r26052%2Bnobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz
[18:25] <asac> seb128: seems the headers became pickier or something
[18:27] <seb128> asac, seems so, fix xulrunner? ;-)
[18:27] <asac> seb128: can you please verify that this is intended breakage in the most recent release with gtk+ folks? if so we will fix xulrunner, but not if its a bug
[18:29] <seb128> asac, gtk is moving in this way for sure that's one of the gtk3 goals
[18:30] <asac> do you see the commit that broke it?
[18:30] <seb128> asac, http://git.gnome.org/cgit/gtk+/commit/?id=eab02f697a29f2bfd388f6318adf18e2936e7e96
[18:30] <seb128> asac, gtkentrybuffer.h is a new file
[18:30] <seb128> +#if defined(GTK_DISABLE_SINGLE_INCLUDES) && !defined (__GTK_H_INSIDE__) && !defined (GTK_COMPILATION)
[18:30] <seb128> +#error "Only <gtk/gtk.h> can be included directly."
[18:30] <seb128> +#endif
[18:31] <asac> GTK_DISABLE_SINGLE_INCLUDES
[18:31] <asac> how is that set?
[18:31] <asac> by pkg-config now?
[18:31] <seb128> no, in your makefile that's a simple cflags
[18:32] <asac> seb128: err. we dont set it for sure
[18:32] <asac> i guess it must come from somewhere by default now
[18:32] <seb128> asac, well, you should if you want to be able to use granularity
[18:32] <asac> seb128: GTK_DISABLE_SINGLE_INCLUDES
[18:33] <asac> its a flag to disable it
[18:33] <seb128> yes
[18:33] <asac> e.g. if you dont pass anything it will not complain
[18:33] <asac> so it seems to be defined somewhere now by default ;)
[18:33] <seb128> it's a flag to make it not break when you don't respect single include
[18:33] <asac> no ... its DISABLE ... its a flag to make it break
[18:33] <asac> not to not break ;)
[18:33] <asac> or am i missing something?
[18:33] <seb128> hum
[18:33] <seb128> SINGLE_INCLUDES is what gtk tries to enforce now
[18:33] <asac> which i am sure existed before
[18:34] <asac> but wasnt default
[18:34] <asac> yeah
[18:34] <seb128> ie force you to do include <gtk/gtk.h>
[18:34] <asac> seb128: but where ?
[18:34] <seb128> and not gtkentry.h
[18:34] <asac> seb128: was it added to pkg-config ? ... or is it defined in gtk.h now?
[18:34] <seb128> mclasen, ^ that's a wanted change right?
[18:34] <seb128> asac, gtkentrybuffer.h which triggers your build error in a new file included in gtkentry.h
[18:34] <kenvandine> seb128, hummm... built locally
[18:35] <seb128> kenvandine, you have 2.27.4 from today?
[18:35] <asac> seb128: and gtkentry.h sets that define?
[18:35] <kenvandine> seb128, oh... no
[18:35] <kenvandine> i guess that was after my morning update :)
[18:35]  * kenvandine will fix it
[18:37]  * asac gets gtk+2.0 sources
[18:37] <seb128> asac, you probably include gtkentry.h which uses to not enforce single include
[18:37] <seb128> asac, now gtkentry.h includes gtkentrybuffer.h which does enforce single include
[18:37] <seb128> asac, you can set -DGTK_DISABLE_SINGLE_INCLUDES to not break on that or fix your code to include gtk.h
[18:38] <seb128> "which used to not enforce"
[18:38] <mclasen> seb128: fixed in master
[18:38] <mclasen> it was not intentional to break everybody who includes gtkentry.h
[18:38] <seb128> asac, ^
[18:38] <seb128> mclasen, thanks ;-)
[18:39] <asac> hah. i knew it
[18:39] <asac> mclasen: do you have a commit id?
[18:39] <mclasen> no
[18:40] <asac> hey you even committed it
[18:40] <seb128> asac, do you want me to backport the change?
[18:40] <asac> 26e67850a70869f24686df1f8bc0bab9049e5925
[18:41] <asac> seb128: if you can cherry pick that it would be great
[18:41] <seb128> asac, will do, I've to backport http://git.gnome.org/cgit/gtk+/commit/?id=ea3184f12972a6b03a0479ce26855c709ca41867 too
[18:41] <pitti> Taekwondo time, cu tomorrow!
[18:41] <asac> seb128: why not take a git snapshot ;)
[18:41] <seb128> pitti, see you on wednesday, today is a holiday there
[18:41] <asac> there are just a few commits on top of .4
[18:42] <seb128> asac, because I don't fancy uploading an another 30meg tarball on my 128k upload
[18:42] <pitti> seb128: enjoy
[18:42] <seb128> pitti, danke
[18:42] <pitti> seb128: please send your report, touhgh
[18:42] <seb128> pitti, will do, I might be around for the meeting too but not sure yet
[18:53] <didrocks> pitti: if you have some time (no hurry), can you please give a look at setup.py in lp:quickly branch? (I think it should be ok appart from an added po/ directory I can't remove). I'm not quite confident in my distutil usage.
[19:19] <seb128> asac, uploading
[19:21] <asac> seb128: rock ... and roll ;)
[19:21] <asac> thanks
[19:27] <crevette> seb128, bug 397571 shouldn't be assigned to bluez-gstreamer instead of bluez-gnome?
[19:28] <seb128> crevette, dunno, check where the file is distributed, I've no clue about bluetooth
[19:28] <seb128> brb testing gtk
[19:28] <crevette> dpkg -S libgstbluetooth.so can give you the answer :)
[19:30] <seb128> re
[19:35] <Ampelbein> hi there. is the deskbar-applet upgrade free to take?
[19:36] <seb128> Ampelbein, hey, yes
[19:36] <Ampelbein> seb128: ok, then now it is taken. ;-)
[19:42] <didrocks> kenvandine: why did you remove camel_case_nameWindow.py at rev 129 for quickly? (http://bazaar.launchpad.net/~quickly/quickly/trunk/revision/129)
[19:43] <kenvandine> it was moved to bin/project_name
[19:43] <didrocks> camel_case_nameWindow.py is different from project_name script, no?
[19:44] <didrocks> the file still exists and is not the same than project_name. It's just no more installed when creating a project
[20:16] <Ampelbein> seb128: hey... I have a little trouble understanding deskbar-applet here. They claim in the NEWS-file to have removed dependency on the deprecated libgnomeui. Yet in configure.ac they remove the pkg-config check for gnome-python-2.0, not gnome-desktop-2.0 . Where am I mistaken here?
[20:16] <Ampelbein> seb128: see http://paste.ubuntu.com/217196/ for clarification
[20:18] <seb128> Ampelbein, gnomeui is in gnome-python
[20:22] <Ampelbein> seb128: ok, i got slightly confused there. thanks.
[20:57] <asac> Riddell: if i want to provide a api mostly doing signal emission for kde/Qt, is there any particular base-lib i should use to make adaption easy? (similar to glib)
[21:21] <rickspencer31> kenvandine: thoughts on a  unit testing framework for quickly?
[21:22] <kenvandine> the shell outs there make that a pain
[21:22] <rickspencer31> pyunit?
[21:22] <rickspencer31> hmm
[21:23] <kenvandine> i think the most useful testing work we can do is functional tests
[21:23] <kenvandine> at least the biggest bang for the buck
[21:23] <kenvandine> since that is what we have been breaking
[21:23] <kenvandine> the shell commands
[21:24] <rickspencer31> how do you recommend I approach that?
[21:24] <kenvandine> thinking about that
[21:24] <kenvandine> we would need to create a new stub project and execute all the commands and destroy it after
[21:24] <asac> kenvandine: now that i see you, is this an experiment or something that is supposed to land for karmic: https://code.edge.launchpad.net/~ken-vandine/gwibber/gwibber-dbus-activated  ?
[21:25] <kenvandine> this was something segphault merged
[21:25] <kenvandine> yes for karmic
[21:25] <kenvandine> but for his branch that hasn't merged into trunk yet
[21:25] <asac> kenvandine: ok so its in his "2.0" branch?
[21:25] <kenvandine> yes
[21:25] <asac> thx
[21:25] <kenvandine> np
[21:25] <asac> so i guess having that is a requirement for karmic?
[21:26] <asac> kenvandine: is there a spec about this?
[21:26] <kenvandine> one sec
[21:26] <kenvandine> https://blueprints.launchpad.net/ubuntu/+spec/desktop-karmic-social-from-the-start
[21:28] <asac> kenvandine: i guess the firefox extension is not ment to be installed by default?
[21:29] <kenvandine> if that even happens
[21:29] <kenvandine> not sure if that is reasonable for karmic
[21:29] <kenvandine> if we did it... it would be installed by default
[21:29] <asac> is the task split randome (e.g. the "split service out 1:" and create UI that renders results from service 1)
[21:30] <asac> just wonder because i couldnt find anything about that in the wiki on first glance
[21:30] <kenvandine> not random
[21:30] <kenvandine> but
[21:30] <asac> kenvandine: well if you start working on the firefox extension please talk to me first  ;)
[21:30] <kenvandine> the posting and caching of posts should be in the backend
[21:30] <kenvandine> then the client just renders that
[21:30] <kenvandine> asac, of course :)
[21:30] <rickspencer31> kenvandine: if it's not going into Karmic, you could set the work item to postponed
[21:30] <asac> but thanks for the insight.
[21:31] <kenvandine> rickspencer31, i think we are still negotiating :)
[21:31] <kenvandine> i wish ryan had made it to gcds
[21:31] <asac> kenvandine: negotiating?
[21:31] <kenvandine> well
[21:31] <asac> about the firefox exension?
[21:31] <kenvandine> roadmap
[21:32] <kenvandine> asac, i'll ping you if there is a chance someone will work on it
[21:32] <kenvandine> his 2.0 roadmap includes way too much imho
[21:32]  * kenvandine wants to reduce the scope
[21:32] <asac> kenvandine: great. if you could do that before its started let me know ;)
[21:41] <rickspencer31> kenvandine: so back to testing quickly
[21:41] <rickspencer31> should I just write some python code that runs functional tests?
[21:41] <rickspencer31> or is there a functional testing fx that I should use?
[21:41] <kenvandine> rickspencer31, i think that is the best start
[21:41] <kenvandine> then figure out unit testing later... functional tests is what will save us right now
[21:42] <rickspencer31> right
[21:42] <rickspencer31> I
[21:42] <rickspencer31> m not sure I can automate everything
[21:42] <rickspencer31> like how to confirm that quickly glade works
[21:42] <kenvandine> yeah.. :/
[21:42] <kenvandine> well
[21:42] <rickspencer31> still, it's a start
[21:42] <kenvandine> you could verify by exit code?
[21:42] <rickspencer31> hmm
[21:42] <rickspencer31> okay, should I use quickly to create the functional tests ;)
[21:43] <rickspencer31> quickly new ubutnu-project quickly_tests
[21:43] <rickspencer31> :)
[21:44] <rickspencer31> gotta run
[21:52] <kenvandine> hehe
[22:05] <Riddell> asac: qtcore?
[22:05] <Riddell> that has the essential non gui classes
[22:06] <asac> Riddell: so i need to implement a QObject ?
[22:07] <Riddell> asac: to getsignals and slots yes
[22:07] <asac> are there any snippets how to do moc stuff for normal automake things that dont want to use qmake?
[22:07] <asac> Riddell: what about mainloop and IO stuff?
[22:08] <asac> also qtcore?
[22:08] <Riddell> use the Q_OBJECT macro in the header
[22:08] <asac> i general io things like watches on FDs etc.
[22:08] <asac> Riddell: so no need for moc run during compile? great! ;)
[22:10] <Riddell> yes, mainloop is in qapplication in qtcore, qfile for files and qsocketthing for fd watches
[22:10] <Riddell> you'll need moc if doing signals and slots nand include the gnerated moc file at the bottom
[22:12] <huats> seb128: since when do you release upstream software ? :)
[22:12] <huats> (I just saw the gvfs one :))
[22:12]  * seb128 slaps huats
[22:12] <seb128> huats, I just did the tarball upload ;-)
[22:12] <huats> ;)
[22:13] <Riddell> i think when kde used to use automake it had some magic to run moc when needed, with plain automake i guess you just need a maked target
[22:14] <asac> Riddell: right if you could find that kde automake thing that would be great.
[22:14] <asac> Riddell: so do i usually use .moc as file extension or just .h?
[22:14] <Riddell> moc for the one moc generates
[22:21] <asac> ok
[22:24] <Ampelbein> Is the gnome-keyring update free to take?
[22:26] <seb128> Ampelbein, too late I just did it
[22:26] <seb128> Ampelbein, you can do glibmm if you want
[22:27] <Ampelbein> seb128: ok, will do that. has anybody ever told you that you are really fast at updating? ;-)
[22:27] <crevette> seb128 is the packaging super-hero
[22:30] <seb128> Ampelbein, I've some years of experience in this area ;-)
[22:34] <seb128> Ampelbein, there is also cheese to update if you want
[22:34] <seb128> pitti, the gvfs is yours to do for tomorrow if you want, it starts being late for me to do that and test now and since you landed many of the changes there
[22:35] <Ampelbein> seb128: ok. having some problem with "bzr bd-do" now: gzip: stdout: Broken pipe; tar: Child returned status 1
[22:35] <seb128> is your orig tarball working?
[22:35] <seb128> ie can you use tar to untar it?
[22:37] <Ampelbein> seb128: yeah, that works.
[22:37] <Ampelbein> seb128: will do manual copy of the debian dir and investigate later
[22:39] <seb128> ok
[23:12] <rickspencer31> hi robert_ancell
[23:12] <rickspencer31> good morning, up early? A little jet lag?
[23:13] <robert_ancell> rickspencer31, yeah :)
[23:13] <rickspencer31> sorry
[23:13] <robert_ancell> rickspencer31, nah, it's not too bad
[23:13] <rickspencer31> I'm sitting in the dentist waiting room, awaiting my appointment :(
[23:13] <robert_ancell> rickspencer31, you've got it worse than me!!
[23:13] <rickspencer31> hehe
[23:14] <rickspencer31> robert_ancell: regarding bug 372132
[23:14] <rickspencer31> If I suggest three documents, is there any reason that you could see not to put the templates in asap?
[23:14] <rickspencer31> I'm thinking "Word Processing Document", "Spreadsheet", "Presentation"
[23:15] <robert_ancell> I can propose the merge
[23:16] <asac> will those templates be shipped by the apps (e.g. like ooo-writer package ships the word processing document template)?
[23:16] <rickspencer31> asac: I think we just drop emplates into a directory
[23:17] <rickspencer31> so the templates are shipped by us, not the apps
[23:17] <asac> yeah. but those should not be shipped in nautilus, but rather in the application that can deal with them
[23:17] <rickspencer31> Am I understanding your question?
[23:17] <rickspencer31> I suppose we should tell OOo to install them when it installs itself, and to remove them when it removes itself
[23:17] <asac> well, why not put them in the packages of the apps? in that way you wont see menu entries if the app that can handle them is not installed
[23:18] <rickspencer31> asac: sure, that sounds like a fine solution
[23:18] <asac> rickspencer31: right. that basically means that OOO should ship the templates itself
[23:18] <asac> in particular: ooo-writer -> word processing template, ooo-calc -> spreadsheet template (not sure if thats the right mapping)
[23:18] <rickspencer31> fine, but we should put *something* there
[23:18] <asac> also maybe abiword, etc.
[23:18] <asac> rickspencer31: thats definitly true
[23:19] <asac> so lets add tasks for the apps that should ship templates to the bug
[23:19] <rickspencer31> let's just do Word Processing Document, Spreadsheet, Presentation
[23:19] <rickspencer31> and just for OOo in Karmic
[23:19] <rickspencer31> that will be a substantial improvement without incurring too much work
[23:19] <asac> yeah. though i wouldnt stop contributions for others
[23:19] <asac> ack
[23:19] <rickspencer31> oops time to go!
[23:19] <asac> cu tomorrow
[23:21] <seb128> rickspencer31, the main concern from upstream about templates what not what to put there but to have a location open for abuses
[23:21] <seb128> we can chat about that later, good luck with the dentist
[23:22] <asac> seb128: location for abuses?
[23:22] <seb128> asac, the rational against putting that in the application is that lot of applications will want to ship templates
[23:22] <asac> seb128: if its a system path the risk sounds acceptable ... having $HOME/. ... one might have some risk
[23:22] <seb128> and that you will quickly have 15 entries there
[23:22] <asac> seb128: i would think lets first have that problem
[23:22] <asac> and then think what we can do
[23:22] <seb128> asac, "abuse" in the sense of "too many items will quickly go there and make the menu un-usable"
[23:23] <asac> for now i dont see that many apps that want to ship templates
[23:23] <asac> ooo*, abi*
[23:23] <asac> what else would ship something there?
[23:23] <asac> if the list grows too long on the default install, we can always remove templates from packages that we think are inappropriate
[23:23] <seb128> you will probably quickly have editor dropping template for programming
[23:23] <asac> but why wouldnt you want to offer a template for write/spreadsheet software you have installed?
[23:24] <seb128> in anjuta dropping C programs template
[23:24] <seb128> java doing the same
[23:24] <asac> seb128: yeah. but we can complain and remove from packages
[23:24] <seb128> mono doing the same
[23:24] <seb128> etc
[23:25] <seb128> asac, because I don't use openoffice and I don't want my menu polluted with those
[23:25] <seb128> we need a way to filter the system ones from the user UI if we start adding some
[23:25] <asac> yeah. but we should first have that problem imo. then we can try to fix that on a social way (e.g. removing stuff) or by making a hierachy, like "top level templates", and "more ..." templates
[23:25] <asac> seb128: yeah well. its teh default install, so you could remove ooo
[23:25] <seb128> I don't want to remove OO.o some people have account on the same computer and run it
[23:26] <seb128> if we add system templates we need some editor to allow users to select those they want or not
[23:26] <asac> seb128: personally i think the menu is already nested
[23:26] <asac> so its not a problem
[23:26] <asac> if it would be on first level on right clickt, that would be bad indeed
[23:27] <asac> i guess you rarely use the Create document feature on your own
[23:27] <seb128> well I've some custom and useful templates there
[23:27] <seb128> I don't want it to be cluttered with speadsheet, oowriter, oocalc, etc
[23:27] <asac> seb128: so the menu is currently customizable. so having the ability to disable system templates on a per-user basis would be best)
[23:27] <asac> not sure if we really need that to begin with
[23:27] <seb128> well we need to think about it
[23:27] <asac> seb128: or custom templates always get shown on top
[23:27] <asac> e.g.
[23:27] <asac> Custome 1
[23:27] <asac> CUstom 2
[23:27] <asac> ---------
[23:28] <asac> System 1
[23:28] <asac> System ...
[23:28] <seb128> that has been discussed for a while upstream and alex refused the system template patch for a reason
[23:28] <asac> users that are starters probably dont have custom ones
[23:28] <asac> seb128: is there a bug?
[23:28] <seb128> read http://mail.gnome.org/archives/nautilus-list/2008-June/msg00123.html about that if you want
[23:29] <seb128> asac, http://article.gmane.org/gmane.comp.gnome.nautilus/3745 is the email from alex against those
[23:29] <seb128> "We intentionally avoided that, since it give a load of problems. First
[23:29] <seb128> of all all sort of editing gets extremely complicated with merged
[23:29] <seb128> directories. Both code-wise and conceptually for the user.   Instead you get to personally
[23:30] <asac> pick exactly the templates you use.
[23:30] <asac> "
[23:31] <asac> i understand that argument
[23:31] <asac> but if we want to improve it we need a "customize ..." menu entry right in the Create Document ... folder
[23:31] <seb128> http://mail.gnome.org/archives/nautilus-list/2008-June/msg00139.html too
[23:31] <asac> otherwise no normal user will find it
[23:31] <seb128> "I'm worried that people end up with menus like these
[23:31] <seb128>  Create Document -> OpenOffice Writer ODF document
[23:31] <seb128>                     Abiword ODF document
[23:31] <seb128>                     KOffice ODF document
[23:31] <seb128> times the number of formats, times the number of different document
[23:31] <seb128> types."
[23:31] <asac> well. thats when they install all three solutions
[23:31] <seb128> which is a good point, how do you avoid that on system with several desktop installed?
[23:31] <asac> personally i dont see a problme
[23:32] <seb128> well, some computers are multi-users
[23:32] <asac> nobody complains that the applications -> Submenu grows similarly
[23:32] <seb128> oh they do
[23:32] <seb128> we have a talk about menus being cluttered at every uds
[23:32] <asac> yeah. but still they dont make the menu empty
[23:32] <asac> they fill it up and then users can remove stuff
[23:32] <seb128> well we have a menu editor
[23:32] <asac> thats the same approach that should be done here
[23:32] <seb128> you have no way to remove system templates right now
[23:32] <asac> seb128: yes, but the approach starts with a full glass and not with an empty one ;)
[23:32] <seb128> well I don't say it's not solvable
[23:33] <asac> seb128: i didnt say that ;)
[23:33] <seb128> it's just not as simple as "create the dir, patch nautilus and start throwing things in the directory"
[23:33] <asac> i appreciate that you summarized the disussion and provided links
[23:33] <asac> yes
[23:33] <seb128> well, I've been reading discussions about that several times over the year
[23:34] <asac> though i wouldnt think its a big problem, really :) ...  i have never seen that menu and i guess most advanced users dont need it ;) ... you for instance could do the same for your custom templates, e.g. create a symlink etc.
[23:34] <seb128> so I might be on the other side because I've seen how their turned and upstream disagreeing strongly
[23:35] <seb128> well, I just don't like starting adding difference in behaviour which angry upstream
[23:35] <asac> ack
[23:35] <seb128> that will only lead to tension when they will get bugs about it especially when they know that the topic has been discussed and they made it clear they think it's not a good thing for their software
[23:35] <asac> from what i understand its just alex
[23:36] <asac> but i didnt see all discussion
[23:36] <asac> so ok
[23:36] <seb128> "just", he's the only nautilus maintainer ;-)
[23:36] <asac> in any case. we can do it, because we can control what gets installed
[23:36] <seb128> davidz agrees with him too
[23:36] <asac> ;)
[23:36] <asac> ok
[23:36] <seb128> "control"
[23:36] <seb128> I'm read to bet that you will get the situation with the same templates for openoffice, koffice, abiword quickly
[23:37] <seb128> read -> ready
[23:37] <seb128> once you have the feature on users from those applications will get those patched to provide templates
[23:37] <asac> i just dont think that users having installed openoffice, abiword and koffice should be something we should really care about for now ;)
[23:38] <seb128> well that's probably the case on many office or university installs
[23:38] <asac> i mean, i dont care for bugabundo's firefox experience because he has installed 56 extensions ;)
[23:38] <Ampelbein> seb128: glibmm ready, doing cheese now.
[23:38] <seb128> Ampelbein, cool
[23:38] <asac> seb128: yeah. but why does koffice install its template in the location of the gnome file  bropwser?
[23:38] <asac> it shouldnt show up in gnome
[23:39] <seb128> asac, the suggestion upstream was to use a common locations because some users run kapps under GNOME and other way around
[23:39] <mclasen> whats wrong with having an 'odf document' template ?
[23:39] <asac> oik
[23:39] <mclasen> without odf in the name, of course
[23:40] <asac> dont know if anyone said that in particular was a problem
[23:41] <seb128> mclasen, none, but you want the template to be installed with abiword or openoffice
[23:41] <seb128> ie if any of those is installed
[23:41] <asac> (this is about allowing apps to install their own templates that show up in create document ... in nautilus)
[23:41] <seb128> so you need to have stock documents in each package
[23:41] <seb128> or a clever way to mask duplicates
[23:41] <mclasen> have a office-templates package that gets pulled in by all of those ?
[23:42] <seb128> mclasen, I guess that could work, though they might not support all the same format if you start addict oocalc, etc formats
[23:43] <seb128> could get complicated
[23:43] <mclasen> yeah
[23:43] <mclasen> alternatively, make nautilus not show templates that have an unsupported mime-type
[23:43] <mclasen> or use packagekit to offer installing an app that can handle it...
[23:44] <Ampelbein> seb128: do we want multimedia keys support in cheese? This is a new feature in 2.27.4
[23:44] <seb128> Ampelbein, sounds good
[23:44] <seb128> mclasen, yeah, that should be doable, that just requires some thinking and discussion
[23:46] <seb128> asac, which was sort of my point, we should think about potential issues rather than running into the basis changes which have already been discussed and will trigger buggy situations
[23:46] <seb128> asac_, re, got disconnected?
[23:47] <asac_> yeah
[23:47] <seb128> asac_, I was saying
 asac, which was sort of my point, we should think about potential issues rather than running into the basis changes which have already been discussed and will trigger buggy situations
[23:47] <seb128> ie it's not a "don't do it" but a "wait guys, that has been discussed already and has issues to consider"
[23:47] <asac_> yes. i agree we should first think about where we want to be in the end
[23:47] <asac_> then we have to think how we get there
[23:48] <seb128> good, we agree ;-)
[23:49] <seb128> one thing to think about is what should ship the template, the distribution or sysadmin or the packages when installed
[23:49] <seb128> and one other think is how we let users organize that menu if we use a system location
[23:49] <asac_> i think that in the end we will have a per-app solution with either smart thing or with easy configurability for the user
[23:50] <seb128> during one of the first discussion we had on the topic we discussed copying those to the user directory when the user is added
[23:50] <seb128> so it would be easy to clean things for the user
[23:50] <seb128> but that has drawbacks too, ie no dynamic changes on updates; need a way to copy those when the user is added and for desktop installs only
[23:50] <asac_> right. but if the end solution is that we get something like the gnome menu editor, then we could as well start to do system stuff and keep our eyes open that no packages misuse that (e.g. only those few that we allow get in there until the general problem is fixed)
[23:51] <asac_> but if upstream says they dont want to do something like menu editor, then i dont know ;)
[23:51] <asac_> maybe a mime + xdg wrapper combination
[23:51] <seb128> I don't think the upstream discussions went so far
[23:51] <asac_> so you only get one entry per mime-type
[23:51] <asac_> and you automatically open the xdg configured default application
[23:51] <seb128> they rather argued on whether is was a good idea to let any application be able to clutter your menu
[23:51] <asac_> but then the templates are probably not compatible ,)
[23:52] <asac_> yeah
[23:52] <seb128> that's why I suggest coming with a design first
[23:52] <asac_> i think its reasonable approach and we should think about that and maybe resurrect upstream discussion
[23:52] <seb128> and not running in the "let's drop quickly some templates there"
[23:52] <asac_> in the meantime we can either ship the templates for selected apps only, or ship them system wide
[23:52] <asac_> but then we should automatically hide them if the associated binary is not avilable
[23:53] <asac_> e.g. similar to what preferred applications did for years
[23:53] <seb128> well nautilus doesn't even have a system wide location it reads for those now
[23:56] <asac_> i think there is no other way than enabling that ... copying to user profile is just a mess and will be a pain to cleanup when the system wide solution becomes available
[23:56] <asac_> i think the risk that upstream apps start to install that in the private ubuntu system location is low
[23:57] <seb128> not upstream apps
[23:57] <seb128> but random ubuntu packages
[23:57] <asac_> yeah. but we can make a intermediate policy
[23:57] <asac_> everything needs to be approved in desktop team meeting
[23:57] <seb128> right
[23:57] <asac_> or something
[23:57] <seb128> well there is a valid usecase to have abiword shipping templates
[23:58] <seb128> some people don't install openoffice but abiword and they want that feature to work too
[23:58] <seb128> etc
[23:58] <seb128> if we want to start telling those users they are wrong that will lead to lot of discussions
[23:58] <seb128> not there that's worth the win
[23:58] <asac_> would you deny abiword to install the template? if they ask in the -desktop meeting?
[23:59] <asac_> e.g. is that too much clutter for you already?
[23:59] <asac_> just curious to understand what level amount of templates you think would be offending/confusing etc.
[23:59] <seb128> no I wouldn't


[01:38] -queuebot:#ubuntu-release- Unapproved: exim4 (disco-proposed/main) [4.92-4ubuntu1 => 4.92-4ubuntu1.1] (ubuntu-server)
[05:21] <infinity> vorlon: Historically, we've never emptied proposed at EOL, we just snapshot it as "this is the way it was".  But ESM does make that a bit goofier, I guess.
[05:22] <infinity> vorlon: No strong opinion either way.  We could publish it to -updates, we could binary copy it to ESM (and leave it in proposed)...
[05:25] <infinity> vorlon: I'm even more confused about the seccomp that the security team uploaded (long) after ESMiness.
[05:47] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu-hwe-18.04 (bionic-proposed/main) [18.1.0-1~18.04.1 => 19.0.1-1~18.04.1] (no packageset)
[05:47] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-nouveau-hwe-18.04 (bionic-proposed/main) [1:1.0.15-3~18.04.1 => 1:1.0.16-1~18.04.1] (no packageset)
[05:47] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-ati-hwe-18.04 (bionic-proposed/main) [1:18.1.0-1~18.04.1 => 1:19.0.1-0ubuntu1~18.04.1] (no packageset)
[09:09] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-150.176] (core, kernel)
[09:16] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-150.176]
[09:33] <tjaalton> sil2100: is it your sru day? could you review libglvnd for bionic, it's been sitting on the queue for some weeks now
[09:34] <tjaalton> oh hang on, it's in proposed
[09:35] <tjaalton> huh, the upload never happened.. shame on me
[09:37] -queuebot:#ubuntu-release- Unapproved: libglvnd (bionic-proposed/main) [1.0.0-2ubuntu2.2 => 1.0.0-2ubuntu2.3] (core)
[09:37] <tjaalton> sil2100: nevermind :)
[09:39] <Laney> :D
[09:39] -queuebot:#ubuntu-release- Unapproved: cups (bionic-proposed/main) [2.2.7-1ubuntu2.5 => 2.2.7-1ubuntu2.6] (core)
[09:44] <sil2100> ;)
[09:44] <sil2100> tjaalton: I can try getting to it today, yes
[09:58] -queuebot:#ubuntu-release- Unapproved: cups (disco-proposed/main) [2.2.10-4ubuntu1 => 2.2.10-4ubuntu2] (core)
[10:13] <tjaalton> sil2100: i uploaded it *somewhere* earlier, since it had to be forced now
[10:14] <tjaalton> sil2100: and thanks, if you do
[10:14] -queuebot:#ubuntu-release- Unapproved: libpinyin (bionic-proposed/main) [2.1.91-1 => 2.2.2-1ubuntu<IP_ADDRESS>] (input-methods, ubuntu-desktop)
[10:15] -queuebot:#ubuntu-release- Unapproved: ibus-libpinyin (bionic-proposed/main) [1.9.2-2 => 1.11.0-1ubuntu<IP_ADDRESS>] (input-methods, ubuntu-desktop)
[10:25] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (disco-proposed) [2.578.6]
[10:30] -queuebot:#ubuntu-release- Unapproved: libpinyin (cosmic-proposed/main) [2.2.0-1 => 2.2.2-1ubuntu<IP_ADDRESS>] (input-methods, ubuntu-desktop)
[10:31] -queuebot:#ubuntu-release- Unapproved: ibus-libpinyin (cosmic-proposed/main) [1.10.0-1 => 1.11.0-1ubuntu<IP_ADDRESS>] (input-methods, ubuntu-desktop)
[10:34] -queuebot:#ubuntu-release- Unapproved: accepted tracker-miners [source] (disco-proposed) [2.1.6-1ubuntu1~19.04]
[10:48] -queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (disco-proposed) [1:3.32.2-0ubuntu1]
[10:52] <sil2100> marcustomlinson: hey! Is it intentional that the disco libreoffice SRU has an interim UNRELEASED version in the changelog?
[10:53] <sil2100> I mean, it's probably not a blocking issue, but the changelog looks messy because of it
[11:00] -queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1008.9] (no packageset)
[11:12] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1008.9]
[11:35] <apw> sil2100, that is a very Debian thing to do, is it a Debian version in there ?
[11:41] <sil2100> apw: it looks like it yes
[11:45] -queuebot:#ubuntu-release- Unapproved: systemd (cosmic-proposed/main) [239-7ubuntu10.13 => 239-7ubuntu10.14] (core)
[11:46] -queuebot:#ubuntu-release- Unapproved: ktouch (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu1.1] (kubuntu)
[11:48] -queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.21 => 237-3ubuntu10.22] (core)
[11:49] <sil2100> apw: I'll accept it in this case
[11:49] -queuebot:#ubuntu-release- Unapproved: rejected biosdevname [source] (bionic-proposed) [0.4.1-0ubuntu10.1]
[11:52] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (disco-proposed) [1:6.2.4-0ubuntu<IP_ADDRESS>]
[11:53] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (disco-proposed) [1:6.2.4-0ubuntu<IP_ADDRESS>]
[12:41] <jdstrand> infinity (cc vorlon): libseccomp should be out of -proposed today. there was some question on snapd and trusty/esm which is why it is there in the first place, but that got answered yesterday
[12:59] -queuebot:#ubuntu-release- Unapproved: cups (xenial-proposed/main) [2.1.3-4ubuntu0.8 => 2.1.3-4ubuntu0.9] (core)
[13:01] -queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu16.4 => 0.7.5-1ubuntu16.6] (core)
[13:17] -queuebot:#ubuntu-release- Unapproved: libio-socket-ssl-perl (bionic-proposed/main) [2.056-1 => 2.060-3~ubuntu18.04.1] (core) (sync)
[14:41] <infinity> jdstrand: But why was it there in the first place, that was the question.
[14:46] -queuebot:#ubuntu-release- Unapproved: rejected osgearth [sync] (trusty-updates) [2.4.0+dfsg-6]
[14:52] <sil2100> infinity: I think I heard jdstrand mentioning they put it there for it to get wider testing or something
[14:56] -queuebot:#ubuntu-release- Unapproved: accepted libglvnd [source] (bionic-proposed) [1.0.0-2ubuntu2.3]
[14:58] <vorlon> xnox: tweaked the test case for libwww-perl slightly on the openssl.l.l bug, to ensure we actually test the Breaks
[14:58] <xnox> vorlon:  oooh, ok.
[15:01] -queuebot:#ubuntu-release- Unapproved: accepted libwww-perl [sync] (bionic-proposed) [6.31-1ubuntu0.1]
[15:13] -queuebot:#ubuntu-release- Unapproved: accepted libio-socket-ssl-perl [sync] (bionic-proposed) [2.060-3~ubuntu18.04.1]
[15:14] -queuebot:#ubuntu-release- Unapproved: accepted libpinyin [source] (cosmic-proposed) [2.2.2-1ubuntu<IP_ADDRESS>]
[15:29] <vorlon> xnox: the patch against libnet-ssleay-perl patches the documentation to include statements that certain features are not available in this version of net-ssleay
[15:30] <vorlon> xnox: do we care about the misleading docs? (or is there a fix-up patch I haven't gotten to yet in the review)
[15:31] <xnox> vorlon:  i think some of those docs are not lies, as the missing bits got implemented in 1.88 only which is in eoan
[15:31] <xnox> vorlon:  and i did not yet think about backporting that, or not.
[15:34] <vorlon> xnox: ok
[15:37] <vorlon> xnox: one of the patches added is to ignore unexpected SIGPIPE being raised during tests; have you considered whether this behavior change will raise unexpected SIGPIPE on real-world use cases and be a regression risk?
[15:38] <xnox> vorlon:  as far as i recall, no. it was merged as test-suite flakiness rather than TLS1.3
[15:43] <vorlon> xnox: ok; can you consider now whether there's regression risk there?
[15:43] <vorlon> and would it be gauche for the perl library itself to ignore SIGPIPE
[15:52] -queuebot:#ubuntu-release- Unapproved: libpinyin (cosmic-proposed/main) [2.2.0-1 => 2.2.2-1~ubuntu18.10.1] (input-methods, ubuntu-desktop)
[15:54] -queuebot:#ubuntu-release- Unapproved: libpinyin (bionic-proposed/main) [2.1.91-1 => 2.2.2-1~ubuntu18.04.1] (input-methods, ubuntu-desktop)
[15:56] -queuebot:#ubuntu-release- Unapproved: rejected libpinyin [source] (bionic-proposed) [2.2.2-1ubuntu<IP_ADDRESS>]
[15:58] -queuebot:#ubuntu-release- Unapproved: accepted libpinyin [source] (cosmic-proposed) [2.2.2-1~ubuntu18.10.1]
[16:00] -queuebot:#ubuntu-release- Unapproved: accepted libpinyin [source] (bionic-proposed) [2.2.2-1~ubuntu18.04.1]
[16:08] <jdstrand> infinity: I put it there because snapd development encompasses more than just the deb and I a) thought it was going to be supported in sem and b) didn't think that the snapd team would be able to pull in the esm ppa in all the places it would need it (ie, travis, spread tests, what have you)
[16:08] <vorlon> debian/patches/Move-SSL_ERROR_WANT_READ-SSL_ER
[16:08] <vorlon> oops
[16:09] <vorlon> xnox: debian/patches/Move-SSL_ERROR_WANT_READ-SSL_ERROR_WANT_WRITE-retry-.patch also looks like an interesting behavior change to the Net::SSLeay api, read/write change behavior to not retry?
[16:10] <jdstrand> infinity: so if it was going to be supported I thought for this upload going to trusty-security might make it easier for them to transition to using esm in their project. as it turns out, as of right now, they aren't going to have snapd in esm, so I will push libseccomp to trusty/esm and delete from -proposed
[16:11] <jdstrand> infinity: and I told them if the decision changes wrt snapd/trusty/esm, to come to us so we can work together on a plan for them building/testing/delivering snapd debs via esm
[16:13] <jdstrand> infinity: as to why libseccomp is in any of -proposed, yes, sil2100 is right, we wanted wider testing. the non-trusty releases will go to -security
[16:14] <jdstrand> I'm working to publish the USN for it today
[16:32] -queuebot:#ubuntu-release- Unapproved: accepted ibus-libpinyin [source] (cosmic-proposed) [1.11.0-1ubuntu<IP_ADDRESS>]
[16:34] -queuebot:#ubuntu-release- Unapproved: accepted ibus-libpinyin [source] (bionic-proposed) [1.11.0-1ubuntu<IP_ADDRESS>]
[16:40] <xnox> vorlon:  yes, which is now inline with what openssl told everyone to do.... also note that it's unusual to see those errors from openssl pre-tls1.3 as well.
[16:41] <xnox> vorlon:  i wish i knew how much stuff uses perl for openssl. especially server side, rather than just client.
[16:42] <xnox> however i hope that people normally have their webserver do tls for them
[16:52] <vorlon> xnox: then I think this needs to be called out in the bug as regression potential and say that it's a risk of regression whose impact is currently unknown and we're willing to accept that risk
[17:22] <vorlon> xnox: I'm unsure if the change in SIGPIPE behavior also has the potential to affect non-perl users of lissl
[17:27] <vorlon> xnox: I've written up the regression potential for libnet-ssleay-perl and reading it does not give me warm fuzzies about accepting this package.  I think the API change to read/write/ssl_read_all/ssl_write_all should be reverted and the tests fixed otherwise
[18:23] -queuebot:#ubuntu-release- Unapproved: cups (cosmic-proposed/main) [2.2.8-5ubuntu1.3 => 2.2.8-5ubuntu1.4] (core)
[19:09] <vorlon> ubuntu-mate/daily-live: eoan-desktop-amd64.iso oversized by 61582336 bytes
[19:09] <vorlon> that's a fair number of bytes
[19:10] <vorlon> Wimpress: ^^ was that something you're still planning to slim down, or raise the limit on?
[19:12] <Wimpress> vorlon: I did slim it down, considerably.
[19:12] <Wimpress> But now I have added the nvidia drivers to the shipl-live seed.
[19:14] <Wimpress> Which add ~115MB to the image.
[19:16] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (disco-proposed/main) [2.578.4 => 2.578.5] (desktop-core)
[19:34] <vorlon> rbasak: why do you say it was wrong to continue overriding the pcs autopkgtests which have always been garbage?
[19:36] <vorlon> rbasak: (more precisely, they regressed when /etc/init.d/networking stopped being part of the system)
[20:50] <xnox> vorlon:  shall we do a codesearch of users of read/write?
[20:51] <vorlon> that wouldn't catch 3rd party software
[20:52] <vorlon> xnox: wouldn't it be better to revert the api change, and fix whatever the other problem was with the tests?
[20:53] <xnox> vorlon:  the other problem is that TLSv1.3 started to generate a lot more WANT_READ WANT_WRITE errors, and they were never been properly testing with TLSv1.2 as no renegotiation was done.
[20:53] <xnox> and for people to install hooks they need access to a non-eating read/write......
[20:54] <vorlon> xnox: so we can't sanely support TLSv1.3 from perl without changing the API?
[20:54] <vorlon> OTOH
[20:54] <vorlon> wouldn't it be better to not support TLS1.3 from perl than to break existing third-party code?
[20:55] <xnox> vorlon:  i had an upload to cap context at tls1.2 and be done with it
[20:55] <xnox> vorlon:  but that also means nobody gets tls1.3
[20:55] <xnox> defeating a bit the point of this sru.....
[20:55] <xnox> vorlon:  also 3rd party software in perl?!
[20:56] <vorlon> xnox: I thought the point of sruing the perl bindings is to make sure updating openssl /didn't break the perl bindings/, not to enable TLSv1.3 support in perl
[20:56] <vorlon> I would be happier with capping perl @ 1.2 than breaking the API
[20:59] <xnox> vorlon:  https://paste.ubuntu.com/p/D76nnxWNnY/ is the patch i had around for while whilst the hang drama was ongoing
[21:00] <xnox> it is unexpected behaviour. cause max_proto would be set
[21:00] <xnox> but that only covers i think the CTX api only
[21:00] <xnox> not the SSL api
[21:00] <vorlon> xnox: if you wanted to do the work, I think we could in principle make read/write return short reads only for TLSv1.3; retain the existing behavior for earlier protocol versions; and cap to TLSv1.2 by default requiring someone to opt in from the perl code
[21:01] <vorlon> but barring that, I would still rather cap to 1.2 now, avoid changing the api, and possibly deal with perl 1.3 support later in a separate SRU
[21:01] <xnox> ok
[21:01] <xnox> let me have a cup of tea
[21:19] -queuebot:#ubuntu-release- Unapproved: libseccomp (disco-security/main) [2.4.1-0ubuntu<IP_ADDRESS> => 2.4.1-0ubuntu<IP_ADDRESS>] (core) (sync)
[21:19] <xnox> vorlon:  wait a minute.
[21:20] -queuebot:#ubuntu-release- Unapproved: libseccomp (cosmic-security/main) [2.4.1-0ubuntu<IP_ADDRESS> => 2.4.1-0ubuntu<IP_ADDRESS>] (core) (sync)
[21:20] <xnox> vorlon:  "SSL_MODE_AUTO_RETRY has been made the default"
[21:21] -queuebot:#ubuntu-release- Unapproved: libseccomp (bionic-security/main) [2.4.1-0ubuntu<IP_ADDRESS> => 2.4.1-0ubuntu<IP_ADDRESS>] (core) (sync)
[21:21] <xnox> https://wiki.openssl.org/index.php/TLS1.3#Non-application_data_records
[21:21] <xnox> so ssl_read()/ssl_write() should be auto-consuming things anyway.......
[21:21] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.48 => 2.408.49] (desktop-core)
[21:21] -queuebot:#ubuntu-release- Unapproved: libseccomp (xenial-security/main) [2.4.1-0ubuntu<IP_ADDRESS> => 2.4.1-0ubuntu<IP_ADDRESS>] (core) (sync)
[21:21] <vorlon> xnox: ah
[21:22] <vorlon> xnox: in that case feel free to edit the regression-potential text back
[21:22] -queuebot:#ubuntu-release- Unapproved: accepted libseccomp [sync] (disco-security) [2.4.1-0ubuntu<IP_ADDRESS>]
[21:22] <xnox> vorlon:  but that also has the blocking/non-blocking sockets caveats.
[21:22] -queuebot:#ubuntu-release- Unapproved: accepted libseccomp [sync] (bionic-security) [2.4.1-0ubuntu<IP_ADDRESS>]
[21:22] -queuebot:#ubuntu-release- Unapproved: accepted libseccomp [sync] (cosmic-security) [2.4.1-0ubuntu<IP_ADDRESS>]
[21:22] <xnox> i think i want to double check with upstream on that.
[21:23] -queuebot:#ubuntu-release- Unapproved: accepted libseccomp [sync] (xenial-security) [2.4.1-0ubuntu<IP_ADDRESS>]
[21:23] <xnox> vorlon:  also upstream does cross-test a wide matrix of openssl releases, perl releases, and the perl library.
[21:23] <xnox> they test like all the combinations possible back to forever, and multiple openssl versions & implementations
[21:24] <vorlon> ok
[22:18] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.49]
[22:21] <Eickmeyer> Is there an AA that can process lsp-plugins in the NEW queue?
[22:22] <Eickmeyer> Also, we (the Ubuntu Studio team) now have two packages that need sponsoring.  (bug 1829562 and bug 1831154)
[22:23] <Eickmeyer> Expect more new packages for Ubuntu Studio this cycle. We're WAY behind, and still playing catch-up after the two years of stagnation.
[23:06] <rbasak> vorlon: the pcs autopkgtest might have been garbage before, and may well still be, but the failures in Disco for 0.10 AIUI was a true positive - it correctly failed due to an installability problem that correctly should have blocked proposed migration before it got any further (to something that may or may not be correct - I haven't looked)
[23:07] <rbasak> vorlon: the errors changed.
[23:21] <xnox> but we can't tell the difference between always failed, and always failed but differently now.
[23:21] <xnox> unless there is uninstallability return codes that are returned back to britney? ie. "can't even install"
[23:28] <rbasak> xnox: I was under the impression that the whole point of a versioned badtest was that there would be a manual check before bumping the version forward.
[23:28] <rbasak> I suppose another reason is that if it starts magically working then it won't be ignored forever.
[23:29] <rbasak> But if all we're doing is bumping it forward blindly if it is still failing, then what's the point of doing it manually like this?
[23:30] <rbasak> Anyway, I need to go.
[23:30] <rbasak> I'll check back later.


[21:43] <britanico> Hi. Anyone use expressvpn and managed to get firefox addon to work? There is consistent pain with it after every update, but cannot remember the trick to get addon to see installed.  Works via terminal without issues


[06:52] <dholbach> good morning
[14:30] <l3on> Hello .. someone here could review this ? https://bugs.launchpad.net/ubuntu/+bug/1299015
[14:30] <l3on> thanks in advance!
[14:34] <l3on> nevermind .. I will mail motu-list


[00:53] <holstein> .g white horse blackmountain
[00:53] <holstein> oops
[00:53] <holstein> im playing at ^^ here in a bit
[00:53] <holstein> http://holstein.shacknet.nu:8227/stream.ogg