[01:22] <jbicha> oops, it looks like seb128 broke gnome-control-center with his last upload, bug 1081826
[01:22] <ubot2> Launchpad bug 1081826 in gnome-control-center (Ubuntu) "gnome-control-center crashes with gtk warning" [Critical,Confirmed] https://launchpad.net/bugs/1081826
[01:23] <jbicha> I didn't care much for that navigation bar patch any way
[01:24] <desrt> jbicha: what are you plans with regards to seb's plans for the control center?
[01:25] <jbicha> well I'm annoyed that that patch came back and isn't Unity-specific
[01:25] <desrt> ready to throw in the towel yet?
[01:26] <jbicha> I'm not sure we need ibus 1.4.99 yet
[01:26] <maxiaojun> hi
[01:26] <maxiaojun> can i test your above mentioned stuff using raring daily image?
[01:27] <jbicha> maxiaojun: sure, but you'll need to grab gnome-control-center 1:3.6.3-0ubuntu2 as ubuntu3 is broken
[01:28] <maxiaojun> ok
[01:31] <jbicha> maxiaojun: but I'm sure it will be fixed tomorrow
[01:31] <maxiaojun> just for record, official ibus channel is #ibus, same net
[01:31] <maxiaojun> ok, i will try it inside VirtualBox anyway
[01:33] <jbicha> desrt: not quite yet
[01:50] <maxiaojun> btw, tomorrow in which timezone?
[01:52] <sarnold> maxiaojun: probably Europe/Paris
[01:54] <maxiaojun> ok
[02:03] <maxiaojun> concerning two keyboard indicator issue, ibus 1.4.99 may be a chance to fix it
[03:58] <cyphermox> achiang: no, it wasn't *yet*, it's on my list, but the list is huge :'(
[03:59] <achiang> cyphermox: i'm building a test package now
[03:59] <achiang> cyphermox: or at least attempting to... see my question in #u-devel?
[03:59] <achiang> cyphermox: (aka hopefully i can offload this from you)
[04:03] <cyphermox> I didn't see it, did you ping me? I didn't get a highlight :)
[04:04] <cyphermox> got it :P
[04:10] <achiang> cyphermox: backporting r364 was easy. i'm doing a test build now, and then i'll see about also importing some of the other patches related to leaks from upstream's history
[04:11] <cyphermox> sure. feel free to ask if you're unsure. but the other one you mentioned is still buggy
[04:11] <achiang> cyphermox: which other one?
[04:12] <cyphermox> g_string_append, that line 432 in src/applet-device-wifi.c
[04:12] <cyphermox> or at least, it could be better
[04:12] <achiang>         if (is_encrypted) {
[04:12] <achiang>                 icon_desc = g_string_append (icon_desc, ", ");
[04:12] <achiang>                 icon_desc = g_string_append (icon_desc, _("secure."));
[04:12] <achiang>         }
[04:12] <achiang> that bit?
[04:14] <cyphermox> yup
[04:15] <cyphermox> could just as easily be a g_string_append_printf as above rather than two calls :)
[04:17] <achiang> package built fine, so i can send up an MP soon
[04:17] <achiang> not super familiar w/SRU paperwork process though
[04:19] <cyphermox> achiang: basically, just follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[04:19] <cyphermox> updating the package description and subscribing ubuntu-sru
[04:19] <achiang> cyphermox: ok, will give it a shot
[04:19] <achiang> hopefully this makes your life easier
[04:19] <achiang> :)
[04:20] <cyphermox> ping me if you need help with nominating the package for the release
[04:20] <achiang> alrighty
[04:24] <cyphermox> achiang: I really appreciate the help
[04:24] <achiang> cyphermox: maybe one day i'll become motu. :)
[04:24] <achiang> wish i had more time to work on distro
[04:24] <cyphermox> careful what you wish for ... :)
[05:00] <achiang> cyphermox: https://code.launchpad.net/~achiang/network-manager-applet/precise-lp780602/+merge/135586
[05:37] <pitti> Good morning
[05:39] <maxiaojun> pitti is the author of jockey and u-d-c ?
[05:39] <pitti> maxiaojun: yes
[05:40] <maxiaojun> cool, two things
[05:41] <maxiaojun> 1. can ubuntu provide a graphical hardware lister instead of requiring people to use 'lspci' ? do you agree with the concept?
[05:42] <maxiaojun> 2. as i asked in previous mailing-list thread, some wifi chips still need b43, can jockey / u-d-c pull it?
[05:43] <pitti> maxiaojun: 1. the "system info" in control-center should provide this
[05:43] <pitti> 2. b43 should now work by default, as we ship the firmware; the wl driver explicitly needs to blacklist it
[05:43] <pitti> but I don't have hardware which works with b43; my dell netbook only works with wl
[05:44] <pitti> so I cannot verify on real hw
[05:44] <duflu> smspillaz: What's the main reason for separating glDraw/glPaint?
[05:44] <maxiaojun> for 2 now means raring or quantal?
[05:44] <duflu> Other than guaranteeing call order in an unknown plugin sequence...
[05:44] <pitti> maxiaojun: precise or quantal
[05:44] <pitti> maybe earlier even, not sure
[05:45] <maxiaojun> how do you ship it?
[05:46] <pitti> it's in linux-firmware, which we install by default
[05:46] <pitti> /lib/firmware/brcm/
[05:47] <maxiaojun> different from  /lib/firmware/b43/ right?
[05:48] <pitti> the path doesn't matter much
[05:48] <maxiaojun> but the content is different
[05:49] <pitti> ah, so that is not "the" b43 fw?
[05:50] <pitti> so if we still need the "other" b43 firmware, the b43-fwcutter package needs to get a Modaliases: header to identify the hardware which needs that firmware
[05:50] <pitti> but only those which don't overlap with wl
[05:50] <maxiaojun> http://paste.ubuntu.com/1376507/
[05:51] <maxiaojun> actually b43-fwcutter package itself needs some update
[05:52] <maxiaojun> i just have one laptop that only b43-fwcutter stuff work
[05:53] <pitti> what's the vendor/product ID of that card?
[05:54] <pitti> anyway, it's better to mention this ^ on a bug report
[05:54] <maxiaojun> 14e4:4331
[05:54] <maxiaojun> i linked a bug report in previous mailing list thread
[05:56] <maxiaojun> http://pad.lv/912941
[05:56] <ubot2> Launchpad bug 912941 in b43-fwcutter (Ubuntu) "Broadcom 4331 is not supported" [Undecided,Confirmed]
[05:57] <BigWhale> Good Morning.
[05:58] <maxiaojun> btw, where is "system info", is it a raring thing?
[06:06] <pitti> no, in control-center
[06:07] <maxiaojun> control-center? system settings?
[06:07] <maxiaojun> Details?
[06:11] <pitti> yeah, might be system settings, too; I'm on a German locale, so I don't know the precise English terms
[06:11] <pitti> (the program name is gnome-control-center)
[06:12] <maxiaojun> but that's far from useful i guess
[06:12] <maxiaojun> i cannot know my wifi hardware at all
[06:13] <maxiaojun> a nice related article http://www.webupd8.org/2011/07/how-to-get-hardware-information-in.html
[06:14] <maxiaojun> just check the screenshots
[06:17] <maxiaojun> both os x and redmond os can provide detailed hardware information using built-in graphical tool
[06:23] <maxiaojun> os x: http://www.askdavetaylor.com/how_big_apple_mac_macbook_hard_disk_drive.html
[06:24] <maxiaojun> redmond os: http://en.wikipedia.org/wiki/Device_Manager
[06:24] <maxiaojun> we don't have it, we use 'lspci -vvnn' probably with 'grep'
[06:25] <sarnold> maxiaojun: feel free to file a "main inclusion request" for your favorite gui hardware display tool
[06:26] <sarnold> maxiaojun: see https://wiki.ubuntu.com/MainInclusionProcess for details
[06:26] <maxiaojun> among those listed on the above mentioned blog post, HardInfo works best
[06:26] <maxiaojun> but it seems unmaintained since 2009
[06:27] <maxiaojun> i know there is MIR
[06:27] <maxiaojun> works best i mean on 12.04
[06:33] <BigWhale> I wonder when Ubuntu One will be integrated in control center :>
[06:34] <maxiaojun> it is already in it
[06:35] <RAOF> But not integrated
[06:35] <maxiaojun> though i just noted a issue that since i bought some music from Ubuntu music store, i already using Ubuntu One
[06:36] <maxiaojun> but the control-center entry still ask me to install Ubuntu One
[06:40] <didrocks> good morning
[06:41] <duflu> smspillaz: Ignore that question. I now remember glPaint is for occlusion detection. I wish it was more obvious by the name :{
[09:01] <seb128> seb128_, hey
[09:01] <seb128> larsu, ^
[09:02] <larsu> seb128, thanks :)
[09:03] <didrocks> seb128: this is the crashing seb, right? ;)
[09:03] <seb128> didrocks, I didn't restart my main client with the new lib :p
[09:03] <seb128> <- not crazy
[09:03] <Laney> hey
[09:03] <larsu> seb128 is too clever!
[09:03] <didrocks> heh
[09:03] <seb128> I hope I will not need to restart IRC or my session during the day though ;-)
[09:04] <seb128> hey Laney
[09:04] <didrocks> stop pinging people I would say |o|
[09:23] <chrisccoulson> good morning everyone
[09:34] <didrocks> hey chrisccoulson
[09:39] <seb128> chrisccoulson, hey, how are you?
[09:39] <chrisccoulson> seb128, yeah, not too bad thanks. how are you?
[09:40] <seb128> chrisccoulson, I'm good thanks
[09:49] <pitti> seb128: bonjour
[09:49] <pitti> seb128: I hate users
[09:49] <pitti> seb128: when you break floppies, they don't stop complaining; then, when you fix floppies, the other half doesn't stop complaining
[09:49] <pitti> well, I don't hate the users really, I hate floppies
[09:49] <pitti> a lot!
[09:51] <seb128> pitti, hey, me too!
[09:52] <seb128> pitti, floppy and acls on filesystems, right? ;-)
[09:52] <pitti> yeah, the ACL bug is still a mystery to me :(
[09:54] <didrocks> seb128: ping!
[09:54] <didrocks> and seb128 is still up there \o/
[09:55] <seb128> didrocks, works \o/
[09:55] <didrocks> great :)
[09:55]  * didrocks waits on jenkins to merge it
[09:55] <seb128> larsu, running my real client under your new patch, working so far ;-)
[09:55] <didrocks> then, pushing the trigger
[09:56] <larsu> seb128, I feel honored! ;)  Thanks for testing it out
[09:58] <larsu> didrocks, let me know if jenkins takes too long, then I'll merge it manually
[09:59] <didrocks> larsu: I'm a little bit frightened about merging manually under jenkins' feet
[09:59] <larsu> didrocks, I've done it a couple of times, it works fine if you set the status to "merged"
[10:01] <didrocks> larsu: let me look if it runs
[10:01] <larsu> yep
[10:01] <didrocks> larsu: oh it's merged :)
[10:01] <didrocks> just having emails lagging
[10:01] <larsu> \o/
[10:01] <didrocks> let me push the trigger for an automated upload
[10:01] <larsu> thanks didrocks!
[10:05] <didrocks> larsu: it's building in the ppa now and waiting
[10:24] <didrocks> pitti: can you bump the priority of https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4004054? we need the fix ASAP on the distro
[10:24] <didrocks> the other archs are on a 3-4 minutes timerate, which means it will built in the next 30 minutes I hope :
[10:24] <didrocks> :)
[10:25] <pitti> didrocks: oui, je peux
[10:25] <didrocks> pitti: un grand merci! :)
[10:25] <didrocks> 32 minutes, way better :)
[10:25] <pitti> fini
[10:25] <didrocks> larsu: FYI ^ I guess it will be hopefully in proposed in 30 minutes
[10:25] <didrocks> (built)
[10:25] <didrocks> I meant, 60 minutes
[10:25] <pitti> didrocks: currently building ubiquity and gcc, not the smallest packages
[10:26] <pitti> hm, we used to have three ppc builders
[10:26] <didrocks> yesterday, 3 were available
[10:26]  * didrocks checks
[10:26]  * pitti asks in #devel
[10:26] <didrocks> oh, just 2 today? someone stole the copper!
[10:27] <larsu> didrocks, nice!
[10:39] <dholbach> salut mes amis
[10:39] <dholbach> seb128, didrocks: I was wondering if we should do a french^WDesktop Development hangout some time soon: https://wiki.ubuntu.com/UbuntuDevelopment/Hangouts :-)
[10:40] <seb128> dholbach, hey
[10:41] <seb128> what's the principle? hang out and chat and take questions ?
[10:41] <didrocks> morning dholbach :)
[10:41] <dholbach> seb128, yes, whatever we want to do, we do - if it's a demo or just a chat or a presentation - everything goes
[10:43] <seb128> dholbach, why not
[10:43] <didrocks> sure :)
[10:43] <dholbach> personally I think demos always work best
[10:44] <dholbach> so it could be "watch seb128 and didrocks, how they update 10 gnome packages in just 5 minutes"
[10:44] <dholbach> or whatever else you have to talk about :)
[10:44] <didrocks> we should do that when they are gnome updates to do then :)
[10:45] <seb128> which is not this cycle :p
[10:45] <dholbach> well, unity update then ;-)
[10:46] <didrocks> dholbach: it's a button to push soon
[10:46] <didrocks> or even, done daily automatically :)
[10:46] <dholbach> ok, then you can just how you slack off all day
[10:46] <didrocks> héhé :)
[10:46] <dholbach> I'll leave it up to you ;-)
[10:46] <dholbach> or we can practise your German
[10:47] <didrocks> "cracking the whip" session :)
[10:47] <dholbach> or my French
[10:47] <dholbach> whatever you feel might interest new folks is very much welcome
[10:47] <dholbach> or if you need help somewhere
[10:48] <seb128> dholbach, let's discuss it next week? this week is a bit crazy
[10:48] <seb128> dholbach, around when did you envision doing it?
[10:49] <dholbach> seb128, just grab a slot on the wiki page
[10:49] <dholbach> whenever you like
[10:50] <seb128> dholbach, ok, I will think about it ;-)
[10:50] <dholbach> great
[12:18] <bizhanMona> HI does ubuntu 12.10 supports EFISTUB bootloader?thx
[12:22] <seb128> bizhanMona, hey, try asking the question on #ubuntu-devel, bootloader is a bit lower in the stack than what desktop work on
[12:36] <bizhanMona> seb128: thx will do that.
[12:51] <didrocks> larsu: seb128: all build steps ok for indicator-messages, just need to wait in 9 minutes next copy to proposed
[12:51] <seb128> didrocks, \o/
[12:51] <larsu> \o/
[12:59] <desrt> good morning european people
[13:00] <seb128> desrt, hey
[13:01] <didrocks> hey desrt
[13:02] <didrocks> larsu: https://launchpad.net/ubuntu/raring/+source/indicator-messages/12.10.6daily12.11.22-0ubuntu1
[13:02] <didrocks> (rev 333 \o/)
[13:25] <larsu> didrocks, !!!
[13:31] <desrt> didrocks: how did that whole automated uploading thing go from a few days ago?
[13:34] <didrocks> desrt: "few" == 2 days in prod now :)
[13:34] <didrocks> desrt: seems to work well, larsu quickly broke ubuntu automatically :)
[13:35] <desrt> didrocks: i warned you :)
[13:35] <didrocks> desrt: well, we need tests
[13:35] <didrocks> dogfooding isn't the only way to rely on things to work :)
[13:36] <larsu> desrt, morning!
[13:36] <desrt> larsu: hi.
[13:36] <larsu> desrt, this crash would have gone in with a regular release as well
[13:36] <larsu> desrt, /me was too stupid for g_variant_get ;)
[13:36] <larsu> we need to test indicator-messages better
[13:36] <desrt> larsu: _everyone_ is too stupid for g_variant_get()
[13:36]  * desrt fucked it up yesterday too
[13:37] <desrt> although the compiler caught me in this case...
[13:37]  * desrt had like foo (GAction *action) { gchar *action_name; ... ... g_variant_get (blah, "(..s..)", .., &action, ...); .... use_string (action_name); ... }
 "uh... are you sure action_name is initialised?"
 @#$@#$ g_variant_get
[13:42]  * desrt wonders why he types 'make -j 16' for webkit and sees 0.39 load average
[13:44] <larsu> desrt, lol. Mine was g_variant_get (v, "(uxsb)", &one, &two, &three) -- crashed when unpacking the 4th value
[13:44] <larsu> interestingly only on x86
[13:44] <desrt> probably what was happening on amd64 was worse...
[13:44] <desrt> either that or it happened to have a NULL at the end
[13:44] <desrt> in which case the unpack is skipped
[13:47] <larsu> desrt, we really need a gcc extension for it. Like the printf one
[13:47] <desrt> larsu: i tried writing one.  it's exceptionally non-trivial.
[13:48] <desrt> i wasted a good 3 days on it at one point
[13:48] <larsu> really?
[13:48] <larsu> holy ****
[13:48] <desrt> ya.  gcc extentions are a mess
[13:48] <desrt> there is hope, however
[13:48] <desrt> since then a few people (including mozilla?) have written frameworks for writing gcc extentions in python
[13:48] <desrt> and also: clang
[13:49] <xnox> didrocks: the unity upload you did, only has one of the changes you claim to include =)
[13:49] <xnox> https://launchpadlibrarian.net/123689550/unity_6.12.0-0ubuntu2_6.12.0-0ubuntu3.diff.gz
[13:49] <didrocks> xnox: urgh, but wth?
[13:49] <didrocks> I applied the two diffs :/
[13:50] <didrocks> grrrr, uploading the new one
[13:50] <desrt> larsu: https://gcc-python-plugin.readthedocs.org/en/latest/working-with-c.html#spell-checking-string-constants-within-source-code
[13:50] <desrt> larsu: this looks like it would be exceptionally easy to deal with
[13:50] <xnox> didrocks: happens, if you use a VCS for debian source packages =/
[13:51] <larsu> desrt, nice!
[13:51] <larsu> desrt, we could do lots of warnings for glib and glib-object
[13:51] <desrt> larsu: ya...
[13:51] <didrocks> xnox: uploaded, thanks :)
[13:51] <xnox> ;-)
[13:52] <xnox> desrt: wow, that is so cooL!
[13:52] <desrt> my favourite would be "you called G_DEFINE_INTERFACE on a vtable struct that doesn't have GInterface as its first member"
[13:52]  * xnox slowly backs away
[13:53] <larsu> desrt, that happens to people?
[13:53] <desrt> ya
[13:53] <desrt> i do it about once a year
[13:53]  * larsu apparently writes too few interfaces
[13:53] <desrt> fortunately i'm getting better at recognising the symptoms
[13:53] <desrt> which is approximately
[13:53] <desrt> (1) i've been writing a new interface
[13:53] <desrt> and
[13:53] <desrt> (2) WEIRD things are happening
[13:54] <larsu> haha
[14:03] <mhr3> mvo, you need to ping someone if you need a review ;)
[14:03] <larsu> mhr3, doesn't launchpad send you emails?
[14:04] <mvo> mhr3: oh? I was not aare of this
[14:04] <mvo> mhr3: like anyone? or specific people?
[14:04] <mhr3> larsu, it does, and there are hundreds of them :P
[14:04] <larsu> mhr3, I was expecting exactly that answer :)
[14:04] <mhr3> mvo, probably someone from unity team? :)
[14:05] <mhr3> if you don't ping the right person, they'll probably forward it
[14:05] <mvo> mhr3: haha, ok
[14:05] <mhr3> mvo, for the stuff you're working on, i'd start with Trevinho or andyrock
[14:06] <larsu> mvo, general rule of thumb: whoever's listed as "author" in the file you patched
[14:06] <Trevinho> mhr3: yeah, I alredy gave him a review
[14:06] <Trevinho> mhr3: I didn't write on MR, but I contacted him for few changes
[14:07] <mhr3> Trevinho, ah, cool :)
[14:08] <mhr3> larsu, hah, i usually just copy those and leave anyone in "Authored by" for double fun :P
[14:08] <larsu> mhr3, haha that sounds like ...... fun?!
[14:09] <mhr3> larsu, it's called "make someone suffer" :P
[14:10] <larsu> lol
[14:19] <desrt> larsu: btw: 90% chance i won't be in bremen
[14:21] <larsu> desrt, well, there's always a next time :)
[14:23] <mvo> thanks larsu
[14:24] <mvo> Trevinho: I did address the points I think :) or did I miss something?
[14:25] <mvo> Trevinho: aha, ok, got the updated MP now
[14:25] <Trevinho> :)
[14:26] <mvo> Trevinho: will work on that next, it means I need to implement the desktop-id algorithm in software-center now which looks like a bit of duplication, but maybe there is a implementation of this already (and if not it looks easy enough :)
[14:26] <mlankhorst> mvo: I'm probably hitting another apt bug on switching back now
[14:26] <mlankhorst> :P
[14:26] <mvo> mlankhorst: *nooooo* ;)
[14:26] <Trevinho> mvo: probably there's something around to compute it...
[14:26] <mvo> mlankhorst: looks like you should consider a career in QA ;)
[14:27] <Trevinho> mvo: unfortunately gio doesn't provide it, if you load an app via .desktop file it can't compute it's id -_-
[14:27] <mlankhorst> I was trying to force all lts-quantal packages to be unremoved with apt-get install xserver-xorg
[14:27] <Trevinho> it gives it to you only if you already open an app via its id
[14:27] <mvo> Trevinho: heh :) thats funny, so if you have it already it gives it to you? crazy ;)
[14:28] <mlankhorst> mvo: xserver-xorg has a break and conflicts on xorg-renamed-package http://paste.ubuntu.com/1377183/
[14:29] <mlankhorst> all of the packages with -lts-quantal in the name provide xorg-renamed-package
[14:29] <Trevinho> mvo: yeah, exactly :)
[14:29] <mlankhorst> hence none of the packages with lts-quantal in the name should be considered for keeping..
[14:29] <Trevinho> mvo: don't know if it's not implemented by purpose or if it's still missing, but that's a fact :/
[14:33] <mvo> mlankhorst: hmm, yeah, looks like the problem resolver is failing badly, at leat this time its not happening when dpkg is already called
[14:36] <mlankhorst> yeah it's a hairy situation though
[14:37] <mlankhorst> I want the problem resolver to come up with 'hey none of the lts-quantal packages work any more, see what else can satisfy it'
[14:47] <mlankhorst> woops
[14:48] <mlankhorst> would probably have helped if I depended on the physical packages there
[15:23] <robru> seb128, ping
[15:23] <seb128> robru, hey
[15:23] <robru> hey ;-)
[15:23] <robru> seb128, ken told me to pester you about some SRUs that he needs to get done, can you help/guide me with that? I know nothing of the SRU process.
[15:23] <seb128> sure
[15:24] <seb128> robru, the documentation is on https://wiki.ubuntu.com/StableReleaseUpdates
[15:24] <robru> seb128, ken says he "need needs" unity-chromium-extension gnome-control-center-signon libsignon-glib
[15:24] <seb128> robru, you basically need to have a minimal diff which includes only the changes to fix the issue you want to fix
[15:24] <robru> seb128, I think ken was saying that they're done, they just need to get approved?
[15:26] <seb128> robru, ok, so basically Ken needs me to find somebody to get those accepted is what you say ;-)
[15:26] <robru> seb128, yes ;-)
[15:28] <ricotz> cyphermox, hi :)
[15:28] <ricotz> seb128, hi
[15:29] <seb128> robru, thanks ... pinged the SRU guys
[15:29] <seb128> ricotz, hey
[15:29] <ricotz> seb128, there is a rhythmbox gst1.0 build available in my ppa
[15:29] <ricotz> the packaging isnt cleaned though, just a "prove of concept" and it works with disabled visualizer-plugin
[15:30] <seb128> ricotz, laney has one as well in https://launchpad.net/~ubuntu-desktop/+archive/gstreamer1.0
[15:30] <Laney> hey
[15:30] <seb128> Laney, btw we should start uploading that stack soon I think ;-)
[15:30] <Laney> ricotz: what did you do? just build the branch?
[15:30] <ricotz> seb128, ah i see ;)
[15:30] <Laney> seb128: yeah, there are still some possibly worrying mixed stack cases that dont have any work in progress
[15:30] <ricotz> Laney, yes, just the gstreamer-1.0 branch
[15:31] <Laney> ricotz: right, I merged it into the 2.98 tag and applied that diff
[15:31] <ricotz> ok, good
[15:31] <Laney> do you know if upstream plans to merge it any time soon?
[15:31] <ricotz> sorry, idk
[15:31] <Laney> want to ask?
[15:32] <robru> seb128, thanks
[15:32] <seb128> hum, I'm out for ~45min trying to debug my aunt machine having email issues, bbiab
[15:32] <seb128> robru, yw!
[15:32] <ricotz> cyphermox, jfyi the networkmanager package should be called <IP_ADDRESS>~ since that is what it contains ;)
[15:33] <Laney> miro gtkpod goobox gnomeradio
[15:33] <Laney> those may be broken if we upload the new stack
[15:33] <Laney> also libu1ui
[15:33] <Laney> which AFAICS uses gstreamer just to install fluendo
[15:34] <ricotz> Laney, i guess while the visualizer plugins isnt ported it won't get merged
[15:34] <robru> didrocks, ken and I fixed your concerns here: https://code.launchpad.net/~robru/unity-firefox-extension/inline-packaging/+merge/135237 can you approve now? ;-)
[15:34] <Laney> ricotz: maybe
[15:34] <Laney> didn't the branch have daap disabled too?
[15:34] <Laney> ISTR it being two plugins
[15:34] <ricotz> yes
[15:35] <didrocks> ricotz: looking!
[15:35] <Laney> mmm
[15:35] <Laney> not sure about uploading to ubuntu with it in that state
[15:35] <ricotz> libclutter-gst-dev (>= 1.4) should be libclutter-gst-2.0-dev (>= 1.4),
[15:35] <robru> didrocks, I have a couple others for review too ;-)
[15:35] <Laney> uh huh
[15:35] <Laney> the version is redundant in that case
[15:36] <ricotz> Laney, the clutter-gst api didnt really changed, just bumped for gst1.0
[15:37] <ricotz> hmm, debian/*.prs usr/share/gstreamer-0.10/presets?
[15:37] <ricotz> in -data.install
[15:37] <Laney> i already got fixed locally
[15:37] <ricotz> not sure if this simply should go in 1.0
[15:37] <ricotz> ok
[15:39] <ricotz> Laney, could you push the totem package to gnome3-ppa quantal?
[15:39] <didrocks> robru: approved, you can ping your prefered jenkins master to get it merged :)
[15:39] <Laney> ricotz: you should be able to copy it
[15:39] <Laney> if you view the ppa in the web interface
[15:40] <robru> didrocks, oh, is there more than one? I've been working with vrruiz the last couple days, but he suddenly got busy...
[15:40] <ricotz> Laney, not a copy a rebuild with ~ubuntu12.10.1
[15:40] <didrocks> robru: vvruiz, fghinter, alesage or mmrazik :)
[15:40] <didrocks> 2 of them are on vacations though
[15:40] <robru> didrocks, cool thanks
[15:40] <didrocks> yw!
[15:40] <mlankhorst> mvo: I'll just open another bug for apt then :)
[15:40] <ricotz> Laney, i can grab it too later
[15:41] <robru> didrocks, hey, you forgot to mark 'approved', you just made a comment ;-)
[15:41] <Laney> might do it after finishing the ubiquity port
[15:41] <ricotz> thanks
[15:41] <didrocks> ricotz: greenified :)
[15:42] <robru> didrocks, thanks. and I'm not ricotz  ;-)
[15:42] <didrocks> robru: speak more! s<tab> + smart completion is a general failure :)
[15:42] <didrocks> in fact, I should probably remove this weechat "smart completion"
[15:42] <ricotz> didrocks, robru, hi, yeah i got a bit confused ;)
[15:43] <robru> didrocks, so just type 'ro' before hitting tab ;-)
[15:43] <mlankhorst> I use first 2 letters most of the time..
[15:43] <didrocks> robru: yeah, but the thing is supposed to complete by the latest speaking on a channel matching the letters you type
[15:43] <didrocks> so one letter + tab is generally enough
[15:43] <didrocks> we have too many r and s here :)
[15:44] <robru> didrocks, ah, well you should file a bug so that you can hit 'tab' multiple times until it gets it right ;-)
[15:44] <didrocks> robru: yeah, or just fix it TBH :p
[15:44] <robru> didrocks, aaaaaannnnnnyyyyyways.... can you review this one too? https://code.launchpad.net/~robru/signon-keyring-extension/inline-packaging/+merge/135496 ;-)
[15:45] <didrocks> sure sure :)
[15:46] <didrocks> before building, I like it :)
[15:46] <didrocks> now, let's see…
[15:51] <didrocks> robru: approved! good work :)
[15:51] <robru> didrocks, thanks ;-)
[15:51] <robru> didrocks, got time for one more? ;-)
[15:51] <didrocks> thanks to you :)
[15:51] <didrocks> robru: how could I refuse? :)
[15:51] <robru> didrocks, https://code.launchpad.net/~robru/webaccounts-browser-extension/inline-packaging/+merge/135463 ;-)
[15:52] <didrocks> robru: not ignoring the .pem is on purpose?
[15:52] <didrocks> ah yeah
[15:52] <didrocks> as we store the key
[15:52] <robru> didrocks, yeah, build fails without the .pem
[15:53] <robru> didrocks, I was considering just 'add -f' the one .pem and leaving other .pems ignored, but ken told me to unignore .pems in general
[15:54] <didrocks> robru: yeah, that's fine IMHO
[15:55] <didrocks> robru: small comment though
[15:55] <didrocks> see MP
[15:55] <robru> didrocks, of course
[15:55] <robru> didrocks, this is why I ask for reviews ;-)
[15:56] <didrocks> robru: yeah, always better to double check! :)
[15:58]  * desrt looks out over a sea of green
[16:01] <robru> desrt, you high? I doubt there's any green in Toronto at the moment...
[16:01] <robru> ;-)
[16:01] <didrocks> desrt: is that the pond near the airport? :p
[16:01] <desrt> robru: jhbuild results page
[16:01] <robru> ahhhhh
[16:01] <desrt> things are going *very* nicely lately
[16:01] <didrocks> desrt: daily upload then! :)
[16:01] <robru> I built jhbuild once. once. ;-)
[16:02] <desrt> meta-gnome-core-shell builds with 100% success at this point
[16:02] <desrt> extras as well
[16:02] <desrt> (after applying my gnome-control-center patch, of course)
[16:02] <desrt> disk-utility is failing due to too high udisks dependency
[16:02] <robru> didrocks, ok, fix pushed, please approve ;-)
[16:02] <mlankhorst> mvo: woops, might have helped it conflict more by having some old package installed accidentally
[16:02] <desrt> and there's some stupid issues with graphviz and libmusicbrainz
[16:03] <desrt> but everything else is perfect
[16:05] <mvo> mlankhorst: oh, does it still fail?
[16:06] <mlankhorst> not sure yet
[16:07] <mlankhorst> but it probably didn't help
[16:09] <robru> didrocks?
[16:09] <didrocks> robru: building fine, files installed at the right place. perfect and approved:)
[16:09] <robru> didrocks, thanks!
[16:10] <robru> didrocks, ok, one last one I swear ;-)
[16:10] <robru> didrocks, https://code.launchpad.net/~robru/webapps-applications/inline-packaging/+merge/135247 ;-)
[16:10] <didrocks> robru: heh, keep them coming :)
[16:10] <mlankhorst> got a stale xserver-common in my ppa somehow..
[16:11] <robru> didrocks, actually ken said there were none left to do after this... I pestered him to give me a list of packages to do but he wouldn't ;-)
[16:11] <didrocks> robru: oh? maybe cyphermox can use some help then! :)
[16:11] <didrocks> robru: there are still some on the indicator/notify-osd stack
[16:11] <didrocks> as it seems you love that… ;)
[16:11] <didrocks> (oh also oif)
[16:12] <robru> didrocks, yeah actually... the only thing on my plate for today is to hassle people until these land.
[16:12] <robru> didrocks, so I could definitely do more if there are some available
[16:12] <didrocks> excellent, please cyphermox ^
[16:12] <didrocks> let me review first
[16:12] <robru> cyphermox, yeah, if you want to assign me to inline 3-4 packages today that would be cool
[16:14] <didrocks> robru: debian/copyright -> I guess TBH it should be all canonical :)
[16:14] <didrocks> just a minor thing, but simplifying the license and all the work we do in ubuntu for packaging is copyright canonical
[16:14] <didrocks> I don't think ken will object :)
[16:15] <robru> didrocks, so just drop the whole last paragraph there?
[16:15] <cyphermox> robru: didrocks: what's left by my count is appmenu-gtk, globalmenu-extension, indicator-applet, appmenu-qt, libappindicator, sni-qt ; picking any in the list is fine, just tell me which :)
[16:15] <didrocks> robru: yeah
[16:15] <didrocks> cyphermox: you have notify-osd and the oif stack as well, right?
[16:16] <cyphermox> ah, yes
[16:16] <cyphermox> there are those too
[16:16] <didrocks> robru: so start with indicators one first I would say ^
[16:16] <robru> cyphermox, ok, that's 6. I'll take the last three, so appmenu-qt, libappindicator, and sni-qt
[16:16] <didrocks> see, there are a lot of fun here :)
[16:16] <robru> cyphermox, oh, ok
[16:16] <robru> ok wait
[16:17] <robru> didrocks, you want me to do indicator-applet?
[16:17] <didrocks> robru: the first line is all indicators, so your plan works :)
[16:17] <robru> didrocks, cyphermox, ok, the three I originally said stand. ;-)
[16:17] <didrocks> thanks robru, cyphermox :)
[16:19] <robru> didrocks, ok, pushed that copyright fix, please approve ;-)
[16:19] <didrocks> it's building building building…
[16:19] <cyphermox> didrocks: how did libindicate look after all, anything jumping out? was I too tired when I did it ? :)
[16:21] <didrocks> robru: and approved :)
[16:21] <didrocks> cyphermox: hum, did I miss this review?
[16:21] <didrocks> let me look again :)
[16:21] <cyphermox> there isn't a MR, it's one I told you about early this morning
[16:21] <cyphermox> or do you rather just review it later? :P
[16:22] <didrocks> cyphermox: oh right, yeah, I didn't get time, TBH, I planned to go outside running for some hours ago and still didn't get to it :)
[16:22] <didrocks> cyphermox: so no, didn't review that one, just finish what you wanted and I'll review :)
[16:23] <didrocks> that one and libindicator (which I reviewed I guess)
[16:24]  * didrocks refreshes the stack of indicator deployed by jenkins
[16:32]  * didrocks goes out to do some exercice, back in an hour
[16:34]  * xnox unity takes a while to compile
[16:41] <didrocks> xnox: welcome to my world :)
[16:42] <mlankhorst> mvo: ok false alarm it seems, it seems to have gone insane for having the xserver-common weirdness..
[16:42] <xnox> didrocks: and I have i7 and doing a parallel build =)
[16:42] <xnox> sorry, i5, not i7.
[16:43] <mlankhorst> still seems to need some help to switch forward though on multiarch
[16:45] <xnox> mlankhorst: yeah, with multiarch it's a pain to dist-downgrade and dist-upgrade unless all enabled arches are insync.
[16:46] <xnox> didrocks: now that I have built it, why are there so many lintian tags, including warnings & errors.
[16:47] <mlankhorst> xnox: not that, getting E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
[16:47] <mlankhorst> I can help it out with apt-get install xserver-xorg-lts-quantal  libgl1-mesa-glx-lts-quantal:i386, though..
[16:47] <xnox> never saw that before.
[16:48]  * mlankhorst stresses apt's limits a bit more than usual..
[16:51] <xnox> mlankhorst: since you get an error message instead of a coredump, it may mean that you are not first one to actually do this =)))))
[16:51] <xnox> there is hope =)
[17:12] <robru> didrocks, back yet?
[17:28] <cyphermox> robru: can I help?
[17:28] <robru> cyphermox, probably ;-)
[17:28] <robru> cyphermox, I was just curious about appmenu-qt, because it's not owned by a team. It's the first one I've seen owned by an individual.
[17:29] <robru> didrocks, cyphermox: so the comment looks weird here: http://bazaar.launchpad.net/~robru/appmenu-qt/inline-packaging/view/head:/debian/control
[17:30] <robru> cyphermox, like, who is this person? are they active? is it ok for me to say that this one guy is going to handle the packaging for us once it's inlined?
[17:32] <cyphermox> ah, no it's pretty much because it wasn't moved, I think this branch should belong to ~indicator-applet-developers too
[17:36] <Laney> argh
[17:36] <Laney> I can't get my laptop or my desktop to boot into a live env due to a multitude of failures
[17:36] <Laney> anyone ever used vbox USB passthrough?
[17:37] <cyphermox> heh. I get crazy lag
[17:37] <robru> cyphermox, so how would I go about fixing that?
[17:37] <Laney> It "sees" the webcam but cheese shows a-nothing
[17:42] <cyphermox> robru: pushign the branch to the new location once it's all merged
[17:43] <cyphermox> gah, the lag is painful
[17:43] <xnox> Laney: right, is the webcam enabled via Fn-hotkey?
[17:43] <cyphermox> why is everything so slow
[17:43] <xnox> Laney: or give me the branch & I can test this on my netbook.
[17:44]  * xnox had zero luck doing webcam over usb-passthrough
[17:44] <robru> cyphermox, but I mean... do I have permission to fix that? or are we waiting for agateau to merge my branch and then push it somewhere else?
[17:44]  * Laney hides under xnox
[17:44] <cyphermox> robru: let's check that out with mmrasik
[17:44] <Laney> I'll push it but it could be a pile of failure
[17:47] <didrocks> xnox: most of them are false positives
[17:47] <didrocks> xnox: and due to compiz
[17:48] <xnox> didrocks: hm?
[17:50] <didrocks> xnox: the hardening-no-fortify-functions is a false positive one, as steve looked at it
[17:50] <didrocks> the executable-not-elf-or-script or generate by dh_migrations
[17:50] <didrocks> W: unity source: quilt-build-dep-but-no-series-file
[17:50] <didrocks> W: unity source: patch-system-but-no-source-readme
[17:51] <xnox> ember: unity-common: python-script-but-no-python-dep usr/lib/unity/makebootchart.py
[17:51] <didrocks> -> quilt was added by someone else
[17:51] <didrocks> xnox: yeah, we don't want to add the python dep on purpose
[17:51] <didrocks> it's used by autopilot only
[17:51] <didrocks> and that's all of them
[17:51] <xnox> didrocks: that's wrong. that file should then be shepped in the unity-autopilot package.
[17:51] <xnox> didrocks: and the python dependency should be there.
[17:52] <xnox> didrocks: or port to python3 =)
[17:52] <didrocks> xnox: the unity-autopilot didn't exist at the time, it can be moved
[17:52] <xnox> didrocks: yes, please.
[17:52] <didrocks> xnox: "please"?
[17:52] <didrocks> xnox: TBH, I don't really like this ton
[17:52] <didrocks> we can see how you will deal once you will have more than 40 packages under your responsability
[17:53] <didrocks> especially for things where the quality of the package is not directly impacted
[17:53] <xnox> didrocks: i can do merge proposals if you like.
[17:54] <didrocks> xnox: yes please
[17:55] <xnox> didrocks: and sorry about the tone. it was not meant like that. I am not sure, how I was suppose to say "oh, since unity-autopilot didn't exist at the time, I see why the python dep was not explicitely added at the time. But now that autopilot package exists, moving that file there is a good idea. I agree with you, can this be a wishlist packaging bug/task?"
[17:56] <didrocks> xnox: it's more on the "17:46:25          xnox | didrocks: now that I have built it, why are there so many lintian tags, including warnings & errors." which I find pedantic and accusive
[17:56] <didrocks> accusative*
[17:56] <xnox> didrocks: I do understand that maintaining a large stack of packages is hard and in no way trying to point it out.
[17:56] <didrocks> thanks :)
[17:57] <xnox> didrocks: it's the first time I built unity myself, and I wondered if there was a good reason for it to be in a state like it is or I should fix it.
[17:57] <didrocks> xnox: apart from the python one, I think you can remove quilt now that we have inline branch
[17:57] <xnox> usually large amont of lintian can be very much intentional.
[17:58] <xnox> didrocks: well, I recognise the quilt one, as some of my packages have it - if you built it as both 1.0 or 3.0 source package depending on the target release.
[17:58] <didrocks> then we have the executable-not-elf-or-script and hardening-no-fortify-functions which are wanted
[17:58] <xnox> so I don't actually mind that one.
[17:58] <didrocks> the only "error" is a false positive
[17:59] <didrocks> I meant:
[17:59] <didrocks> patch-system-but-direct-changes-in-diff
[17:59] <didrocks> but this is due to merge-upstream
[18:00] <didrocks> xnox: btw, the MP should be done for lp:unity now
[18:01] <didrocks> xnox: as we are moving all packaging inline
[18:01] <xnox> didrocks: that was going to be my next question =)
[18:01] <xnox> ack.
[18:03] <chrisccoulson> hmmm, our street is rapidly turning in to a river
[18:04] <didrocks> chrisccoulson: running that much?
[18:04] <didrocks> raining*
[18:04] <desrt> our street has a rather ironic habit of turning into a lake...
[18:04]  * didrocks has a broken head after today :)
[18:04] <chrisccoulson> didrocks, yeah, it's been raining pretty heavy for the last half an hour
[18:05] <didrocks> here, the weather is cold, but not rainy
[18:07] <robru> didrocks, chrisccoulson: we have a foot of snow in Winnipeg!
[18:07] <didrocks> robru: waow! what's the temperature?
[18:07] <desrt> robru: pfft.  'real canada'
[18:07] <desrt> enjoy your snow, eh?
[18:08] <didrocks> desrt: you definitively don't live in canada :p
[18:08] <desrt> didrocks: ask robru.  he'll tell you :p
[18:08] <didrocks> heh ;)
[18:08] <robru> I am getting on a plane in a week... ;-)
[18:08] <robru> and I'm never coming back to this town!
[18:08] <didrocks> seems like a relief :)
[18:08] <didrocks> where are you moving btw?
[18:08] <desrt> robru hates winnipeg
[18:09] <robru> I am moving to Victoria, BC. it's a cute little coastal town... they only get snow for a few days per year.
[18:09] <robru> and also they're a cycling haven... they're like Canada's copenhagen ;-)
[18:09] <chrisccoulson> robru, lucky you! i love snow :(
[18:10] <didrocks> oh, sounds lovely :)
[18:10] <chrisccoulson> robru, want to swap for a few months?
[18:10] <chrisccoulson> birmingham is lovely at this time of year
[18:10] <chrisccoulson> honest ;)
[18:10] <desrt> chrisccoulson: you should know better than to believe any of us would believe the words 'birmingham is lovely' coming from your mouth :)
[18:10] <robru> chrisccoulson, if you love snow so much, you should strongly consider moving to Winnipeg. ;-)
[18:11] <chrisccoulson> desrt, heh ;)
[18:11] <desrt> chrisccoulson: but only if you also love having bricks thrown at you
[18:11] <didrocks> robru: is the weather better than Seattle? I hear that it was already raining around there
[18:11] <didrocks> seems like 150kms away
[18:11] <robru> didrocks, yeah, it's actually quite sunny in Victoria. I don't know how to explain it, but there's this one mountain that shaped just right to deflect all of the rain clouds over into Vancouver instead.... ;-)
[18:12] <didrocks> robru: "let's have the USA keep their weather" :p
[18:12] <cyphermox> didrocks: having some issues with actually testing reverse-depends of libindicator for now; for some reason my internet is really slow this afternoon
[18:13] <cyphermox> but I updated to fix the issues mentioned on the MR
[18:13] <cyphermox> (about to push now)
[18:13] <didrocks> cyphermox: no worry, I think I'll review tomorrow right now.
[18:13] <cyphermox> ok
[18:14] <didrocks> robru: cyphermox: just keep them coming as you can, I'll review that in my inbox :)
[18:14] <cyphermox> I'm going to stay up until I finish at least ubuntu-menu-bar; and perhaps oif and notify-osd too
[18:14] <cyphermox> ok
[18:14] <didrocks> cyphermox: sweet!
[18:15] <didrocks> cyphermox: I'll do the part 2 of the bootstrap
[18:15] <didrocks> meaning the message and commits
[18:15] <cyphermox> any bootstraps missing?
[18:15] <cyphermox> I can do them too
[18:15] <robru> didrocks, I have a good 6 hours left on my shift, you probably dont want to stay up that late.... but you can get more reviews tomorrow ;-)
[18:15] <didrocks> cyphermox: I think I ended up what is merged
[18:15] <cyphermox> ok
[18:15] <didrocks> robru: I would love them \o/
[18:15] <didrocks> robru: then, tomorrow, we can talk together (I think we didn't) about the step 2 of the boostrap
[18:16] <didrocks> which is really simple :)
[18:16] <cyphermox> yup
[18:16] <cyphermox> for the indicator packages my script works well :D
[18:16] <didrocks> heh :)
[18:16] <robru> didrocks, yep, I know very little about this process, i just do what I am told so far ;-)
[18:16] <cyphermox> didrocks: you just don't trust my work  ;)
[18:16] <didrocks> robru: well, you know, the process is new to everyone, we just shape it as it goes :)
[18:17] <didrocks> cyphermox: not that, it's just that I wanted for tomorrow to have more things running
[18:17] <didrocks> cyphermox: oh btw, you did notice the 3rd merge I'm doing?
[18:17] <cyphermox> 3rd merge?
[18:17] <didrocks> it's when there is something to release, to have at least one additional commit to release
[18:17] <robru> didrocks, ok, you have a new one in the email ;-)
[18:17] <cyphermox> oh, right ok
[18:17] <didrocks> robru: too late, just closed thunderbird (lucky? ;))
[18:17] <cyphermox> just for changing thing to check that it works
[18:17] <didrocks> cyphermox: right
[18:18] <didrocks> cyphermox: I'm only doing those for projects that have something not in distro
[18:18] <didrocks> like a commit not backported already and so on
[18:18] <didrocks> that's why all projects don't necesserally have it
[18:19] <didrocks> waow 14s of lag, I guess it shows I should EOD :)
[18:20]  * didrocks waves good evening
[18:20] <didrocks> and enjoy inlining :)
[18:22] <notgary> Hey, would anyone have a problem with the paper cuts team having a brief meeting here in about 40 minutes, or would you prefer us to do it somewhere else?
[18:24] <desrt> notgary: looks like nobody minds :)
[18:25] <notgary> desrt: I guess I can take the silence as implicit consent :)
[18:26] <robru> notgary, I don't mind...
[18:27] <notgary> robru: explicit consent is of course always preferred :)
[18:28] <xnox> notgary: is ubuntu-meeting booked? Cause if not, you can highjack it & use the meeting notes bot with #startmeeting title
[18:32] <notgary> I wasn't sure if our thing would be big enough for Ubuntu meeting. I was thinking of holding it here and seeing what kind of turnout we got before moving onto that.
[18:32] <xnox> notgary: asked on #ubuntu-irc and was pointed to http://fridge.ubuntu.com/calendars/ looks like #ubuntu-meeting is free.
[18:32] <xnox> http://fridge.ubuntu.com/calendars/
[18:33] <notgary> Heh, free all day
[18:33] <notgary> Thanks for the heads up
[18:33] <xnox> notgary: meh, I think the _whole_ ubuntu-motu meetings sometimes have like 3 people in it. But the onlookers are great =)
[18:34] <notgary> Heh, fair enough :)
[18:34] <xnox> notgary: ask for a meeting to be put on the fridge on #ubuntu-irc. #ubuntu-meeting is always a good place to hold meeting, as there won't be accidental interruptions to the conversations.
[18:34] <xnox> notgary: plus fridge is an advertisement platform for meetings ;-)
[18:35] <notgary> xnox: thanks for the advice :)
[18:36] <xnox> np
[18:36] <notgary> I think it's too late to change it now as people will probably miss it, but next time I'll set that up.
[18:55] <MCR1> notgary: Hi :) I heard a meeting is about to happen ?
[18:55] <radu> hey everyone
[18:56] <notgary> MRC1: You heard right. Hold on a few more minutes.
[18:56] <MCR1> :)
[19:04] <cyphermox> notgary: ok so you're having the meeting here instead of #ubuntu-meeting after all?
[19:05] <cyphermox> ignore me
[19:06] <notgary> cyphermox: you must have missed my last message about it being too late to change it this time, but next time we'll do that
[19:06] <cyphermox> yeah yeah, no problem :)
[19:06] <notgary> right
[19:06] <notgary> Who's all here for the paper cuts meeting? Say hello if you ar.
[19:07] <chilicuil> hi =)
[19:07] <radu> hey
[19:07] <_Psy_> Hi
[19:08] <notgary> Anyone else? MCR1, I'm looking at you :)
[19:08] <notgary> Ah well, he'll be back
[19:08] <notgary> Anyway
[19:09] <notgary> Thanks a lot for coming along. I appreciate you taking the time to attend
[19:09] <notgary> If anyone's not familiar with the agenda, you should quickly check it out here https://wiki.ubuntu.com/PaperCutsRaring/Meeting1
[19:09] <notgary> The first item:
[19:10] <notgary> how are we doing?
[19:10] <notgary> So far we have...
[19:10] <notgary> fixed 8 bugs
[19:10] <MCR1> notgary: Sry, I am here now :)
[19:10] <notgary> No probs
[19:10] <notgary> :)
[19:10] <MCR1> @all: Hi
[19:11] <notgary> 8 paper cuts fixed: 6 committed upstream and 2 already released
[19:11] <notgary> For a project that was on it's last legs this time last month, I'd say we've gotten off to a greta start
[19:12] <notgary> So far we've been focusing mostly on Rhythmbox bugs
[19:12] <notgary> and 4 of the fixes are in there
[19:12] <notgary> Anyone got any thoughts or comments on our progress so far?
[19:12] <notgary> Hoe are we doing?
[19:12] <notgary> What could we be doing better?
[19:13] <notgary> A specific point was raised on the mailing list
[19:13] <notgary> about the role of GTK in the project
[19:13] <radu> i'd say we're doing good
[19:14] <notgary> It was pointed out that a lot of the bugs fixed so far have been issues in GTK, rather than the app they were reported in
[19:14] <notgary> radu: excellent. Nice to know it's not just my warped outlook on life :)
[19:14] <_Psy_> Well, I can say that I was not sure about the "app focusing" plan, but I'm very surprised about the results and I must give congratulations for the idea
[19:15] <radu> yeah, for that. Since GTK+ touches a lot of projects, I'd say if we want to target it specifically, we should give it a larger time period than the rest
[19:15] <_Psy_> Its really making sense, focusing the project
[19:15] <MCR1> I'd say a good idea with GTK, a good idea to work on problems near the foundation of things...
[19:15] <notgary> I was sceptical about the potential success of it too
[19:15] <notgary> but it seems to have worked out well :)
[19:16] <notgary> As for GTK, I was thinking maybe we could give it some kind of preferential treatment, maybe targeting more bugs to it than we would on anything else.
[19:16] <notgary> What do people think about that?
[19:17] <radu> that would be my idea too. Maybe treat it like three-four normal applications
[19:17] <_Psy_> Yep, I really believe that can be the foundation on where the papercut project gravitates, because many bugs found and reported are foundational ones: GTK+, Unity, Compiz.
[19:17] <_Psy_> And thouse papercuts are usually difficult to report if you don't have a good test case on one app
[19:17] <MCR1> Yeah, I hoped I would not have to say that - _Psy_ I agree 100%
[19:18] <radu> personally, I think targetting Unity is not such a bad thing. Some Unity bugs should be easy to fix (typos, descriptions etc), and this has a direct impact on all Ubuntu users
[19:18] <MCR1> Compiz as foundation of Unity is even more important IMHO
[19:18] <notgary> Unity has it's own foundational technology, called Nux, which is an interface widget library developed specifically or Unity
[19:19] <notgary> I'm not sure how it all works, but perhaps we could know out some bugs in Nux that manifest as paper cuts in Unity
[19:19] <MCR1> notgary: I have contributed a lot to both projects (Compiz/Unity) already, so I can help with this
[19:20] <BigWhale> who's the goto guy for Launcher API?
[19:20] <notgary> Not sure. We can ask on the Unity dev and design mailing lists
[19:20] <MCR1> Unity devs hang around in #ubuntu-unity
[19:20] <notgary> Or we could ask there :P
[19:21] <BigWhale> MCR1, notgary yeah... I just joined. Thanks.
[19:21] <notgary> Anyway
[19:21] <notgary> we should probably wrap up this item and conclude that we're going to look closer at the foundational technologies in Ubuntu
[19:22] <MCR1> It would be important to have some scripts, setting up build and testing environment for Compiz/Unity as those are not easy to set up
[19:22] <radu> ok, that would be a good summary
[19:22] <_Psy_> My feeling is that Unity/Compiz/GTK+ must have a permanent "focusing" week every month
[19:22] <MCR1> I saw the idea of Papercutters PPA
[19:22] <radu> MCR1, I agree with the scripts idea
[19:23] <notgary> Which is a perfect segway into that item
[19:23] <notgary> A pity we don't have a seaway sound effect for that :P
[19:23] <notgary> The paper cutters PPA would just be a catchall holding area for any scripts and apps that are developed for helping out the paper cuts proejct
[19:24] <notgary> So far we've got a single script for reporting the current progress of the project for the current cycle https://wiki.ubuntu.com/PaperCutsProgressReporter
[19:25] <notgary> and I was hoping to iteratively expand it as we go on, turing it into a very comprehensive guide to how we're doing
[19:25] <notgary> This would be the first one to go in
[19:25] <notgary> and I was wondering if anyone had any ideas for anything else we could stick in our toolbelt.
[19:25] <notgary> There was mention of setup scripts for Compiz/Unity and friends
[19:26] <MCR1> I could try to build some basic scripts that help to set up Compiz/Unity, but that is not so easy as it sounds...
[19:27] <notgary> Yeah, those ones are quite nasty
[19:27] <MCR1> but otherwise it is important for a contributor to be able to test his fixes, without having to set up everything from scratch
[19:27] <notgary> So how would you think these scripts should work?
[19:28] <notgary> in terms of workflow for the user/contributor
[19:28] <MCR1> Every info regarding building Unity from source is heavily outdated
[19:29] <MCR1> So I suggest adding scripts like "branch_and_build_compiz_and_unity_from_source.sh" would be helpful
[19:29] <notgary> That would indeed be helpful
[19:29] <notgary> to Ubuntu at large as well as the paper cut project
[19:30] <MCR1> They should pull in all build-deps, pull/update bamf/nux/libunity/compiz/unity and install the builds to the home dir for testing
[19:30] <notgary> How difficult do you think it would be to keep them unto date?
[19:30] <notgary> *upto
[19:30] <MCR1> So people can start hacking on it more easily
[19:31] <MCR1> well, there are many unannounced changes all the time, soooo - rather hard...
[19:31] <notgary> Maybe we could enlist the help of the Unity devs for this
[19:32] <notgary> We'd also need to make sure we tested it regularly, to make sure it worked
[19:32] <notgary> probably daily
[19:32] <MCR1> that would be great
[19:32] <notgary> and any build failures should be reported as bugs
[19:33] <notgary> This sounds like a great idea because of the benefit it will have for Ubuntu as a whole.
[19:33] <MCR1> we could start with hacks on Compiz though, as those would be much easier to test...
[19:33] <notgary> Do you know of any small ones that we can get started on?
[19:33] <MCR1> I have developed a way of testing Compiz plug-ins and fixes, that is quite simple and efficient
[19:33] <MCR1> yes, I got a ton of them ;)
[19:34] <notgary> Awesome
[19:34] <_Psy_> notgary: So far we saw many bugs that goy stuck just because we needed the input from design or UX team to clarify a possible "good" behave of the UI
[19:34] <notgary> _Psy_
[19:34] <notgary> Yeah
[19:34] <MCR1> _Psy_: Yes, design is not very responsive, I agree...
[19:34] <_Psy_> So, I think to have them roaming makes a lot of sense
[19:34] <notgary> that's something I've been working on trying to fix
[19:34] <MCR1> See also the ayatana list
[19:35] <MCR1> a ton of great ideas without any response whatsoever
[19:35] <notgary> I've spoken with mpt about how to get more response from design
[19:36] <notgary> He said that if we assign the bug to jnick_tait, a project manager on the design team, then he'd get it delegated to another memebr
[19:36] <notgary> hopefully leading to more members of the design team working with community members
[19:37] <MCR1> that would be something appreciated from the community I think
[19:37] <notgary> He also said it was ok to ping jnick_tait on #ubuntu-design if we wanted to get his attention
[19:37] <notgary> Though I would suggest letting a little time go by before doing that :P
[19:37] <_Psy_> Oh, thats great
[19:38] <MCR1> many bugs are just bugs and do not really need design input, so there is enough to do
[19:38] <notgary> I think this is another bit we can wrap up now
[19:38] <notgary> In summary...
[19:39] <notgary> Start working on build scripts to get the foundation packages up and running more easily
[19:39] <notgary> and pester design to provide input
[19:39] <notgary> Next...
[19:39] <notgary> Another idea was suggested for the reporting of paper cuts
[19:39] <notgary> instead of asking people to report them on pre-release CD, where the code was likely to change anyway
[19:40] <_Psy_> MCR1: yes, but sometimes just with a little input you can quicly dismiss a bug and avoid to wate resources.
[19:40] <notgary> we should be soliciting paper cuts from stable releases
[19:40] <_Psy_> (sorry if I'm a bit slow, english is not my first language)
[19:40] <MCR1> yes and there are other great ideas, which would not need much work to get implemented (ideal for papercutters), but need-design
[19:40] <notgary> Where the code is frozen and much less likely to be broken
[19:40] <MCR1> I agree, _Psy_
[19:41] <notgary> In the past, a lot of bugs that are a natural part of pre-release software have been sent as paper cuts
[19:41] <notgary> clocking up the system and making it tougher to spot genuine ones
[19:41] <radu> Well, currently, only a handful of people are marking papercuts in the bug tracker, so this is not such a big problem
[19:42] <notgary> At the moment yes, but it would be great for it to be a big problem, if you see what I mean :)
[19:42] <notgary> You're right that a lot of paper cuts aren't being reported right now
[19:42] <notgary> but that's something I'd like to change
[19:43] <notgary> If we ask people to sit down for an hour or two with their favourite app
[19:43] <radu> heh, yeah I understand what you're saying
[19:43] <notgary> and just tell us everything they find annoying about it
[19:43] <notgary> then we'll never be short of paper cuts to fix
[19:43] <notgary> If we can get them doing that ...
[19:44] <druellan> Well, if you want more "average user" contributions, you must target what people already have installed.
[19:44] <notgary> Then we need to make sure they know to do it on stable releases, and not betas
[19:44] <MCR1> it is important to get high-quality bug reports, which are easily reproducable then - that is a half-fix already
[19:44] <notgary> druellan, MCR1: exactly
[19:44] <notgary> pre-release software is a moving target in terms of fixing bugs
[19:45] <notgary> at least if you not a Canonical developer
[19:45] <notgary> so we should focus our attention on stable code
[19:45] <notgary> in the case right now, 12.10 and 12.04 LTS
[19:45] <MCR1> in the case of Compiz/Unity you will always hack on latest trunk, no ?
[19:45] <notgary> Yes
[19:46] <notgary> The bug is reported in stable code
[19:46] <notgary> and tested/fixed on development
[19:46] <seb128> notgary, the stable release have limited scope for updates though
[19:47] <seb128> you also need to get the issues fixed in the current serie before doing an SRU
[19:47] <radu> yeah, the issue will be fixed for the next release anyway
[19:47] <MCR1> yes, that is what I mean
[19:47] <notgary> Hmm, goods points.
[19:48] <MCR1> you fix stuff in trunk, then you backport it
[19:48] <notgary> OK, that's a good point.
[19:48] <radu> backporting might be difficult, especially for the LTS
[19:49] <druellan> Even worse if you are trying to fix an upstream bug, like GTK+, thouse are unlikely to be backported to a LTS
[19:49] <MCR1> it gets harder once the code diverges too much, because you have to fix conflicts
[19:49] <notgary> radu: which is why they should be reported and fixed in pre-reales. Now I'm getting you
[19:50] <notgary> Ok, focus on the current trunk sound like the best way to go about it.
[19:50] <MCR1> but generally most bugfixes will apply cleanly to LTS (old) versions of the code also
[19:51] <radu> well, you could restrict the bug reporting to the stable version. This is not a problem. But the fixes will probably be available with the next release and might not be backported
[19:51] <notgary> If we summarise that it's best to focus on pre-release and not current stable, and that I'm talking nonsense, will everyone be cool: :P
[19:52] <MCR1> bug reports can and should also focus on current stable if they are still valid for trunk
[19:52] <seb128> it's usually better to fix trunk
[19:52] <seb128> so you know the bug is fixed for the futur versions
[19:53] <seb128> you need that anyway if you want to SRU a fix because the stable update will not be accepted if the bug is not fixed in the current serie
[19:53] <radu> MCR1,  that's my opinion also
[19:53] <MCR1> but fixes should be done in trunk versions and later backported
[19:54] <radu> ok, so focus on bug reports from stable version. Fix in trunk, if still present. And backport if possible
[19:54] <radu> does that sound resonable?
[19:54] <MCR1> yep
[19:55] <notgary> yep
[19:55] <notgary> Right...
[19:55] <notgary> Last item from the agenda is the future of #ubuntu-papercuts
[19:56] <notgary> Since I set it up, I've noticed there's been net to no traffic in there. It's also been suggested that the paper cutters hang about here in #ubuntu-desktop so the work we do has greater exposure to the rest of the development community, since this is the hub of that.
[19:57] <notgary> I also think it's useful to have the desktop team generally aware of what we're doing since our focus on the CD effectively makes us s sub team of them
[19:57] <MCR1> I have no problem with that and think we do not need a new channel, there are really enough #ubuntu-* channels already
[19:57] <seb128> it makes sense to have discussions about usability issues on the channel that's on topic of the component which has the issue
[19:57] <seb128> e.g here for desktop stuff
[19:58] <seb128> #ubuntu-unity maybe for compiz/unity
[19:58] <notgary> seb128 chiming in here is evidence enough of the usefulness of that :)
[19:58] <seb128> ;-)
[19:58] <druellan> I think it makes sense. Papercuts will always gravitate towards UX
[19:59] <notgary> So maybe we could use #ubuntu-desktop as out main channel, and move into the relevant channels as and when we need to, such as #ubuntu-unity for talk about Unity
[19:59] <MCR1> +1
[20:00] <notgary> MCR1 's vote is enough to decide :)
[20:00] <seb128> +1 as well
[20:00]  * druellan rises a +1
[20:00] <notgary> I'll closed down #ubuntu-papercuts in a couple of days
[20:00] <radu> ok
[20:00] <notgary> I'll change the entry message to point people here
[20:01] <notgary> so anyone that doesn't here about this won;t try to join a non-existent channel
[20:01] <notgary> So, that's the agenda out the way.
[20:01] <notgary> Anyone got anything else that's like to add
[20:01] <notgary> ?
[20:01] <druellan> Ejem
[20:02] <druellan> About Unity
[20:02] <notgary> Go ahead
[20:02] <druellan> Its not better to call it Unity/Compiz and to focus the raring cycle to both?
[20:02] <druellan> I've found several reports that turned to be about Compiz more than Unity
[20:03] <notgary> I think that's what we're going to do
[20:04] <notgary> Compiz, GTK and Nux are the three primary foundation technologies in the Ubuntu GUI
[20:04] <notgary> and so we're going to look closely at all three of them
[20:04] <notgary> both in Raring, and in the future
[20:04] <cyphermox> stuff there is unlikely to be papercut though
[20:05] <MCR1> a very good decision IMHO
[20:05] <druellan> cyphermox: good point
[20:05] <cyphermox> (or at least feel to me like)
[20:05] <notgary> The bugs themselves may not be paper cuts, but they can manifest as such
[20:05] <notgary> I've closed plenty of bug reports that sounded like they were simply paper cuts in this app or that
[20:05] <druellan> But, from the user point of view, Unity and Compiz are almost the same, they both shape the desktop
[20:05] <seb128> often when bugs exist for a long time there is a reason
[20:05] <cyphermox> right, but the whole idea of papercut projet initially was to be small annoying bugs that can be easily fixed ;P
[20:05] <seb128> or said different: they are not trivial to fix
[20:05] <MCR1> cyphermox: I can not confirm that. Although people think that everything in Compiz/Unity has to be very complicated it often is not...
[20:06] <cyphermox> MCR1: you're right, but it also has a high chance to be
[20:06] <MCR1> sure, some are also hardcore ;)
[20:06] <cyphermox> as opposed to elements closer to the user, like a specific application
[20:07] <MCR1> if you build a house, you gotta take care to build a good fundament
[20:07] <cyphermox> yes
[20:07] <druellan> The point here is not to dismiss unity reports just because for a dev are different beast. If they fall from Papercut's scope, then, be it.
[20:07] <cyphermox> right
[20:08] <notgary> I think it would be good to at least spend a cycle looking at these sort of bugs
[20:08] <cyphermox> shouldn't be dismissed, but taken care of carefully.
[20:08] <radu> It's a good idea to get some feedback from the main developers, like on the Rhythmbox bugs. They can tell us if it's easy to fix or not :)
[20:08] <cyphermox> I didn't follow everything, but did you engage with unity devs for getting papercut reports?
[20:09] <desrt> seb128: time to stop working :)
[20:09] <MCR1> developers will test and proofread every merge-request anyway
[20:09] <seb128> desrt, oh?
[20:09] <desrt> unless you're in north america today?
[20:09] <cyphermox> MCR1: yes, but the papercut idea is to identify low-hanging fruit, that's before the merge request point
[20:09] <notgary> cyphermox: we haven't yet, only because we haven't gotten round to looking at Unity yet
[20:09] <seb128> desrt, I started at 10 and I've been away from 16 to 21
[20:09] <cyphermox> notgary: ok
[20:09] <seb128> desrt, with lunch in the middle of 10-16
[20:09] <desrt> seb128: lazy, then :)
[20:09] <seb128> desrt, ;-)
[20:10] <notgary> We've already seen that plenty of paper cuts can be fixed in GTK, so we're just extending that to the other foundation graphical technologies, though we may draw the line at X.Org :)
[20:10] <notgary> We'll take a cycle to see how it goes
[20:10] <notgary> And regular meetings like this one will stop us going too long down the wrong path
[20:10] <radu> MCR1, I was thinking of getting feedback when marking the bug as a papercut, if it's tricky or not
[20:11] <seb128> you guys can probably talk to attente about GTK things you hack on
[20:11] <notgary> We're just trying new things right now and seeing what happens
[20:11] <seb128> he joined recently and he's working on GTK
[20:11] <attente> o/
[20:12] <seb128> attente, hey, I guess you would be fine helping the papercut guys to get their usability fixes in shape to land in GTK?
[20:12] <seb128> attente, or working with them trying to see what makes sense at least ;-)
[20:13] <attente> seb128: sure thing, as long as i understand what's happening
[20:13] <desrt> attente: how are the menus?
[20:13] <attente> desrt: still working on the action group export
[20:14] <attente> but we now ignore tearoff menu items properly at least
[20:14] <desrt> nice
[20:14] <desrt> is the menu syncing itself fully completed and no longer crashing?
[20:15] <attente> there's still the one case that crashes, removing a separator from the end of a menu
[20:15] <attente> i want to get the action group working before looking at that
[20:15] <desrt> maybe we should work together tomorrow.  i wouldn't mind looking at that.
[20:15] <attente> ok
[20:15] <attente> also
[20:15] <desrt> how are you handling the actiongroup API?
[20:15] <attente> if the menu is build using GtkUIManager, the menus don't appear at all
[20:15] <desrt> implementing the interface on the GMenuModel of the parser itself or as an auxilliary object?
[20:16] <attente> auxilliary object
[20:16] <desrt> good enough
[20:16] <MCR1> radu: Well, if you make a comprehensive bug report with exact information on how-to-reproduce the bug it *could* be determined from there, but what is easy and what is hard ? - for a foreign coder a English tooltip might be hard to fix, while for a native English-speaker code might be hard to fix, so...
[20:16] <attente> desrt: i thought this was the better way of doing it
[20:16] <desrt> attente: possibly
[20:17] <desrt> considering the menumodel tree is recursive in nature and you want them all to share a single actiongroup...
[20:17] <seb128> attente, don't worry, the papercut are usually about small usability issues and there is no requirement to get things fixed, it's mostly a matter to try to help the contributors to get their patch in bugzilla up for review or comments ... even if the fix is not right it might be a good step to help getting the issues resolved ;-)
[20:17] <desrt> it makes the API slightly less awesome, but you don't really have to care about that since it's internal anyway
[20:17] <notgary> attente: thanks a lot for offering to help. How would you like us to bring you in on the GTK bugs we look at?
[20:18] <notgary> Also, I think we can consider the official part of the meeting over :)
[20:18] <notgary> I'll grab the logs later and pick out the things we need to work on and stick them on a wiki page somewhere
[20:18] <seb128> notgary, attente: I would suggest you just use launchpad bugs for tracking (and maybe open a bugzilla ticket as well) and subscribe attente when there is a patch up for review
[20:18] <radu> notgary, thanks for hosting this
[20:19] <notgary> Next time, we'll do this in #ubuntu-meeting, so I don't have to do that :)
[20:19] <druellan> notgary: thanks a lot
[20:19] <attente> notgary: are there already bugzilla tickets written up?
[20:19] <MCR1> notgary: Great Job ! Respect 8-)
[20:19] <seb128> notgary, attente: I do watch GTK bugs as well so I will make sure we find a way that works for everyone
[20:19] <attente> seb128: thanks!
[20:19] <notgary> no problem. Thanks a lot for coming along :)
[20:21] <seb128> yw ;-)
[20:44] <seb128> 'night
[20:44] <notgary> good night
[20:44] <notgary> and thanks for your input earlier
[21:40] <rigved> hello everyone
[21:40] <rigved> is the papercuts ninja meeting over?
[22:01] <Sweetshark> there is a special place in hell for people who think they should barf their random pet bug behaviour into some other unrelated bug because that one has more 'bug heat' and the party looks more fun there as there are lots of inconsistent comments already.
[22:03] <MCR1> rigved: yep, over.


[01:38] <ChrisP1948> I filed this bug report this afternoon - https://bugs.launchpad.net/ubuntu/+bug/1428356 I have no idea however what source pkg to file it against and that missing info needs to be added.
[12:45] <MegaBrutal> Hi all! I'd like to have #1423796 triaged.
[13:07] <Laibsch> anybody here understand the webdav protocol well?  I've had a problem with one of my webdrives (but not others) where when mounted it is always showing 13 of 26GB full.  This could be on a 5GB webdrive or one 150GB in size.  Actual filling also doesn't seem to have any effect: bug 1052595


[00:00] <slangasek> directhex: right; except that now by touching gnome-sharp2, I've inadvertently added to the NBS list, which means it's also on my todo list :)
[00:01] <directhex> don't forget gnome-desktop-sharp2 too!
[00:01] <directhex> i have no idea why upstream split those
[00:04] <kirkland> slangasek: iso coming down painfully slower than usual
[00:05] <kirkland> any ideas why my usb mouse stopped working in jaunty after an update earlier this week?
[00:06] <slangasek> usb mouse - no idea here
[00:09] <Keybuk> weird, four files are now missing from my git import
[00:10] <geubank4><PHONE_NUMBER>00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[00:10] <geubank4><PHONE_NUMBER>000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[00:12]  * slangasek scratches his head
[00:12] <directhex> 0!
[00:14] <slangasek> right, I got that part :)
[00:14] <NCommander> morning/evening/whenever slangasek and directhex
[00:14] <directhex> NCommander, just gone midnight
[00:15] <slangasek> NCommander: dawn of a new age, NCommander
[00:15] <NCommander> according to my inbox, yes, yes it is :-P
[00:15] <slangasek> oh hah, gnome-sharp2 is missing Replaces: on the old package names
[00:20] <kirkland> slangasek: so those server cd's still have the "encrypt home" option
[00:20] <kirkland> slangasek: which is going to fail miserably
[00:20] <kirkland> slangasek: if a user select the "yes, encrypt my home" option, the user creation will fail
[00:21] <kirkland> slangasek: i was under the impression that cjwatson had disabled that, in lieu of the missing kernel modules
[00:25] <slangasek> kirkland: seems appropriate to treat that as errata, IMHO
[00:26] <kirkland> slangasek: :-/  i'll go ahead and file a bug and prepare for the many duplicates
[00:27] <slangasek> you should only get duplicates from those who use early alphas without reading the errata from the technical overview
[00:27] <slangasek> I hope this is a small set :)
[00:28] <directhex> always the optimist, steve
[01:06] <calc> best buy is giving away bluray players when you buy any HDMI cable $79.99 or higher and 10 bluray movies (out of a set of 50)
[01:07] <calc> and has a cable advertised next to it for $116.99
[01:07] <calc> when you can get them for $4.99 easily
[01:07] <kirkland> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/user-setup/+bug/309541
[01:07] <kirkland> slangasek: details of that bug;  workaround too
[01:07] <kirkland> slangasek: can you add that to the errata?
[01:29] <kirkland> slangasek: okay, server iso testing posted for amd64 and i386
[01:29] <slangasek> kirkland: woot, thanks.  Working on the errata now
[01:30]  * kirkland -> back to work that requires far more brain cycles
[01:38] <slangasek> evand: was there a bug number for the ongoing issues with ubiquity manual partitioning?
[01:47] <RAOF> Hm.  It seems https://wiki.ubuntu.com/JauntyJackalope/TechnicalOverview is lying at the moment; while alpha 2 contains the DDX part of nouveau, synced from debian, we still need the kernel modules before it'll actually work.
[01:48] <RAOF> I've got a dkms'd source package built for them; it just needs some debian/copyright love and a review.
[02:03] <NCommander> slangasek, where are the CD build logs?
[02:03] <slangasek> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ ?
[02:05] <bryce> RAOF, ah okay - can you update the release notes accordingly
[02:05] <RAOF> bryce: Certainly
[02:05] <bryce> RAOF basically what I was going for is, "Yeah, -nouveau is in the archive, but don't expect it to work"
[02:06] <NCommander> slangasek, thanks, for some reason, twm is on the Xubuntu CD O_O;
[02:06] <RAOF> bryce: I think we _might_ want bugs, once the kernel module's in.  Upstream certainly doesn't mind bugs against the 2d component.
[02:07] <slangasek> RAOF: please let me know when you're done making that change, I have other cleanup pending
[02:09] <RAOF> Hm.  Do you still have the lock on that page?
[02:11] <RAOF> slangasek: Do you want to finish your edits before I do mine?    Done.
[02:38] <NCommander> slangasek, can you confirm a bug for me on the CD in /etc/apt/sources.list
[02:39] <NCommander> universe seems to have gone missing ....
[02:39] <slangasek> in xubuntu?
[02:39] <NCommander> yeah
[02:39] <NCommander> this is the line shipped:  deb cdrom:[Xubuntu 9.04 _Jaunty Jackalope_-Alpha i386 (20081218)/ jaunty main multiverse restricted
[02:40] <slangasek> I don't have the xubuntu images to hand where I could inspect them
[02:40] <NCommander> bah. Who do I file a bug with to get that fixed :-)?
[02:40] <slangasek> is this the same xubuntu image that someone said 3 of 4 test cases passed just fine on for alpha-2?
[02:41] <NCommander> The alternate passed
[02:41] <NCommander> No one has reported success with desktop
[02:41] <slangasek> you're talking about desktop?
[02:41] <kirkland> slangasek: fyi, RAID seems busted in the installer
[02:41] <slangasek> ok
[02:41] <NCommander> slangasek, sorry that I wasn't clear
[02:41] <slangasek> kirkland: bug + errata? :)
[02:42] <kirkland> sladen: https://bugs.edge.launchpad.net/ubuntu/+source/partman-md/+bug/309555
[02:42] <slangasek> ack
[04:08] <ScottK> slangasek: iso tracker says we aren't currently testing upgrades.  Is the intended?
[04:14] <ashiswin> hello
[04:51] <lool> morning
[04:54] <slangasek> ScottK: I wasn't planning on focusing on upgrades yet given that upgrades are a moving target (generally happening via upgrade against the archive, not against ISOs)
[04:55] <kirkland> cjwatson: kees: hey guys, i just merged mdadm for jaunty
[04:55] <ScottK> slangasek: OK.  As long as it's by design.
[04:55] <kirkland> cjwatson: kees: i haven't seen TheMuso around lately, who did the last merge
[04:55] <kirkland> cjwatson: kees: the diff is exceptionally big, due to our udev methodology
[04:55] <kirkland> cjwatson: kees: so I'd appreciate a good review
[04:56] <kirkland> cjwatson: kees: importantly, this merge fixes a couple of really nasty, critical segfault issues, brought up by Fabbione earlier today
[04:56] <kirkland> https://bugs.edge.launchpad.net/ubuntu/+source/mdadm/+bug/282492 for example
[04:57] <kirkland> cjwatson: kees: my work is available for review/sponsoring at http://people.ubuntu.com/~kirkland/mdadm/
[04:58] <kirkland> cjwatson: kees: from a testing perspective, i've functionally tested only a small subset of the vast array of mdadm functionality
[04:59] <kirkland> cjwatson: kees: raid1, booting, degraded, adding a disk, failing a disk
[05:00] <kirkland> cjwatson: kees: it would take a week or more to test every mdadm option ... what's my due diligence, here?
[05:10] <nixternal> kirkland: I may be able to lend a mdadm testing hand in the next few days if needed when I get back in the office...I am looking at mdadm as an option for one of our appliances in the future
[05:38] <ScottK> slangasek: I think we're in reasonable shape for Kubuntu unless some ubiquity fixes magically appear.
[05:39] <ScottK> For Alpha 2, I'm not sure we care.
[05:39]  * slangasek nods
[05:39] <ScottK> slangasek: We also have release notes for you  to link to in your release announcment.
[05:40] <slangasek> URL?
[05:41] <ScottK> https://wiki.kubuntu.org/JauntyJackalope/Alpha2/Kubuntu
[05:41] <ScottK> Sorry.  Got distracted.
[05:41] <ScottK> They aren't "Done", but they aren't horrible either.
[05:43] <Keybuk> dh_install --sourcedir=debian/tmp-udeb -pudev-udeb
[05:43] <Keybuk> dh_install: libvolume-id1 missing files (lib/libvolume_id.so.*), aborting
[05:43] <Keybuk> err, but I didn't tell you to do that package
[05:43] <ScottK> The iso tracker is reasonably well filled out http://iso.qa.ubuntu.com/qatracker/build/kubuntu/all - nixternal is currently doing more amd64 alternates.
[05:44] <ScottK> slangasek: If it were up to me and everyone else was ready to go, I'd say Kubuntu is ready enough to pull the trigger.
[05:44] <ScottK> slangasek: In the meantime, we'll keep testing.
[05:44] <ScottK> JFTR I did a kubuntu-desktop upgrade in a chroot and it went smoothly.
[05:45] <Keybuk> ah, apparently I did
[05:45] <Keybuk> bloody build-arch: DH_OPTIONS=a
[05:45] <nixternal> ScottK: I am going to pass it...retested w/o my goofy setup just fine
[05:46] <ScottK> nixternal: Great.  Progress.
[05:46] <nixternal> just gotta remember which partition is root for my goofy partition.... /dev/sda9 == (hd0,8)
[05:46] <nixternal> ooh, pretty KDE 4 :)
[05:48] <ScottK> slangasek: I'm off to bed, so good luck.
[05:56] <kees> kirkland: cool, I will review and install it tomorrow.  generally, if it looks right and you think it's ready, it's good to upload.  we should always be careful, but glitches are okay -- it is the devel release, after all.  :)
[05:57] <nixternal> who needs a stripe anyways :p
[05:58] <lool> Hmm I'm afraid I need to raise a SRU regression, even if it's fairly minor
[05:58] <lool> dpkg : erreur de traitement de /var/cache/apt/archives/linux-libc-dev_2.6.27-11.21_amd64.deb (--unpack) : tentative de remplacement de « /usr/include/drm/drm_sarea.h », qui appartient aussi au paquet libdrm-dev
[06:00] <lool> Ah no, not promoted to updates yet
[06:00] <lool> slangasek: Around?  we need to prevent linux from migrating to intrepid
[06:01] <slangasek> oh gar, I was wondering about that bit of the changelog
[06:01] <lool>   * synchronise our linux-libc-dev with the kernel userspace headers
[06:01] <lool>     - LP: #300803
[06:02] <slangasek> lool: please mark bug #300803 verification-failed
[06:02] <lool> I don't think this should have been done in intrpeid
[06:02] <lool> slangasek: (done)
[06:02] <slangasek> indeed not; but the changelog was terse and the upstream delta large, so it didn't get very close inspection on its way through unapproved
[06:04] <lool> Touching the linux-libc-dev headers in a released distro doesn't make sense IMO
[06:06] <lool> (didn't exactly understand the scope of the change until reading the full description in the bug)
[06:06] <lool> slangasek: Also, this needs to go synchronized with a new meta, right?
[06:06] <slangasek> yes
[06:10] <dholbach> good morning
[06:10] <lool> hey Daniel
[06:11] <dholbach> hey lool :)
[06:32] <Keybuk> hmm
[06:32] <Keybuk> keep getting internal compiler errors
[06:36] <Keybuk> only in an i386 chroot though
[08:16] <NCommander> hey cjwatson_
[11:24] <cjwatson> hmm, something apparently went wrong with the pygobject build for hardy-updates/sparc; it claims to be only for python 2.5, unlike other architectures
[11:24] <cjwatson> this breaks ubiquity's build
[11:26] <cjwatson> gar, timestamps caused an autotools regeneration
[11:56] <cjwatson> bug 309674: hardy-updates regression
[11:56] <cjwatson> (I've mailed the TB and others)
[12:26] <ScottK> pitti: Is it your day for Archive duties?
[12:28] <ScottK> pitti: If so, if you would accept kde4-style-bespin from binary New, then libplasma2 could be removed (NBS).
[12:34]  * ScottK just noticed that kdeedu is also in binary New.
[13:29] <NCommander> WOOO, My application moved!
[13:39] <NCommander> ^NM
[13:40] <directhex> NCommander, quick, apply to be project secretary!
[13:40] <NCommander> Still no account
[13:40] <NCommander> and I think you need to be in a year before you can apply
[13:40]  * NCommander would be more interested in FTP assistant if I did anything
[13:40] <NCommander> Must. Get. NEW. Queue. Empty
[13:41] <directhex> yeah, greenlight my moon package plz kkthx
[14:17] <evand> Does anyone know if gettext has a mechanism for handling a variable length list?  For example, "%s, %s, and %s" or "%s and %s" or "%s".
[14:28] <fta> bryce, just attached the info you asked in bug 265029
[14:45] <kirkland> nixternal: awesome, thanks dude!
[14:45] <kirkland> kees: cool, thanks.
[14:54] <norsetto> kees, what do you think about bug 309732?
[14:58]  * EtienneG wonder: should mkfs create ext3 file system by default?
[14:59] <ScottK> EtienneG: According to man mkfs, ext2 is the default.
[15:00] <EtienneG> ScottK, I know, I am questioning why :)
[15:01] <ScottK> At a guess either a developer picking a very conservative default or not updated in a long time.
[15:03] <ScottK> Since it's util-linux, I'd just ask lamont`
[15:05] <EtienneG> on the other hand, if it is the default in util-linux as shipped by upstream, no need to break people's assumption needlessly
[15:05] <EtienneG> still, I get caught almost everytime I manually create an fs :(
[15:07] <NCommander> hey ScottK
[15:08] <ScottK> Heya NCommander.
[15:08] <NCommander> how goes it?
[15:10] <ScottK> I keep waiting for slangasek to pull the trigger on Alpha 2.  In the meantime I might get some actual $WORK done.
[15:16] <NCommander> ScottK, same here
[15:16]  * NCommander is working on fixing a rather nasty bug in dpkg
[15:16] <NCommander> assuming my sid chroot will actually build this century
[15:38]  * kirkland is wondering if an archive admin out there could nudge screen profiles through the queue, https://edge.launchpad.net/ubuntu/jaunty/+queue
[15:38] <kirkland> pretty please :-)
[15:42]  * RainCT hugs kirkland for creating the screen profiles :)
[15:42] <kirkland> RainCT: \o/
[16:16] <kees> norsetto: since duma was designed to overload those kinds of things, yeah, I think it's fine to pass -U_FORTIFY_SOURCE to it.
[16:57] <LaserJock> asac: around?
[16:57] <asac> LaserJock: on vac ;) whats up?
[17:00] <LaserJock> asac: oh, sorry. was just a NM question
[17:01] <LaserJock> asac: I can't seem to get NM to stick with a connection when I have eth0 and wifi available
[17:01] <LaserJock> when I first get on the network I tell it to connect to the eth0 network, but then it starts connecting to various wifi networks I also have available
[17:02] <LaserJock> is there some way to like prioritize them or something?
[17:02] <ScottK-laptop> Airplane mode switch should do it.
[17:02] <ScottK-laptop> ;-)
[17:02] <cody-somerville> Remember how I said people's #1 complaint is updates break their computer? I'm on the phone with someone who says after the updates they're getting the following error message:
[17:02] <cody-somerville> Aborted because of invalid compressed format (error=2)
[17:02] <cody-somerville> Kernel Panic: SYNCING VFS, unable to mount root fs on unknown-block.
[17:03] <asac> LaserJock: commonly complained feature ... only solution as of now is to disable wireless while being on wired
[17:04] <LaserJock> asac: ok
[17:04] <LaserJock> asac: I thought I had turned of "automatically connect" on the wifi networks but when I go into the editor it's checked
[17:04] <LaserJock> asac: does NM keep that setting?
[17:04] <asac> LaserJock: system connection?
[17:04] <LaserJock> no
[17:04] <asac> LaserJock: usually it works for me
[17:05] <LaserJock> asac: ok, I'll play with it some more
[17:21] <norsetto> kees, okki, thx
[17:47] <rtg> evand: when is ext4 gonna appear as an option when installing server?
[17:52] <ion_> When It’s Ready™ would be my guess. :-)
[17:54] <cjwatson> rtg: do you think it's appropriate? it wouldn't be hard to add but I think we were waiting for the go from you guys ...
[17:54] <cjwatson> oh and I suppose we need the userspace tools to be in place, I don't know if they are
[17:54]  * ScottK knows jdong has been experimenting with ext4.
[17:55] <rtg> cjwatson: The UDS discussion was that ext4 would be offered as an option on a disk formatted installed. dist-upgrades would continue with ext3
[17:55] <cjwatson> somebody might need to hack minimal ext4 support into parted
[17:55] <rtg> s/installed/install/
[17:55] <cjwatson> dist-upgrades> yeah, I didn't doubt that
[17:55] <rtg> ext3 will remain the default, but ext4 needs exercizing.
[17:57] <evand> I'd love to have ext4 support for fallocate.
[17:57] <cjwatson> doesn't appear to be any ext4 support in libparted. poo.
[17:57] <rtg> indded, ext4 has a number of advantages.
[17:58] <rtg> I'm interested in the trim instruction on SSDs
[17:59] <slangasek> hmm, I thought fallocate was being implemented in ext3 as well?
[18:00] <fta> kees, we planed to point to the partner repository instead of the adobe web site.
[18:00] <evand> Is it?  I searched for such an article on Google hoping that it would be, but came up empty.  Perhaps my google-fu is lacking.
[18:00] <evand> slangasek: link?
[18:00] <calc> cjwatson: iirc the discussion mentioned the userspace tools were already in intrepid, but i'm sure they are still being updated as bugs are found ;-)
[18:01] <slangasek> evand: some factoid I absorbed from skimming the samba-technical mailing list; it's possible I misunderstood
[18:02] <evand> I'll just continue to hope then :)
[18:02] <kees> fta: yeah, just got a brain-dump from asac
[18:03] <cjwatson> calc: looks like e2fsprogs is but that nobody's worked on libparted at all
[18:03] <fta> kees, if you're already done, well.. go ahead
[18:03] <calc> cjwatson: ah ok
[18:20] <ScottK> cody-somerville: What update caused that crash?
[18:21] <ScottK> slangasek: Is there anything from Kubuntu holding you back from Alpha 2?
[18:22] <slangasek> ScottK: no, I just have one more Ubuntu test failure to review and some publishing to do, then we should be there
[18:22] <slangasek> though xubuntu alternate/amd64 is untested
[18:22] <slangasek> cody-somerville, NCommander: either of you in a position to test that?
[18:22] <ScottK> slangasek: Great.  Just wanted to make sure we weren't on the critical path.
[18:23] <slangasek> sure, thanks for asking
[18:23] <cody-somerville> slangasek, NCommander is
[18:24] <ScottK> slangasek: Any chance of getting some binary New done? I'm particularly anxious for kde4-style-bespin and kde-edu.  Once kde4-style-bespin is out, libplasma2 can be removed.
[18:25] <LaserJock> ScottK: why is kde-edu in NEW?
[18:25] <slangasek> ScottK: yes, but not before I finish up alpha2
[18:25] <ScottK> New/renamed biany, I assume.
[18:25] <ScottK> biany/bianary
[18:25] <ScottK> slangasek: Great.
[18:26] <ScottK> LaserJock: What university are you at again?
[18:26] <LaserJock> ScottK: University of Nevada
[18:27] <hunger> Is somebody working on fixing X again in jaunty?
[18:27] <ScottK> LaserJock: plasmoid-worldclock is the new package for kde-edu
[18:28] <ScottK> LaserJock: ondrej from DPMT is moving to Reno to go to U of N, Reno.
[18:29] <LaserJock> why is worldclock in KDE Edu?
[18:29] <ScottK> Debian Python Modules Team (where you show up to talk matplotlib sometimes)
[18:29] <ScottK> Dunno.  Upstream does as upstream wills.
[18:29] <LaserJock> ScottK: oh, cool
[18:48]  * directhex reckons that if the desktop experience team were hiring for some kind of GL programming position, they should really really look at the application from the gtkglarea maintainer
[18:48] <directhex> if such a person had applied, anyway
[20:07] <EvanCarroll-box2> Is there a channel for mirror maintence, the /fiesty/* is down at <IP_ADDRESS> 80
[20:07] <EvanCarroll-box2> does any one have an alt ip i can use?
[20:12] <calc> EvanCarroll-box2: feisty is EOL its available at old-releases but should no longer be used in general
[20:13] <EvanCarroll-box2> hrm, i thought it was supported for 1yr
[20:13] <Nafallo> EvanCarroll-box2: 1.5 years...
[20:13] <calc> EvanCarroll-box2: 18 months and it came out in apr 2007
[20:13] <EvanCarroll-box2> oh shit. I'm a year behind the rest of the world.
[20:13] <calc> EvanCarroll-box2: no longer supported as of Oct 2008
[20:15] <calc> EvanCarroll-box2: current release is intrepid (8.10)
[20:17] <EvanCarroll-box2> calc: yes, i know, i'm trying to trouble shoot intrepids cups-pdf which i think is bugged, and I wanted to have an older version for these issues..
[20:18] <EvanCarroll-box2> I aparently overachived.
[20:18] <EvanCarroll-box2> I wanted 8.04, i got 7.04
[20:20] <calc> EvanCarroll-box2: heh
[20:20] <calc> EvanCarroll-box2: well if you do need to go back that far you can get all releases at old-releases.ubuntu.com
[20:45] <tedg> I love that on one mailing list is a discussion on how SRU is too easy and on the other there is a discussion on how it's too difficult.  :)
[20:45] <ScottK> Well they both probably have their points.
[20:46] <tedg> Yes, but you'd have to admit there is a certain amount of irony there.
[20:46] <ScottK> OTOH, I'm still waiting to find out which update broke cody-somerville's friend's box
[20:46] <ScottK> Totally
[20:46] <cody-somerville> ScottK, I have no idea. I'm in Ontario and they're in New Brunswick
[20:46] <cody-somerville> ScottK, they can't even boot their machine
[20:47] <elmo> cody-somerville: surely they can use an older kernel?
[20:47] <elmo> like vorlon said, that's just the kind of error that comes from update-initramfs being killed or breaking
[20:47] <elmo> last time I saw it, a user had closed the upgrade window mid-run
[20:48] <cody-somerville> elmo, Yes, I was going to give those directions but unfortunately the power is out now for her
[20:48] <cody-somerville> (yea winter!)
[20:48] <LaserJock> ScottK: I find it pretty hard to figure out which update breaks things
[20:49] <LaserJock> if you're getting ~20 packages/update and you don't notice the breakage right away it's hard to pin down
[20:49] <slangasek> elmo: hrm, our kernel postinsts should be robust against a mid-upgrade abort
[20:50] <LaserJock> you know, I think I had one of those the other day
[20:50] <slangasek> ("should" in both the "damn well oughta be" and "I believe they're designed correctly" senses)
[20:51] <LaserJock> I was upgrading and my computer froze at updating the initramfs
[20:51] <LaserJock> but I was able to reboot ok, and running dpkg --configure -a got everything in shape
[20:51] <elmo> slangasek: unfortunately, I wasn't there to witness what they did, I only arrived in time to stop some helpful muppet from wiping their laptop as a "fix"
[20:55] <slangasek> in the future I will have a consultancy firm named "Helpful Muppets"
[20:57] <elmo> slangasek: ok, so checking my irc logs, it appears it use to be broken; keybuk claims to have fixed it, back in Feb or so
[20:57] <slangasek> hmm
[20:57] <elmo> or rather, TheMuso fixed it
[20:57] <slangasek> bad that it was ever broken; the root design of initramfs-tools was always correct in this matter
[21:04] <cjwatson> elmo: right, this was something we fixed as a hardy "feature" (i.e. err this is a scary bug let's call the fix a feature to make damn sure it gets scheduled)
[21:07] <calc> if you know the upstream bug number of a bug can you search for that via lp somehow to find the ubuntu bug report
[21:07] <calc> if they are already attached together
[21:07] <calc> i have a new dupe that i can't find the original bug report for
[21:19] <cjwatson> calc: yeah, there's a special redirect, let me look up how you get to it
[21:23] <cjwatson> calc: there might be a better way to do this, but one way is https://bugs.launchpad.net/bugs/bugtrackers, follow the link to the bug tracker in question, and then append /BUGNUMBER to the URL
[21:23] <cjwatson> if the bug is linked, it'll redirect you to the LP bug; otherwise it'll 404
[21:25] <calc> cjwatson: cool, thanks :)
[22:01] <bryce> slangasek: is archive still frozen for alpha-2, or can we start uploading post-alpha-2 stuff?
[22:01] <slangasek> bryce: go ahead with uploading, I'm pushing the button now
[22:01] <slangasek> (need to set up some kind of better pulley system to push the button for me)
[22:07] <cjwatson> err. did somebody NBS the armel kernel without making sure there was a new one there?
[22:08] <cjwatson> Please Don't Do That
[22:08] <cjwatson> (and if somebody could score up https://launchpad.net/ubuntu/+source/linux/2.6.28-3.4/+build/811335, I'd appreciate it)
[22:09] <cjwatson> (reason not to do it is that it means the kernel-overrides script won't be usable)
[22:22] <slangasek> cjwatson: possibly my fault for not thinking through the implications for armel, sorry
[22:23] <slangasek> rather, I appear to have assumed the NBS report's claim that the armel kernel flavors had no reverse-deps was an accurate indication of their state; do we not have a linux-meta on armel yet?
[22:46] <NCommander> ScottK, ping?
[23:04] <Caesar> slangasek: can you help out with #304907 at all?
[23:06] <ScottK-palm> slangasek do you mind if I add a link to the Kubuntu release notes on the testing wiki page you referenced in the announcement?
[23:15] <slangasek> ScottK: hmm, fail.  I noticed after sending the mail that I didn't link to the release notes anywhere; you can link to them from the TechnicalOverview wiki page, and I can ask for the contents to be copied to www.u.c
[23:15] <slangasek> Caesar: I can start by helping to stare at it in disbelief
[23:18] <slangasek> Caesar: this seems to be a package version newer than hardy, older than hardy-updates?
[23:19] <slangasek> Caesar: hrm, still buggy, though.  I'm surprised, because I remember us having to fix a bug just like this already in hardy
[23:38] <cr3> what page on wiki.ubuntu.com might provide insight on how upstream project collaborate their branches with the ubuntu-core-dev team? I'm looking at the UbuntuDevelopers page and I was expecting to see somekind of link to best practices for collaboration
[23:45] <Hobbsee> cjwatson: rescored
[23:46] <cr3> one of the questions I'm asking myself relating to collaboration is whether I should add the ubuntu-core-dev team to the trunk of my project or if I should create another branch specifically for the team.
[23:47] <slangasek> cr3: perfectly reasonable to let ubuntu-core-dev create its own branch which is authoritative for the Ubuntu packaging
[23:47]  * Hobbsee mutters something about mail as a result
[23:48] <cr3> slangasek: is there a usual naming convention or recommendation for the branch used by the ubuntu-core-dev team/
[23:48] <slangasek> Caesar: actually, I can't find any record of this particular file conflict existing in the Ubuntu archive
[23:48] <cr3> slangasek: and, in launchpad, should the branch be under the ubuntu project or under the upstream project?
[23:48] <slangasek> cr3: that would normally be created by the ubuntu-core-dev team itself
[23:48] <slangasek> it would be a branch associated with the upstream project
[23:49] <slangasek> but belonging to the ubuntu-core-dev
[23:49] <slangasek> group
[23:49] <slangasek> e.g., lp:~ubuntu-core-dev/grub/ubuntu
[23:51] <StevenK> And if you're not in ubuntu-core-dev, you can request a merge into that branch
[23:54] <cr3> slangasek: thanks for the explanation, everything is now clear :)