[04:07] <nunyab> Hello, has anyone heard of a fix for the logon on loop issue, most forum discussions say it is related to desktop resolution but none of their "fixes" work for me
[04:09] <nunyab> now I am getting....  Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details -  1: Failed to get connection to session: Failed to connect to socket /tmp/dbus-xV8IiXCKol: Connection refused)
[08:14] <pitti> Good morning
[08:17] <bryyce> heya pitti
[08:25] <chrisccoulson> good morning everyone
[08:26] <pitti> hey chrisccoulson
[08:27] <chrisccoulson> hey pitti, how are you?
[08:27] <pitti> I'm great, thanks! How about you?
[08:27] <chrisccoulson> yeah, not too bad, but a little cold
[08:38] <seb128> good morning
[08:38] <chrisccoulson> good morning seb128
[08:39] <seb128> hey chrisccoulson
[08:39] <seb128> how are you today?
[08:39] <pitti> bonjour seb128
[08:39] <chrisccoulson> yeah, i'm ok thanks. and you?
[08:39] <seb128> hey pitti!
[08:39] <seb128> I'm good
[08:39] <pitti> chrisccoulson: cold> get well soon then!
[08:39] <seb128> not fully awake yet but after some extra coffee that will do
[08:39]  * pitti shivers, temperatures below zero for two weeks aren't my definition of "comfortable"
[08:40] <seb128> same here
[08:40] <chrisccoulson> pitti - oh, sorry, i meant i was feeling cold rather than having a cold. i'm not feeling ill just yet ;)
[08:40] <pitti> aah
[08:40]  * pitti hands chrisccoulson a blanket
[08:40]  * chrisccoulson thanks pitti
[08:41] <chrisccoulson> it's quite cold at work, as most of our building is empty now, so they keep the heating off in those parts to save money
[08:42] <chrisccoulson> but it makes it cold everywhere
[08:54]  * baptistemm hugs chrisccoulson to heat him on
[09:47] <huats> morning
[09:48] <bittin_> morning
[10:47] <seb128> asac, hey
[10:48] <mpt> mvo, hi, can you remind me of the command to rebuild the USC database (e.g. when switching from the PPA package to software-center trunk branch)?
[10:48] <seb128> asac, will you do the gnome-bluetooth 2.29 update too?
[10:48] <seb128> asac, just asking before starting on it to not dup work
[10:48] <mvo> mpt: if you run from trunk, just delete data/xapian/* - trunk builds a local DB
[10:49] <mvo> mpt: you will need the aptdaemon from the PPA on karmic for current trunk
[10:51] <mpt> mvo, I do have aptdaemon from the PPA, but after deleting data/xapian/* I have the same problem as before it: The only department that shows up is "System Packages".
[10:52] <mpt> mvo, and lots of "console message: undefined @1: ReferenceError: Can't find variable: addCategory"
[10:55] <mvo> mpt: rigtht, the software-center.menu file got updated, easieist is to run bzr-buildpackage and then sudo dpkg -i ../build-area/*1.1.7*.deb - or I can upload to the PPA if you prefer that
[10:56] <mpt> I'll try the buildpackage thingy first
[11:00] <mpt> mvo, that fails with "gpg: /tmp/debsign.l6wyJ0ec/software-center_1.1.7.dsc: clearsign failed: secret key not available"
[11:00] <seb128> mpt, it's not failing
[11:00] <seb128> mpt, it's just a warning saying you don't have a key to sign
[11:00] <seb128> that's fine for a local build
[11:00] <mvo> mpt: that is ok
[11:01] <mpt> "bzr: ERROR: The build failed."
[11:01] <mpt> If it's not failing, it has a funny way of showing it ;-)
[11:01] <seb128> depends of what call fail
[11:01] <seb128> it's not good to upload
[11:01] <seb128> but it's good to locally install
[11:01] <seb128> the debs should be there
[11:01] <mpt> huh, so they are
[11:02] <mpt> I guess that's what they call "catastrophic success"
[11:05] <mvo> mpt: please let me know if it works with the new version, I leave for lunch now but will read scrollback
[11:05] <mpt> mvo, "software-center depends on aptdaemon (>= 0.11+bzr322); however: Version of aptdaemon on system is 0.11+bzr319-0ubuntu1~ppa1."
[11:06] <mpt> Oh, that's just because I haven't installed updates yet this morning
[11:06] <mpt> never mind
[11:07] <mpt> Hm, it's not good for Update Manager to bring up the "You have 1 broken package on your system! Use the 'Broken' filter to locate it." alert when Update Manager has no such thing as a "Broken" filter
[11:07] <seb128> technically it's not update-manager since that comes from synaptic
[11:08] <seb128> but right not good from an user view
[11:08] <mpt> I guess that would disappear if/when Update Manager used aptdaemon
[11:08] <seb128> yes
[11:09] <mvo> hm, i fix that after lunch
[11:28]  * mpt giggles in delight at the new "Games" screen
[12:20] <davmor2> Just a quicky is it known that there is no evolution on todays iso
[12:29] <gord> davmor2, are you sure? its not in the internet menu, its in office
[12:31] <davmor2> gord: nope not in internet not in office and not in notification applet either
[12:33] <davmor2> gord: also calendar applet doesn't open it and nor does typing evolution into the terminal
[12:40] <seb128> Amaranth, mvo: do you plan to do a compiz upload soon?
[12:41] <mvo> seb128: not currently, why? I can do one if needed?
[12:41] <seb128> mvo, it needs a rebuild for libgnome-desktop soname change
[12:41] <seb128> mvo, no hurry but I was pondering between doing it or wait for your next upload
[12:42] <mvo> seb128: let me quickly check bzr
[12:42] <seb128> mvo, there is no code change required I think, the api change is the gnome-bg api which I don't think compiz uses
[12:44] <rodrigo_> how the hell do you specify a port for a server on xchat / xchat-gnome?
[12:44] <mvo> seb128: nothing pending, feel free to just upload (but please keep bzr in sync) - I can also it, either way is fine for me
[12:44] <rodrigo_> it doesn't like host:port
[12:44] <seb128> mvo, I will do it
[12:45] <james_w> rodrigo_: host/port
[12:45] <seb128> mvo, speaking about keep bzr in sync you didn't for cheese ;-)
[12:46] <seb128> mvo, (cost me a reject, fix, reupload round yesterday)
[12:46] <rodrigo_> james_w: yay, that did it, why it doesn't use host:port ?
[12:46] <james_w> because it is special
[12:46] <Tm_T> xchat indeed is special
[12:47] <mvo> seb128: I do not even remember touching that
[12:47] <mvo> oh, right
[12:47] <seb128> mvo, you sponsored a gconf key change
[12:47] <seb128> mvo, anyway no worry I fixed it
[12:47] <rodrigo_> yeah, indeed it's special
[12:47] <seb128> I just hate when I notice that bzr out of sync because the upload got rejected
[12:48] <seb128> we need better tools to warn you that what you try to build is not in sync with the archive or something ;-)
[12:49] <mvo> agreed
[12:49] <pitti> perhaps debuild -S could fail if DEBEMAIL =~ /ubuntu/ and there is a Vcs-Bzr:.*launchpad.net, but no .bzr?
[12:49] <pitti> (it quickly gets hackish at this point, though :-( )
[12:49] <seb128> mvo, do you have any clue if Amaranth is still working on the compiz cleaning?
[12:49] <seb128> or splitting things we don't use in a new binary
[12:50] <pitti> in general, folks should use debcheckout first nowadays
[12:50] <seb128> pitti, I do use bzr pull usually
[12:50] <seb128> and then do changes
[12:50] <seb128> and bzr-buildpackage
[12:50] <pitti> seb128: then you already know it's in bzr
[12:51] <seb128> pitti, well I've checked of all the things I work on
[12:51] <pitti> I mean if you want to do a drive-by fix for a random packge
[12:51] <pitti> you should never start with "apt-get source", but "debcheckout"
[12:51] <seb128> checked -> checkouts
[12:51] <seb128> right
[12:51] <seb128> in this case I did update something I had a checkout for already
[12:51] <pitti> I mean "you" == "anybody", not "you" == "seb128" in this case
[12:51] <seb128> so that would not prevent such issues for those cases
[12:52] <pitti> no, I meant mvo should have used debcheckout
[12:52] <seb128> maybe he did but forgot to push
[12:52] <seb128> I did that a couple of time
[12:53] <seb128> anyway that's not happening too often nowadays
[12:54] <seb128> pitti, btw do you have an opinion about converting desktop components to use source in bzr in the standard location now?
[12:54] <seb128> rather than debian dirs as we do
[12:54] <pitti> I'm a bit torn here
[12:55] <pitti> from a design POV it would certainly be nice once having the full source actually makes sense (i. e. we have upstream imports and can directly merge from upstream trunk)
[12:55] <pitti> but I don't think we're quite there yet
[12:55] <pitti> right now, having the full history in bzr just makes things excruciatingly slow for no real benefit
[12:56] <pitti> you have to push MBs over MBs of data to launchpad to do a single quick change
[12:56] <pitti> and upload bandwidth is still scarce for most people (for me, anyway)
[12:57] <seb128> yeah, same here
[12:57] <pitti> in theeeeeory, LP should have stacked branches
[12:57] <pitti> so pushing a new fix to a new branch should be trivial
[12:57] <pitti> but it just doesn't work
[12:57] <seb128> I scp things on canonical servers and wget the tarball there for uploads
[12:58] <pitti> and even if you can directly commit to the ~ubuntu-desktop branch, you still have to download the entire history
[12:58] <seb128> I'm quite happy with what we have now so I was not pushing for change
[12:58] <pitti> and the history is both big and useless, since it's tarball imports, not the real trunk
[12:58] <seb128> I was just checking other people don't get blocked on a workflow they don't like because or me there
[12:59] <seb128> that doesn't seem to be the case for you ;-)
[12:59] <pitti> I'm quite happy with what we have right now, TBH
[12:59] <seb128> ok, let's stay on that for this cycle
[12:59] <seb128> we can revisit that later
[12:59] <seb128> thanks
[12:59] <pitti> if I do an upstream fix for gnome, I still have to get the upstream git, apply it there, and do a git format-patch, of course
[12:59] <pitti> but that wouldn't be any different with having everythign in bzr
[13:01] <seb128> right, everything would be great if GNOME was using the same vcs and you could cherrypick commits in one command and push those
[13:01] <seb128> but since that's not the case...
[13:02] <james_w> pitti: stacked branches should work. If they don't for the package branches that's a bug and I'd like to take a look at it.
[13:03] <pitti> james_w: the other day I got ubiquity, did a commit, and pushed to my branch; that uploaded some 90 MB of data
[13:03] <pitti> which took me some half an hour..
[13:04] <james_w> ouch
[13:04] <pitti> and I got that for other packages as well
[13:04] <james_w> I don't suppose you can grab the ~/.bzr.log snippet for that could you?
[13:05] <james_w> searching for "fetch logic.*ubiquity" should pick out relevant chunks
[13:06]  * pitti gets the relevant chunk
[13:08] <pitti> james_w: http://paste.ubuntu.com/352901/ is the relevant bits
[13:09] <james_w> wow, not a lot of information there :-)
[13:10] <james_w> thanks, I'll file a bug requesting more details be logged
[13:11] <pitti> james_w: could it be an older format?
[13:12]  * seb128 kicks the pc speaker
[13:12] <seb128> xset -b doesn't work
[13:12] <james_w> pitti: it does seem to be
[13:12] <james_w> that might have something to do with it
[13:14] <james_w> bug 504232
[13:14] <james_w> in case we need to do this again sometime :-)
[13:16] <pitti> james_w: thanks; I sub'ed, and commented
[13:38] <seb128> asac, hey
[13:40] <asac> seb128: g-b?
[13:40] <asac> if you want to do it today, go ahead
[13:41] <seb128> asac, I will have a look
[13:41] <seb128> asac, could you push your changes to bzr?
[13:41] <seb128> asac, the bzr is outdated by several updates
[13:42] <seb128> asac, you also wrongly dropped the status icon change, it's back to colored icon
[13:42] <seb128> asac, or crevette did and you didn't catch the issue
[13:42] <seb128> asac, don't worry I will handle the update and the icon issue, if you could just push your changes ;-)
[13:43] <seb128> or did you stop using bzr for this one?
[13:55] <kenvandine> is there any known problems with language-pack-en?
[13:56] <kenvandine> after updating this morning my locale seems to have disappeared
[13:56] <seb128> bug #504198
[13:56] <kenvandine> seb128, thx :)
[13:56] <seb128> you're welcome
[13:57] <kenvandine> yay
[13:57] <kenvandine> that fixed it :)
[13:57] <seb128> good
[13:58] <kenvandine> man things are unhappy when it can't set the locale :)
[13:58] <pitti> hey kenvandine
[13:59] <pitti> kenvandine: sudo apt-get locale-gen --purge should help
[13:59] <pitti> kenvandine: (bug is known and filed)
[14:05] <seb128> pitti, do you follow device-kit power upstream changes?
[14:05] <seb128> pitti, do you know if the battery estimation code will be turned on before lucid?
[14:07] <pitti> seb128: I didn't have a look at it recently, I'm afraid I don't know; I thought it already had code for that?
[14:08] <seb128> pitti, right, the configure option is off by default though
[14:09] <seb128> pitti, don't bother, I was just looking at this bug your forwarded because extra users commented saying they also have no battery estimation since karmic
[14:18] <pitti> rickspencer3: good morning
[14:18] <pitti> gosh, I just wasted 20 minutes debugging why my new work item tracker spits out wrong numbers, only to finally see that they are actually correct, and the current chart is wrong
[14:19] <kenvandine> rodrigo_, ping
[14:20] <kenvandine> rodrigo_, your latest branch doesn't have my pythondir fix, which i think was merged into trunk already
[14:22] <chrisccoulson> pitti - perhaps you have not had enough coffee ;)
[14:23] <pitti> chrisccoulson: clearly not, since I don't drink coffee :)
[14:23] <pitti> chrisccoulson: it just shows me how urgent this work item tracker rewrite actually is
[14:23]  * seb128 thinks pitti is slowly turning into a manager
[14:23] <pitti> feeding my boss wrong numbers, rickspencer3 could never sleep well!
[14:24] <pitti> argh! no! argh!
[14:24] <pitti> :)
[14:24]  * seb128 hugs pitti
[14:24]  * pitti hugs back seb128
[14:24]  * chrisccoulson hugs seb128 and pitti
[14:24] <pitti> hugfest!
[14:25]  * pitti hugs chrisccoulson
[14:25]  * seb128 hugs chrisccoulson
[14:48] <seb128> asac, I've uploaded gnome-bluetooth 2.29.3, the icon issue is fixed in this version
[14:48] <seb128> asac, let me know if you have your changes in bzr and didn't push or if you didn't use bzr
[14:49] <seb128> asac, just to know if I should just copy the current version to bzr and push that or not
[14:54] <asac> seb128: i can replay everything if we still want that
[14:55] <asac> but we have the Distributed development import now
[14:55] <asac> not sure if we really want that
[14:55] <asac> do we need a special branch still?
[14:55] <seb128> we discussed that before with pitti
[14:55] <seb128> our upload suck basically
[14:55] <seb128> and since upstream is not in bzr and full source in bzr doesn't win anything we stay on debian dir only for now
[14:55] <asac> our upload?
[14:55] <asac> hmm
[14:55] <asac> ok
[14:56] <asac> though it would help people to not forget that ;)
[14:56] <seb128> it takes ages to push new version updates if you have full source
[14:56] <asac> then i can replay it for you if you want
[14:56] <seb128> where pushing only debian changes is quick
[14:56] <asac> yeah
[14:56] <seb128> well we have a vcs url in the control
[14:56] <seb128> I don't really care strongly which one
[14:56] <seb128> the one listed is just outdated
[14:56] <seb128> either it should be dropped or updated
[14:57] <seb128> I will keep debian only my the things I usually work on
[14:57] <seb128> but I've no strong opinion for this one
[14:57] <seb128> do whatever you find easier
[14:57] <davmor2> seb128: I just been hunting down the evolution missing issue is appears that evolution-documentation-en is 2.28.1-0ubuntu2 but evo itself is 2.28.2-1ubuntu3.  If I remove the docs I can install evo
[14:58] <seb128> evolution-documentation-* have been dropped in lucid
[14:58] <seb128> since we have proper langpack for documentation now
[14:58] <seb128> the split is of no use
[14:59] <davmor2> seb128: okay so I'll check that again tomorrow then and ensure that evolution is on the cd
[14:59] <seb128> it's not today?
[14:59] <seb128> how can that happen if it's seeded?
[14:59] <davmor2> seb128: nope
[15:00] <davmor2> seb128: I'm assuming it is because e-d-en is installed
[15:00] <seb128> that doesn't make any sense to me
[15:00] <davmor2> seb128: evo-data-server is on but evo the app isn't
[15:01] <seb128> why would -en be installed?
[15:01] <seb128> it's not built in lucid
[15:01] <seb128> and there is no rdepends
[15:04] <seb128> davmor2, can you check with slangasek what's going on?
[15:05] <davmor2> seb128: no probs
[15:05] <seb128> thanks
[15:11] <pitti> asac: hm, my work item tracker really gets confused about you being in both canonical-desktop-team and canonical-mobile-team :)
[15:11] <davmor2> seb128: just for your info http://imgbin.org/index.php?page=image&id=1135 is evo listed in synaptic
[15:12]  * asac is a multi-team bug ;)
[15:13] <pitti> asac: well, not really confused, it just shows your assigned mobile specs in the desktop report
[15:14]  * pitti tried to simplify the configuration by looking at LP teams and sorting reports by that
[15:14] <pitti> well, I can fix that later on
[15:14] <pitti> and re-add the manual spec pattern stuff
[15:15] <asac> would it help to throw me out of desktop?
[15:15] <asac> and using the pattern?
[15:15] <pitti> asac: either
[15:15] <asac> if it helps just do it. i dont get any permissions from that team i guess ;)
[15:16] <pitti> well, you should stay in ~ubuntu-desktop, that's not a problem (and it would be bad to remove you from there); it's just the canonical-desktop-team thing that causes some duplication
[15:16] <pitti> asac: no permissions, just bug spam :)
[15:17] <pitti> asac: there, less bug spam for you now
[15:18] <asac> heh. no that i notice the difference ;)
[15:23] <rickspencer3> kenvandine seb128 what's the scoopage with the Dx release today?
[15:24] <kenvandine> rickspencer3, pretty big
[15:24] <kenvandine> mostly because of timing and depends
[15:24] <kenvandine> everything is blocked by dbusmenu, which is waiting on a merge
[15:25] <rickspencer3> kenvandine, thanks for the update, is it still on track for today?
[15:25] <kenvandine> yeah, i am pretty beat so if things run to late i will just finish them in the morning
[15:25] <kenvandine> :)
[15:25] <kenvandine> one of them will be a new package and need sponsoring too
[15:25]  * kenvandine hugs seb128
[15:26] <kenvandine> i don't think any of them will be a ton of work for me, but it is waiting for them to start falling into place
[15:26] <seb128> oh, which one?
[15:26] <kenvandine> indicator-me
[15:26] <seb128> I can help on updates, I'm almost done with GNOME catching up now
[15:27] <kenvandine> seb128, nah... they won't be hard
[15:27] <kenvandine> it is mostly waiting for tedg to do his thing
[15:27] <seb128> so let me know if you need me to review, sponsor or update anything
[15:27] <kenvandine> sure
[15:27] <kenvandine> thx
[15:27] <seb128> np
[15:27] <dobey> pitti: hmm
[15:27] <seb128> kenvandine, does the indicator-me change require gnome-panel config change on upgrade?
[15:27] <seb128> or is that transparent?
[15:27] <kenvandine> no
[15:27] <kenvandine> transparent
[15:27] <kenvandine> at least i am pretty sure
[15:28] <kenvandine> tedg, can you confirm?
[15:28] <kenvandine> it should hang off the indicator applet
[15:28] <tedg> seb128: kenvandine: transparent.
[15:29] <seb128> ok good
[15:29] <kenvandine> great
[15:29]  * kenvandine waits for tedg to do his "thing" :)
[15:29] <seb128> go ted go
[16:01] <jcastro> hey, someone fixed the rb icon!
[16:01] <seb128> jcastro, I did
[16:01] <jcastro> <3
[16:01] <seb128> that's for some value of fixed though
[16:01]  * pitti sends a ♥ to seb128, too
[16:01] <seb128> I changed the icon to use the standard rhythmbox one
[16:02] <jcastro> oh, so you hid it. :D
[16:02] <seb128> set_icon is broken so it will not change to the playing one on play but that's an indicator bug
[16:02] <seb128> but at least it's better than a broken icon
[16:02]  * seb128 hugs pitti and jcastro
[16:02] <jcastro> he's fixing it today for real I though
[16:03] <seb128> let's see
[16:03] <seb128> the bug is staying ignored in launchpad for a while now
[16:03] <jcastro> it's ted appreciation day
[16:03] <seb128> ;-)
[16:03] <jcastro> seb128: any idea on the closing tomboy window/quits tomboy instead bug?
[16:03] <seb128> We all appreciate ted, but we also know how busy he can be ;-)
[16:04] <seb128> jcastro, I didn't look at this one
[16:04] <jcastro> unless that's on purpose
[16:04] <jcastro> I don't know if closing an app is supposed to return it to the app indicator area or close it close it.
[16:05] <seb128> I don't think anybody ever wrote a clear policy about that
[16:05] <seb128> rhythmbox has a gconf key for it after year of discussion
[16:05] <jcastro> hah, great
[16:14] <kenvandine> jcastro, there is a bug about that
[16:15] <pitti> coffeedude: hm, did you remove your LP account again, or is LP just going mad? (just got cron mail about the work item tracker complaining about the invalid account)
[16:17] <kenvandine> jcastro, bug 503037
[16:18] <jcastro> kenvandine: yeah, the question is, is that on purpose?
[16:18] <jcastro> ie. are apps that go into app-indicators supposed to act normal or minimize to that area?
[16:19] <kenvandine> should act the same as before
[16:19] <kenvandine> which was to not close
[16:19] <kenvandine> afaik
[16:19]  * kenvandine confirms
[16:20] <coffeedude> pitti, haven't done anything to my account.
[16:21] <coffeedude> I changed the contact email addr for the likewise-open tree to point to a moderated ml.  But nothing should be bouncing.
[16:21] <pitti> coffeedude: ok, thanks; I guess it was just a glitch then
[16:21] <kenvandine> jcastro, i confirmed, closing the search window doesn't quit tomboy in karmic
[16:21] <kenvandine> but it does when using indicator application
[16:22] <kenvandine> i suspect there is some check somewhere to see if the status icon exists, and if it does don't exit
[16:22] <coffeedude> pitti, was it a mail bounce?  Or saying that or coffeedude.jerry is an invalid user?
[16:23] <pitti> coffeedude: the latter
[16:23] <coffeedude> pitti, that's log to be a glitch. I'm logged into LP right now.
[16:23] <pitti> coffeedude: right, nevermind for now; if it happens again, I'll investigate it
[16:23] <jcastro> kenvandine: there's a bp for design to clarify behavior for app-indicator apps.
[16:24] <coffeedude> pitti, ACK.
[16:24] <kenvandine> jcastro, humm... well it doesn't happen when any window is closed
[16:24] <kenvandine> on the search window
[16:24] <kenvandine> closing notes doesn't do it
[16:26] <jcastro> right
[16:26] <jcastro> but hit X on rhythmbox, it doesn't quit
[16:28] <kenvandine> right
[16:28] <kenvandine> some apps are designed to work that way
[16:28] <kenvandine> right or wrong :)
[16:28] <dobey> pitti: can you clarify why the startup issues with the applet are?
[16:28] <jcastro> yeah, I am just saying, we need to figure out which apps are supposed to do what
[16:28] <kenvandine> jcastro, but that would mean closing notes should quit tomboy too
[16:28] <kenvandine> which is weird
[16:29] <kenvandine> and why quit the app when you close the search dialog
[16:29] <kenvandine> which would close all the notes you have open
[16:29] <jcastro> I'm not the one supposed to think of solutions, just point out that kind of stuff.
[16:29] <pitti> dobey: it's about the two work items of your's on https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-startup-speed
[16:29] <jcastro> :p
[16:29] <kenvandine> the current behavior driving me nuts
[16:29] <pitti> dobey: ISTR that the plan was to drop the applet?
[16:29] <kenvandine> everytime i search for a note, i end up killing the 10+ notes i have open
[16:29] <dobey> pitti: i didn't know i had work items on there :)
[16:32] <dobey> pitti: the plan is to drop the applet, yes
[16:33] <kenvandine> dobey, statik said it would probably not make it for a2, but would email you :)
[16:34] <dobey> the new ui is definitely not going to be in a2
[16:34] <kenvandine> basically we aren't expecting anything from you guys until a3
[16:34] <kenvandine> sorry pitti :)
[16:35] <pitti> kenvandine: what about?
[16:35] <kenvandine> not losing the applet by a2
[16:35] <pitti> oh, I'm not at all concerned about that for a2
[16:35] <kenvandine> i know you were hoping for that
[16:35] <kenvandine> good
[16:35] <pitti> beta-1 would be nice, though
[16:35] <pitti> I just trawled through the startup-speed list some days ago and was curious
[16:36] <dobey> well, feature freeze is in a month
[16:36] <pitti> sounds perfect
[16:36] <dobey> so i hope i can have it done by then
[16:36] <dobey> should do anyway :)
[16:36] <dobey> and i'll be at the platform sprint
[16:37] <seb128> pitti, I will probably not done the f-spot change for editing in view mode for next week
[16:37] <pitti> seb128: we can move it to a3 easily
[16:38] <seb128> pitti, upstream didn't land that to 0.6x that we use but is doing some refactoring while adding that to their trunk now
[16:38] <seb128> the thing is work in progress
[16:38] <seb128> and there is a new GNOME on monday
[16:38] <pitti> seb128: the main bits why this spec was a2 was pitivi, gbrainy, dropping gimp, etc.
[16:38] <seb128> I doubt I will manage to work on that by next week
[16:38] <seb128> ok
[16:38] <seb128> I still have pitive mirs, etc on my list
[16:38] <pitti> seb128: these are all done :)
[16:39] <seb128> pitti, well I still need mir for the extra build-depends no?
[16:39] <seb128> pitti, or you did that as well?
[16:39] <pitti> seb128: I'll move the fspot one over to a3 later (I don't want to touch it right now, I just produced an up to date DB which I need for testing and comparing)
[16:39] <pitti> seb128: yep, I did
[16:39] <seb128> pitti, oh you rock
[16:39]  * seb128 hugs pitti
[16:40] <pitti> these became victims of my "get rid of my a2 work items, damnit" sprint :)
[16:40] <seb128> sorry I've not been really active on that this week, took me the week to catch up on GNOME updates, gnome-desktop soname transition, etc
[16:40] <seb128> I wanted that done before the alpha
[16:40] <pitti> seb128: no worries; I see lucid-chagnes is full of seb128 goodness
[16:40] <seb128> ;-)
[16:40]  * pitti hugs seb128
[16:40]  * seb128 hugs pitti
[16:40] <seb128> on that brb
[16:41] <seb128> rebooting to try the gdm update
[16:41] <seb128> I'm done with my list of updates then
[16:41] <seb128> I will have a look to the indicators next
[16:57] <seb128> re
[16:57] <seb128> using a dock station and an external screen is a fail often
[16:58] <seb128> ie suspend while using the docked screen, resume and you get no screen
[16:58] <seb128> and g-s-d tend to crash often
[16:58] <seb128> after what you can't use the magic key to change screen settings
[17:03] <baptistemm> anyone is aware of an issue, that let a black screen at start without no gdm, not alt+F? running to switch VT, I thought it could be an issue with fb (seen in a bug reported) so I blacklisted vga16fb but it didn't fix my issue.
[17:04] <seb128> gdm crashes due to a locale issue
[17:04] <seb128> you can sudo locale-gen --purge to fix it
[17:06] <seb128> baptistemm, I assume it's the same issue
[17:08] <baptistemm> seb128, okay Thx a lot for the tip, I'll try
[17:15] <seb128> tedg, is there a way to disable the user switching in the indicator menu which is in the corner?
[17:17] <tedg> seb128: I thought we had one, you should be able to tell ConsoleKit that you can't user switch.  But I think I checked and I couldn't figure out how to make it work.
[17:18] <seb128> tedg, you don't respect /desktop/gnome/lockdown/disable_user_switching then?
[17:18] <seb128> tedg, would it be hard to do?
[17:18] <tedg> seb128: No, I don't think we do.  It shouldn't be too hard to do.
[17:19] <seb128> ok thanks
[17:26] <rickspencer3> pitti, seb128, kenvandine, ccheney, bryyce, TheMuso, etc...
[17:26] <rickspencer3> everyone is prepared for the distro sprint, right?
[17:27] <kenvandine> rickspencer3, i will be today... i got distracted with all the family stuff
[17:27] <seb128> rickspencer3, define prepared? I didn't know we had to prepare anything for it
[17:27] <rickspencer3> ArneGoetje, ^
[17:27] <seb128> I've ideas of what I want to work on yes
[17:28] <kenvandine> i'll make sure i am today
[17:28] <seb128> but that's about it
[17:28] <rickspencer3> seb128, like, know when it is, booked or booking travel, etc...
[17:28] <seb128> oh, that, sorry
[17:28] <seb128> yes
[17:28] <rickspencer3> I kind of lost track of it, and am worried that I didn't get everyone to dial in
[17:28] <seb128> you can check the list on the wiki probably
[17:28] <seb128> people are supposed to add details
[17:28] <seb128> I added my flight info before vac
[17:28] <rickspencer3> I recall an email was sent, but I feel that I kind of dropped the ball making sure all the "i";s were dotted
[17:30] <ArneGoetje> rickspencer3: yes, ticket is issued
[17:30] <pitti> rickspencer3: travel wise, yes, didn't plan a schedule yet
[17:30] <rickspencer3> pitti, you slacker!
[17:31]  * rickspencer3 makes review notes, sprint schedule was not ready one month in advanced
[17:31] <pitti> rickspencer3: hey, I'm busy with making you be able to sleep again :)
[17:31] <rickspencer3> heh
[17:31] <rickspencer3> oops, gotta do a call
[17:31] <rickspencer3> sorry
[17:31] <pitti> rickspencer3: oh, you mean *this* year's sprint? :-)
[18:00]  * ccheney is going to be pushing OOo 3.2.0~rc1-1 into lucid this afternoon, unless there are objections
[18:09] <seb128> I'm off for some sport, be back in 2 hours
[18:09] <seb128> see you later
[18:56] <Ash1> how do i disable the usb single port
[18:58] <vish> mpt: hi...  could you decide on Bug #194472
[18:59] <vish> mathiaz wanted someone to mention if the change to default is desired
[18:59] <Ash1> how do i disable the usb single port
[18:59] <Ash1> how do i disable the usb single port
[18:59] <vish> !topic | Ash1
[18:59] <vish> Ash1: #ubuntu is for support
[19:00] <rickspencer3> pitti, I hate to bug you about this, but I don;t have access to my previous emails atm
[19:00] <rickspencer3> was this the list of the draft a3 plan:
 sure
[19:00] <rickspencer3>  'sup?
[19:00] <rickspencer3> oops
[19:00] <rickspencer3> http://www.piware.de/workitems/desktop/lucid-alpha3/report.html
[19:00] <Ash1> i'm asking about ubuntu desktop machine
[19:00] <djsiegel2> hey kenvandine
[19:01] <kenvandine> djsiegel, yo
[19:01] <djsiegel> kenvandine: https://edge.launchpad.net/hundredpapercuts/+milestone/lucid-round-4
[19:01] <vish> Ash1: this is channel is regarding development... for help kindly join #ubuntu
[19:01] <djsiegel> can you get some people excited about those empathy paper cuts?
[19:01] <djsiegel> who can I talk to about them?
[19:01] <kenvandine> djsiegel, wow... 10
[19:01] <vish> djsiegel: cassidy :)
[19:01] <djsiegel> cassidy?
[19:01] <djsiegel> hey cassidy, look at these lovely empathy paper cuts: https://edge.launchpad.net/hundredpapercuts/+milestone/lucid-round-4
[19:02] <kenvandine> djsiegel, bug 503052
[19:03] <djsiegel> yes?
[19:03] <kenvandine> djsiegel, do you agree with that?
[19:03] <djsiegel> Yes I filed it.
[19:03] <kenvandine> i like it this way :)
[19:03] <kenvandine> ok...
[19:04] <kenvandine> i think it has the same behavior with the status icon
[19:04] <djsiegel> human beings will launch empathy and go... "huh?"
[19:04] <kenvandine> so not just the messaging menu
[19:04] <djsiegel> same with evolution
[19:04] <kenvandine> and rhythmbox
[19:04] <djsiegel> oh I see
[19:04] <djsiegel> right
[19:04] <kenvandine> they start in the last state
[19:04] <djsiegel> can we distinguish how it was launched?
[19:04] <kenvandine> no idea
[19:04] <djsiegel> I think we should err on the side of understandability
[19:04] <kenvandine> but if the window was hidden on quit then it starts hidden
[19:04] <kenvandine> yeah
[19:04] <djsiegel> when I launch empathy from docky or the apps menu
[19:05] <kenvandine> it can be confusing
[19:05] <djsiegel> and no window is shown
[19:05] <djsiegel> it's really bad
[19:05] <kenvandine> but... when it starts in your session for example
[19:05] <kenvandine> i love that it starts hidden
[19:05] <djsiegel> hmm
[19:05] <kenvandine> same for tomboy actually... right?
[19:05] <djsiegel> not sure about tomboy
[19:05] <kenvandine> djsiegel, why not??? consistent behavior :)
[19:05]  * kenvandine ducks
[19:06] <djsiegel> because it's really confusing for normal people
[19:06] <djsiegel> consistent confusion is not good because it's consistent
[19:06] <kenvandine> yeah... but why should tomboy be different?
[19:06] <djsiegel> hehe
[19:06] <djsiegel> I am not talking about tomboy right now
[19:06] <djsiegel> this is the empathy paper jam
[19:06] <kenvandine> yeah... i know
[19:06] <kenvandine> :)
[19:06] <djsiegel> so, when would we want empathy to start hidden?
[19:06] <kenvandine> i think there should be bugs for all the apps that behave this way
[19:06] <djsiegel> (1) Session, (2) status menu
[19:07] <kenvandine> i think if it starts in your session it should
[19:07] <djsiegel> yeah
[19:07] <kenvandine> but by clicking a launcher open the contacts
[19:07] <kenvandine> not sure how to tell the difference
[19:07] <djsiegel> yeah, including when launched from the messaging menu
[19:07] <kenvandine> but i bet we can tell
[19:07] <djsiegel> with a flag>
[19:07] <kenvandine> yeah... it is just a launcher
[19:07] <djsiegel> --start-minimized
[19:07] <kenvandine> hack
[19:07] <kenvandine> :)
[19:07] <kenvandine> i think there should be some property on the window or something
[19:08] <djsiegel> so, we have two things to weigh against each other
[19:08] <djsiegel> (1) current behavior of not showing the buddy list when you go online via the status menu or when empathy starts with your session
[19:08] <djsiegel> (2) confused users who launch empathy by other means and see no window open
[19:09] <chrisccoulson> kenvandine - to check if an application was started from the session manager or not, just look for the DESKTOP_AUTOSTART_ID in the environment
[19:09] <chrisccoulson> gnome-session sets that on autostart apps
[19:09] <kenvandine> great
[19:09] <chrisccoulson> if it's not there, then it was started manually
[19:09] <kenvandine> djsiegel, so we could easily just check that and if it is set hide it :)
[19:09] <kenvandine> otherwise not hide
[19:09] <chrisccoulson> or DESKTOP_STARTUP_ID, i will check just to make sure :)
[19:09] <kenvandine> all though not sure how upstream feels about that
[19:10] <kenvandine> chrisccoulson: thx
[19:10] <kenvandine> djsiegel, upstream does the start in previous state stuff...
[19:10] <djsiegel> hmm
[19:10] <kenvandine> cassidy: opinions?
[19:10] <kenvandine> djsiegel, we would need to ignore the previous state
[19:10] <kenvandine> which i am fine with
[19:10] <djsiegel> yeah
[19:11] <djsiegel> I mean, sometimes I will leave empathy window hidden, then use my computer a couple days later and scratch my head when I launch empathy and see no buddy list
[19:11] <kenvandine> :)
[19:11] <djsiegel> if it happens to me, I imagine it happens to many people
[19:11] <kenvandine> we already ignore that behavior if you click on it in the indicator
[19:11] <djsiegel> especially anyone who wouldn't think it terms of stored previous state affecting the window visibility across restarts
[19:11] <kenvandine> we force it to raise instead of toggle
[19:11] <kenvandine> which upsets some people
[19:12] <kenvandine> yeah
[19:12] <djsiegel> who can I chat with this about upstream?
[19:13] <djsiegel> I mean, I guess all we would really need to do is add some mechanism to just detect the "empathy was launched from empathy.desktop"
[19:13] <djsiegel> keep existing confusing behavior, unless the user clicked a launcher in their session
[19:13] <djsiegel> then force show the buddy list
[19:14] <kenvandine> well we can detect it wasn't started by the session
[19:14] <kenvandine> by checking env
[19:14] <djsiegel> I would not worry about that case
[19:14] <djsiegel> because the user didn't initiate anything
[19:15] <djsiegel> we just need to fix one case for this paper cut
[19:15] <djsiegel> (1) user clicks on empathy (2) nothing happens
[19:15] <kenvandine> yeah
[19:15] <djsiegel> (as far as the user sees)
[19:15] <kenvandine> so we check to see if we were started with the session, and if not raise the contacts list
[19:15] <kenvandine> otherwise (1) do what we do now (2) start hidden
[19:15] <djsiegel> hmm
[19:16] <djsiegel> so, we don't want to always show
[19:16] <djsiegel> even if not started with session
[19:16] <djsiegel> in the case where I set my status to available?
[19:16] <djsiegel> or does that just trigger telepathy and not empathy?
[19:17] <djsiegel> yeah, I suppose if (DESKTOP_AUTOSTART_ID) start hidden; else start_visible
[19:17] <djsiegel> that could do it
[19:17] <djsiegel> I will post something upstream
[19:17] <djsiegel> on the bug
[19:17] <djsiegel> oh there isn't an upstream bug
[19:18] <kenvandine> i'll gladly create the patch
[19:18] <kenvandine> djsiegel, can you do the upstream bug?
[19:18] <djsiegel> ok, so this is not caused by the Messaging menu per se
[19:18] <djsiegel> I will do the upstream bug thing
[19:19] <kenvandine> yeah, we didn't change any of that behavior
[19:19] <kenvandine> just the toggle
[19:19] <chrisccoulson> kenvandine - as an example, nautilus checks DESKTOP_AUTOSTART_ID to work out if it was autostarted by gnome-session, for similar reasons
[19:19] <kenvandine> djsiegel, what's your opinion on toggle on click as opposed to raise on click?
[19:19] <kenvandine> chrisccoulson: is that just a bool?
[19:20] <djsiegel> kenvandine -- in the m.m.?
[19:20] <djsiegel> toggle seems really weird there
[19:20] <chrisccoulson> kenvandine - no, it's a unique sequence of characters. but you just need to check if it exists or not
[19:21] <kenvandine> djsiegel, same for the status icon, if you click it we force it to raise
[19:21] <kenvandine> but upstream has it toggle
[19:21] <kenvandine> to me it seems weird to toggle, if i click it... i want it :)
[19:21] <kenvandine> not everyone agrees
[19:21] <djsiegel> I think it should do if (empathy is not focused) raise; else hide
[19:21] <kenvandine> especially when closing the window doesn't exit
[19:21] <kenvandine> djsiegel, so you thing toggle?
[19:21] <djsiegel> yeah
[19:22] <djsiegel> it doesn't seem to hurt
[19:22] <kenvandine> you and mpt should have a death match over this :)
[19:22] <djsiegel> I mean, we don't really show the icon
[19:22] <djsiegel> so why bother?
[19:22] <kenvandine> to raise it?
[19:22] <djsiegel> we use the messaging menu
[19:22] <djsiegel> right?
[19:22] <djsiegel> we don't show empathy's status icon
[19:22] <kenvandine> yeah... it is the same code path
[19:22] <djsiegel> so why bother patching this against upstream?
[19:22] <kenvandine> it is in empathy not the indicator
[19:23] <kenvandine> the indicator doesn't decide that
[19:23] <kenvandine> i wish it did :)
[19:23] <djsiegel> By default, ubuntu users are not exposed to this empathy status icon, so I don't see the point of spending our time on it, is what I mean.
[19:23] <kenvandine> djsiegel, no... i am talking about in the indicator
[19:23] <djsiegel> oh, ok
[19:23] <kenvandine> if you click on empathy in the indicator
[19:23] <kenvandine> it raises
[19:23] <djsiegel> yeah
[19:23] <kenvandine> not toggles
[19:23] <djsiegel> right
[19:24] <djsiegel> that is right, I agree
[19:24] <kenvandine> ok
[19:24] <kenvandine> good
[19:24] <kenvandine> it is the same code path, so changing that also changed it for the status icon
[19:24] <kenvandine> which seems fine to me
[19:24] <djsiegel> menu items shouldn't have toggle behavior  like that
[19:24] <djsiegel> yeah
[19:24] <kenvandine> ok
[19:24] <kenvandine> it wasn't important
[19:24] <kenvandine> i just wanted your opinion
[19:24] <djsiegel> cool
[19:24] <kenvandine> that is the behavior we have now
[19:24] <kenvandine> so no action :)
[19:25] <djsiegel> who is the omgubuntu guy? what's his nick?
[19:25] <djsiegel> I am wondering if he wants to work on https://bugs.edge.launchpad.net/ubuntu/+source/empathy/+bug/392488
[19:26] <kenvandine> no idea
[19:26] <jcastro> I thought we had copyright issues with the existing adium theme adaptation thing?
[19:27] <kenvandine> djsiegel, most or all of the existing adium themes i found have copyright's missing and no licenses
[19:27] <kenvandine> i contact a couple people to change that and got no where
[19:27] <kenvandine> i wanted an adium theme in karmic by default
[19:31] <bjf> bryyce, bug 494627
[19:31] <djsiegel> kenvandine, ok
[19:31] <djsiegel> I will try to chase down renkoo
[19:33] <bjf> bryyce, I just tried todays live-cd image and I'm seeing the colormap is all wonky issue referred to in the bug
[19:33] <kenvandine> djsiegel, is renkop your favorite?
[19:34] <djsiegel> yeah, it seems pretty unanimous too
[19:35] <tgpraveen> djsiegel: the prob with renkoo is that it is not suited for multiuser chat like irc etc
[19:36] <tgpraveen> and currently empathy uses the same theme for both single and multi user chat
[19:36] <tgpraveen> a bug for separate themes for separate modes has been requested upstream (by me only iirc)
[19:37] <kenvandine> kwwii had based one off a simpler one
[19:37] <kenvandine> oh renkoo uses the left right side images
[19:37] <kenvandine> which makes sense for one on one chats
[19:39] <djsiegel> what version of webkit will empathy use in lucid?
[19:39] <djsiegel> kenvandine: ^
[19:39] <kenvandine> dunno
[19:40] <djsiegel> can you give me a bottom bound>?
[19:40] <kenvandine> we have 1.1.17
[19:40] <kenvandine> what do you need?
[19:43] <djsiegel> I am chatting with the guy who made renkoo
[19:43] <djsiegel> he's interested in helping out
[19:43] <kenvandine> cool
[19:43] <djsiegel> what license do we need?
[19:43] <kenvandine> :)
[19:43] <kenvandine> i think anything we can freely distribute
[19:43] <kenvandine> one of the CC ones maybe?
[19:43] <kenvandine> or even GPL
[19:43] <kenvandine> kwwii has opinions
[19:44] <djsiegel> he says it's BSD and MIT
[19:44] <djsiegel> so we can do whatever we want with renkoo
[19:44] <kenvandine> ok
[19:44] <kenvandine> that should be fine
[19:45] <kenvandine> finally a adium theme that has a license!
[19:45] <kenvandine> everything kwwii suggested had none
[19:46] <kenvandine> djsiegel, the javascript isn't covered by that license
[19:47] <kenvandine> The fading javascript is not covered in this license. The code is fadomatic and is covered under its own license as set by its author.
[19:47] <kenvandine> so maybe not all of the js
[19:47] <kenvandine> that is from the LICENSE file
[19:48] <djsiegel> ok, i will ask
[19:48] <djsiegel> I asked him to join here
[19:48] <djsiegel> his name is torrey
[19:48] <djsiegel> not sure of his nick
[19:49] <djsiegel> kenvandine: itorrey is our guy
[19:49] <itorrey> hello :)
[19:49] <djsiegel> itorrey: is there anything we can do about the fader js? like replace it with something free?
[19:49] <djsiegel> let me google fadomatic
[19:50] <itorrey> We have a few options. We can pull in dojo's fade code
[19:50] <kenvandine> hi itorrey
[19:50] <djsiegel> ok, fadomatic author is<EMAIL_ADDRESS>[19:51] <itorrey> I work at SitePen and we create the dojo toolkit and we're currently in the process of a major overhaul on the UI and stuff for that website
[19:51] <itorrey> and dojo is MIT/BSD
[19:51] <itorrey> But I think that if the version of webkit you use supports the css animations we may be able to easily write some small JS that toggles the CSS transition for opacity
[19:53] <kenvandine> cool
[19:54] <djsiegel> itorrey kenvandine, that sounds like a better plan than using fadomatic, but I did email the author anyway
[19:54] <djsiegel> wouldn't hurt to have more free code in the world! :)
[19:54] <kenvandine> hehe
[19:54] <kenvandine> yeah
[19:54] <itorrey> I can try a few ways and see what one works the best
[19:55] <kenvandine> itorrey, great
[19:55] <kenvandine> we appreciate it
[19:55] <itorrey> I'm well versed in licensing in open source as well so no worries there :)
[19:55] <djsiegel> itorrey: awesome, I will ask some of our artwork guys to think of some ubuntu-specific changes like new hex color values
[19:55] <kenvandine> djsiegel, talk to kwwii, he already did some of that for another theme
[19:55] <kenvandine> that didn't have a license
[19:55] <djsiegel> kenvandine: ok
[19:55] <kenvandine> so we never did anythign
[19:56] <djsiegel> itorrey, kenvandine, all that's left to do is check IRC conflicts...
[19:56] <djsiegel> itorrey: Empathy also does IRC, and kenvandine thinks renkoo may not work well for irc
[19:56] <itorrey> Does Empathy do IRC as well or does anothe program handle that but uses the same themes?
[19:56] <djsiegel> if it uses alternating buddy images
[19:56] <itorrey> ah hehe
[19:56] <kenvandine> tgpraveen, thought that :)
[19:56] <kenvandine> i am not sure
[19:57] <kenvandine> itorrey, it does use the same theme
[19:57] <kenvandine> i just tested it
[19:57] <djsiegel> it would not be the end of the world if we disable themes for IRC...
[19:57] <kenvandine> and the buddy icons are all on the same side
[19:57] <djsiegel> oh, that seems like it will work then?
[19:57] <kenvandine> yeah
[19:57] <djsiegel> (I am still using pidgin for IRC anyway)
[19:57] <itorrey> What was the concern about Renkoo in Empathy?
[19:58] <djsiegel> itorrey: (1) licensing (2) how renkoo looks in an IRC conversation
[19:58] <djsiegel> that's it I believe
[19:59] <itorrey> Curious what the concerns were with #2
[19:59] <djsiegel> kenvandine: can elaborate -- he just thought the positioning of buddy images wouldn't work or something
[19:59] <itorrey> Ah
[19:59] <kenvandine> djsiegel, that was just a hunch
[19:59] <kenvandine> tgpraveen, was the one that mentioned it
[20:00] <itorrey> On os x there's a bubble theme for Colloquy that's pretty similar that I use for IRC
 djsiegel: the prob with renkoo is that it is not suited for multiuser chat like irc etc
[20:00] <kenvandine>  and currently empathy uses the same theme for both single and multi user chat
[20:00] <kenvandine>  a bug for separate themes for separate modes has been requested upstream (by me only iirc)
[20:00] <kenvandine> it seems fine to me though
[20:00] <itorrey> Ok cool
[20:01] <tgpraveen> well in a irc conversation with many people around like in this one and lots of messages being said constantly
[20:01] <kenvandine> pitti, how do you test jockey?
[20:01] <kenvandine> is there  a way to make jockey pretend to find a driver and install it?
[20:02] <tgpraveen> at that time renkoo would not be pleasant to use because of fading and using lot of space for the message,etc
[20:02] <kenvandine> tgpraveen, so just the wasted space between messages?
[20:02] <djsiegel> yeah, I think we should leave IRC "unthemed"
[20:02] <tgpraveen> kenvandine: and the fade using a lot of time (for each msg so adds up to a delay each time)
[20:03] <djsiegel> but again, think of the audience here
[20:03] <kenvandine> the fade seems real fast
[20:03] <tgpraveen> djsiegel: I agree. though for prettiness
[20:03] <djsiegel> Who uses Empathy for IRC?
[20:03] <kenvandine> djsiegel, not me :)
[20:03] <tgpraveen> there could be some themes that work for irc
[20:03] <djsiegel> Hackers, or novice users looking for help in #ubuntu ?
[20:03] <kenvandine> although it is getting better
[20:03] <kenvandine> tgpraveen, i would be in favor of disabling adium themes for irc
[20:03] <kenvandine> there must be a way
[20:03] <djsiegel> right, I just mean, renkoo could be a good IRC theme for Empathy IRC users
[20:04] <tgpraveen> djsiegel: well on ubuntu it is the default irc client so it can't be ignored though hardly
[20:04] <kenvandine> djsiegel, true
[20:04]  * vish wishes kenvandine fixes the user list in xchat-gnome .. to finally switch from xhcat ;)
[20:04] <djsiegel> yeah
[20:04] <tgpraveen> anyone with some technical skils uses it
[20:04] <kenvandine> vish, hehe :)
[20:04] <djsiegel> I don't
[20:04] <djsiegel> tgpraveen: I use pidgin
[20:04] <djsiegel> heavy users tend to use xchat
[20:04] <djsiegel> irssi
[20:04] <tgpraveen> I too use pidgin
[20:04] <djsiegel> I just think that Empathy IRC users may be "light" IRC users
[20:04] <tgpraveen> one day I will use empathy (hopefully ;-) )
[20:04] <djsiegel> even 1-time users
[20:05] <kenvandine> we could speed the fade up
[20:05] <djsiegel> and therefore, renkoo might be good for them
[20:05] <djsiegel> kenvandine: let itorrey be in charge of that
[20:05] <djsiegel> he's the upstream here :)
[20:05] <itorrey> anybody that uses a tool for extended periods of time will generally customize it to fit their need. If renkoo is too slow for them then they'lll switch the theme. And it is only likely to be hardcore users that would care to switch it
[20:05] <djsiegel> he created a very nice, subtle, successful theme -- let's not make ad hoc changes to please Empathy IRC users lol
[20:05] <tgpraveen> djsiegel: well in time for lucid empathy should be as good as pidgin for irc
[20:06] <tgpraveen> many of the bugs have already been fixed in muc chats
[20:06] <djsiegel> cool
[20:07] <kenvandine> djsiegel, i would be in favor or renkoo, or a varient of renkoo being the default
[20:07] <tgpraveen> I still think for irc no theme would be best. though for 1-1 chat and also chats like 3-4 persons etc might be best with renkoo
[20:07] <kenvandine> make the colors "human" :)
[20:07] <istaz> ideally we should have a way to set different theme for muc and one to one chat
[20:07]  * tgpraveen was afraid of that :-(
[20:07] <djsiegel> kenvandine: awesome, so itorrey will help sort out the fade without fadomatic, then will you package it?
[20:07] <djsiegel> istaz: sounds perfectly reasonable and not hard to do
[20:07] <djsiegel> but not necessary
[20:08] <kenvandine> djsiegel, yup
[20:08] <itorrey> And I'll also see about using the webkit gradients rather than a table full of images
[20:08] <istaz> or have Muc channel handled by a different programm/widget all toegether
[20:08] <djsiegel> awesome, this will be an awesome fix for lucid!
[20:08] <istaz> djsiegel: patch welcome ;)
[20:08] <djsiegel> istaz: I set up my empathy folder in ~/src just three days ago :)
[20:08] <pitti> rickspencer3: yes, that's it
[20:08] <djsiegel> I plan to get hacking
[20:08] <rickspencer3> pitti, can you generate it?
[20:08] <itorrey> Is there a version of Ubuntu and Empathy I should run off of?
[20:08] <kenvandine> itorrey, ping me and i can get it packaged
[20:09] <rickspencer3> when you get a chance?
[20:09] <kenvandine> itorrey, lucid if you can :)
[20:09] <kenvandine> which is in alpha
[20:09] <pitti> kenvandine: yes, there is; copy http://paste.ubuntu.com/353094/ to /usr/share/jockey/modaliases/local
[20:09] <pitti> rickspencer3: like, refresh?
[20:09] <istaz> I don't know what are cassidy actual plans for MUC in 2.30
[20:09] <istaz> the roadmap don't say much
[20:10] <kenvandine> pitti, thx
[20:10] <cassidy> istaz, what's the question? :)
[20:10] <kenvandine> hey cassidy!
[20:10] <cassidy> hi !
[20:11] <istaz> cassidy: how we could improve the irc experience in empathy
[20:11] <istaz> cassidy: and if they are plan to have no theme or a different theme for MUC
[20:12] <cassidy> short term plan is to continue to improve the current UI (see the "multi user chat" bugs)
[20:12] <cassidy> longer term plan is to eventually create a dedicated app for muc (ala xchat-gnome)
[20:12] <cassidy> istaz, https://bugzilla.gnome.org/show_bug.cgi?id=601176
[20:13] <cassidy> not planned for 2.30 but a patch would be welcome :)
[20:13] <istaz> cassidy: yeah tgpraveen mentionner reporting it
[20:13] <cassidy> see the roadmap for muc related changes planned for 2.30 : http://live.gnome.org/Empathy/Roadmap
[20:13] <istaz> djsiegel: if you are interested in making you first contribution in empathy ^ ;)
[20:14] <djsiegel> istaz: I will probably work on paper cuts :)
[20:14] <istaz> djsiegel: ok
[20:14] <istaz> djsiegel: we have a #empathy channel on Gimpnet if you need help getting started
[20:14] <djsiegel> ok, thanks!
[20:14] <cassidy> djsiegel, please be sure that there is an upstream confirmed bug before starting to work on something
[20:15] <djsiegel> cassidy: ok :(
[20:15] <djsiegel> itorrey: http://twitter.com/davidsiegel/status/7490555739
[20:15] <cassidy> djsiegel, once you have open a bug just ping me and I'll look at it soonish :)
[20:15] <istaz> djsiegel: just transfer the bug you find on launchpad to to the gnome bugzilla and ping cassidy
[20:15] <cassidy> but I prefer to have the bug confirmed to avoid to do useless work
[20:15] <djsiegel> cassidy: can you please skim: https://bugs.edge.launchpad.net/hundredpapercuts/+milestone/lucid-round-4
[20:16] <cassidy> I can take a quick look
[20:17] <istaz> cassidy: would you mean if I marked what bugs are already fixed in the roadmap?
[20:17] <cassidy> istaz, they are
[20:17] <cassidy> but the default theme don't change them
[20:18] <cassidy> show
[20:18] <istaz> ah
[20:18] <istaz> cassidy: what theme do you use?
[20:19] <itorrey> Downloading Lucid now and will take a look over things this evening (I'm on Seattle time)
[20:19] <cassidy> istaz, "classic" (which is fugly)
[20:19] <istaz> :/
[20:19] <djsiegel> itorrey: author of Fadomatic says he's flattered and can't believe anyone is still using that script, and we can pick any license we want and he will apply it
[20:20] <djsiegel> haha
[20:20] <itorrey> Ok nice, I'll try fadomatic vs dojo vs css transitions and see what one is best
[20:20] <djsiegel> itorrey: which license should I ask him to apply? (just in case you use it)
[20:20] <djsiegel> we would prefer not to ship anything large like a whole js framework
[20:20] <itorrey> I dual license everything under the BSD and MIT licenses
[20:20] <djsiegel> we have very stringent space requirements on the CD
[20:21] <itorrey> Yeah if we used dojo it'd be like 20k
[20:21] <djsiegel> ok, cool
[20:21] <itorrey> we'd just use the little bit we need
[20:21] <itorrey> gotta go get lunch, back in a bit
[20:21] <djsiegel> peace
[20:21] <istaz> cassidy: you are  right it's ugly
[20:22] <cassidy> fredp, promise me to fix https://bugzilla.gnome.org/show_bug.cgi?id=590421
[20:23] <istaz> ah thanks for liking I was just about to search for one
[20:26] <pitti> rickspencer3: http://piware.de/workitems/desktop/lucid-alpha3/report.html is updated
[20:26] <istaz> *linking
[20:32] <djsiegel> kenvandine tedg, I've been really confused that recently signed-on buddies show up in the messaging menu
[20:32] <kenvandine> djsiegel, only for a few seconds
[20:32] <kenvandine> with no time
[20:32] <kenvandine> that is part of the spec
[20:33] <djsiegel> I only just realized why they were there -- the whole time I thought it was a bug
[20:33] <djsiegel> and it does show a time
[20:33] <kenvandine> mine doesn't
[20:33] <djsiegel> hmm
[20:33] <kenvandine> it should only show a time if there is a message
[20:34] <tedg> djsiegel: Yeah, they're distinguished in the menu by not having a time.  But, they show up there for a limited time.  The goal is to have a quick way to respond to someone you just noticed logged in.
[20:35] <djsiegel> yeah I understand the rationale
[20:35] <djsiegel> when I hear it
[20:35] <djsiegel> but we don't print the rationale in a label in the menu :)
[20:35] <tedg> We do, it's just in a *very* small font :)
[20:40] <rickspencer3> thanks pitti
[20:41] <cassidy> djsiegel, I commented https://bugs.edge.launchpad.net/hundredpapercuts/+bug/502999
[20:51] <pitti> good night everyone
[20:51] <djsiegel> cassidy: ah, I see
[20:51] <djsiegel> well, you should not put something that looks like a button on every buddy in the list
[20:52] <djsiegel> put the buttons in one spot
[20:52] <djsiegel> can you imagine if every song in Rhythmbox had its own play, pause, stop button on every row?
[20:52] <cassidy> kenvandine,  FYI I started to work on https://bugzilla.gnome.org/show_bug.cgi?id=599158 this afternoon. Once it's fixed it should be doable to re-implement the libindicate badger as an Approver
[20:52] <djsiegel> it would look like junk
[20:52] <cassidy> that's not the same
[20:53] <djsiegel> not exactly the same
[20:53] <cassidy> this icon has 2 purposes
[20:53] <djsiegel> but the point is, this is a list of buddy names
[20:53] <cassidy> a) let you know that you can call the contact
[20:53] <istaz> djsiegel: rythmbox doesn't allow to play more than one song at the same time ;)
[20:53] <cassidy> b) be able to quickly click it (most user don't understand right click)
[20:53] <djsiegel> adding controls inside each element in the list is really crowded
[20:53] <istaz> the point is to quickly show you which contact you can call
[20:53] <cassidy> s/click/call
[20:53] <djsiegel> istaz: no, that's not the point
[20:53] <cassidy> it is
[20:53] <djsiegel> the point is to show you capabilities, and it's being used as a click target
[20:53] <kenvandine> cassidy, good... maybe that explains why i was getting grief
[20:54] <djsiegel> I agree the point should be to show who you can call
[20:54] <kenvandine> i had success as an observer
[20:54] <djsiegel> I don't agree it should be a button
[20:54] <djsiegel> I think it would be nice to maybe do this:
[20:54] <cassidy> kenvandine, once it's done, I'll take a look at your code if you want (ping me in a week or so)
[20:54] <djsiegel> I click on a contact, and the item expands
[20:54] <kenvandine> cassidy, sure
[20:54] <djsiegel> to show Call, Chat buttons
[20:54] <cassidy> djsiegel, that's the behaviour in master
[20:54] <djsiegel> what is "that"?
[20:55] <cassidy> djsiegel, see http://people.collabora.co.uk/~cassidy/shot.jpg
[20:55] <djsiegel> yeah I see
[20:55] <djsiegel> I was suggesting something else
[20:55] <djsiegel> like, I click on your name to highlight it
[20:55] <djsiegel>  /then/ it shows me buttons labeled "call" or "chat"
[20:56] <kenvandine> djsiegel, in place?
[20:56] <djsiegel> right below, in line -- not a context menu
[20:56] <istaz> djsiegel: you mean only display the icon when the contact is selected?
[20:56] <cassidy> that's not really GNOMEish
[20:56] <djsiegel> well, GNOME hasn;t had this use case before
[20:56] <djsiegel> and using a context menu is the lazy solution
[20:56] <kenvandine> cassidy, so? nothing wrong with challenging the norm :)
[20:56] <djsiegel> nothing wrong with being lazy
[20:56] <djsiegel> it's just the tool people grab first, and it leads to lots of menus that aren;t fun to use
[20:57] <istaz> cassidy: why not show the full contextual menu when clicking on these button actually?
[20:57] <djsiegel> you might have a dedicated buttons in a toolbar?
[20:57] <itorrey> By default it could simply show the icons on hover and have the option to always show them in a pref pane
[20:57] <cassidy> kenvandine, sure, but as a GNOME app we try to fit well iin the GNOME desktop and offer a coherent user experience
[20:57] <kenvandine> understand
[20:57] <djsiegel> with a phone, video, and chat buttons in the toolbar that enable/disable according to the selected contact
[20:57] <cassidy> istaz, maybe
[20:57] <istaz> cassidy: or at least have the share desktop and file transfer action
[20:58] <djsiegel> (1) we agree it's nice to look at the buddy list and see who you can call
[20:58] <cassidy> djsiegel, this suck. That means you select a contact and then have to move your mouse to the top of the contact list to call
[20:58] <djsiegel> cassidy: yeah
[20:58] <djsiegel> or right-click
[20:58] <djsiegel> using a context menu as the main way to initiate a call is worse
[20:58] <djsiegel> a worse experience
[20:58] <djsiegel> you may feel it's faster, and it may be faster, but it's yucky
[20:59] <istaz> but I'm of the option that if we have a menu we better not have a different one than the context menu, it confuse the user to have to remember two different menu structure
[20:59] <cassidy> I don't know. Let's see how it goes with the new popup
[20:59] <djsiegel> I never knew those icons were clickable
[20:59] <djsiegel> and with the proposed change in style, they will look less clickable
[20:59] <djsiegel> also, can I have video but not audio support?
[20:59] <istaz> djsiegel: if you need to select a contact anyway to see if you can call it, you might as well right click it
[20:59] <itorrey> What if we took a step back and looked at it from the perspective of what the user is trying to do. In general, baseline there is going to be audio. Video is a bonus. What if it were a single call button and the call interface enabled video to be started
[21:00] <itorrey> and a pref pane or something that lets you set to auto start video by default or not
[21:00] <itorrey> So the action is call and then video is just an extra that may or may not exist
[21:00] <djsiegel> right, that's my point
[21:00] <djsiegel> Show only one icon/button
[21:00] <djsiegel> the "call" button
[21:01] <djsiegel> it's a phone handset if they don't have video, otherwise it;s a video icon
[21:01] <itorrey> Why make the user make an arbitrary choice based on the technology used?
[21:01] <cassidy> itorrey, there is only one button now
[21:01] <djsiegel> cassidy: but it looks like two things
[21:01] <djsiegel> is the point
[21:01] <djsiegel> the user doesn't know there's only one click target
[21:01] <cassidy> no, there is only one icon in the contact list now
[21:01] <djsiegel> oh
[21:01] <cassidy> yeah, that's why I opened https://bugzilla.gnome.org/show_bug.cgi?id=606235
[21:01] <kenvandine> but it takes you to a context menu?
[21:01] <djsiegel> perfect!
[21:02] <cassidy> kenvandine, yes
[21:02] <djsiegel> yes, this is great
[21:02] <cassidy> djsiegel, try empathy master
[21:02] <kenvandine> cassidy, why not take you to the call dialog?
[21:02] <djsiegel> Yeah, I would start the call
[21:02] <kenvandine> which has the video button already?
[21:02] <djsiegel> and make it easy to disable the video feed if video is enabled
[21:02] <kenvandine> saves a click, generally :)
[21:02] <cassidy> because for some protocol we have to choose if we want an audio or audio/video call before starting the call
[21:02] <cassidy> as we can't add video later
[21:03] <djsiegel> cassidy: ah, ok
[21:03] <kenvandine> humm
[21:03] <cassidy> (thanks google video)
[21:03] <kenvandine> before opening the call dialog even?
[21:03] <djsiegel> just do video if it can
[21:03] <djsiegel> I think it's worth forcing video :)
[21:03] <djsiegel> lol
[21:03] <djsiegel> to get rid of a menu
[21:03] <cassidy> If I'm naked I certainly don't want to automatically start my webcam
[21:03] <cassidy> and then people accidentally start calls when clicking on the roster
[21:03]  * kenvandine especially if i am calling you :)
[21:04] <istaz> kenvandine: we are starting the call as soon as the call dialog is open
[21:04] <kenvandine> humm
[21:04] <kenvandine> ok
[21:04] <cassidy> djsiegel, this one should be easy to fix https://bugzilla.gnome.org/show_bug.cgi?id=603472
[21:04] <kenvandine> why not make that the decision step?
[21:04] <kenvandine> cassidy, i have a patch for making the custom message dialog wider
[21:05] <kenvandine> seems like a no brainer
[21:05] <cassidy> which dialog?
[21:05] <cassidy> the edit custom status?
[21:05] <kenvandine> setting the custom away message
[21:05] <kenvandine> it is one of the bugs
[21:05] <kenvandine> yeah
[21:05] <istaz> kenvandine: otherwhise the user would have to open the call dialog, then click on a call button. Which is strange since if they open the call dialog they want to call anyway
[21:05] <cassidy> kenvandine, I'm looking at the bugs atm
[21:06] <seb128> re
[21:06] <cassidy> hi seb128
[21:06] <seb128> hey cassidy
[21:07] <cassidy> kenvandine, can you please fw your patch uptream? I'll review it tomorrow
[21:07] <seb128> cassidy, how are you?
[21:07] <kenvandine> cassidy, yeah, thx
[21:07] <cassidy> patch applied and not forwarded https://bugs.edge.launchpad.net/hundredpapercuts/+bug/502996/comments/2 :(
[21:07] <cassidy> seb128, good good. Lot of work :)
[21:08] <seb128> hehe, I know that ;-)
[21:09] <cassidy> hopefully one day all the 455 will be closed :)
[21:09] <istaz> cassidy: how much bug were there when you started again?
[21:09] <seb128> ;-)
[21:10] <cassidy> problem is, I usually close one bug and open 2 new ones :D
[21:10] <cassidy> as I tri to have all the tasks list on the bugzilla
[21:11] <seb128> you do a rocking work on empathy ;-)
[21:11] <seb128> now we just need somebody doing that on telepathy-* too
[21:11] <cassidy> thanks :)
[21:11] <seb128> some protocols are buggy
[21:12] <djsiegel> seb128: can we remove "Back" and "Forward" labels from Nautilus for Lucid? they are the only buttons labeled horizontally in the Nautilus toolbar, and they need labels the least
[21:12] <cassidy> seb128, yeah. Hopefully istaz's recent work should improve MSN a bit
[21:12] <seb128> djsiegel, we could, I would prefer having somebody suggesting that on the upstream list though
[21:12] <seb128> better than having distro specific change
[21:13] <seb128> cassidy, oh, butterfly changes? ;-)
[21:13] <seb128> nice
[21:13] <seb128> I've started running empathy again in lucid
[21:13] <seb128> let's see how it goes
[21:14] <cassidy> 2.29.4 works pretty well for me
[21:14] <seb128> so far I'm annoyed by the lack of tooltip infos on contacts
[21:14] <cassidy> the vCard info?
[21:14] <seb128> but otherwise it seems to work good
[21:14] <seb128> well things like idle time on icq
[21:15] <cassidy> this is a protocol feature?
[21:15] <seb128> I don't know, pidgin displays it
[21:15] <seb128> gnomeicu did too
[21:15] <seb128> when I used it
[21:15] <cassidy> I don't have any clue about ICQ tbh
[21:15] <kenvandine> jcastro, i just uploaded the tomboy/appindicator fixes to both lucid and the karmic ppa
[21:16] <seb128> cassidy, well pidgin displays the connected time too in pidgin for jabber
[21:16] <jcastro> <3, thanks!
[21:17] <seb128> -in pidgin
[21:17] <cassidy> seb128, that's probably done by the client then
[21:17] <seb128> cassidy, ups sorry that was an icq contact
[21:18] <seb128> I think it's an icq protocol feature
[21:18] <cassidy> we don't have API to expose that in Telepathy actually
[21:18] <cassidy> so it's not going to happen soonish
[21:18] <seb128> in fact I've the idle time for danilo on jabber
[21:18] <seb128> so it's not icq specific
[21:18] <seb128> ok
[21:19] <seb128> just a detail
[21:19] <seb128> if I complain about detail that's a good sign ;-)
[21:19] <seb128> I like the lines to reconnect in the buggy list if you connect from somewhere else
[21:19] <cassidy> indeed :)
[21:19] <seb128> you just have to click on the reconnect icon
[21:19] <seb128> that rocks ;-)
[21:19] <cassidy> you're the on who asked for it :p
[21:19] <seb128> buggy -> buddy
[21:19] <seb128> yeah
[21:20] <seb128> and I'm happy to see it working ;-)
[21:20] <seb128> I think I will stay on empathy this time
[21:21] <cassidy> \o/
[21:22] <cassidy> let me know when you'll switch back to Pidgin ;)
[21:23] <cassidy> djsiegel, I commented all the bugs on https://bugs.edge.launchpad.net/hundredpapercuts/+milestone/lucid-round-4 and/or their upstream equivalent
[21:27] <seb128> kenvandine, still there?
[21:27] <vish> cassidy: hi... i just included a monochrome icon in humanity for the mic...
[21:27] <seb128> kenvandine, is the package you needed review for ready?
[21:27] <vish> cassidy: you want the icon to be included in empathy itself?
[21:28] <cassidy> vish, can I see it? :)
[21:30] <vish> cassidy: http://bazaar.launchpad.net/~elementaryart/elementaryicons/trunk/revision/388#humanity-icon-theme/Humanity/devices/16/audio-input-microphone.svg
[21:31] <vish> cassidy: it would be great if its in empathy itself... then we can make the icon darker
[21:36] <cassidy> vish, actually this icon is not shipped in Empathy
[21:36] <cassidy> it comes from gnome-icon-theme
[21:37] <vish> cassidy: yup... but we can use a custom icon in empathy itself
[21:37] <cassidy> I prefer to rely on gnome-icon-theme when possible
[21:38] <vish> cassidy: ok , the monochrome icons are now using the namespace -symbolic so i guess that is a small change to do
[21:39] <istaz> seb128: yeah the bug preventing you to make more than one consecutive call should be fixed now
[21:39] <istaz> (well as soon as jonnylamb review my branch)
[21:39] <seb128> nice
[21:39] <istaz> and I'm hoping to have file transfer done by next week
[21:40] <seb128> that would rock
[21:44] <TheMuso> Is wacom-tools on anybody's radar? If its trivial to fix, I'll have a look at it, as its currently breaking studio disk builds.
[21:44] <TheMuso> Well, the disks build, but they are uninstallable.
[21:45] <fredp> cassidy: got it, added to my plate.
[21:46] <cassidy> fredp, the theme bug?
[21:46] <fredp> cassidy: the strike class, yeah.
[21:46] <fredp> cassidy: hit me hard tomorrow afternoon, and I'll do it then.
[21:46] <cassidy> I will :)
[22:09] <chrisccoulson> good evening everyone
[22:10] <seb128> hey chrisccoulson
[22:10] <seb128> how are you?
[22:10] <kenvandine> seb128, no... it will be tomorrow
[22:10] <chrisccoulson> hi seb128, i'm good thanks :)
[22:10] <chrisccoulson> how are you?
[22:10]  * kenvandine heads out for a bit, bbl
[22:10] <seb128> kenvandine, ok
[22:10] <kenvandine> seb128, thx though
[22:10] <seb128> chrisccoulson: good thank you
[22:10] <seb128> np
[22:13] <chrisccoulson> hmmmm, facebook has started appearing in french for me now
[22:13] <seb128> nice ;-)
[22:14] <chrisccoulson> aha, i must have changed the language bt accident
[22:14] <seb128> we should make french the default language for ubuntu too
[22:14] <chrisccoulson> s/bt/by
[22:14] <chrisccoulson> lol
[22:14] <seb128> there was a elibc bug which broke locales yesterday
[22:15] <seb128> it's fixed with today updates though
[22:15] <seb128> you might just be hitting it
[22:15] <chrisccoulson> yeah, i saw that earlier
[22:15] <seb128> btw did you start on g-c-c?
[22:15] <seb128> it's the only source in the default install that need a rebuild for the libgnome-desktop soname change now
[22:16] <chrisccoulson> seb128 - i'm going to do that in a minute. i ran out of time last night
[22:16] <seb128> brb restarting session
[22:16] <chrisccoulson> sorry, i'm a bit slow to type, i've only got 1 hand available atm
[22:19] <seb128> re
[22:19] <seb128> chrisccoulson: don't worry
[22:19] <seb128> chrisccoulson: how is the baby doing?
[22:20] <chrisccoulson> yeah, she's ok. she's just watching the computer screen at the moment
[22:20] <seb128> ;-)
[22:20] <seb128> you don't let her use the keyboard? :-)
[22:21] <chrisccoulson> lol, not yet. the cats occasionally use the keyboard though
[22:21] <seb128> hehe
[22:41] <djsiegel> kenvandine: https://bugzilla.gnome.org/show_bug.cgi?id=606358
[22:55] <ccheney> grr OOo 3.2 is broken in weird ways still
[22:56] <ccheney> will just have to put it off until later and just fixup 3.1.1 to be good enough for the next alpha


[15:18] <cr3> is it possible that for a few seconds, the images on cdimage.u.c not match the MD5SUM file?


[01:10] <Scary_Guy> Meh, I use audacious these days anyway.  I get to use the winamp classic skins so that nostalgia feel is real.  I even made one of them from "scratch" taking screenshots of Traktor 2 and making a Traktor amp in 2002


[13:12] <BluesKaj> Howdy folks
[15:29] <BluesKaj> question arose in another chat: has Kubuntu switched to the Calamares installer? I don't see anything


[00:23] <pleia2> added another article to the doc, and still have a couple in blogosphere and audio and video summaries
[01:47] <pleia2> finished audio&video and did editing, moving everything over + adding stats now
[01:47] <pleia2> still need 4 blogosphere summaries written
[02:24] <pleia2> ok, I finished summaries and am copying over final things
[02:26] <pleia2> Unit193: link check? https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue469
[02:27] <pleia2> sent to summary writers
[02:28]  * pleia2 seeks dinner
[03:03] <Unit193> Yes I do this which you speak of.
[03:09] <Unit193> http://loco.ubuntu.com/events/japaneseteam/3387-ubuntu-16.04-lts-release-party-and-offline-meeting-in-japan/
[22:28] <pleia2> Unit193: thanks, fixed :)
[22:29] <pleia2> looks like I was the only one to do editorial review of this issue, so if anyone else has some time to have a look, I'd appreciate some eyes on it to see if I've missed anything: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue469
[22:29] <pleia2> if it helps, it's a short issue, not a ton to look at :)


[00:07] <tgm4883> Can SRUs include the removal of features?
[00:30] <RAOF> tgm4883: Under extreme circumstances, yes.
[00:32] <tgm4883> RAOF: hmm, ok. I'll take a look at fixing this
[00:51] <mwhudson> sigh, michael wait for the accepted mail before going to lunch
[01:27] <noalternative> I am trying to compile fifth browser into a deb.  I am inexperienced, and I am trying to follow the hithear instructions & I am getting errors.  I have successfully compiled hithear, but I am trying to apply lessons to fifth browser.  Here are the hithear instruction.  I am at debuild -us -uc  https://wiki.debian.org/Packaging/Intro
[01:28] <noalternative> now the errors http://pastebin.com/Ph5QPcWX
[01:28] <sarnold> noalternative: your first message was cut off mid-way through the URL
[01:29] <sarnold> noalternative: what does 'file' report on the fifth_0.4.orig.tar.gz file?
[01:30] <noalternative> https://wiki.debian.org/Packaging/Intro?action=show&redirect=IntroDebianPackaging
[01:31] <noalternative> I am not sure what you mean.
[01:32] <noalternative> maybe I named it wrong?  I downloaded this from source forge, not github
[01:32] <noalternative> tried to rename the file according to instructions.
[01:32] <noalternative> https://sourceforge.net/projects/fifth-browser/files/v0.4/
[01:33] <noalternative> admttedly the original was not a tar.gz
[01:33] <noalternative> so I simply renamed it
[01:33] <noalternative> is that what your getting at?
[01:36] <noalternative> I just wanted to complie the browser for my personal use not as a package maintainer
[01:36] <tgm4883> noalternative: you can't just rename it
[01:36] <noalternative> ok
[01:36] <tgm4883> what was it previously?
[01:37] <noalternative> fifth-0.4.txz
[01:37] <sarnold> try something like fifth-_0.4_orig.tar.xz
[01:38] <tgm4883> sarnold: with the dash in there?
[01:38] <sarnold> I wanted to see what 'file' thought the file is. it might be empty. (that happens). it might be an HTML error page from some stupid download site. or, it might be an xz'd file rather than gzipped file :)
[01:38] <sarnold> tgm4883: nah, probaly better withuo the dash
[01:38] <sarnold> wow
[01:38] <sarnold> how long until tab-complete can just type my thinking for me.. not soon enough
[01:43] <noalternative> http://pastebin.com/KA1nVLzY
[01:44] <noalternative> It liked the original name I think.
[01:44] <tgm4883> noalternative: you should name it fifth_0.4.orig.tar.xz
[01:44] <sarnold> I detest the "rename the tarball" step. so. annoying.
[01:44] <tgm4883> I agree
[01:45] <sarnold> because I can never guess the name to use correctly on the first try, I always wind up having to copy-and-paste the demanded name from this error message :)
[01:46] <sarnold> (you've seen my typing, this shouldn't be a surprise :)
[01:52] <noalternative> We made some headway, but it ultimaely retruned errors.  I can't cut and paste all of it from my terminal because my terminal stops before the command was given.
[01:53] <noalternative> Is there a log I can paste?
[01:53] <noalternative> or maybe a specific part of the terminal like the part about errors.
[02:01] <noalternative> Here are errors from a file called fifth_0.4-1_amd64.build
[02:02] <noalternative> http://pastebin.com/TeCS4BWC
[03:51] <infinity> tgm4883: You absolutely can just rename orig tarballs.
[03:51] <tgm4883> infinity: you can just rename an orig tarball from a .tar.xz to .tar.gz?
[03:52] <infinity> tgm4883: Oh.  No.  I missed the context, I guess. ;)
[03:53] <tgm4883> infinity: hah yea, I didn't think you could do that. I guess I should have said can't just change the extension
[03:53] <tgm4883> although you kinda can, if you know what you're doing
[03:53] <infinity> tgm4883: Not in a way that keeps dpkg happy and the file unchanged. :P
[03:53] <infinity> Pick one.
[03:54] <tgm4883> infinity: well in this case, we had to change .txz to .tar.xz
[03:54] <infinity> 'tar xf' autoguesses these days, but dpkg-source ain't having none of that modern nonsense.
[03:54] <tgm4883> although maybe we didn't need to do that and just rename it to the proper format
[03:54] <infinity> tgm4883: Oh, sure, tgz == tar.gz, etc, though.
[03:55] <tgm4883> yep
[10:08] <Laney> Mirv: trying a test build of ffmpeg ...
[10:08] <Laney> cross your toes
[10:16]  * sil2100 crosses his toes too
[10:30]  * Mirv crorres toes and fingers
[10:34] <cjwatson> Mirv: so ... would you be sad if I just fixed that click test rather than approving your hack, given that I know how to do it and it's fairly easy having spotted the problem?
[10:42] <cjwatson> Mirv: https://code.launchpad.net/~cjwatson/click/new-debsig-policy-url/+merge/302652
[10:48] <Mirv> cjwatson: terrible! (thank you)
[10:49] <Mirv> replacing the silo MP with that
[10:49] <Laney> 'k, that built
[10:49]  * Laney copies
[10:50] <cjwatson> Mirv: thanks; I tested it enough locally that I think it's good
[10:50] <Mirv> Laney: \o/
[11:00] <Laney> gizza builder, launchpad
[11:39] <seb128> hum, does anyone has an idea what's wrong on bug #1611256?
[11:39] <seb128> xenial to yakkety upgrades are hitting that
[11:40] <seb128> "dpkg: dependency problems prevent processing triggers for gconf2:
[11:40] <seb128>  gconf2 depends on python3:any; however:
[11:40] <seb128>   Package python3 is not configured yet."
[11:56] <doko> apw, when do you plan to upload the updated kernel to y?
[11:58] <xnox> doko, in two weeks when he is back from vac?
[11:58] <xnox> =)
[11:58] <ogra_> they allowed him vac ?!?
[11:58] <ogra_> carzy kernel team ...
[11:58] <ogra_> *crazy too
[13:19] <doko> LocutusOfBorg, what are you saying in 1608129? build it once without the tests, and then reenable the tests?
[13:19] <LocutusOfBorg> or build-conflict with itself
[13:20] <LocutusOfBorg> your solution seems good too
[13:20] <LocutusOfBorg> BTW I already asked ginggs but you might want to upload this patch http://paste.ubuntu.com/23021246/
[13:24] <loladiro> Hi folks, hope this is the right channel. I’ve been looking for the `dash` debug symbol package, but been unable to find it. Any pointers?
[13:25] <xnox> loladiro, https://wiki.ubuntu.com/Debug%20Symbol%20Packages did not help?
[13:25] <loladiro> Nope, tried that, but neither dash-dbg nor dash-dbgsym seemed to exist
[13:29] <xnox> loladiro, yeah weird.
[13:29] <xnox> pitti would be the person to ask, but I don't see him online atm (holidays?!)
[13:29] <cjwatson> dash has a very old-fashioned debian/rules that doesn't use debhelper, so that'll be why
[13:30] <xnox> ah
[13:30] <xnox> tru, dh_strip is not called.
[13:30] <loladiro> So, no debug symbols for me then :(?
[13:30] <cjwatson> it should be pretty easy and quick to build locally
[13:30] <cjwatson> not a complex package
[13:30] <loladiro> Yeah, absolutely
[13:31] <loladiro> I’m not really interested in dash actually, but was just using it as a test case for some automation - guess I picked the wrong thing ;)
[13:32] <loladiro> Should I file some sort of bug report so this doesn’t get forgotten for future versions, or is this known and will be fixed anyway
[13:34] <cjwatson> I think it would be reasonable to file a bug asking for debug symbols (though a solution-neutral bug - it may be easier to just bodge the one or two necessary lines into debian/rules than to convert the whole thing to debhelper, as a downstream)
[13:34] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/dash/+filebug
[13:36] <LocutusOfBorg> I would open a bug in Debian
[13:37] <cjwatson> that's only a good idea if you can come up with a reasonable way to make it applicable to Debian
[13:38] <loladiro> Alright, bug filed. Appreciate the quick response folks.
[13:39] <cjwatson> http://debug.mirrors.debian.org/debian-debug/pool/main/d/dash/ similarly doesn't exist, so that may be such an argument
[13:55] <LocutusOfBorg> yes, the strip is done in a really obscure way
[13:55] <LocutusOfBorg> https://sources.debian.net/src/dash/0.5.8-2.3/debian/rules/
[13:55] <LocutusOfBorg> converting into some new format will fix the issue for both OS
[14:36]  * xnox moved IRC from a US vps to the one in docklands, so much better =)
[14:36] <xnox> http://memesvault.com/wp-content/uploads/Dog-Meme-Wow-Wallpaper-03.jpg
[14:47] <rbasak> stgraber: https://bugs.launchpad.net/ubuntu/+source/juju-mongodb/+bug/1612116
[14:48] <xnox> rbasak, whilst juju-2 is still saying that it may not be used for production use?!
[14:48] <xnox> how does one connect and/or deploy things with juju in yakkety then?
[14:49] <stgraber> xnox: I just commented in the bug that I don't think we should do this until Juju 2.0 is released and stable
[14:49]  * xnox hits F5
[15:02] <rbasak> xnox: don't ask me!
[15:38] <setuid> If I've pulled a package 'bar' with a BD on foo, which then uses 'import foo' in its code, but there's no RD on 'foo', removing 'foo' will break 'bar'. Does a BD incorporate foo.py into bar? Or did I just find a bug?
[15:49] <LocutusOfBorg> b-d don't incorporate runtime dependencies for python packages
[15:49] <LocutusOfBorg> usually they are listed in setup.py install_requires
[15:50] <LocutusOfBorg> and the parses and replaced with debian dependencies into python:Depends substvar that is evaluated during build by dh_python2 and replaces the dependencies with some runtime stuff
[15:50] <LocutusOfBorg> but if install_requires is not available... the maintainer has to list them in runtime-Depends
[15:51] <LocutusOfBorg> for libraries is easier
[15:51] <setuid> LocutusOfBorg, So sanity check this for me; python-keystone has a BD on python-ldappool, and keystone/core/core.py does an 'import ldappool', but installing python-keystone doesn't install python-ldappool
[15:52] <setuid> So installing python-ldappool on its own will satisfy that r-d, but will break when removed (no deps depend on it)
[15:52] <setuid> sorry, keystone/common/ldap/core.py
[15:52] <setuid> imports ldappool
[15:53] <setuid> there's a changelog entry showing the b-d being added, but they missed the r-d
[15:58] <mterry> seb128: can you reject a lightdm upload I just made to vivid accidentally?  Got my dput arguments in the wrong order and for some reason haven't disabled 'ubuntu' as the default location
[16:00] <mterry> Or any archive-admin I guess really  :)
[16:05] <infinity> mterry: Done.
[16:09] <mterry> infinity: thanks -- I've now fixed my dput too
[17:03] <LocutusOfBorg> setuid, you seems to be right, setup.py has no install_requires keyword, so the dependencies are not picked up (and nor explictly listed on Depends: of the runtime package)
[21:12] <ahoneybun> cyphermox: you work on the slideshow right?
[21:12] <ahoneybun> for the installer
[21:25] <cyphermox> ahoneybun: yes
[21:26] <ahoneybun> are the sizes in the slideshow.conf strict?
[21:26] <ahoneybun> like it HAS to be that size?
[21:27] <ahoneybun> reason I'm asking is because QtWebkit is broken in Qt4 or something and we are making our slideshow in qml
[21:27] <ahoneybun> not html
[21:39] <bdmurray> jbicha: for bug 1063019 you could use the Errors bucket for the crash as a test case
[22:09] <ahoneybun> heyo our installer slideshow is broken with 1 week before freeze
[22:09] <juliank> Would be nice if the apt 1.2.14 SRU in the queue would be processed at some point :)
[22:25] <bdmurray> juliank: which release is that for?
[22:25] <juliank> bdmurray: xenial, the 1.2.X series is the stable APT series for xenial
[22:32] <juliank> bdmurray: In case you're wondering: The release is from Jun 22; it was supposed to be synced a month ago or so, but getting the new APT with the same bugfixes into yakkety was a bit complicated, so it was delayed some time.
[22:33] <juliank> There will be a 1.2.15 update at some point in the future merging bugfixes from the 1.3~pre1, 1.3~pre2, 1.3~pre3, 1.3~rc1 releases; but not in the immediate future.
[22:33] <juliank> 1.2.14 basically  brings us up to 1.3~exp2 in terms of important bug fixes
[22:34] <juliank> oops, ~exp3
[22:35] <juliank> 1.2.15 will then fix the issues with ZFS module stuff not allowing you to autoremove kernels, amongst other things
[22:37] <juliank> (That will be an awful release to do, so many changes to look at and see what should be backported/cherry-picked)
[22:39] <juliank> Also need to wait for pitti so we can set up autopkgtests for that stuff before we upload it...
[22:57] <juliank> Oh dear, I also have to update the <IP_ADDRESS> series for Debian stable ...
[22:57] <jbicha> bdmurray: thanks, I see that there's a lot of errors on trusty for that gnome-contacts bug, so do you want to accept the sru for trusty too now (just uploaded)?
[23:08] <Term1nal> Question: https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-5696.html
[23:08] <Term1nal> What does DNE stand for in that listing?
[23:09] <sarnold> Term1nal: does not exist
[23:09] <sarnold> Term1nal: it means that package doesn't exist in that release
[23:09] <Term1nal> Ah.
[23:10] <Term1nal> So... DNE is saying, what... patch not needed for that specific issue?
[23:10] <sarnold> right; for example, the linx-lts-trusty package doesn't exist in trusty, 16.04, 16.10, etc..
[23:12] <Term1nal> So is this page effectively saying that there's no fix needed for 16.04?
[23:12] <sarnold> Term1nal: the 'linux' package on 16.04 is marked 'needed'
[23:13] <Term1nal> ah
[23:13] <sarnold> Term1nal: the linux ones are far more complicated than the other packages.. you've got to know which source package generated the kernels you're using in order to really read the page
[23:13] <Term1nal> Can't wait until the DDoS kiddies figure out how to exploit this and sell it as a service O.O
[23:14] <sarnold> hey great business idea!
[23:14] <sarnold> I mean
[23:14] <Term1nal> :P
[23:14] <sarnold> yeah that'll be trouble...
[23:15] <Term1nal> I guess what I'm trying to figure out.. is a currently up-to-date patched 16.04 machine vulnerable to this CVE still or?
[23:15] <Term1nal> Cause, sure, it's fixed in 4.7 kernel. But obviously we're not using 4.7 out of the box.
[23:15] <sarnold> it's certainly forced to to think about TCP slightly differently; 2^32 gaurantees are ...  not impressive. with so many machines on the internet moving so many packets of data each second, 1/2^32 happens all the time..
[23:16] <sarnold> Term1nal: you're affected. We expect the fix to land around august 27
[23:16] <Term1nal> Neato, that's a nice specific timing.
[23:17] <sarnold> the kernel team works on a three-week cadence; patches in one portion, testing in another portion, publish on a date; it normally works out pretty predictably
[23:17] <Term1nal> Let's just hope PoCs aren't released before then and used to start the next poodlecorp
[23:20] <Term1nal> Odd though, isn't it typical to have these sorts of CVEs announced once a patch is ready to go?
[23:21] <sarnold> we do, we release USNs, e.g. http://www.ubuntu.com/usn/usn-3055-1/
[23:22] <sarnold> this issue came out at an inconvenient time to fit into the release that was released last week, so it's in the current cycle, which should be released in ~two weeks..
[23:23] <sarnold> we also mail our USNs to a moderate-traffic mail list https://lists.ubuntu.com/mailman/listinfo/ubuntu-security-announce
[23:26] <Term1nal> I get those USNs through RSS
[23:30] <juliank> Hmm, I messed up the apt 1.3~rc1 a bit - I did not consider the ubuntu-specific config file in the packaging. I'll fix this tomorrow.
[23:31] <juliank> And what's going on with all those dlsym(acl_set_file): /usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so: undefined symbol: acl_set_file?
[23:32] <juliank> Well, the config stuff kind of happens when you switch to a new build system and rewrite the packaging rules.
[23:43] <TheMuso> c
[23:43] <TheMuso> whoops
[23:53] <Term1nal> Oh, please package latest Golang toolchain for 16.04, thanks! <3
[23:53] <Term1nal> Have fun you hard workin' folks


[00:00] <seb128> alright, enough work for today, see you later
[08:56] <crevette> hello
[08:56] <crevette> is universe freezed ? ie can we push new version of softawre ?
[09:01] <crevette> I would like to see nemiver pushed
[09:01] <crevette> we still ship a 8 monthsq old version
[17:42] <fta> pochu, don't worry, you're not alone, some are doing that for more than 6 months
[17:42] <pochu> wow
[17:42] <pochu> that sounds like a bug in ppa then
[17:43] <fta> i've already reported that but it's by design apparently
[17:43] <pochu> hmm
[17:43] <fta> not limited to ppa
[17:43] <fta> go complain :)
[17:43] <pochu> :)


[05:16] -queuebot:#ubuntu-release- New binary: gensio [amd64] (noble-proposed/universe) [2.8.2-2] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: gensio [s390x] (noble-proposed/universe) [2.8.2-2] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: gensio [arm64] (noble-proposed/universe) [2.8.2-2] (no packageset)
[05:59] -queuebot:#ubuntu-release- New binary: gensio [riscv64] (noble-proposed/universe) [2.8.2-2] (no packageset)
[06:06] <LocutusOfBorg> arraybolt3, see  https://forums.virtualbox.org/viewtopic.php?t=110346&sid=5795c6a7b2099a713547da45fab63c35
[06:22] -queuebot:#ubuntu-release- New binary: gnss-sdr [amd64] (noble-proposed/universe) [0.0.19-1] (no packageset)
[06:22] -queuebot:#ubuntu-release- New binary: gnss-sdr [s390x] (noble-proposed/universe) [0.0.19-1] (no packageset)
[06:22] -queuebot:#ubuntu-release- New binary: gnss-sdr [armhf] (noble-proposed/universe) [0.0.19-1] (no packageset)
[06:23] -queuebot:#ubuntu-release- New binary: gnss-sdr [arm64] (noble-proposed/universe) [0.0.19-1] (no packageset)
[06:23] -queuebot:#ubuntu-release- New binary: gnss-sdr [ppc64el] (noble-proposed/universe) [0.0.19-1] (no packageset)
[07:11] <LocutusOfBorg> vorlon, FYI: w.r.t. gnss-sdr, now BLA_PREFER_PKGCONFIG is defined inside CMakeLists file https://launchpadlibrarian.net/679713569/gnss-sdr_0.0.17-1ubuntu5_0.0.18-2ubuntu1.diff.gz
[07:11] <LocutusOfBorg> so the delta can be dropped
[07:12] <LocutusOfBorg> (well, I guess the issue was somewhat related to some latomic underlink issue, and I checked a simple find_package(BLAS) and works on riscv64 natively
[07:13] <LocutusOfBorg> so pretty sure the hack BLA_PREFER_PKCONFIG is not even needed anymore, but meh
[07:23] -queuebot:#ubuntu-release- New: accepted asterisk-espeak [amd64] (noble-proposed) [5.0~1-4]
[07:23] -queuebot:#ubuntu-release- New: accepted asterisk-espeak [armhf] (noble-proposed) [5.0~1-4]
[07:23] -queuebot:#ubuntu-release- New: accepted asterisk-espeak [riscv64] (noble-proposed) [5.0~1-4]
[07:23] -queuebot:#ubuntu-release- New: accepted gensio [amd64] (noble-proposed) [2.8.2-1]
[07:23] -queuebot:#ubuntu-release- New: accepted gensio [amd64] (noble-proposed) [2.8.2-2]
[07:23] -queuebot:#ubuntu-release- New: accepted gensio [riscv64] (noble-proposed) [2.8.2-2]
[07:23] -queuebot:#ubuntu-release- New: accepted gnss-sdr [amd64] (noble-proposed) [0.0.19-1]
[07:23] -queuebot:#ubuntu-release- New: accepted gnss-sdr [armhf] (noble-proposed) [0.0.19-1]
[07:23] -queuebot:#ubuntu-release- New: accepted gnss-sdr [s390x] (noble-proposed) [0.0.19-1]
[07:23] -queuebot:#ubuntu-release- New: accepted asterisk-espeak [arm64] (noble-proposed) [5.0~1-4]
[07:23] -queuebot:#ubuntu-release- New: accepted asterisk-espeak [s390x] (noble-proposed) [5.0~1-4]
[07:23] -queuebot:#ubuntu-release- New: accepted gensio [arm64] (noble-proposed) [2.8.2-2]
[07:23] -queuebot:#ubuntu-release- New: accepted gnss-sdr [arm64] (noble-proposed) [0.0.19-1]
[07:23] -queuebot:#ubuntu-release- New: accepted pointpats [amd64] (noble-proposed) [2.4.0-1]
[07:23] -queuebot:#ubuntu-release- New: accepted asterisk-espeak [ppc64el] (noble-proposed) [5.0~1-4]
[07:23] -queuebot:#ubuntu-release- New: accepted gensio [s390x] (noble-proposed) [2.8.2-2]
[07:23] -queuebot:#ubuntu-release- New: accepted gensio [s390x] (noble-proposed) [2.8.2-1]
[07:23] -queuebot:#ubuntu-release- New: accepted gnss-sdr [ppc64el] (noble-proposed) [0.0.19-1]
[10:05] <LocutusOfBorg> 2 years ago Adam left us :/
[10:05] <LocutusOfBorg> *3
[11:29] -queuebot:#ubuntu-release- New source: llvm-toolchain-18 (noble-proposed/primary) [1:18.1.0~++20240126095841+0991d3c7b53d-1~exp1]
[11:30] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-18 [source] (noble-proposed) [1:18.1.0~++20240126095841+0991d3c7b53d-1~exp1]
[13:18] <doko> bdmurray, ginggs: the amd64 autopkg test queues are empty on amd64, but there are still a lot of packages in "Building" state
[16:29] -queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [s390x] (noble-proposed/universe) [1:19~++20240125092523+41fe98a6e7e5-1~exp1] (i386-whitelist)
[16:51] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [s390x] (noble-proposed) [1:19~++20240125092523+41fe98a6e7e5-1~exp1]
[17:12] -queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [amd64] (noble-proposed/universe) [1:19~++20240125092523+41fe98a6e7e5-1~exp1] (i386-whitelist)
[17:12] -queuebot:#ubuntu-release- Packageset: Added gcc-14-cross to i386-whitelist in noble
[17:12] -queuebot:#ubuntu-release- Packageset: Added llvm-toolchain-18 to i386-whitelist in noble
[17:17] -queuebot:#ubuntu-release- New binary: snappy-tools [amd64] (noble-proposed/none) [0-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: snappy-tools [armhf] (noble-proposed/none) [0-1] (no packageset)
[17:18] -queuebot:#ubuntu-release- New binary: snappy-tools [ppc64el] (noble-proposed/none) [0-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: snappy-tools [arm64] (noble-proposed/none) [0-1] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: snappy-tools [s390x] (noble-proposed/none) [0-1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [amd64] (noble-proposed) [1:19~++20240125092523+41fe98a6e7e5-1~exp1]
[17:29] -queuebot:#ubuntu-release- New: accepted snappy-tools [arm64] (noble-proposed) [0-1]
[17:29] -queuebot:#ubuntu-release- New: accepted snappy-tools [ppc64el] (noble-proposed) [0-1]
[17:29] -queuebot:#ubuntu-release- New: accepted snappy-tools [amd64] (noble-proposed) [0-1]
[17:29] -queuebot:#ubuntu-release- New: accepted snappy-tools [s390x] (noble-proposed) [0-1]
[17:29] -queuebot:#ubuntu-release- New: accepted snappy-tools [armhf] (noble-proposed) [0-1]
[17:35] -queuebot:#ubuntu-release- New binary: snappy-tools [riscv64] (noble-proposed/universe) [0-1] (no packageset)
[17:46] -queuebot:#ubuntu-release- New binary: llvm-toolchain-snapshot [armhf] (noble-proposed/universe) [1:19~++20240125092523+41fe98a6e7e5-1~exp1] (i386-whitelist)
[18:15] -queuebot:#ubuntu-release- New: accepted llvm-toolchain-snapshot [armhf] (noble-proposed) [1:19~++20240125092523+41fe98a6e7e5-1~exp1]
[18:15] -queuebot:#ubuntu-release- New: accepted snappy-tools [riscv64] (noble-proposed) [0-1]
[23:18] -queuebot:#ubuntu-release- New binary: miniflux [amd64] (noble-proposed/none) [2.0.51-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: miniflux [ppc64el] (noble-proposed/none) [2.0.51-1] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: miniflux [s390x] (noble-proposed/none) [2.0.51-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: miniflux [armhf] (noble-proposed/none) [2.0.51-1] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: miniflux [arm64] (noble-proposed/none) [2.0.51-1] (no packageset)
[23:30] -queuebot:#ubuntu-release- New binary: nmodl [amd64] (noble-proposed/none) [0.6-2] (no packageset)
[23:31] -queuebot:#ubuntu-release- New binary: nmodl [arm64] (noble-proposed/none) [0.6-2] (no packageset)
[23:32] -queuebot:#ubuntu-release- New binary: nmodl [ppc64el] (noble-proposed/none) [0.6-2] (no packageset)
[23:32] -queuebot:#ubuntu-release- New binary: nmodl [s390x] (noble-proposed/none) [0.6-2] (no packageset)
[23:40] -queuebot:#ubuntu-release- New binary: nmodl [armhf] (noble-proposed/none) [0.6-2] (no packageset)
[23:47] -queuebot:#ubuntu-release- New binary: miniflux [riscv64] (noble-proposed/universe) [2.0.51-1] (no packageset)