[23:13] -queuebot:#edubuntu- Unapproved: dnspython (focal-proposed/main) [1.16.0-1build1 => 1.16.0-1ubuntu1] (edubuntu, i386-whitelist, ubuntu-server)


[04:45] <doko> how are device files for the parallel interface named?
[04:47] <Keybuk> do you mean the old-fashioned parallel port?
[04:47] <doko> Keybuk: yes, /dev/parportN
[04:48] <Keybuk> there isn't a device for those, is there?
[04:48] <doko> sure, but there should be one?
[04:48] <Keybuk> I doubt it
[04:49] <Keybuk> do you see computers with them these days?
[04:49] <doko> at least MAKEDEV had support to create these device files
[04:49] <Keybuk> really?
[04:49] <doko> dude, every thinkpad has a parpart ...
[04:49] <Keybuk> I always thought you just talked to parallel ports directly via io, rather than through a device file
[04:50] <doko> >>> import parallel
[04:50] <doko> >>> p=parallel.Parallel()
[04:50] <doko> Traceback (most recent call last):
[04:50] <doko>   File "<stdin>", line 1, in ?
[04:50] <doko>   File "/usr/lib/python2.4/site-packages/parallel/parallelppdev.py", line 186, in __init__
[04:50] <doko>     self._fd = os.open(self.device, os.O_RDWR)
[04:50] <doko> OSError: [Errno 2]  No such file or directory: '/dev/parport0'
[04:50] <Keybuk> ok
[04:50] <Keybuk> loading the parport and parport-pc modules doesn't create that device
[04:50] <doko> yes
[04:50] <Keybuk> seems nobody's bothered to driver-core them
[04:59] <mjg59> Mm?
[04:59] <mjg59> Don't they appear as /dev/lp0?
[04:59] <Keybuk> that's a parallel printer
[04:59] <Keybuk> which is the "lp" driver
[04:59] <Keybuk> not raw parport access
[05:00] <mjg59> Ah, yes, that does assume a printer
[05:27] <Keybuk> mjg59: err @ your bug reassign
[05:27] <Keybuk> where does the docs say rmmod is the same as modprobe -r
[05:28] <Keybuk> all the docs say you should use modprobe -r as its better
[05:38] <infinity> Keybuk: So, when you changes how root mounting works in initramfs-tools, did you break LVM along the way?
[05:38] <infinity> Keybuk: There seems to be some murmuring to that effect.
[05:38] <Keybuk> I did, yes
[05:38] <Keybuk> I fixed it again though
[05:38] <Keybuk> the upload to initramfs-tools is the fix, not the cause
[05:38] <Keybuk> (worth an explanation)
[05:39] <infinity> Indeed..
[05:39] <Keybuk> we worked out, thanks to mjg59's knowledge of strange things called "reserved regions" that once a SATA driver was loaded there was no way ide-generic could steal the devices
[05:39] <Keybuk> when I'd investigated I was looking as to when udev got the "ADD /dev/sda" event, which is some time later
[05:39] <mjg59> Keybuk: Yeah, my mistake
[05:40] <Keybuk> so we were able to do away with the "if ide do this, if scsi do that" branching code in udev
[05:40] <Keybuk> and thus we can mount root filesystems with:
[05:40] <Keybuk> - load PCI drivers
[05:40] <Keybuk> - load ide-generic
[05:40] <Keybuk> - wait for up to three minutes for root to appear
[05:40] <Keybuk> PCI IDE drivers it'll appear instantly, so it won't wait
[05:40] <Keybuk> ide-generic will be a no-op if a PCI driver was loaded
[05:41] <Keybuk> if ide-generic runs the device, it'll appear instantly, so it won't wait
[05:41] <infinity> Didn't we have some bizarre race in the past when doing it that way?
[05:41] <Keybuk> for SATA drivers the driver will reserve the regions immediately so ide-generic won't break it, but it'll be a few seconds before udev gets the real "device add" events (which we wait for)
[05:41] <infinity> I vaguely recall my /dev/sda being /dev/hda on 3 out of 4 boots...
[05:42] <Keybuk> for SCSI drivers we get the devices after waiting for a few seconds
[05:42] <Keybuk> three minutes is a good upper limit on any device waiting
[05:42] <Keybuk> right
[05:42] <Keybuk> we had a bug certainly, but that has gone away
[05:42] <Keybuk> and that was partially caused by an old kernel patch which I removed
[05:42] <infinity> Ahh, well that's nice to know.
[05:42] <Keybuk> and the fact we loaded ide-generic *first*
[05:42] <Keybuk> we had a strange patch on our kernels that made loading ide-generic mandatory to get any PCI IDE driver to actually probe
[05:43] <Keybuk> rather than just probing in the PCI IDE drivers
[05:43] <infinity> Special.
[05:43] <Keybuk> ok
[05:43] <Keybuk> so I modified udev to do the above sequence
[05:43] <Keybuk> and all was good
[05:43] <Keybuk> except for LVM, EVMS, MD, etc.
[05:43] <Keybuk> which suddenly would "hang for three minutes" on boot
[05:43] <Keybuk> the fact they didn't before was actually a bug :)
[05:44] <Keybuk> and I fixed that bug when I rewrote the udev initramfs script, which made them break
[05:44] <Keybuk> they should have been breaking all through dapper
[05:44] <Keybuk> the bug is obvious; doing the three minute wait in the udev init-premount means that evms/lvm/etc. haven't been run yet (they're run in local-top)
[05:45] <Keybuk> so we're waiting for a root device to appear before running the magic that makes it
[05:45] <infinity> Right.
[05:45] <Keybuk> I thought about putting the wait in a udev local-top script, but couldn't get PREREQS to play nice (it's not possible to "DEPEND ON EVERYTHING")
[05:45] <Keybuk> and if you depend on something that doesn't exist, your script never gets run and initramfs goes into infiniloop territory
[05:45] <infinity> You could prereq *, perhaps.
[05:45] <makx> yeah that's a bug
[05:45] <Keybuk> I couldn't put it in local-premount because that's after mountroot() has already panic'd
[05:45] <infinity> Or something equally fucked up.
[05:46] <Keybuk> infinity: I tried that :p  you can't
[05:46] <infinity> But I'm pretty sure it wasn't designed to be used that way. :)
[05:46] <Keybuk> then I realised, that that loop code should be in mountroot() anyway
[05:46] <infinity> I could rewrite it to work that way, but icky corner case.
[05:46] <infinity> And yeah, it's better living in mountroot()
[05:46] <infinity> Debian may appreciate that change too.
[05:46] <Keybuk> so mountroot() now runs local-top, loops for up to three minutes to wait for the root to appear, then if it still hasn't appearered, loops calling panic to let the user fix it, and then carries on
[05:47] <Keybuk> for dapper+1 we can think about changing it to loop forever with a pretty message asking the user to insert the damned root filesystem, or press any key to get a shell, or something
[05:47] <Keybuk> tbh
[05:47] <Keybuk> for initramfs-tools, I'd rather get rid of PREREQS and just use run-parts and NN-* like everything else <g>
[05:48] <infinity> I don't like magic shell for dependencies either.
[05:48] <Keybuk> anyway
[05:48] <Keybuk> this should fix all occurances of the bug
[05:48] <Keybuk> as now we have
[05:48] <Keybuk> - probe for PCI devices
[05:48] <infinity> Not everything about Jeff's code gives me warm fuzzies, just enough to work on it. :)
[05:48] <Keybuk> - load ide-generic
[05:48] <Keybuk> - run evms, lvm, md, etc.
[05:49] <Keybuk> - wait for root to appear
[05:49] <Keybuk> - mount root
[05:49] <infinity> Rock.  Thanks, dude.
[05:49] <infinity> These little bugs have been biting us since dapper opened.
[05:49] <Keybuk> it actually makes the boot a bit cuter too, because 9/10 now your scsi card gets its act in gear while initramfs is working up to getting to mounting the root
[05:50] <makx> the fixed revsion of initramfs-tools is -25?
[05:50] <infinity> makx: Any chance of shoving the udev side of these changes down Md's throat, so you can make the initramfs changes to match ours?
[05:50] <infinity> makx: Yes, 24-25 would be the patch Scott did, then obviously, his new udev hooks are important to go with it.
[05:51] <makx> haven't looked at the udev changes.
[05:51] <makx> infinity: atm i work around Md with udev_helper which prequs udev
[05:51] <infinity> (And make sure Debian's kernels don't have that buggy behaviour mentioned above with ide-generic)
[05:51] <makx> which is suboptimal
[05:51] <Keybuk> ubuntu20->ubuntu21
[05:51] <Keybuk> infinity: Debian's kernels probably still do, because that's where we got the patch
[05:51] <Keybuk> it was a Xuism
[05:52] <Keybuk> something to do with making the old initrd "load every PCI driver" stuff less icky
[05:52] <makx> na it got dropped since 2.6.14
[05:52] <Keybuk> ok
[05:52] <Keybuk> actually, you want udev ubuntu19->ubuntu21
[05:52] <infinity> makx: Well, just from reading the description on IRC (haven't looked at the hooks yet), Keybuk's new udev hook is probably a fair bit simpler than before, so maybe Md wouldn't be too unhappy to include it.
[05:53] <makx> cool i'll take a look in some hours, will work on that.
[05:53] <makx> thanks
[05:53] <mjg59> BenC: Do we have anything other than bcm43xx using softmac yet?
[05:54] <BenC> not that I know of
[05:54] <infinity> Keybuk: Ahh, yes, init-premount/udev looks MUCH cleaner now.  Awesome.
[05:54] <mjg59> Ok, cool
[05:56] <infinity> Keybuk: Also, usplash_write calls don't need a || true on them, it exits zero even if your computer's on fire.
[05:56] <Keybuk> heh, everything else does || true
[05:56] <infinity> Yeah, not sure who to blame for the first || true. :)
[05:57] <mjg59> BenC: You have patches
[05:58] <BenC> patches!? we don't need no stinkin' patches!
[05:59] <mjg59> They ought to be enough to get bcm43xx to work nicely without hacky scripts
[05:59] <infinity> BenC: when do you want to co-ordinate the ipw3945 junk?
[06:00] <BenC> infinity: I think I'll just do the lrm end of it too, I need to add fwcutter aswell
[06:00] <infinity> Ahh, cool, all you, then.
[06:01] <mjg59> BenC: No joy with negotiating bcm43xx firmware?
[06:01] <infinity> fwcutter can go in LRM-common (which will need to become arch:any, I assume, unless it's a script), but the ipw3945 daemon appears to be versioned with the kernel module, so it should go in lrm-`uname -r` to keep lockstep (and the binary will need to be versioned on the filesystem)
[06:03] <infinity> BenC: If you'd prefer I do any of it, just poke me.  LRM and I are close personal friends (or enemies) at this point.
[06:07] <mjg59> The sooner we get the 3945 stuff in, the sooner we actually start getting bug reports about how broken it is
[06:08] <infinity> makx: What problem, exactly, did you have with moving the module lists to files?  I just tried it and it went smashingly...
[06:08] <BenC> mjg59: none so far
[06:09] <infinity> mjg59: Is that assuming someone has the hardware in their grubby little hands already?
[06:09] <mjg59> infinity: Oh, people /do/
[06:09] <makx> infinity: creation time of initramfs
[06:09] <mjg59> BenC: Yeah, that's because we're not shipping it...
[06:09] <makx> was 1/2 longer
[06:10] <infinity> makx: I get no slowdowns here... You must have been doing something scary weird...
[06:10] <BenC> mjg59: no I meant no luck with bcm43xx firmware
[06:10] <mjg59> BenC: Oh, right
[06:10] <makx> infinity: ok cool
[06:10] <infinity> makx: Perhaps you've been too heavily influenced by jbailey's shell. ;)
[06:10] <mjg59> BenC: Shame
[06:11] <mjg59> Wonder if I can get it out of the Broadcom UK people (who are all embedded MIPS)
[06:11] <infinity> mjg59: ISTR suggesting that once before...
[06:11] <infinity> The MIPS folk are very friendly with Debian, at any rate.
[06:16] <mjg59> I'll ask tbm about it
[06:16] <mjg59> He's been in touch with them before
[06:18] <infinity> Yes, he has a machine or two from them.
[06:18] <infinity> I wouldn't mind one myself.
[06:35] <Keybuk> infinity: random thought ...
[06:35] <Keybuk> we could split the udev script even further
[06:35] <Keybuk> start udevd, and probe for existing buses in init-premount
[06:35] <Keybuk> then move the local code to local-premount
[06:35] <Keybuk> and the network code to nfs-premount
[06:35] <Keybuk> or something
[06:36] <infinity> Yeah, when looking at your switch on $BOOT, I was noting you could do that.
[06:36] <Keybuk> (actually, probably nfs-top and init-top)
[06:36] <infinity> Not that it would make much difference, it would just seem "cleaner"
[06:36] <infinity> OTOH, if it's working how it is now, why break it again? :)
[06:37] <Keybuk> cleanliness? :p
[06:38] <Keybuk> it'd fix the bug where if you change the boot options on the kernel command line, udev ignores it
[06:38] <infinity> Next to godliness, I hear.
[06:38] <Keybuk> (it gets $BOOT by reading conf/initramfs.conf)
[06:38] <infinity> Oh, really?  Yeah, that's kinda icky, then.
[06:38] <infinity> By all means, muck with your stuff how you want.  They're your hooks. ;)
[07:07] <Keybuk> infinity: "while I was in there" ...
[07:07] <Keybuk> I moved the lvm and md scripts to lvm-common and mdadm
[07:08] <infinity> Gar.
[07:08] <Keybuk> Gar?
[07:08] <infinity> Our uploads collided.
[07:08] <Keybuk> lol
[07:08] <Keybuk> what did you upload?
[07:08] <infinity> And soyuz happily accepted both.  AWESOME.
[07:08] <infinity> Go soyuz!
[07:09] <Keybuk> yeah, it does that
[07:09] <infinity> Clearly it has a different concept of "ACCEPT" than katie does...
[07:09] <Keybuk> I think whichever one gets mailed second wins
[07:09] <infinity> That would be me, then.
[07:10] <infinity> I wasn't going to move the lvm and md stuff until Debian did, but I don't mind seeing it go either. :)
[07:10] <Keybuk> I long ago gave up "waiting for Debian" :p
[07:10] <Keybuk> actually, it was about the time I resigned from Debian
[07:10] <Keybuk> lol
[07:10] <infinity> I assume lvm-common and mdadm have appropriate Replaces: on them?
[07:10] <Keybuk> they do
[07:10] <infinity> (Of course, the Replaces will now be wrong..)
[07:10] <Keybuk> I found that if we do stuff for them, it gets into Debian quicker
[07:10] <Keybuk> lol
[07:10] <infinity> (Cause my version still has those scripts)
[07:10] <Keybuk> actually, one of them will be right
[07:11] <Keybuk> because I mucked up the Replaces
[07:11] <Keybuk> LOL
[07:11] <infinity> Right, well you may as well bang up new uploads with fixed Replaces, and then we can yank the scripts AGAIN.
[07:12] <Keybuk> who wants to make a 28 with the right things?
[07:12] <Keybuk> do you want to, or shall I?
[07:12] <infinity> 27, even.
[07:12] <Keybuk> 27?
[07:12] <Keybuk> you want to upload a THIRD 27? :p
[07:12] <infinity> Unless you're skipping one out of deference to the one that got lost in the queue. :)
[07:12] <Keybuk> or did we both upload clashing 26s?
[07:12] <infinity> We did 26. :)
[07:12] <Keybuk> ahh
[07:12] <Keybuk> I did a 27 seconds later
[07:12] <Keybuk> well, minutes later
[07:13] <Keybuk> Accepted:
[07:13] <Keybuk>  OK: initramfs-tools_0.40ubuntu27.dsc
[07:13] <Keybuk>      -> Component: main Section: utils
[07:13] <Keybuk>  OK: initramfs-tools_0.40ubuntu27.tar.gz
[07:13] <infinity> Oh, so I need a 28 with my changes? :)
[07:13] <infinity> Rock.
[07:13] <infinity> I'll do that when yours beats mine, then. :)
[07:13] <infinity> FUN GAME.
[07:13] <Keybuk> ok
[07:13] <Keybuk> http://people.ubuntu.com/~scott/packages
[07:14] <Keybuk> that has my 0.40ubuntu27 source
[07:14] <Keybuk> grab that, add your patch, then upload a 28
[07:14] <Keybuk> and see if we can get four accepteds for the same daily run <g>
[07:25] <zul> gday..
[07:25] <zul> BenC: new patch for you i sent in email..
[07:26] <BenC> zul: ok
[07:26] <zul> im not dead yet...just resting ;)
[07:28] <zul> oops...it bounced
[07:29] <Keybuk> infinity: what is the NM patch to madwifi?  does that make it support background scanning?
[07:29] <infinity> Sadly, no, just WPA extensions.
[07:30] <infinity> Background scanning would probably be an unwieldly backport, although the NM keeners are looking into it.
[07:30] <infinity> (I've not even tried to find the bits required)
[07:30] <infinity> Also, our ubuntu26 uploads got under the wire for the last cron.daily, so we didn't get 4 in one cycle.. *sad*
[07:31] <infinity> (That also means that my ubuntu26 is building right now... Or yours.. One of them)
[07:32] <infinity> In the end, looks like mine won. :)
[07:34] <crimsun> BenC: pong
[07:34] <BenC> crimsun: unping, current patches fixed hda problems that people were seeing
[07:35] <Keybuk> In Soviet Distro ... Soyuz accepts you!
[07:35] <crimsun> BenC: ok. Were these the sigmatel or realtek folks?
[07:38] <crimsun> ah, analog
[07:45] <BenC> zul: already got the patch in
[07:45] <zul> BenC: ok good to know
[08:36] <BenC> mjg59: Can you look at https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/33704
[08:37] <BenC> mjg59: User claims his amd64 system wont boot unless he removed the ATI IO-APIC block from you (timer pin fixup)
[08:37] <mjg59> BenC: Yes, some newer BIOSes "fix" it in a way that breaks that
[08:37] <mjg59> We should revert my fix and go to the one used in 2.6.16
[08:37] <mjg59> Hang on, I'll dig it out
[08:37] <BenC> ok
[09:16] <dilinger> hm
[09:16] <dilinger> BenC: so davem claims he's got silo booting from iso9660 on the sunfire 280 i sent him
[09:17] <BenC> dilinger: as far as I know silo 1.4.11 contains all the fixes needed
[09:17] <dilinger> BenC: cool, ok
[09:18] <dilinger> BenC: hm, is there a changelog anywhere or anything?  i'm curious what the actual fix involved?
[09:19] <BenC> there's a subversion repo
[09:19] <BenC> svn.sparc-boot.org
[09:19] <dilinger> s-b.o/websvn is a 404
[09:20] <dilinger> what's the full path for the repo?
[09:21] <BenC> that's not an http url
[09:21] <BenC> it's svn:// url
[09:21] <dilinger> yea, i tried that
[09:21] <dilinger> svn: PROPFIND of '/': 405 Method Not Allowed (http://svn.sparc-boot.org)
[09:21] <BenC> svn co svn://svn.sparc-boot.org/silo/trunk silo
[09:21] <dilinger> thanks
[10:01] <fabbione> dilinger: yes.. i got the iso to boot here too on the netra
[10:15] <mjg59> BenC: More network drivers for you
[10:16] <mjg59> (You love it really)
[10:37] <mjg59> BenC: And there go the apic fixes


[00:06] <bluesabre> hello friends :)
[00:26] <DalekSec> And non-friends?
[00:37] <bluesabre> not too many of those, I'd hope
[05:35] <zequence> bluesabre: Hi
[05:35] <zequence> OvenWerks: Been a while since I was working on that, so I don't actually remember much
[05:35] <zequence> I'm thinking we should try creating a simple meta that installs another DE, and our settings on top of it
[05:36] <zequence> Add it to a PPA
[06:05] <astraljava> Hey all. So what plans for the next cycle? :)
[06:40] <DalekSec> zequence: Wouldn't you rather have whatever flavor figure out the DE defaults, and you just layer Studio stuff atop of that?
[08:52] <zequence> DalekSec: Yep. That has been the plan for a while, but we've not been very active with it.
[08:53] <zequence> astraljava: I'll start working on that this weekend
[08:55] <zequence> We have stuff from before that is still in the works
[08:55] <zequence> Better start with that, and see which way to go from there
[09:01] <astraljava> zequence: True. What are your thoughts on the LTS status?
[09:13] <zequence> astraljava: How do you mean?
[09:13]  * zequence is travelling and will loose connectivity now and again
[09:14] <zequence> We already decided a while back not to put too much effort on promoting the non-LTS releases
[09:14] <zequence> One might as well think of us only developing LTS releases
[09:16] <zequence> All though each release needs to be functional of course
[09:21] <astraljava> zequence: I mean that how much new development are you willing to push in contrast to maintaining a stable upcoming LTS release.
[09:29] <zequence> astraljava: We do what we have time for. One thing at the time :)
[09:37] <astraljava> Hehe, well that much is true. And has always been with Studio especially. :D
[09:37] <astraljava> Not exactly devs in abundance. :p
[09:40] <zequence> Last cycle was propbably the least active ever.
[09:42] <astraljava> Right, but still you managed. That's quite impressive!
[09:44] <zequence> I didn't have to do much. I keep updating linux-lowlatency every three weeks, which I will be quitting now
[09:45] <zequence> The most work I did was probably at the end, when I realized our meta and seed setup was broken
[09:45] <zequence> Come to think of that, I still have one last linux-lowlatency update which I have neglected :P
[09:45] <astraljava> So how exactly is the kernel situation going to be handled in the future?
[09:46] <zequence> linux-lowlatency no longer has a patch, so there was no problem merging the source with -generic
[09:46] <zequence> There's just a config diff. We maintain that, but we don't need to do any building or testing of the lowlatency kernel, other than what we do for our own sake
[09:47] <zequence> i.e., making sure it's doing what it is supposed to now and again
[09:47] <zequence> I've kept maintaining the precise kernel, which still has a patch
[09:47] <zequence> The patch allows the use of rtirq
[09:47] <zequence> Nowadays, this can be done using a config
[10:03] <astraljava> Ok great! Thanks for the clarification.
[19:19] <cub> zequence, I saw about making videos. It would be about time. :D I'll start installing and setting up my workstation soon enough
[19:20] <millerthegorilla> does anyone know if I can upgrade xfce to 4.12 if I install the lts 14.0.4
[19:47] <cub> millerthegorilla, http://www.webupd8.org/2015/03/install-xfce-412-in-xubuntu-1404-or.html
[19:47] <cub> should be the same procedure in Ubuntu Studio
[19:49] <cub> exit
[19:50] <cub> oops wrong window. :D


[05:36] <pitti> Good morning
[06:29] <didrocks> good morning
[06:36] <pitti> bonjour didrocks, comment vas-tu?
[06:36] <didrocks> pitti: ça va bien, et toi? comment s'est passé le voyage de retour?
[06:37] <pitti> didrocks: tout etait bien, merci
[06:38] <pitti> c'était une voyage calme
[06:38] <pitti> et j'ai faire beaucoup de hacking :)
[06:40] <didrocks> oui, j'ai lu ton post sur g+ ;)
[08:25] <didrocks> hey larsu, uneventful flying back home? :)
[08:36] <larsu> didrocks, yup, all 40 minutes of it ;)  And for you?
[08:37] <didrocks> larsu: all good for me, no surprise ;)
[08:56] <duflu> I think I left my heart in San Francisco... and my body clock in Copenhagen :P
[08:58] <didrocks> duflu: take it easy until you can get used to your timezone again :)
[09:00] <seb128> hey desktopers
[09:02] <sil2100> ;p
[09:06] <mlankhorst> heya
[09:06] <didrocks> hey seb128, sil2100, mlankhorst!
[09:07] <sil2100> Morning everyone!
[09:07] <mlankhorst> my body clock is slowly shifting towards amsterdam again, waking up later than before :p
[09:07] <BigWhale> good morning all
[09:07] <seb128> hey didrocks sil2100 mlankhorst BigWhale
[09:07] <mlankhorst> waking up at 7 was fun while it lasted
[09:07] <BigWhale> hey seb
[09:08] <BigWhale> So, are there any guidelines about unit testing GTK?
[09:08] <Laney> hey
[09:08] <seb128> hey Laney
[09:14] <chrisccoulson> hey desktop team
[09:14]  * Laney saw Skyfall yesterday... some creative computing in there
[09:14]  * Laney strips off the packet headers to decypher the GPS trace
[09:14] <didrocks> hey chrisccoulson, Laney!
[09:17] <seb128> hey chrisccoulson, Laney, how are you?
[09:17] <chrisccoulson> hi didrocks, Laney, seb128
[09:18] <chrisccoulson> seb128, yeah, not too bad thanks. did you get back ok?
[09:18] <Laney> good thank you
[09:18] <Laney> going through a forced mobile phone detox ;-)
[09:19] <seb128> chrisccoulson, going back was fine, I was home at 11am on saturday, got some ubuflu though :-(
[09:19] <seb128> Laney, you broke your phone?
[09:19] <Laney> yeah I did it after the UDS party
[09:19] <seb128> ouch
[09:19] <xnox> Laney: it wasn't exactly christmas for creative computing =) but I liked that it was mostly in London & Scotland.
[09:20] <Laney> waiting for the nexus 4 to come out
[09:20] <Laney> xnox: yeah, the locations were good
[09:21] <chrisccoulson> seb128, ah, that sucks :(
[09:21] <chrisccoulson> i've not been too bad since i got back. and i biked for more than 100km since friday too :)
[09:21] <seb128> you crazy man ;-)
[09:22] <seb128> training for the tour de france next year? ;-)
[09:22] <chrisccoulson> heh
[09:23] <chrisccoulson> hmmmm, all of my daily builds failed last week because my PPA's all ran out of space :/
[09:23] <chrisccoulson> https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/+packages
[09:23] <seb128> you are fighting with Sweetshark on disk space? ;-)
[09:23] <chrisccoulson> not sure where more than 20GB is going there :/
[09:24] <chrisccoulson> and it seems a coincidence that they've all ran out of space at the same time
[09:24] <chrisccoulson> all 3 PPA's :/
[09:25] <chrisccoulson> launchpad bug? ;)
[09:26] <chrisccoulson> oh yes, it's full of old builds: http://ppa.launchpad.net/ubuntu-mozilla-daily/thunderbird-aurora/ubuntu/pool/main/t/thunderbird/
[09:28] <xnox> chrisccoulson: old builds... you mean like 5 days old? =)
[09:29] <chrisccoulson> xnox, daily builds from 24th october ;)
[09:29] <pitti> hey seb128, how are you?
[09:29] <pitti> hey Laney, morning chrisccoulson
[09:29] <chrisccoulson> hi pitti, how are you?
[09:29] <seb128> pitti, hey, I'm ok, got some ubuflu though ... you?
[09:30] <pitti> chrisccoulson: quite fine, thanks!
[09:31] <pitti> seb128: je suis desolé à entendre que
[09:32] <chrisccoulson> xnox, it's bug 1071562 (from #launchpad)
[09:32] <ubot2`> Launchpad bug 1071562 in Launchpad itself "UEFI signing failures cause binaries to be republished continuously" [Critical,Triaged] https://launchpad.net/bugs/1071562
[09:44] <didrocks> on my phone connection as it seems my ISP provider decided to stop working…
[10:09] <pitti> desrt: hey Ryan, how are you? got a minute today?
[10:19] <Sweetshark> hmm, were do I ask for a fresh canonicaladmin password again?
[10:19] <Laney> I think #hr internal
[10:20] <Sweetshark> Laney: thx
[12:29] <Alpic> Hi all.
[12:29] <Alpic> Just need to know how to integrates pidgin in unity notification area : any idea a?
[12:33] <Alpic> Anyone there ?
[12:36] <mitya57> Alpic: I think the broken integration is bug 1040259
[12:36] <ubot2`> Launchpad bug 1040259 in skype-wrapper "FFE: libmessaging-menu transitions for quantal" [High,In progress] https://launchpad.net/bugs/1040259
[12:37] <Alpic> thanks for the tip
[13:03] <mhr3> seb128, we lost the pkexec patch from gnome-system-log again? :/
[13:05] <desrt> pitti: hi
[13:05] <desrt> jbicha: pong
[13:05] <pitti> hey desrt, how are you? had a safe trip?
[13:05] <seb128> mhr3, seems like somebody re-enabled that yes :-(
[13:06] <desrt> pitti: yup.  nice and uneventful. :)
[13:06] <desrt> seb128: greetings
[13:06] <seb128> desrt, hey, how are you?
[13:06] <desrt> everyone else back home safe or still some lingerers behind?
[13:06] <pitti> desrt: the best kind :)
[13:06] <mhr3> seb128, how come debian is fine with pkexec? did they patch it or glib or something?
[13:06] <pitti> desrt: I wondered if you could have a look at https://bugzilla.gnome.org/show_bug.cgi?id=686149 and check it's what you meant
[13:06] <ubot2`> Gnome bug 686149 in general "fix class initialisation" [Normal,Assigned]
[13:06] <desrt> seb128: very happy!  i'm still riding the happy jetlag that lets me wake up at 8am and feel like it's past noon :)
[13:07] <seb128> lol
[13:07] <pitti> it _is_ past noon! :-)
[13:07] <desrt> attente: hey.  what's up?  back home?
[13:07] <seb128> mhr3, they are not, they "fixed" that recently: http://packages.qa.debian.org/g/gnome-system-log/news/20121012T153227Z.html
[13:07] <attente> desrt: yes :)
[13:08] <desrt> attente: ĉhu venos vi al esperanto vespere?
[13:08] <attente> desrt: i didn't practice any
[13:09] <attente> desrt: better i just skip
[13:09] <desrt> nenioj levionoj?
[13:09] <desrt> *lec
[13:09] <seb128> hey attente, had a good flight back?
[13:09] <desrt> looks like i am out of practice as well :)
[13:10] <attente> seb128: i'm alive, that's enough for me :)
[13:11] <seb128> hehe
[13:12] <mhr3> seb128, hmm, and the reporter lies about StartupNotify, it doesn't fix it :P
[13:15] <xnox> didrocks: I noticed that on the desktop-r-2d-test-environments I got a workitem "fix ubiquity-frontend-gtk to not pull in metacity"
[13:16] <xnox> didrocks: while in the "foundations-r-arm-ubiquity" I got a workitem "fix ubiquity-frontend-gtk to optionally use compiz/unity instead of metacity"
[13:17] <xnox> didrocks:  Is that the same thing or do you want ubiquity to work with lxce window manager?
[13:26] <didrocks> xnox: it's the same one I would say :)
[13:27] <didrocks> xnox: so pick the blueprint your prefer
[13:27] <xnox> didrocks: hmm.... I'm picking your blueprint at it has higher priority and I don't want this work item to sink.
[13:27] <didrocks> xnox: thanks!
[13:37] <jbicha> desrt: hey, I think we need to patch yelp to convert help:gnome-help URI prefixes to help:ubuntu-help when running Unity
[13:38] <jbicha> I expect that somebody good at string manipulation could do that in a few minutes but it would take me a whole lot longer to figure it out
[13:38] <desrt> instead of having patches all over various desktop components like nautilus?
[13:38] <jbicha> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/yelp/raring/view/head:/src/yelp-application.c#L379
[13:38] <jbicha> desrt: yes :)
[13:38] <desrt> jbicha: a worthy cause :)
[13:38] <desrt> jbicha: that's a pretty nasty place to be doing the tweak...
[13:41] <jbicha> oh it seemed to be the right place but you're welcome to do it somewhere else
[13:48] <desrt> jbicha: it depends on what you want to do
[13:48] <desrt> do you want to redirect *all* uri requests from one place to the other?
[13:49] <desrt> or only the ones given on the commandline directly
[13:49] <desrt> what if, for example, the help of some application made a link to the gnome docs?
[13:50] <larsu> seb128, thanks for updating the descriptions of those indicator-messages SRU bugs
[13:51] <seb128> larsu, yw, thanks for providing the testcases ;-)
[13:51] <larsu> desrt, hey! had a good flight back?
[13:51] <larsu> seb128, np :)
[13:51] <jbicha> desrt: wouldn't that be the same place? doesn't yelp interpret those the same way as commandline args?
[13:53] <jbicha> I just want the help links to work; I'm fine with the command line working w/o being mangled but I didn't think it worked that way
[13:55] <desrt> larsu: yup. you?
[13:55] <desrt> jbicha: the commandline arg thing is only for commandline args...
[13:56] <desrt> i doubt that yelp reinvokes itself on the commandline when clicking a link in a document
[13:56] <larsu> desrt, yeah. Had a bit of an ubuflu this weekend, though
[13:56] <pitti> desrt: so the main point of https://bugzilla.gnome.org/show_bug.cgi?id=686149 was to not add any interfaces after g_type_class_ref(), right? the patch does that now, I believe; or was there more to it?
[13:56] <ubot2`> Gnome bug 686149 in general "fix class initialisation" [Normal,Assigned]
[13:56] <pitti> hey larsu
[13:56] <pitti> larsu: urgh, ubuflu again? gute Besserung!
[13:56] <desrt> pitti: sorry.  under a pile of bugs/patches/reviews at the moment :)
[13:56] <larsu> hi pitti! Did you enjoy Copenhagen?
[13:56] <desrt> pitti: yours is next on the list :)
[13:56] <pitti> desrt: ack, not that urgent
[13:57] <pitti> larsu: yes, I did! http://www.piware.de/fotos/UDS-Kopenhagen-Oct2012/
[13:57] <jbicha> desrt: oh, so yelp_application_new_window is what we want?
[13:57] <desrt> jbicha: probably even deeper...
[13:57] <desrt> jbicha: i'd talk to shaunm
[13:57] <desrt> it may even be that you need some kind of webkit hook.  i don't know how it's implemented.
[13:58] <jbicha> ok, I'll ask him, I think my main problem is that I didn't know how to properly sed a string
[13:58] <desrt> i can help with that part
[13:58] <desrt> so we have like gnome-help:foo and we want ubuntu-help:foo, right?
[13:58] <larsu> pitti, you saw the mermaid! Awesome, isn't it ;)
[13:59]  * larsu likes the picture of seb128 best
[13:59] <pitti> larsu: well, I was a bit underwhelmed by that one :)
[13:59] <desrt> and let's say we have the string in an input string 'instr' and want to produce a new string 'outstr'
[13:59] <desrt> so first, the check:
[13:59] <desrt> if (g_str_has_prefix (instr, "gnome-help:"))
[13:59] <pitti> larsu: https://plus.google.com/107564545827215425270/posts/CHKYc34MGt7 :)
[13:59] <larsu> ya that one
[13:59] <desrt> in that case we want to drop the first 11 characters ("gnome-help:") and concatenate the remainder with our own prefix, so:
[14:00] <desrt>   outstr = g_strconcat ("ubuntu-help:", instr + 11, NULL);
[14:00] <jbicha> yeah I kind of figured out the first line, it's the next that I wasn't sure about
[14:00] <desrt> else
[14:00] <desrt>   outstr = g_strdup (instr);
[14:00] <desrt> ^^ straight copy
[14:00] <desrt> so either way we end up with a freshly-allocated 'outstr' that contains the new value
[14:00] <jbicha> desrt: ok cool
[14:00] <desrt> it's a bit of a point of style in glib-ish circles not to do conditional memory allocation
[14:01] <desrt> ie: even though it's a waste to allocate the exact copy, we do it anyway for consistency with the other case
[14:01] <desrt> because it helps avoid leaks caused by weird logic bugs
[14:01] <desrt> it's easier to just always free....
[14:06] <jbicha> mterry: I tried to start on the System Settings Appearance panel but I didn't know what I was doing so it doesn't really work
[14:08] <mterry> jbicha, OK.  You mean to make it a separate panel from Background?
[14:08] <jbicha> yeah; maybe it doesn't actually need to a separate panel
[14:09] <seb128> hey mterry, had a good flight back?
[14:10] <mterry> seb128, yeah  :)
[14:10] <mterry> jbicha, why not?
[14:10]  * kenvandine waves
[14:10] <mterry> kenvandine, hi!
[14:10] <seb128> kenvandine, hey, how are you?
[14:10] <kenvandine> tired :)
[14:10] <kenvandine> and you?
[14:10] <seb128> good, though ubuflued slightly
[14:10] <kenvandine> ugh
[14:11] <kenvandine> hopefully that passes quickly :)
[14:11] <seb128> it had to happen, wouldn't be UDS without that :p
[14:11] <kenvandine> indeed
[14:11] <jbicha> mterry: just because I couldn't get it to work and maybe it would be simpler to just have a separate .ui and .desktop and add some lines of code to the background panel
[14:12] <attente> seb128: is it common to catch ubuflu?
[14:12] <jbicha> attente: if you didn't catch it, you're lucky :)
[14:12] <seb128> attente, yeah, it happens to a bunch of people at every UDS
[14:13] <seb128> where bunch is a non trivial % of the team usually
[14:13] <mterry> jbicha, eh, they are so different I think that if we can get separate panels to work, it would make sense.
[14:13] <attente> heh
[14:14] <mterry> seb128, did you have an opinion on where the Ubuntu Appearances panel should live once it's separated?  Still in g-c-c?
[14:14]  * desrt managed to avoid it this time
[14:15] <seb128> mterry, no strong opinion but I suppose it would be easier to maintain as a standalone component, would it only be for having its own vcs commit logs etc
[14:15] <mterry> seb128, sure
[14:17] <didrocks> desrt: it's all because you had an awesome roomate :)
[14:18] <desrt> :D
[14:19] <kenvandine> haha
[14:19] <kenvandine> didrocks, did you escape the ubuflu too?
[14:20] <seb128> well I think there was not a lot of flu around
[14:20] <kenvandine> i think i did... i just had alergies while i was there
[14:20] <didrocks> kenvandine: yeah :) I think that's because I had a 4 week flu just a month before UDS. So strong body :)
[14:20] <kenvandine> which are gon enow
[14:20] <seb128> but pitti came with the flu and I was rooming with him so...
[14:20] <seb128> well, classic UDS story ;-)
[14:20]  * pitti hugs seb128
[14:20] <pitti> je suis desolé
[14:20]  * seb128 hugs pitti back
[14:21] <didrocks> seb128: pitti: stop hugging! that's how it started :)
[14:21] <kenvandine> hehe
[14:21] <seb128> pitti, il n'y a pas de problème, maintenant ou plus tard ... comme ça c'est fait pour la saison
[14:21] <pitti> IRC hugs are BzgA approved!
[14:21] <didrocks> héhé :)
[14:22] <mdeslaur> we definitely need to quarantine dholbach during flu season
[14:41] <qengho> My secret to avoiding Summit-disease was to be near the path of an enormous hurricane, get allergies from all the stirred-up airborne pollen and fungal spores, and be so sniffly and paranoid about getting other people sick at UDS that I washed my hands every hour. So, now allergies are gone, and no "flu".
[14:41] <qengho> I'll plan a hurricane every time, if I can.
[14:44] <kenvandine> qengho, :)
[14:44] <kenvandine> qengho, i got on the plane in denmark sniffling... like i had been for nearly two weeks
[14:44] <kenvandine> and got off the plane clear
[14:44] <kenvandine> no more sniffles :)
[14:45] <qengho> You may be alergic to umlauts, kenvandine.  Consult a doctor.
[14:45] <kenvandine> hehe
[15:27] <achiang> hello, where does one file bugs regarding plymouth? LP is telling me that there really isn't an LP project for it
[15:30] <desrt> pitti: can you explain this unknown signal thing to me?
[15:31] <desrt> pitti: i guess it's a _good_ thing that this warning is now emitted?
[15:31] <desrt> the testcase appears to be engaging in some intentionally-incorrect behaviour
[15:31] <chrisccoulson> hmmm, my pandaboard feels like it's going to catch fire!
[15:32] <stgraber> achiang: https://launchpad.net/ubuntu/+source/plymouth/+filebug ?
[15:32] <stgraber> achiang: upstream isn't using Launchpad so you won't find a launchpad.net/plymouth project
[15:32] <desrt> chrisccoulson: firefox build? :)
[15:32] <chrisccoulson> desrt, heh, how did you guess?
[15:33] <desrt> chrisccoulson: because i know that you're not insane enough to try libreoffice?
[15:33] <achiang> stgraber: thanks
[15:39] <qengho> Ooo, sexy pandaboard. Some madman suggested I try to set up this Nexus 7 as a build machine.
[15:39] <desrt> qengho: nexus 7 makes a nice build machine
[15:39] <qengho> There he is!
[15:40] <desrt> beats the pants off of a pandaboard in terms of performance
[15:41] <qengho> Is cross-compliation such a mess that this even makes sense?
[15:42] <desrt> cross-compilation sucks
[15:42] <qengho> More than slow hardware does?
[15:42] <desrt> no.
[15:43] <desrt> there are all kinds of problems with build systems that try to compile and then use tools
[15:43] <desrt> and even larger problems with things like gobject-introspection which need to open the just-built library in order to poke around its insides
[15:43] <desrt> doesn't work so well when the library that you just built won't run on the machine that you're on
[15:43] <rodrigo_> hi
[15:44] <rodrigo_> any idea what's wrong on a package that complains about missing m4 dir when running aclocal in build stage?
[15:44] <rodrigo_> creating the m4 directory makes it build ok, but I guess that's not the correct fix :)
[15:44] <desrt> rodrigo_: 'mkdir m4' ?
[15:44] <desrt> rodrigo_: i have 'mkdir -p m4' in some of my autogen scripts...
[15:44] <rodrigo_> yeah, but I don't want to add that to debian/rules
[15:44] <desrt> *shrug*
[15:45] <desrt> building from git or a tarball?
[15:45] <rodrigo_> tarball
[15:45] <rodrigo_> a package
[15:45] <desrt> weird.
[15:45] <desrt> and it didn't dist any m4 macros?
[15:45] <rodrigo_> locally creating the m4 dir makes it build ok
[15:45] <rodrigo_> but launchpad then fails with that 'missing m4' error
[15:45] <desrt> i guess the answer is that you should no attempt to run aclocal on a tarball....
[15:45] <rodrigo_> desrt, I guess that's it, checking
[15:46] <rodrigo_> ok, so it's autogen.sh that creates the empty m4 dir, so I guess debian/rules should be running autogen, not configure
[15:47] <desrt> configure is not the problem....
[15:47] <desrt> aclocal is
[15:48] <desrt> there is one thing supported after you extact a tarball: ./configure
[15:48] <pitti> re
[15:48] <dobey> rodrigo_: are you running autoreconf, or just aclocal?
[15:48] <desrt> if that's not working, file a bug upstream because their package is broken
[15:48] <rodrigo_> dobey, dh_autoreconf
[15:48] <pitti> desrt: I'm not sure why the warning wasn't shown before
[15:48] <desrt> dh_autoreconf on a tarball is somewhat wrong-headed....
[15:48] <rodrigo_> desrt, well, it might be my fault, I am packaging a new upstream release
[15:48] <pitti> desrt: I stepped through with it in gdb, and it's running through the exact same code
[15:48] <rodrigo_> the previous package should work, it's in quantal
[15:49] <desrt> pitti: i suppose you consider it to be a good thing that we now get the warning, though
[15:49] <pitti> desrt: you always get the python exception, but an additional warning doesn't hurt
[15:50] <desrt> ah.  i see.
[15:50] <desrt> okay
[15:50] <desrt> pitti: what's the easiest way for me to exercise this code?
[15:50] <desrt> run the pygobject testsuite?
[15:50] <pitti> desrt: git am, and make check, yes
[15:50] <desrt> k.
[15:50] <pitti> I hope it still applies, we have made quite some changes today
[15:50]  * pitti checks
[15:50] <desrt> i'm adding my warning to glib to make sure that it breaks
[15:51] <desrt> then i'm applying your patch and making sure it unbreaks :)
[15:51] <pitti> ah, nice
[15:51] <pitti> yep, still applies
[15:52] <desrt> hm.  it's not breaking.
[15:52] <pitti> the tests fail on glib warnings (except those where we explicitly expect and thus ignore them, but there's only a few)
[15:52] <desrt> is it possible that you lack a testcase that implements interfaces?
[15:52] <pitti> desrt: you mean it doesn't trigger your warning?
[15:53] <pitti> explicitly in tests/test_interface.py, and I'd think implicitly all over the place
[15:53] <pitti> desrt: when I removed either of the pyg_type_add_interfaces() calls, it failed all over the place
[15:53] <desrt> fair enough
[15:54] <desrt> either i'm loading the wrong libgobject or my warning is not working
[15:54] <pitti> you are building/trying in jhbuid?
[15:54] <desrt> ish
[15:55] <desrt> strace says it's getting the right one
[15:55] <pitti> if you build pygobject on quantal, you'll get some failures
[15:55] <desrt> lemme poke around a bit more
[15:59] <desrt> ahah.  it's actually getting the wrong one.
[15:59] <desrt> hrmph.
[15:59]  * desrt wonders if library paths get hardcoded in typelibs or something
[15:59] <pitti> hm, I don't think so
[15:59] <pitti> I remember hacking on glib while running sth. like LD_LIBRARY_PATH=~/upstream/glib/.libs python3 -c '...'
[16:00] <desrt> ya.  my LD_LIBRARY_PATH is fine...
[16:00] <pitti> but "make check" sets its own library path
[16:00] <desrt> seems to be favouring a different flavour of the library, though
[16:00] <pitti> tests/Makefile.am:      LD_LIBRARY_PATH=$(builddir)/.libs:$$LD_LIBRARY_PATH \
[16:00] <pitti> this is meant to preserve an already existing one
[16:00] <desrt> i get the impression that this is libtool's fault
[16:01] <desrt> yup!
[16:01]  * desrt has such intense hatred for rpath...
[16:01] <pitti> urgh, rpath? where?
[16:01] <desrt> everywhere, if you're using libtool
[16:02] <pitti> OMFGreally?
[16:02] <desrt> as soon as you do --prefix=/something/outside/of/usr it sets the rpath on everything it installs
[16:02] <desrt> so you get libfoo depending on a rpath'd version of libgobject in a particular place
[16:02] <desrt> overriding your LD_LIBRARY_PATH
[16:02] <desrt> utter utter braindamage
[16:02] <pitti> $ chrpath -l ./gi/_gi.so
[16:02] <pitti> ./gi/_gi.so: RPATH=/home/martin/upstream/pygobject/gi/_glib/.libs:/home/martin-scratch/gnome/lib64
[16:02] <pitti> eek
[16:03] <pitti> so presumably when I did above tests, I just did ./configure, not a jhbuild build
[16:03] <desrt> i desperately hate .la files
[16:03] <desrt> like, very very badly
[16:03] <desrt> but it's nowhere near the level of my hatred for the fact that libtool sets rpath
[16:06] <desrt> pitti: your patch seems to do the trick
[16:06] <pitti> \o/
[16:07] <desrt> let me upload my gobject patch...
[16:07] <desrt> and see if you can come to the same conclusions
[16:07] <pitti> yep, will do
[16:08] <pitti> desrt: to https://bugzilla.gnome.org/show_bug.cgi?id=687659 ?
[16:08] <ubot2`> Gnome bug 687659 in gobject "drop support for adding interfaces after class_init" [Normal,New]
[16:08] <desrt> yup
[16:08] <desrt> attaching a patch there in just a moment
[16:09] <desrt> okay.  patch is attached.
[16:10]  * pitti runs jhbuild buildone glib
[16:10] <desrt> pitti: before your pygobject patch I see:
[16:10] <desrt> (process:22791): GLib-GObject-WARNING **: attempting to add an interface (TestInterface) to class (test_interface+MyObject) after class_init
[16:10] <desrt> Trace/breakpoint trap
[16:10] <desrt> after your patch, it works again
[16:11] <pitti> confirmed, it's unhappy with the glib patch applied
[16:12] <pitti> Ran 700 tests in 9.854s
[16:12] <pitti> OK (expected failures=1)
[16:12] <pitti> and that's with my patch
[16:12]  * pitti ^5s desrt
[16:12] <desrt> sweet :)
[16:12] <desrt> i've commented about the positive test results on the bug
[16:12] <desrt> it's up to you if you want to go ahead with pushing your patch
[16:12] <desrt> in its own right it's a nice patch
[16:13] <desrt> it will take a little more discussion on the glib side before i can push my patch....
[16:13] <desrt> the glib testsuite itself is in the foul, for example
[16:13] <pitti> desrt: I pushed it
[16:13] <desrt> awesome
[16:13] <pitti> I like it a lot more that way
[16:13] <desrt> ya.  me too.
[16:13] <pitti> while I'm in the mood of simplifying code :)
[16:13] <desrt> even without the glib changes it makes more sense
[16:14] <desrt> thanks a bunch
[16:14] <pitti> and another firefox tab gone :)
[16:14] <pitti> I had some 5 bz ones yesterday, and now it's down to 1
[16:14] <desrt> ya.  this morning is pretty productive for me too :)
[16:17] <mterry> didrocks, so did you want inline branches to be native or split?  /me is not partial, but wants to be consistent
[16:19] <didrocks> mterry: we discussed it a little bit earlier with ken, split seems to be the best IMHO
[16:19] <mterry> didrocks, k
[16:19] <didrocks> thanks :)
[16:19]  * didrocks is fighting jenkins to have fork and join jobs workflow
[16:28] <mterry> didrocks, so this means no need to switch to format 3.0?
[16:29] <didrocks> mterry: not really needed, indeed, this will make the SRU more readable to keep 1.0 if we need to cherry-pick at some point
[16:40] <jbicha> GunnarHj: did you see my comment for bug 1035219?
[16:40] <ubot2`> Launchpad bug 1035219 in Baltix "In System Settings preference tool/keyboard layouts page automaticaly wrong language selectedGNOME" [High,In progress] https://launchpad.net/bugs/1035219
[16:42] <jbicha> while looking through all the gnome-control-center patches to get ready for 3.6 I stumbled across the 52 patch which needs work
[16:44] <seb128> jbicha, if you do g-c-c work please commit to the vcs so we don't dup work, I already reviewed the whole patch stack and took notes, I was going to look at continuing on that soon (I commited by g-s-d 3.6 work to the vcs)
[16:46] <jbicha> seb128: my g-c-c work is already committed
[16:47] <seb128> jbicha, great ;-)
[16:47] <seb128> jbicha, do you know if anyone is looking at getting realmd uploaded btw?
[16:48] <jbicha> oh do we need that?
[16:50] <jbicha> I think we're pretty close on having g-c-c/g-s-d 3.6 ready, we need to figure out the Appearance panel & 2 g-c-c patches need updating
[16:50] <seb128> yes we need that, the user panel depends on it
[16:50] <seb128> we also need the new ibus
[16:50] <jbicha> there's still the keyboard/ibus indicator rework to do but I don't think that should be a blocker at this point
[16:51] <seb128> I would like the ibus indicator to be updated if possible
[16:51] <seb128> the g-s-d one will be harder
[16:56] <jbicha> seb128: how do you want to handle that? we could push what we have to the desktop ppa so that it can be worked on
[16:56] <seb128> jbicha, that works for me
[16:57] <jbicha> or we could push to raring-proposed and as long as ibus has 1 nbs package, it won't migrate to raring
[16:57] <seb128> jbicha, somebody needs to have a proper look to ibus, I plan to do that in the next weeks if nobody beats me to it
[16:57] <seb128> jbicha, proposed is not meant for that, it's for things ready to be uploaded to the archive
[16:57] <seb128> let's use the ppa
[16:57] <jbicha> seb128: Debian experimental has already started, the initial testing I did in an experimental PPA last month seems to work
[16:58] <jbicha> ok, I'll push to the PPA later today
[16:58] <seb128> well, I don't think Debian ported our ibus indicator and tested if it still works under unity ;-)
[16:58] <seb128> thanks
[17:05] <seb128> jbicha, you had rb 2.98 ready for upload right? you should probably push it to raring
[17:24] <chrisccoulson> heh, 90.2degC!
[17:24] <chrisccoulson> will the panda die before the build finishes?
[17:27] <achiang> chrisccoulson: you should get the new samsung chromebook. dual A15s + 2GB of memory
[17:27] <achiang> only $250 USD
[17:29] <GunnarHj> jbicha: Yes, I saw your bug 1035219 comment. Sounds as if you found a way to limit the importance of the bug for standard Ubuntu users, which is good, of course.
[17:29] <ubot2`> Launchpad bug 1035219 in Baltix "In System Settings preference tool/keyboard layouts page automaticaly wrong language selectedGNOME" [High,In progress] https://launchpad.net/bugs/1035219
[17:29] <GunnarHj> jbicha: As regards the g-c-c patch 52, please note that it's there for the User Accounts capplet only. Of course it will need work now when Region and Language is going to be used in Ubuntu.
[17:37] <robru> pitti: ping
[17:38] <jjohansen> so after updating this morning unity is failing to start for me, compiz appeared to be running but has finally crashed
[17:38] <desrt> seb128: i guess you're watching on #g-h?
[17:38] <seb128> desrt, I'm subscribed to the distributor list, saw it there
[17:39] <desrt> cool
[17:39] <seb128> desrt, no surprise there
[17:39] <desrt> seb128: nope.
[17:39] <desrt> and good that they're discussing it so openly and making decisions early and firmly
[17:39] <seb128> though I didn't think they would drop the g-s-d "render the background" code
[17:40] <desrt> a good followup question might be what happens to GnomeBG in libgnome-destkop
[17:40] <seb128> that code didn't change for years and is working ... but, oh well
[17:40] <desrt> seb128: we really want unity doing that rendering... seriously
[17:40] <seb128> desrt, nautilus does it for us
[17:40] <desrt> if we have nautilus rendering the desktop then that's one thing
[17:40] <seb128> desrt, it gives us nice icons on the desktop :p
[17:40] <desrt> because we have to draw the desktop anyway
[17:41] <desrt> but if we don't have nautilus then the cost of having the background drawn by a process other than the WM is fairly high
[17:41] <desrt> it's substantially more efficient to just do it from unity
[17:41] <seb128> desrt, I think compiz has a plugin to draw the background *g*
[17:41] <desrt> ;)
[17:42] <desrt> seb128: unfortunately it doesn't have one to draw the background without snow falling on it or fire or smoke or something else
[17:42] <seb128> well, a background without rain on it would be boring you have to admit
[17:45] <desrt> ya.  that's true.
[17:45] <desrt> and i forgot about the rain one
[17:45] <desrt> rain is nice.  peaceful.
[17:56] <desrt> pitti: is there some way that we can know if pygobject is the one doing the interface registration?
[17:56] <desrt> pitti: i noticed for example that the class name appears to have '+' in it.  is this always the case?
[17:56]  * desrt wants to avoid triggering the warning (in the short term) just because the user is running an old pygobject
[18:10] <didrocks> have a good evening everyone!
[18:23] <jbicha> seb128: realmd isn't really required for g-c-c as I've been using g-c-c 3.6 ok for the past month, it just adds some magic enterprise stuff, right?
[18:25] <seb128> jbicha, not sure, I didn't look at it in details, but during the 3.5 cycle the configure.ac had an hard requirement on it
[18:32] <jbicha> the hard requirement is gone at least
[18:32] <seb128> ok
[18:32] <seb128> still it would be good to get enterprise support in ;-)
[18:44] <seb128> jbicha, did you see my rhythmbox question before?
[18:45] <jbicha> seb128: yes, I was waiting for the quantal sru to be accepted into -proposed first but that's been done now
[18:45] <seb128> ok
[18:45] <seb128> jbicha, did you look at the new ibus yet? I will try to start on that tomorrow otherwise (just don't want to dup work)
[18:49] <jbicha> seb128: I updated it so that I could play with ibus-enabled g-c-c but that was a month ago before Debian picked up the update; I didn't try to rewrite the indicator patch but just disabled it
[18:49] <seb128> jbicha, ok, thanks
[18:50] <qengho> kenvandine: I'm trying to make sense of chromium package versions.  E.g., "<IP_ADDRESS>~r12345-0ubuntu1".  I think revisions always add to a release, so should sort after. Not that we should ever just release "<IP_ADDRESS>" without "rev5678", but it seems awkward to me.
[18:52] <qengho> ~ is good for naming prereleases, but I'm not sure it's best here.
[18:52] <qengho> GOOG's chrome(tm) packages use hyphen, I notice.
[18:53] <jbicha> qengho: I didn't think chromium did actual releases
[18:54] <qengho> jbicha: there's no one to make packages except us, but they do indeed have releases.
[18:55] <kenvandine> they define the release based on the revision
[18:56] <kenvandine> or really a combination of revisions
[18:56] <qengho> Hah, stable chrome and quantal packages have nearly identical versions right now.   http://pastebin.ubuntu.com/1335481/
[18:57] <kenvandine> http://omahaproxy.appspot.com/viewer
[18:57] <qengho> kenvandine: AFAICT, revisions continue to accrue and add to a past release.
[18:57] <kenvandine> yes
[18:57] <kenvandine> but they use the branch_revision to identify it
[18:57] <qengho> So, 1.2.3 is released at revision 4.  They add rev 5 and rev 6 later, but it's still 1.2.3.
[18:58] <kenvandine> i think so
[18:58] <qengho> ...just 1.2.3-r6
[18:58] <kenvandine> which is why we have the revision there
[18:58] <qengho> Right.
[18:59] <kenvandine> so i guess in this case "-" might make more sense
[18:59] <qengho> kenvandine: this is not important at all, considering how we release.  I was just trying to get everything right.
[18:59] <kenvandine> but it is probably never going to matter
[18:59] <qengho> Yep.
[18:59] <qengho> kenvandine: thanks.  Sorry for noise.
[18:59] <kenvandine> and, we are really used to seeing the  ~ in versions like this
[18:59] <kenvandine> no worries
[18:59] <kenvandine> how's it going?
[19:00] <kenvandine> qengho, i think it would make sense to attempt to build the dev channel for raring, but the patches.... ugh
[19:01] <qengho> kenvandine: Everything is going good. I'll get to beta and dev patches next week, I expect.
[19:01] <kenvandine> i know there will be big problems in the dev channel
[19:02] <kenvandine> the changes for handling extensions
[19:02] <kenvandine> will affect webapps
[19:02] <kenvandine> so make sure you test the webapps integration
[19:02] <kenvandine> and try to work with alex-abreu
[19:02] <dobey> qengho: btw, did you get past that spot you were stuck on with the chromium builds, and posted on G+? did the u1 nightlies build stuff help?
[19:04] <BigWhale> Greetings all
[19:04] <kenvandine> hey BigWhale
[19:05] <qengho> dobey: We decided to break the problem into two.  Merging lp translations before making the orig is out, and we'll send the translations upstream and receive them back already inside source.  It wins in many ways, but adds some lag.
[19:05] <BigWhale> so if I wasn't deploying right now.. I'd be asking about guidelines for unit/integration testing in Gtk. Any docs on that lying around?
[19:16] <dobey> qengho: cool
[19:37] <BigWhale> dobey! https://bugs.launchpad.net/ubuntu/+source/rhythmbox-ubuntuone/+bug/934206
[19:37] <ubot2`> Launchpad bug 934206 in rhythmbox-ubuntuone (Ubuntu Precise) "track duplication from RB-U1" [High,Fix released]
[19:37] <BigWhale> dobey, I'm still seeing this ... :'(
[19:37] <BigWhale> on 12.10
[19:45] <dobey> BigWhale: unpossible!
[19:47] <BigWhale> dobey, it might be a leftover from 12.04 ...
[19:47] <BigWhale> but I am not sure.
[19:47] <dobey> BigWhale: how are you seeing it? what are the paths of two duplicated files? what paths are in your library paths setting (gsettings get org.gnome.rhythmbox.rhythmdb locations)
[19:47] <seb128> ricotz, you should talk to desrt about the
[19:47] <seb128> #if !GLIB_CHECK_VERSION(2, 35, 0)
[19:47] <seb128>    g_type_init ();
[19:48] <seb128> #endif
[19:48] <seb128> it was approved as I see, desrt doesn't like it though ;-)
[19:48] <seb128> Trevinho, ^
[19:49] <ricotz> seb128, i see, i didnt want to break the backwards compatibility while glib 2.35 isnt available in ubuntu yet
[19:49] <ricotz> seb128, what is desrt favorite solution? ;)
[19:50] <ricotz> a runtime check?
[19:51] <Trevinho> seb128: mh, ok
[19:52] <seb128> ricotz, Trevinho: he said to use GLIB_VERSION_MIN_REQUIRED IIRc
[19:54] <ricotz> seb128, i see
[19:57] <BigWhale> dobey, actually I have only one file of each song ...
[20:02] <dobey> BigWhale: see, i told you it was unpossible! :)
[20:03] <BigWhale> yeah well rythmbox still shows two entries
[20:03] <BigWhale> I'll just delete everything
[20:03] <BigWhale> and see what happens
[20:04] <dobey> BigWhale: oh, so that wasn't an answer to my question. the two entries point to the same path, for one song?
[20:04] <dobey> BigWhale: also, the fix didn't remove existing duplicates; so they are probably left over
[20:05] <BigWhale> that's what I was asking myself
[20:05] <dobey> BigWhale: easiest fix is to remove ~/.local/share/rhythmbox/rhythmdb.xml and let it rescan everything
[20:08] <BigWhale> I removed the whole rhythmbox directory :>
[20:08] <BigWhale> I only have 5 mp3 so it won't take too long to rescan :>
[21:05] <desrt> kenvandine: NC is looking a fainter and fainter shade of red ;)
[21:06] <kenvandine> heh
[21:06]  * kenvandine crosses fingers
[21:06] <kenvandine> 55% of the voters voted early, so i should have short lines tomorrow
[21:07] <desrt> that 55% figure is bad news for improving obama figures
[21:07] <desrt> too late for people to change their minds
[21:08] <mlankhorst> who cares
[21:09] <desrt> mlankhorst: was a hot topic for discussion at UDS :)
[21:09] <mlankhorst> whether you follow it or not, you still end up with the same president, so it's a waste of time following the news :-)
[21:11] <mlankhorst> and for those cynical and outside the us, they still are going to do the same thing on foreign policy, which is basically pushing only us's point of view there, that's always been us' policy there :p
[21:27] <achiang> kenvandine: desrt: do you guys know what package displays the suspend/shutdown/restart dialog when power button is pressed?
[21:32]  * achiang guesses gnome-settings-daemon
[21:34] <sarnold> achiang: see /etc/acpi/powerbtn.sh
[21:35] <achiang> sarnold: doesn't exist on my nexus7 :)
[21:35] <sarnold> achiang: hrm :)
[21:36]  * achiang is chasing http://pad.lv/1041137
[21:36] <ubot2`> Launchpad bug 1041137 in ubuntu-nexus7 "Activating suspend from power button menu does not work" [High,Confirmed]
[21:36] <achiang> it works from indicator-session, but not from that dialog box
[21:37] <achiang> so trying to figure out why that assert fails
[21:37] <achiang> gnome-settings-daemon is indeed running as the logged in user and not as root or anything weird like that
[22:06] <robert_ancell> Laney, hey, can you drop the gnome-games upload I just did to quantal-proposed? I should have numbered that -0ubuntu1.1 instead of -0ubuntu2
[22:08] <robert_ancell> hang on, me checks if you're an archive admin...


[16:30] <jdstrand> hi!
[16:30] <tyhicks> hello
[16:30] <mdeslaur> hi!
[16:31] <jdstrand> #startmeeting
[16:31] <jdstrand> huh, the bot seems dead
[16:31] <jdstrand> The meeting agenda can be found at:
[16:31] <chrisccoulson> hi!
[16:31] <jdstrand> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[16:31] <jdstrand> [TOPIC] Announcements
[16:32] <jdstrand> Rohan Garg (rohangarg) provided debdiffs for saucy and trusty for kde4libs (LP: #1332064). Your work is very much appreciated and will keep Ubuntu users secure. Great job!
[16:32] <jdstrand> [TOPIC] Weekly stand-up report
[16:32] <jdstrand> I'll go first
[16:32] <jdstrand> fyi, I'm off all next week
[16:32] <jdstrand> I'm on triage this week
[16:33] <jdstrand> I'm helping test/coordinate the apparmor landing with mdeslaur today. I expect it to be pushed to the archive in a little while
[16:33] <mdeslaur> \o/
[16:33] <tyhicks> nice
[16:33] <jdstrand> I will be working on the ofono profiles bug this week, and any other June work items I can get to
[16:33] <jdstrand> I have a pending update I will hopefully get out later today
[16:33] <jdstrand> that's it from me
[16:33] <jdstrand> mdeslaur: you're up
[16:34] <mdeslaur> I'm on community this week
[16:34] <mdeslaur> I just pushed out a few updates
[16:34] <mdeslaur> and am currently testing the apparmor and other packages that will get published
[16:34] <mdeslaur> I plan on taking a bite out of the long list of accumulating CVEs
[16:34] <mdeslaur> tomorrow, I'm on national holiday
[16:35] <mdeslaur> and I also have to write a wiki page about click store package signing
[16:35] <mdeslaur> that's it from me
[16:35] <mdeslaur> sbeattie: you're up
[16:35] <tyhicks> so you're planning on uploading the new apparmor and then splitting for day?? ;)
[16:35] <mdeslaur> tyhicks: SUCKS TO BE YOU!
[16:35] <mdeslaur> :)
[16:36] <sbeattie> I'm still working on pie by default for gcc/amd64.
[16:36] <tyhicks> heh :)
[16:36] <sbeattie> (mdeslaur: heh)
[16:36] <jjohansen1> tyhicks: don't be surprised if he is sick tomorrow
[16:36] <mdeslaur> sbeattie: any progress there?
[16:37] <sbeattie> One thing I discovered is that if an otherwise dynamically linked binary includes a libxxx.a, the object files in that .a file need to be compiled with -fPIE as well, which isn't a big deal when they're in the same package, but could introduce an ordering issue for situations where they're in different source packages.
[16:38] <sarnold> interesting, I hadn't heard that before.
[16:38] <sbeattie> (the apparmor parser does this, but since it's just internal to the source, it's not a big deal)
[16:38] <sbeattie> sarnold: yeah. I get a link time failure if they're not.
[16:40] <sbeattie> anyway. Other things for this week: I need to look at a mod_apparmor issue — I missed a note in the 2.2 -> 2.4 transition about the authentication hooks changing, which is causing some of people's problems with the HANDLING_UNTRUSTED_INPUT hat, I think
[16:40] <sbeattie> and other misc apparmor stuff.
[16:41] <sbeattie> that's pretty much it for my week. tyhicks?
[16:41] <tyhicks> I'm wanting to wrap up my rtm work items this week
[16:41] <tyhicks> "review trust session and lp:trust-store for pid/APP_ID/apparmor/etc" has turned into a design discussion
[16:42] <tyhicks> and "verify kernel security features in phablet image (besides ufw and apparmor)" just needs a little bit of testing today before I send out the kernel config patches
[16:43] <tyhicks> I had done one swoop at verifying the kernel security features and enabled everything that we test for in QRT, but there's other things that we don't test for
[16:43] <tyhicks> things that we're interested in but are not enabled in all of the touch kernels
[16:43] <tyhicks> (like ecryptfs)
[16:43] <tyhicks> so I'll add those config tests to QRT after I send out the patches
[16:44] <sbeattie> tyhicks: thanks for that.
[16:44] <tyhicks> np
[16:44] <tyhicks> that's it for me
[16:44] <tyhicks> jjohansen1: you're up
[16:44] <jdstrand> tyhicks: design discussion?
[16:44] <jjohansen1> I'm working on my rtm WIs this week
[16:44] <jdstrand> tyhicks: does that mean you are blocked?
[16:45] <jjohansen1> I also have the latest revision for the touch kernels to land this week, as soon as the new userspace lands
[16:45] <jjohansen1> and I am off tuesday
[16:46] <jdstrand> jjohansen1: that should land today. does that mean as soon as it lands you can do the pull request?
[16:46] <jjohansen1> rtm WIs == apparmor extended mediation of unix sockets
[16:46] <jjohansen1> jdstrand: yes
[16:46] <jdstrand> cool
[16:47] <jdstrand> re your rtm work items-- would it help if tyhicks or sbeattie helped you if they put aside non-rtm work items?
[16:48] <jdstrand> if so, we can take that offline (just putting it out there)
[16:49] <tyhicks> jdstrand: no, I'm not blocked - my WI was to review the code and I guess that is technically done
[16:49] <tyhicks> jdstrand: now it has turned into a discussion on how to improve things
[16:50] <jdstrand> tyhicks: I see. update the work item as you see fit and continue guiding them as necessary :) thanks for taking that on
[16:50] <jjohansen1> that is it for me sarnold you are up
[16:50] <jdstrand> jjohansen1: did you see my question about help?
[16:52] <jjohansen1> jdstrand: not yet but soon, I'll poke them later in the week, wednesday, thursday,
[16:52] <sarnold> I'm in the happy place this week, there's an openssl098 community update I'm still working on from last week, I'm still working on the qrt test-django script, and I'm hopeful for some apparmor patch reviews to distract me from the test-django work :)
[16:52] <jjohansen1> jdstrand: don't worry I'll poke you to join the party too
[16:53] <jdstrand> jjohansen1: ok, thanks
[16:53] <sarnold> I think that's it for me, chrisccoulson?
[16:54] <chrisccoulson> so, bug 1312082 is finished. I'm just waiting on something olivier is finishing before I merge it, so that I don't break his work
[16:54] <chrisccoulson> i've got through some of my review queue :)
[16:55] <chrisccoulson> today, I started on bug 1332754, which should hopefully improve our memory usage a bit
[16:55] <chrisccoulson> other than that, it's business as usual :)
[16:56] <chrisccoulson> i think that's me done
[16:58] <jdstrand> sarnold: there were some other reviews that are listed as work items that we talked about last week-- did you work on those, where are they prioritized for you?
[16:58] <jdstrand> chrisccoulson: re 1312082> nice!
[16:59] <jdstrand> chrisccoulson: seems like the media-hub/oxide integration is progressing well (which is part of your reviews I think)
[16:59] <mdeslaur> jdstrand, tyhicks, jjohansen1, chrisccoulson, sarnold, sbeattie: we're nearing the end of june. Please look at your assigned work items, and if anything is marked may or june and you won't be done in the next week, please let me know
[16:59] <tyhicks> ack
[16:59] <sbeattie> mdeslaur: okay
[16:59] <sarnold> jdstrand: I'd really like to be out from underneath this test-django script, so I was hoping to get it done. I'm sick of it. :)
[17:00] <jdstrand> sarnold: sure. how close are you?
[17:00] <sarnold> jdstrand: it feels like another day or two
[17:01] <sarnold> mdeslaur: ack
[17:01] <jdstrand> ok, cool
[17:03] <jdstrand> I'm going to proceed-- chrisccoulson feel free to interrupt to answer my question whenever
[17:03] <jdstrand> [TOPIC] Highlighted packages
[17:03] <jdstrand> The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so.
[17:03] <jdstrand> See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved.
[17:03] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/merkaartor.html
[17:03] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/libipc-pubsub-perl.html
[17:03] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/gridengine.html
[17:03] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/autotrace.html
[17:03] <jdstrand> http://people.canonical.com/~ubuntu-security/cve/pkg/gajim.html
[17:03] <jdstrand> [TOPIC] Miscellaneous and Questions
[17:03] <jdstrand> Does anyone have any other questions or items to discuss?
[17:07] <jdstrand> #endmeeting
[17:07] <jdstrand> mdeslaur, sbeattie, tyhicks, jjohansen, sarnold, ChrisCoulson: thanks!
[17:07] <tyhicks> thanks
[17:07] <mdeslaur> thanks jdstrand
[17:07] <sbeattie> thanks, jdstrand
[17:08] <sarnold> thanks jdstrand
[17:11] <jjohansen1> thanks jdstrand


[00:12] <mlankhorst> RAOF: bug bug :P
[00:12] <RAOF> Goose!
[00:13] <mlankhorst> llvm-3.1? Then I can upload some stack..
[00:17] <RAOF> I'll do so now.
[00:24] <mlankhorst> also one more thing to consider, should we allow unrenamed mesa dev packages to work with renamed stack? it would make my life easier..
[00:25] <RAOF> If it's easy to do then it seems reasonable to me.
[00:26] <RAOF> The older -dev packages should be guaranteed to work against the newer libraries, because they're not allowed to break API or ABI.
[00:26] <mlankhorst> yeah, it's mostly stripping off the version requirements
[00:26] <mlankhorst> but right now it allows you to accidentally remove the entire stack by installing the -dev packages
[00:35] <RAOF> I'd like a bit of a check that removing the strict versions there won't make things break - particularly for mesa-common-dev - but I don't think it will.
[00:36] <mlankhorst> yeah :/
[02:29] <Dandel> it looks like waffle 1.2.2 will be required soon for piglit.
[02:33] <Sarvatt> Dandel: do you want to join xorg-edgers to maintain that piglit build? I have no desire to keep it up to date, updating wayland/mesa/etc in that ppa to keep it building isn't something i want to babysit every few days :) i updated it to build gl only tests and have a separate branch for that that builds on every release. piglit should really be built from git, those packages are just a hack :)
[02:34] <Dandel> Sarvatt: it's a required change that will be introduced soon.
[02:34] <Dandel> it's in preparation for the opengl es 3.0 stuff
[02:34] <Sarvatt> the piglit i care about doesn't use waffle, ricotz added waffle there
[02:35] <Dandel> Sarvatt: so i take it as you are a die hard GLX fan ><;
[02:35] <Dandel> the current piglit setup is worthless for testing EGL W/ OpenGL Contexts
[02:37] <Dandel> egl with opengl contexts is a two line change
[02:37] <Sarvatt> nah there is some IHV testing being done for OEMs just for testing GL regressions, I was just asked to update it a few months ago, thats why if you want it to be whatever you care about it'd be appreciated if you took on that burden :)
[02:37] <Dandel> one is to test for the egl contexts and then you haft to bind the opengl api ( it works similar to how you setup opengl es )
[02:37] <Sarvatt> a two line change that makes it stop working in oneiric yeah
[02:39] <Dandel> Sarvatt: there's already a mainline fix for the last time egl ( opengl es/opengl es2, and desktop gl )
[02:39] <Dandel> it's just a little broken atm ( simple difference between ifdef and ifndef )
[02:42] <Dandel> honestly, the main thing i was interested in on egl w/opengl is the fact that the results *should* be nearly identical to what you see with glx/opengl ( and if applicable, windows/opengl )
[02:43] <Dandel> it honestly doesn't matter which context is used, and if egl can be tested, it should be possible to easily test wayland also ( and results should also be the same there )
[13:16] <Dandel> ricotz: latest commits for piglit should work for egl/opengl building.
[13:19] <ricotz> Dandel, yeah, it already got imported too http://bazaar.launchpad.net/~xorg-edgers/piglit/trunk/revision/3399
[13:20] <Dandel> r3399 is still bad.
[13:21] <Dandel> requires r3400 to work
[13:24] <ricotz> right
[13:25] <Dandel> now all that's needed is to retest the piglit with egl/opengl es tests.
[13:29] <Dandel> now all that's needed is to send messages to chad about the fact that libwaffle 1.2.2 is broken for the same reasons as piglit was.
[14:24] <Dandel> ricotz: i can confirm that the tree builds with latest piglit tree right now ( all i have is ubuntu 12.04 w/ xorg edgers installed )
[14:41] <ricotz> Dandel, using the edgers ppa will give you a recent enough mesa with gl/es-headers, so this isnt really a prove it will build in the piglit ppa ;)
[14:47] <Dandel> i just noticed that.
[14:47] <Dandel> i tend to use edgers to make sure to be able to properly report bugs that bleeding edge users would run into.


[05:48]  * Kilos waves to ZA
[10:37] <Kilos> ight all. sleep tight
[10:37] <Kilos> ight as well
[10:37] <Kilos> ai!
[10:37] <Kilos> nnnnnnnnnnnight
[11:27]  * pavlushka smiling for Kilos nights :)
[13:06] <dlPhreak> I have never used Slackware.
[13:06] <dlPhreak> Is that wrong?
[13:07] <dlPhreak> I've used Gentoo tho..
[13:11] <MaNI> why would that be wrong?
[13:16] <superfly> dlPhreak: It just means you're not as masochistic as some folks out there ;-)
[13:24] <dlPhreak> But I want to use it, you know.. for leet points!
[18:17] <pavlushka> Hello Cryterion :)
[18:17] <Cryterion> Hi
[18:17] <pavlushka> hey The rebooted theblazehen_ :p
[18:17] <pavlushka> Cryterion: how are you?
[18:27] <Cryterion> I'm all good and you
[19:29] <superfly> hi Cryterion
[19:30] <kulelu88> I'm debating with the copyfree okes about their unbridled copyright utopia :D
[19:32] <Cryterion> heya superfly
[19:42] <superfly> kulelu88: ohdear
[19:43] <kulelu88> superfly: their arguments seem to halt at a point where copyfree is only good when opposed on other people.
[19:43] <superfly> kulelu88: ah yes, i've heard that sort of thing before
[19:44] <superfly> "you're free to have you own opinion as long as your opinion is the same as mine"
[19:44] <kulelu88> they seem to disagree with every type of OSS license except the one that agrees to their philosophy
[19:46] <MaNI> they can do whatever they want with their code, just don't tell me what to do with mine :p
[19:48] <kulelu88> MaNI: that is precisely my point. I am free to choose the license I want.
[19:59] <paddatrapper> Sounds like the protesters at UCT...
[20:00] <paddatrapper> superfly's point at least
[20:28] <Cryterion> Just burn it, see what they say afterwards
[21:59] <kulelu88> the thing about the protests is a tough 1. fees are outrageously expensive, but I think everyone besides the students themselves finds it equally outrageous to learn that they burnt books


[03:16] <Isolde> 早上好
[08:37] <archlinuxer> ????
[14:54] <tomahawk> i do not like being 4000 Mt. Sinai and am Confuscious computer too many times as soul
[14:54] <tomahawk> not 4000 but more than 6000
[14:55] <tomahawk> 60000
[14:55] <tomahawk> not sandpit, but pain


[09:36] <Noskcaj> Hey everyone. I've got a new laptop, so i can start doing stuff again. downside is i'm now in year 12 so i have to focus more on school. Have i missed anything major?
[10:54] <bluesabre> Hey Noskcaj, welcome back
[10:54] <bluesabre> The biggest thing right now is going to be testing and reporting/fixing bugs
[11:59] <knome> yep, final freeze tomorrow
[12:03] <flocculant> we can hope so :p
[18:51] <Noskcaj> The installer's popup to overwrite windows 8's UEFI talks about debian not ubuntu. If someone can reproduce it that would be great, since i'd prefer to not nuke my new setup
[18:59] <flocculant> hi Noskcaj - belated welcome back :)
[19:00] <Noskcaj> hey :)
[19:00] <flocculant> I can't - I'd just report it manually
[19:03] <Noskcaj> oh crap, no one fixed redshift
[19:38] <flocculant> is it broken then
[19:39]  * flocculant wouldn't know nor worry either :)
[19:39] <drc> General Relativity is broken?
[19:39] <flocculant> yep
[19:40] <drc> darn, better inform Einstein. :)
[20:11] <Noskcaj> If i open multiple xfce4-terminal's they all come up on top of each other, rather than at different points on the screen. Is this a regression (didn't happen at the start of the cycle) or my laptop?
[20:15] <flocculant> been like that as long as I remember
[20:18] <Noskcaj> ok, must have been something i accidently made work
[20:18] <flocculant> nope
[20:18] <flocculant> just booted vivid image - that opens them in multiple positions
[20:19] <flocculant> so you're not going mad
[20:19] <drc> The only time I've ever seen them open in the same place is if one sets tweaks->Center of Screen.
[20:20] <flocculant> drc: yep - but you can't seemingly turn that off
[20:22] <drc> sure you can...set Minimum Size to small...or are we talking over each other?
[20:22] <flocculant> didn't know that ...
[20:23] <flocculant> settings editor - shows placement_mode as center
[20:23] <flocculant> silly me - thought the lock column was on or off :D
[20:23] <flocculant> ignore that
[20:26] <flocculant> and yes drc - that does at least work around it - though why it affects terminal in that way suddenly
[20:27] <Noskcaj> Where do i find possible value's for the setting?
[20:27] <flocculant> I just set placement to small in tweaks like drc said
[20:28] <Noskcaj> ok, that fixed it
[20:29] <flocculant> Unit193 or ochosi or bluesabre would possibly be the best to ask when or why probably
[20:30] <drc> flocculant: It's been that way as long as I remember...say, about 5 minutes :)
[20:30] <flocculant> hah
[20:30] <flocculant> funny that :p
[20:30] <drc> I know it was in 4.10
[20:34] <flocculant> was like what? over the top of each other?
[20:34] <flocculant> cos it's not like it in vivid default
[20:36] <drc> Never mind...I think we were slightly talking past each other (i.e., talking about different things)
[20:36] <flocculant> entirely possible :)
[20:37] <flocculant> mmk
[20:37] <flocculant> so in wily livesession it doesn't do this
[20:38] <drc> I trust the Live Session about as far as I can throw the Isle of Man.
[20:39] <flocculant> lol
[21:13] <Unit193> http://sigma.unit193.net/comix.html#explosm
[21:13] <Unit193> ....Uhh.
[21:13] <Unit193> https://lists.ubuntu.com/archives/ubuntu-devel/2015-October/038924.html
[21:17] <knome> almots
[21:17] <knome> almost too
[21:17] <knome> ...
[21:18] <Unit193> I selected the link and copied it, some reason it didn't copy. >_<
[21:22] <knome> yyeeeep.
[22:08] <ochosi> Noskcaj, flocculant: what setting where and why again? :)
[22:51] <Unit193> Amusingly, the link I posted doesn't include Xubuntu.