[00:10] <zul> im back as well
[00:11] <zul> kees: ill upload it and do the testcase if you want
[00:15] <zul> slangasek: sorry I wasnt available I was getting some dental work done and was at the dentist
[00:15] <zul> slangasek: um dental work done and family commitments
[00:16] <kees> zul: that'd be great, thanks.
[01:36] <emgent> Hi ember
[01:36] <ember> hey emgent, sup
[01:51] <slangasek> zul: ah, so kees volunteered you sight-unseen, ok then... :)
[01:52] <zul> slangasek: im trying to test the debdiff now after I get this dapper vm setup
[01:54] <Rudd-O> guys
[02:00] <kees> slangasek: well, I'd volunteered zul and mathiaz since they've had the most apache-touching recently and I was already swamped with equally time-critical things.  :)
[02:08] <[Relic]> how long does it take between a report and the time someone actually looks at fixing something?
[02:09] <StevenK> [Relic]: It depends, usually. What's the bug number, I'll have a quick look.
[02:10] <[Relic]> basically it is snatching a c file from a newer kernel module and inserting to bring ubuntu 45nm core temp support  ->  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/235119
[02:10] <StevenK> Ahhhh.
[02:12] <[Relic]> I run blender which is CPU rendering so I really want to know my core temp.  I know multiple people have verified it can work if lm-sensors 3.0.2 sensors detect and the new coretemp.c with the model x17s are brought in
[02:43] <[Relic]> I need a bigger back buffer when they do that  :(
[02:44] <Rudd-O> can I float this idea guys? http://software-libre.rudd-o.com/Streams_vs._documents
[02:46] <ScottK> Seems a bit OT here.  More of an upstream thing.
[02:52]  * davidm is away: 
[02:53] <pwnguin> Rudd-O: ever heard of plan9?
[03:21] <RAOF> Rudd-O: Is that in response to bryce's blog post?
[03:29] <calc> heh i got a bug report about openoffice from the head of osnews
[03:30] <calc> the name sounded familar so i googled it and found out it was her
[03:30] <StevenK> calc: In Launchpad?
[03:31] <calc> StevenK: yea
[03:32] <StevenK> calc: Bug number? :-)
[03:32] <pwnguin> Eugenia?
[03:32] <calc> 242557
[03:32] <calc> yea
[03:33] <pwnguin> bug #242557
[03:33] <calc> probably should just find the original bug where it is filed and merge it rather than invalid
[03:38] <pwnguin> calc: im not sure if it counts as invasion of privacy, but I found knuth's LP account
[03:42] <persia> Polling it for activity is maybe an invasion of pricacy, but LP accounts have become part of our public faces.
[03:43] <lamont> so... lets say that I have a raid 6 device that I want to do an install on, and an up-and-running hardy box to plug it into...  is there a wubi-like thing, or do I get to reboot the machine and do the install from there?
[03:47] <emgent> morning people
[03:51] <persia> lamont: debootstrap?
[03:51] <lamont> well, yeah.
[03:51] <lamont> I want all the rest of it to turn it into a hardy desktop machine
[03:51] <lamont> preferrably without doing all those steps manually
[03:51] <lamont> (because that sucks)
[03:51] <lamont> (all 6  or 7 times I've done it before...)
[03:52] <persia> OK.  debootstrap target; chroot target /bin/bash; apt-get install ubuntu-desktop
[03:52] <lamont> that's about 16 steps short of clueful
[03:52] <persia> Well, yes.  It could use a pretty GUI python wrapper, and misses a few bits.
[03:53] <persia> How about booting the ISO in a VM attached to the device?
[03:54] <lamont> "few".  heh
[03:56] <persia> lamont: What?  Do you really want such niceties as a locale, or host definitions?
[03:59] <lamont> default first user, partitioner, etc
[04:02] <persia> Right.  `kvm -hdc /dev/sdq ubuntu-hardy.iso`
[04:03] <RAOF> Or virt-manager.  I've found that nice.
[04:03] <persia> Err `kvm -hdc /dev/sdq -cdrom ubuntu-hardy.iso`
[04:03] <persia> RAOF: For installing Ubuntu Desktop on a bare RAID device?
[04:04] <RAOF> Start the interface as root and I'm pretty sure you can use a raw device as the target.
[04:05] <RAOF> kvm also works, of course, and may be more obvious given a browse of the man page ;)
[04:19]  * pwnguin should try out kvm now that ubuntu-mobile is offering an image
[04:51] <lamont> does the -generic kernel have kvm support, or does that require the kvm kernel?
[04:51] <RAOF> -generic has kvm support.  Is there a kvm kernel?  Do you mean -xen, or -openvt, or something?
[04:52] <persia> -generic supports kvm as a guest, and runs within kvm
[04:52] <pwnguin> hmm
[04:52] <pwnguin> Daniel T Chen 2005-08-07 Expired on 2007-08-16
[04:53] <persia> Your hardware must support kvm though.  Otherwise virtualbox and kqemu are alternates (but you have to build your own kqemu modules from source)
[05:54] <lamont> hrm... 3TB ext3 FS on RAID5 takes a while to create... :-(
[06:03] <lifeless> win 20
[06:03] <wgrant> It's such a badly named command.
[06:07] <RAOF> Nah.  It's awesome.
[06:07] <RAOF> lifeless: Can I win 30? :)
[06:07] <lifeless> that would #squeak
[06:08]  * StevenK wonders about Unicode code points for small caps
[06:30] <dholbach> good morning
[06:30] <dholbach> bryce: still there? :)
[06:59] <pitti> Good morning
[07:00] <StevenK> Morning pitti
[07:00] <nxvl> good $TZ_TIME_OF_DAY
[07:00] <pitti> cjwatson_: chiark> my server moved to a new IP, could that gbe it?
[07:01] <pitti> cjwatson_: s/gbe/be/
[07:01] <dholbach> tjaalton: do you keep X packages in bzr/git/something?
[07:02] <dholbach> tjaalton: if not, I'm going to drop our patch on xserver-xorg-input-vmmouse (as the scaling was fixed in the new upstream release too and fixing the scaling twice broke the mouse in kvm for me)
[07:07] <nxvl> pitti: oh, btw, i already upload the debdiff for openvpn
[07:07] <pitti> nxvl: debdiff?
[07:07] <pitti> it's a (fake)sync, isn't it? not much of a diff
[07:07] <nxvl> Bug #242537
[07:07] <ubott2> Launchpad bug 242537 in openvpn "Please sync openvpn 2.1~rc7-5 (main) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/242537
[07:08] <nxvl> pitti: yep, but i don't have any other way to upload my work
[07:08] <nxvl> pitti: the diff is the debian changes aplied to our old package
[07:08] <pitti> nxvl: ah, I see; heh, I could just have done it myself, but thanks
[07:08] <nxvl> :D
[07:08]  * pitti uploads
[07:09] <nxvl> it was just a bitsize fix
[07:09] <nxvl> just one line
[07:12] <pitti> nxvl: uploaded
[07:13] <nxvl> :D
[07:13] <nxvl> thanks
[08:13] <dholbach> hi seb128
[08:13] <seb128> hello dholbach
[08:18] <bryce> dholbach: yeah
[08:19] <dholbach> bryce: did the xserver-xorg-input-vmmouse upload myself - hope that was OK
[08:19]  * pitti hugs dholbach for the vmmouse fix -- the previous version drove me mad in intrepid :)
[08:19] <bryce> dholbach: sure that's probably fine.  I was just looking at that bug earlier
[08:20] <pitti> hey seb128, bonjour
[08:20] <seb128> guten tag pitti
[08:28] <DarKnesS_WolF> i'm trying to build a gdal package with gdal support but i am getting this error in hardy , feisty gutsy it did work fine
[08:28] <DarKnesS_WolF> http://pastebin.ca/1055587
[08:29] <DarKnesS_WolF> i'm building using that command dpkg-buildpacka
[08:29] <DarKnesS_WolF> ge -rfakeroot
[08:29] <DarKnesS_WolF> i'm building using that command dpkg-buildpackage -rfakeroot
[08:35] <pitti> Riddell: oooh! https://svn.pardus.org.tr/uludag/trunk/PolicyKit-kde/
[08:35] <pitti> Riddell: just read a mail on hal@ that it is near completion
[08:57]  * ogra wonders why Keybuk set bug 98955 to fix committed ...
[08:57] <ubott2> Launchpad bug 98955 in upstart "logd not running" [Medium,In progress] https://launchpad.net/bugs/98955
[09:08] <berzerka> sorry for question not strictly related to ubuntu development, but i think you devs might be the only ones able to answer: how is the CAP_SYS_RAWIO capability handled in ubuntu? i am developing a userspace USB driver and read with ioctl from /dev/bus/usb/*/*. on my gentoo machine, no problem. on ubuntu i get "Operation not permitted" and the only thing i can imagine is that the RAWIO capability is disabled. on the other hand, it doesn't even
[09:08] <berzerka> work using sudo. any ideas?
[09:09] <dholbach> berzerka: you could try in #ubuntu-kernel
[09:09] <berzerka> dholbach: oh, right. thank you!
[09:10] <dholbach> np :)
[09:52] <dholbach> thekorn: bug.activity is GREAT - thanks
[09:52] <seb128> dholbach: what is that?
[09:53] <dholbach> >>> import launchpadbugs.connector as Connector
[09:53] <dholbach> >>> Bug = Connector.ConnectBug()
[09:53] <dholbach> >>> bug = Bug(242667)
[09:53] <dholbach> >>> print bug.activity
[09:53] <dholbach> [<hito 2008-06-24 14:06:00 UTC 'bug'>, <ikuya-fruitsbasket 2008-06-24 14:24:00 UTC 'bug'>, <ikuya-fruitsbasket 2008-06-24 14:55:00 UTC 'bug'>, <arnegoetje 2008-06-25 07:17:00 UTC 'scim-anthy: status'>]
[09:53] <dholbach> >>>
[09:55] <seb128> dholbach: ah, nice ;-)
[10:02] <thekorn> dholbach, oh, good to hear it's working and you like it
[10:02] <thekorn> but this shows me that I have to update the wiki more often
[10:02] <dholbach> :)
[10:07] <cjwatson> pitti: could be - what's the new IP, and I'll pass it on?
[10:08] <pitti> cjwatson: 213.9.93.70
[10:08] <pitti> cjwatson: (host piware.de)
[10:08] <cjwatson> pitti: ah yes, doesn't match slave0.ns.chiark.greenend.org.uk
[10:09] <StevenK> Heh, wasn't piware moved like a week ago? :-)
[10:11] <cjwatson> can take a little while to notice slave NS misconfiguration
[10:11] <cjwatson> the cron job that whines about it on that system is weekly, I think
[10:12] <StevenK> Ah.
[10:16] <pitti> which reminds me, I should set the DNS TTL back to a day (currently an hour)
[10:16] <Keybuk> ogra: because a "fix" has been committed ?
[10:17]  * StevenK checks what his TTL is, since he recently moved his domain too
[10:19] <dholbach> ArneGoetje: does the anthy patch apply for you? it doesn't for me
[10:21] <ArneGoetje> dholbach: against the hardy version?
[10:21] <ArneGoetje> dholbach: works for me
[10:21] <ogra> Keybuk, well, removing the code is not actually what i would call a fix :)
[10:22] <ogra> (unless i understood the upstream commit wrong)
[10:22] <dholbach> ArneGoetje: sorry - my mistake, I'll update it to be "intrepid" instead of "hardy
[10:22] <ArneGoetje> dholbach: ?
[10:23] <dholbach> ArneGoetje: the changelog says 'hardy'
[10:24] <dholbach> ArneGoetje: ah - we have a newer version in intrepid - that why it does not apply
[10:25] <ArneGoetje> dholbach: correct
[10:25] <dholbach> the patch needs a bit of updating then
[10:25] <ArneGoetje> dholbach: in that case, I'll test if the bug still applies for intrepid
[10:26] <dholbach> well, we can't upload to hardy any more (or it needs to follow StableReleaseUpdates)
[10:26] <ArneGoetje> dholbach: bug fix?
[10:27] <dholbach> still it'd be hardy-proposed instead of hardy and it needs to go into intrepid first anyway
[10:27] <dholbach> https://wiki.ubuntu.com/StableReleaseUpdates
[10:27] <ogra> MacSlow, 01_fix_missing_semicolon.patch ? thats sweet :)
[10:27] <ArneGoetje> dholbach: my guess is that the issue has been fixed in intrepid already... but I'll check that
[10:28] <MacSlow> ogra, mvo found that one actually
[10:28] <Keybuk> ogra: it closes the bug
[10:28] <dholbach> ArneGoetje: gracias
[10:28] <ogra> Keybuk, it doesnt fix logging, so i'd disagree
[10:28] <Keybuk> ogra: where "Fix Committed" means that the bug will be made invalid
[10:28] <MacSlow> ogra, I didn't even see this failing initially with all the tons of output pbuilder creates
[10:28] <Keybuk> since there's no "Something that will make this bug Invalid Committed" status ;)
[10:29] <ogra> well, isnt it to be fixed in upstart in the end ? and isnt the final fix to have a proper boot log ?
[10:29] <Keybuk> no
[10:29] <MacSlow> ogra, Keybuk: I informed the debian maintainer and also filed a bug upstream with the patch attached... as it was still not fixed in trunk... odd isn't it... in over four months nobody ran into that
[10:29]  * ogra doesnt get the logic
[10:30] <ogra> MacSlow, well, i poked on that package quite often in the past and slangasek as well ... seems nobody of us ever spotted it
[10:31] <MacSlow> are we meant to keep confflags-gnome and confflags-gtk in debian/rules for goffice? debian only uses confflags and does not make a distinction between gtk- and gnome-related flags.
[10:31] <ogra> MacSlow, xubuntu :)
[10:31] <ogra> they dont want gnome libs
[10:32] <MacSlow> mvo, sorry for implicitly stealing your credit regarding the semicolon-patch regarding planner!
[10:32] <MacSlow> ogra, so how should I go about merging that? just put everything in confflags?
[10:33] <ogra> MacSlow, ask one of the xubuntu people i'd say, they likely have touched that before and created that diff
[10:33] <mvo> MacSlow: no worries
[10:33] <seb128> you likely want to keep the ubuntu changes the way they are
[10:34] <ogra> not sure if there is more involved than confflags
[10:34] <seb128> debian doesn't build a gtk variant
[10:34] <ogra> there might be additional patches
[10:34] <MacSlow> hm... ok... gnumeric is a tougher beast than anticipated... goffice (newer version needed for gnumeric) looks nasty to me merge-wise
[10:35] <mvo> ogra, MacSlow: it seems to be releated/triggered by the new glib
[10:35] <Keybuk> ogra: I don't really have any solution for logging yet
[10:35] <MacSlow> mvo, yes... dependencies of goffice introduced the need for a newer glib
[10:36] <Keybuk> removing the claim of the feature is the best fix for now
[10:37] <ogra> Keybuk, yeah understood, i just didnt get the logic first place
[10:37] <MacSlow> seb128, hm... debian enables static libraries for goffice... do we want that too?
[10:37]  * MacSlow assumes not
[10:38] <seb128> usually we want what debian do if we don't have strong reason to not take the changes
[10:38] <ogra> there might be an entry in the changelog explaining it ;)
[10:39] <Keybuk> ogra: Fix Committed is a silly status really
[10:39] <Keybuk> at least, according to the LP model
[10:39] <ogra> yeah
[10:39] <Keybuk> you should be able to add bug tasks for a branch
[10:39] <Keybuk> then that branch could be marked Invalid/Wont Fix or something
[10:39] <ogra> well, cant you just mark it Invalid and make it hishlist for a new app ?
[10:39] <ogra> *whishlist
[10:39] <Keybuk> then when I make a release on that branch, the bug status should be automatically copied to the task for the upstream package
[10:39] <seb128> Keybuk: it's not when you have the packaging in bzr and if launchpad was updated automatically on commit
[10:40] <Keybuk> seb128: err, ?
[10:40] <Keybuk> seb128: that doesn't make what I said invalid
 ogra: Fix Committed is a silly status really
[10:40] <seb128> that was a reply to that
[10:40] <Keybuk> seb128: the next line is more important ;)
[10:40] <seb128> right, but I was typing then ;-)
[10:41] <Keybuk> in your use, and my model, committing would set the branch bug task to "Fix Released"
[10:41] <seb128> right
[10:41] <Keybuk> releasing would set the upstream bug task to "Fix Released"
[10:41] <Keybuk> packaging would set the distro bug task to "Fix Released"
[10:41] <seb128> hum, not really
[10:41] <Keybuk> Fix Committed is silly because you can do more than commit Fixes :p
[10:41] <seb128> fix released is when the update is pushed in the distribution
[10:41] <Keybuk> right, that's what I mean - couldn't think of a good word :P
[10:42] <MacSlow> what does the -i option in dh_<command> in debian/rules?
[10:43] <cjwatson> man debhelper
[10:43] <cjwatson> MacSlow: ^-
[10:44] <cjwatson> Keybuk: "fixed" would do it ...
[10:44] <MacSlow> cjwatson, ah thanks
[10:45] <Keybuk> cjwatson: ?
[10:46] <MacSlow> seb128, for goffice we still don't want -dbg pakcages?! that's currently stated in a comment in goffice's debian/rules
[10:47] <cjwatson> Keybuk: for a branch status, "fixed" would be sufficient and clearer, and would avoid seb's "is when the update is pushed in the distribution" objection which I guess is due to the "released" word
[10:47] <Keybuk> cjwatson: ogra disagrees that "fixed" is clear
[10:47] <cjwatson> ogra: oh?
[10:47] <Keybuk> cjwatson: an upstream upstart bug is marked "Fix Committed"
[10:48] <cjwatson> Keybuk: oh, I'm not objecting to "invalid" also being an option
[10:48] <Keybuk> because trunk no longer has any code relevant to the bug, so will make it Invalid
[10:48] <Keybuk> ah
[10:48] <Keybuk> got you
[10:48] <cjwatson> ogra: (never mind)
[10:48] <Keybuk> yeah if you get rid of "Fix Committed" then you can rename "Fix Released" to just "Fixed"
[10:48] <cjwatson> right, that's what I mean
[10:48] <Keybuk> which is a much better name without any nasty overtones of "go get it now, pull, pull"
[10:49] <seb128> MacSlow: not sure, I've no real opinion either way
[10:50] <seb128> MacSlow: we have dbgsym so we don't need those, and since the ubuntu version builds several variants the dbg build might require changes
[10:50] <MacSlow> ok
[10:54] <ArneGoetje> dholbach: the bug still exists in intrepid
[10:55] <dholbach> so in any case it needs fixing in intrepid first and the patch needs some changes
[10:57] <wgrant> pitti: You said in bug #228969 that libcairo was gone from Intrepid, but it survives to this day.
[10:57] <ubott2> Launchpad bug 228969 in libcairo "Remove libcairo from Ubuntu" [Wishlist,Fix released] https://launchpad.net/bugs/228969
[10:59] <pitti> wgrant: weird; I was sure I saw it in process-removals, hmm
[10:59] <pitti> wgrant: doing again then
[11:00] <wgrant> pitti: Soyuz does seem to often have issues with overrides, removals or syncs not sticking...
[11:00] <wgrant> Thanks.
[11:02] <pitti> done
[11:07] <munckfish> TheMuso: hi, did you see mail about the PS3 kernel yesterday?
[11:11] <ArneGoetje> dholbach: the patch itself (debian/patches/06_fix_vu_dpatch.dpatch) also works against the intrepid version and fixes the issue
[11:12] <dholbach> ArneGoetje: right... the debdiff needs updating
[11:12] <ArneGoetje> dholbach: I will make a new debdiff for intrepid
[11:13] <seb128> ArneGoetje: I think I synced scim-hangul a bit too quickly the other day and some changes were still required, could you have a look and maybe reapply those if that's the case since you probably know better about those
[11:14] <ArneGoetje> seb128: err... ok, I'll try
[11:14] <dholbach> ArneGoetje: ROCK
[11:15] <ArneGoetje> dholbach: ?
[11:15] <dholbach> ArneGoetje: "great" :)
[11:15] <ArneGoetje> dholbach: ah :D
[11:16]  * ArneGoetje -> dinner, bbl
[11:30]  * pitti arghs at Python's optparse, which suddenly yields a "UnicodeDecodeError: 'ascii' codec can't decode byte" blabla exception
[11:31] <pitti> (suddenly -> after .mo files got installed)
[11:32] <ogra> blabla exception ? oh, thats an evil error :)
[11:33] <pitti> after some googling it seems I need to do some black magic with setting sys.stdout to a codecs wrapper, or something
[11:33] <pitti> but heck -- why should I even care???
[11:34] <DarKnesS_WolF> i'm building using that command dpkg-buildpackage -rfakeroot
[11:34] <DarKnesS_WolF> http://pastebin.ca/1055587
[11:34] <DarKnesS_WolF> any idea ?
[11:34] <DarKnesS_WolF> this is gdal package from apt-get source gdal
[11:34] <dholbach> .
[11:36] <ogra> ;
[11:37] <ion_> ؟
[11:39] <cjwatson> DarKnesS_WolF: seems like a bug, if you're building it on the version of Ubuntu it was released for with all the build-dependencies installed
[11:53] <geser> DarKnesS_WolF: you have a lib in /usr/local/lib which gdal links against
[11:53] <cjwatson> oh yes, I can't read
[11:57] <cjwatson> pitti: see e.g. http://bazaar.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu/annotate/cjwatson%40canonical.com-20080620095615-rf3zpj1maa556ro1?file_id=helptogfxboot.py-20071128181623-fb6n7sukjr5u2r1p-4
[11:59] <pitti> cjwatson: I saw some similar recipes, but those were all hacks which hardcoded a particular encoding
[11:59] <pitti> cjwatson: I think it is http://bugs.python.org/issue2931
[11:59] <pitti> I haven't tried the patch yet
[12:00] <pitti> (hm, that wasn't it)
[12:00] <pitti> cjwatson: thanks for the pointer, anyway!
[12:01] <pitti> cjwatson: I don't see why I should even care in my Python programs (from a 10,000 m perspective)
[12:01] <pitti> the output encoding is determined by the locale, and the input encoding is given in the .mo files and thus by gettext
[12:02] <cjwatson> pitti: replacing 'UTF-8' with locale.getpreferredencoding() should deal with the hardcoding objection (not tested though)
[12:02] <cjwatson> pitti: and I certainly agree the current situation is hopeless
[12:02] <pitti> oh, good idea
[12:03] <cjwatson> pitti: see also http://ewx.livejournal.com/457086.html for the last time I remember discussing this
[12:05] <zul> monining
[12:12] <pitti> cjwatson: hm, it still fails even with your recipe; *gnargh*; anyway, I'll try again after lunch
[12:15] <ogra> could someone poke MOM to get a fresh overview ?
[12:23] <Keybuk> ogra: ? mom is running fine
[12:23] <Keybuk> last update was 11 minutes ago
[12:23] <ogra> Keybuk, how often ? would be good to raise the frequency
[12:23] <Keybuk> hourly
[12:23] <ogra> at least on days before import freeze that makes the overview easier
[12:23] <ogra> hmm
[12:23] <ogra> k
[12:24] <Keybuk> the frequency is not limited by malaise
[12:24] <ogra> well, i still see ltsp and moodle on there
[12:24] <Keybuk> how long ago did you upload the merged packages?
[12:24] <Keybuk> moodle has not yet been published
[12:24] <ogra> moodle was 15mins ago, ltsp 1h
[12:25] <Keybuk> ltsp was only published 20 minutes ago
[12:25] <cjwatson> MoM can't really run faster than the publisher ;-)
[12:25] <ogra> bah, add a time machine :P
[12:25] <Keybuk> when MoM runs at 1105Z, it will see ltsp in the archive (assuming the mirror happens by then)
[12:25] <ogra> right
[12:25] <ogra> thats enough then
[12:25] <Keybuk> it will pick up moodle once that has been published and mirrored, which may be as early as 1105Z, but may not
[12:26] <ogra> yeah
[12:26] <Keybuk> the average MoM run takes between 50 and 70 minutes right now
[12:26] <Keybuk> so it really can't go any faster
[12:26] <ogra> i'm just lazy and dont want to compare changes with MoM all the time to find what to grab and whats gone
[12:26] <ogra> *-changes
[12:26] <Keybuk> actually, the 1105Z was cancelled due to lock
[12:27] <Keybuk> so the next run will be 1205Z (the 1005Z only just finished)
[12:27] <Keybuk> ogra: surely you have a vague idea which source packages you've touched in the last couple of hours? ;-)
[12:27] <ogra> Keybuk, mine are done, i'm starting to grab others
[12:35] <kwwii> mvo: erm, there seems to be a problem with the changelog of the ubuntu-artwork package (dch complains that the maintainer field is empty)
[12:35] <kwwii> mvo: as you were the last one to update it, I thought I should ask you ;-)
[12:36] <mvo> kwwii: let me check
[12:36] <kwwii> mvo:  just look at the last two changelog entries and you'll see the problems
[12:39] <Keybuk> bryce: so, err, around/
[12:39] <Keybuk> I'm having a little X problem
[12:42] <mvo> kwwii: please update, I fixed it in bzr
[12:43] <mvo> kwwii: the " -- author ..." line was empty, emacs is less picky about it, I guess this is why I forgot about it
[12:43] <kwwii> mvo: excellent, thanks for the help :-)
[12:51] <kwwii> how in the hell is one supposed to use bzr with launchpad these days? the crappy lp:~path stuff is simply confusing and shitty
[12:51] <kwwii> boah, sorry for going off but this is silliness
[12:51] <Keybuk> ?
[12:52] <Keybuk> bzr branch lp:upstart
[12:52] <kwwii> how is it that when I do a pull, make changes, commit and then try to push and it gives me grief about using http?
[12:52] <Keybuk> saves remembering a URL
[12:52] <kwwii> the lp stuff is exactly what is messing it up it seems
[12:52] <Keybuk> because you don't have permission to push to that branch?
[12:52] <Keybuk> what's the branch?
[12:52] <kwwii> no, I do
[12:52] <Keybuk> did you at the point you branched?
[12:53] <kwwii>  lp:~ubuntu-art-pkg/ubuntu-artwork/ubuntu
[12:53] <kwwii> yepp
[12:53] <Keybuk> bzr info says?
[12:53] <james_w> kwwii: you need to run "bzr lp-login <lp user id>" I expect
[12:53] <kwwii> kwwii@clive:~/bzr/test/u-art$ bzr push lp:~ubuntu-art-pkg/ubuntu-artwork/ubuntu
[12:53] <kwwii> bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eubuntu-art-pkg/ubuntu-artwork/ubuntu/.bzr/repository/lock): Transport operation not possible: http does not support mkdir()
[12:53] <james_w> kwwii: and then "bzr push --remember lp:~ubuntu-art-pkg/ubuntu-artwork/ubuntu"
[12:53] <lifeless> kwwii: bzr launchpad-login
[12:53] <james_w> newer bzr gives you a hint about this.
[12:54] <kwwii> I just pushed another branch under ~ubuntu-art-pkg and it worked fine
[12:54] <Keybuk> lifeless: doesn't it use $USER if not set?
[12:54] <lifeless> Keybuk: no
[12:54] <Keybuk> lifeless: isn't that a bit silly?
[12:54] <lifeless> Keybuk: root cause - because it doesn't fallback to http on ssh login failure
[12:54] <lifeless> Keybuk: hey, $code-I-didn't-writely-urs
[12:55] <lifeless> Keybuk: or a better answer - incremental improvements
[12:55] <lifeless> Keybuk: if the non-fallback bug is fixed, using $USER becomes plausible
[12:56] <wgrant> But wouldn't that mean it would ask all conceivable key passphrases even if you didn't have an LP account?
[12:56] <ogra> kwwii, do you have  launchpad_username set in ~/.bazaar/bazaar.conf ?
[12:57] <Keybuk> random bug of the day
[12:57] <Keybuk> bootchart still runs in recovery mode
[12:57] <ogra> hey, then you can see how fast you get to the rootshell ... thats a feature :P
[12:58] <Keybuk> ogra: and you see how long you were in the root shell
[12:58] <Keybuk> and you see what you did while there, and how long that took
[12:58] <Keybuk> and then you see how long the rest of the boot took after you resume
[12:58] <ogra> hehe
[12:58] <Keybuk> and then you see your disk full with a massive svg
[12:58] <cjwatson> kwwii: you can continue to use the old-style bzr+ssh:// URLs
[12:59] <cjwatson> kwwii: replace lp: with bzr+ssh:// in the above and it should work (as a means of getting you past the immediate problem)
[12:59] <cjwatson> Keybuk: stop viewing your porn in recovery mode
[12:59] <ogra> lol
[12:59] <Keybuk> cjwatson: I'm trying to get X to work :-/
[13:00] <ogra> and get a bigger disk ...
[13:01] <Keybuk> maybe usplash related
[13:01] <donri> is there any interest in making luks accessible to the masses in ubuntu?
[13:02] <donri> seems rather quiet on launchpad, https://blueprints.launchpad.net/ubuntu/+spec/ubiquity-luks-support
[13:07] <cjwatson> donri: that's blocked on general support in ubiquity for other than plain block devices
[13:08] <cjwatson> donri: we do need to do that anyway, e.g. for dmraid-support, but it's hard to give much attention to ubiquity-luks-support until that's in place
[13:08] <donri> cjwatson: sorry, what? I don't understand.
[13:08] <cjwatson> donri: plain block devices == /dev/sda1 and such
[13:08] <cjwatson> as in ordinary hard disks
[13:08] <cjwatson> in order to support luks, ubiquity needs to have support for more complicated block devices in general
[13:08] <donri> ok...
[13:08] <cjwatson> which is a fair amount of work to put in place, although it is on the plan
[13:09] <donri> i see, that's good.
[13:09] <SEJeff> soren, ping from yesterday. I misread the patch for libvirt. Please ignore the comment in #ovirt
[13:12] <wgrant> cjwatson: Hasn't that been targetted to every release greater than or equal to Edgy?
[13:15] <ogra> wgrant, and you still didnt send a patch :(
[13:15] <soren> SEJeff: Alright, cool :)
[13:15]  * soren goes to lunch
[13:15] <SEJeff> soren, FYI: I'm trying to get ovirt wui running in Ubuntu. We'll see
[13:16] <ogra> is anyone doing hotkey-setup  ?
[13:20] <wgrant> ogra: I wasn't exactly complaining. Just wondering if it really was still coming RSN.
[13:21] <ogra> wgrant, sure, it will if someone sends a patch (hint hint) ;)
[13:21] <ogra> wgrant, its not that we dont want to do it, its a manpower issue
[13:30] <donri> cjwatson: in which upcoming ubuntu release do you estimate it might be included?
[13:31] <lool> lamont: Could you please add virtualbox-ose in Pas to lpia?
[13:32] <lamont> lool: "# Please email comments, corrections to james@nocrew.org, lamont@debian.org and/or adconrad@debian.org.  See ChangeLog for history."
[13:32] <lamont> for tracking purposes and all that
[13:32] <lool> Okay
[13:34]  * lamont finds himself annoyed at the encrypted filesystem stuff
[13:34] <lool> lamont: Mailed
[13:34] <cjwatson> wgrant: *cough*
[13:34] <lamont> "/boot/grub/stage1 not read correctly"
[13:34] <cjwatson> wgrant: actually not so much for edgy because we knew it was blocked on the partitioner reimplementation
[13:34] <cjwatson> donri: hard to say at present, sorry; I think intrepid+1 would probably be a decent guess
[13:35] <lamont> lool: updated
[13:36] <lool> lamont: Thanks; when do Ubuntu buildds notice?
[13:36] <lamont> lool: that'd be an infinity question (in about 3.5 hours when he should be around)
[13:37] <lamont> the answer for debian is "generally within 24-48 hours"
[13:37] <lamont> not sure how quickly ubuntu will notice
[13:37] <lool> lamont: Ok; as long as it's automatic, I don't care
[13:37] <lamont> entirely
[13:39] <jdstrand> lucas: hi. I am doing the ruby1.9 merge for ubuntu, and was doing a schroot amd64 intrepid build before upload, and found that it hangs at test_copy_stream_rbuf(TestIO). Have you seen this before? (I saw your name in the changelog of the Debian package)
[13:40] <jdstrand> \sh: ^ have you seen this in your previous merges?
[13:41] <donri> cjwatson: so 9.04? that's good, it's in october 2009 scary things start happening in sweden.
[13:42] <cjwatson> donri: this isn't a commitment, just my guess as to when we'll have available time
[13:42] <lucas> jdstrand: no, I never saw that
[13:42]  * jdstrand scratches head
[13:42] <jdstrand> lucas: ok thanks
[13:45] <donri> cjwatson: of course, it isn't an obligation. I just think it would be very good, for sake of others. I personally already have a LUKS setup, but less technical people are likely scared away by lengthy technical guides.
[13:46] <wgrant> donri: The alternate installer isn't too terrible, and does LUKS.
[13:46] <donri> I see lots of windows survivors trying out Ubuntu, and I think security is important. Especially in these days, especially here in sweden.
[13:46] <donri> wgrant: from what I understood from the wiki, it does dm-crypt and not luks/cryptsetup?
[13:46] <wgrant> donri: It does LUKS.
[13:47] <wgrant> Though it does support dm-crypt for random swap keys, IIRC.
[13:47] <donri> cool. still, windows survivors who "just surf and chat" likely think it is "too terrible"? I haven't tried the alternate installer though, admittedly.
[13:49] <donri> Does the boot process of ubuntu itself support luks or does it only work for non-root partitions?
[13:49] <wgrant> donri: I run LVM on LUKS for everything but /boot.
[13:49] <donri> Yea, encrypting /boot isn't easy ;)
[13:50] <siretart> it is: boot from USB
[13:50] <donri> but can you have the stick encrypted then?
[13:50] <donri> anything something has to be non-encrypted, eh?
[13:51] <ogra> donri, as i said to wgrant above, every helping hand will speed it up ;)
[13:52] <siretart> donri: no, the stick is removable, so no need to encrypt it
[13:52] <donri> then you have to guard it 24/7 ... if you're paranoid. :P
[13:52] <\sh> jdstrand: nope..
[13:53] <donri> ogra: what could I do?
[13:54] <ogra> donri, talk to the ubiquity maintainer, he might know ... even if people dont work directly on the luks implementation but help out with other stuff that means he can get his hands free earlier :)
[13:54] <ogra> donri, evand is the ubiquity master ...
[13:55] <donri> evand: ping :)
[14:05] <evand> donri: tbh, help would require a understanding of partman internals, though anyone with that knowledge is welcome to take a shot at the ubiquity portion of https://wiki.ubuntu.com/EncryptedFilesystems, and if they're successful I'll merge the branch.
[14:07] <cjwatson> ah yes, that ubiquity-luks-support spec probably ought to be marked as superseded by encrypted-filesystems ...
[14:08] <wgrant> Who has the power to alter blueprints like that?
[14:09] <cjwatson> ubuntu-drivers
[14:09] <cjwatson> and the blueprint assignee/drafter/approver
[14:09] <slangasek> ogra: what package am I supposed to have poked at? planner?  I don't think I've ever poked very deep at that one. :)
[14:09] <cjwatson> I don't want to Just Do It though, the wiki page should be checked for useful things that could be in the EncryptedFilesystems wiki page
[14:10] <cjwatson> (but preferably not random implementation guesses from somebody who doesn't know the current implementation)
[14:10] <ogra> slangasek, i didnt say deep :)
[14:10] <jdstrand> kees: I don't suppose ruby1.9 was in the list of packages that FTBFS with your compiler hardening, was it?
[14:10] <wgrant> cjwatson: So bugs are very publicly editable but specs are ridiculously restrict beyond even the development team?
[14:10] <cjwatson> wgrant: not my idea
[14:11] <ogra> slangasek, but many people have touched it and nobody noticed the build error ever :)
[14:11] <ogra> slangasek, i stole moodle from you if you noticed
[14:11] <cjwatson> wgrant: IMO the practical solution is to stop this pernicious meme of telling people who file wishlist bugs to write specs instead ...
[14:11] <wgrant> Blueprint does seem to be pretty much dead these days.
[14:11] <cjwatson> which I have been complaining about for years
[14:11] <wgrant> cjwatson: I've only seen some novice triagers doing that recently.
[14:12] <cjwatson> maybe my complaints found some ears
[14:14] <wgrant> Hopefully.
[14:14] <wgrant> And hopefully Blueprint will see some development post-2.0...
[14:17] <Rudd-O> guys
[14:17] <Rudd-O> can I interest you in a speculative development direction?
[14:18] <Rudd-O> http://software-libre.rudd-o.com/Streams_vs._documents
[14:19] <wgrant> Didn't bryce blog about that a few hours ago?
[14:19] <ogra> yep
[14:19] <ogra> its on planet.ubuntu.com
[14:30] <pitti> cjwatson: hah! I didn't get it to work with your recipe, but finally I found something simple: http://bazaar.launchpad.net/~pitti/jockey/dbus-backend/revision/348
[14:45] <SEJeff> soren: ping. When you get back from lunch can you hop in #ovirt for a q & a with some redhat guys?
[14:48] <slangasek> kees: I thought there was supposed to already be a fix for bug #219914 in intrepid, did I misinterpret comments yesterday?
[14:48] <slangasek> (the bug is still marked "confirmed" for intrepid)
[14:49]  * ogra WOAHs loudly seeing https://lists.ubuntu.com/archives/ubuntu-users/2008-June/151143.html
[14:51] <ion_> ogra: :-D
[14:51] <Rudd-O> wgrant: yes, bryce blogged about it.  bryce's blog post sparked my article.
[14:51] <Rudd-O> wgrant: in fact, it's the starting point
[14:51] <wgrant> Rudd-O: So I noticed when I read your article.
[14:52] <wgrant> ogra: Nice. Very very nice.
[14:55] <fta> stgraber, i'm having troubles with pastebinit in intrepid: http://paste.ubuntu.com/22865/
[14:57] <stgraber> fta: known bug, we have a potential fix in our bzr branch
[14:57] <stgraber> fta: If you would like to test it, just download it from : https://code.launchpad.net/~pastebinit-developers/pastebinit/trunk
[14:57] <fta> stgraber, when is the next upload planed ?
[14:59] <stgraber> pastebinit is now packaged and maintained in Debian, so I'll see with the Debian maintainer
[15:00] <stgraber> it'll be in Intrepid for sure, I don't know when though
[15:00] <fta> ok
[15:16] <pitti> kirkland: would you mind marking https://code.edge.launchpad.net/~kirkland/jockey/kirkland.214914 as merged or obsolete?
[15:23] <cjwatson> pitti: ah, yes, that would work as long as all your output is via _
[15:23] <kirkland> pitti: yeah, sure
[15:23] <kirkland> pitti: it's obsolete, i think you solved that problem differently than the patch i suggested
[15:24] <kirkland> pitti: branch "deleted"
[15:26] <wgrant> ogra: Look what you've got yourself into now with that XFree86 guy...
[15:29] <Koon> wgrant: I've posted an hardy debdiff for bug 242690
[15:29] <Koon> wgrant: do you need a specific update for gutsy or will this one do ?
[15:30] <Koon> (though the FTBFS patch I had to apply for hardy is hopefully superfluous for gutsy)
[15:32] <ogra> wgrant, well, i have some desease we call the "helper syndrome" in germany :) i feel pity for him :)
[15:34] <wgrant> ogra: Well, yes, but this is particularly nasty...
[15:34] <wgrant> Koon: You'll need to supply a separate debdiff for each, in general. Make sure you give each a unique version number.
[15:34] <Koon> wgrant: ok, will do.
[15:35] <wgrant> Koon: Because we have the same version in multiple releases, the Hardy version should be 0.6.3-0ubuntu1.8.04.1, Gutsy 0.6.3-0ubuntu1.1.7.10.1, etc.
[15:35] <wgrant> Er, I put an extra .1 in the Gutsy version.
[15:36] <wgrant> 0.6.3-0ubuntu1.7.10.1
[15:36] <ogra> wgrant, well, but not unsolvable, see my last mail ;) who knows, probably that works
[15:36] <Koon> wgrant: got it :)
[15:38] <wgrant> ogra: We can hope.
[15:41] <pitti> kirkland: ah, or that; cheers
[15:44] <slangasek> seb128: so do you have any more insight wrt my last comment on bug #207072?  is there some way to make gnome-panel happy here, while still making do_mount DTRT?
[15:44] <slangasek> btw, I think I've found another regression, in at least the latest version of my patch; browsing workgroups seems to no longer work
[15:46] <seb128> slangasek: I've to run now, but nothing trivial that I know, the right way would be to use the async api
[15:46] <seb128> and libgnomeui has a similar issue
[15:46] <seb128> the fileselector widget
[15:46] <slangasek> seb128: so those are fixes that would have to be made to gnome-panel and libgnomeui, ok :/
[15:46] <seb128> yes
[15:47] <slangasek> then I guess we'll have to scrap this for .1
[15:47] <seb128> I guess so :-(
[15:47] <seb128> or use your first version
[15:47] <seb128> which doesn't do the libsmclient call and try password before anonymous
[15:47] <slangasek> I think that "my" first version still has the same problem
[15:47] <seb128> if that doesn't trigger password prompts for bookmarks, I didn't try
[15:48] <seb128> alright, so no easy fix before 8.04.1
[15:48] <slangasek> because it does the smbc_opendir() on mount
[15:48]  * slangasek nods
[15:48] <seb128> anyway I've to run, see you later
[15:49] <Lrrr> cjwatson: ping?
[15:52] <Lrrr> nvm...
[16:14] <slangasek> bryce: I realize that we haven't had any sort of official freeze announcement for intrepid alpha-1 because we've been so scattered, so not to pick on you at all, but please don't change any more X dependencies in the next couple of days; it makes it hard to get releasable alternate CDs when xserver-xorg-video-all picks up new dependencies on drivers that haven't been promoted out of universe yet :)
[16:16] <bryce> slangasek: oh, sorry about that
[16:17] <slangasek> n/p, just means iterating the CDs again after the next publisher run
[16:17] <bryce> slangasek: the xorg change was the only remaining big piece I wanted to get in for alpha-1
[16:18] <slangasek> sure
[16:18] <slangasek> so actually, to amend the above - if yo have any other X dependencies that need changing, please let me know when you upload :-)
[16:18] <bryce> for some reason based on last week's meeting, I thought we had until Thursday
[16:19] <bryce> ok will do.  I also have a libx11 xcb change, but that'll be for hardy not intrepid
[16:20] <slangasek> I'm hoping to be able to /release/ alpha-1 this thursday
[16:20] <slangasek> since otherwise we run up against the 8.04.1 release itself
[16:21] <bryce> okie doke.  I was planning on mainly focusing on bugs for a bit anyway.  I'll keep in mind not to hold uploads for a bit.
[16:24] <kees> jdstrand: it wasn't in gcc 4.2 -- is it blockeded on a FTBFS in intrepid now?
[16:24] <kees> slan	I thought mathiaz uploaded the fix to intrepid?
[16:25] <kees> slangasek: ^^  (irssi lag fail)
[16:26] <slangasek> kees: well, apparently he has done so now, I just got a bug closure mail :)
[16:27] <kees> slangasek: ah-ha, excellent.
[16:40] <stgraber> Riddell: bug 238839, any idea what's causing it ?
[16:42] <Riddell> stgraber: sounds like ICA should be intelligent enough to quit when it is started and other instance is already running
[16:43] <stgraber> Riddell: it shows a warning message so that's not good
[16:43] <Riddell> replace the warning with a quit then
[16:44] <stgraber> and I don't see why KDE's session restore thing starts ica when it's originally been started from an autostart ...
[16:44] <stgraber> things autostarted shouldn't be stored in the list of applications to restore at next login
[16:45] <Riddell> other apps don't have any problems with it
[16:54] <jdstrand> kees: well, my schroot ruby1.9 build doesn't work right, but the dchroot on ronne seems ok
[16:55] <jdstrand> kees: the ronne build just finished btw, so that's info hot off the press
[16:55] <exodos> In some situations it is needed to run 32bit userland with 64bit kernel (we're running hardy under xen like this). Now you have to download deb packages and manually issue dpkg -i --force-architecture *.deb. In debian, in 32bit repositories they have package called linux-image-2.6-amd64, which is installing the latest 64bit kernel. Would it be possible to add similar funcionality to ubuntu?
[16:56] <kees> jdstrand: what failures are you seeing there?
[16:56] <exodos> with Apt Super Cow Power life is much easier....
[16:57] <kees> (in your chroot, I mean)
[16:58] <joaopinto> exodos, if you need a 32 bits userland on a 64 bits system, you do a full 64 bits install, and do a chrooted 32 bits install
[16:59] <jdstrand> kees: it actually builds fine, but one of the tests fails. it is an innocuous looking little thing
[16:59]  * jdstrand goess and gets it
[17:00] <kees> jdstrand: arch-sensitive?
[17:00] <kees> jdstrand: how long is the build/test cycle?
[17:00] <jdstrand> kees: well, amd64 schroot, and amd64 dchroot (ronne) act different, so I dare say no
[17:00] <kees> fortify has been known to cause runtime issues for unusual code.
[17:01] <jdstrand> kees: I'm kinda leaning toward my schroot not being right
[17:01] <jdstrand> kees: interesting, but I should have seen that in dchroot with dpkg-buildpackage-- correct?
[17:01] <kees> I can kick one off to check too -- anything special I need to do, or just build what's in the archive?
[17:01] <kees> jdstrand: I'd think so -- is the chroot up to date?
[17:01] <jdstrand> kees: try building the sid version on intrepid
[17:02] <jdstrand> (I was doing a merge)
[17:02] <jdstrand> it has the security fixes in it, and import freeze is tomorrow
[17:03] <jdstrand> kees: oh, and it doesn't take too terribly long to build
[17:04] <kees> jdstrand: okay, I'll kick it of
[17:04] <kees> ruby1.9 1.9.0.2-1 ?
[17:05] <jdstrand> kees: yes
[17:05] <kees> jdstrand: kicked.
[17:05] <jdstrand> kees: the test that just hangs is test_copy_stream_strio_rbuf in test/ruby/test_io.rb
[17:06] <jdstrand> kees: http://paste.ubuntu.com/22893/
[17:06] <kees> while it's probably not related, I've had to set things like virtmem limits to get some builds from eating my system alive (gcc-4.3, I'm looking at you).
[17:06] <jdstrand> kees: oops, I meant test_copy_stream_rbuf
[17:07] <jdstrand> kees: http://paste.ubuntu.com/22894/
[17:07] <jdstrand> kees: anyway, it certainly doesn't look like it should hang, but it does...
[17:08] <jdstrand> kees: my ruby foo is amazingly low (but growing as of late), so I'm still working through it
[17:08]  * jdstrand wonders if the dchroot is up to date
[17:22] <liw> this is a bit embarrassing... but what am I doing wrong? I took a package that uses dpatch, modified debian/rules and a few other files (none of the patch files), and now I can't run dpkg-buildpackage, because dpkg-source complains that the debian/patches/*.patch files change permissions and this is unrepresentable in a diff
[17:22] <liw> dpkg-buildpackage calls debian/rules clean, which calls dpatch, which changes the permissions, but how do I handle this?
[17:22] <ion_> That should not be a problem, just a warning. #ubuntu-motu is the correct channel for continuing this discussion, btw.
[17:23] <cjwatson> liw: what's the error?
[17:23] <cjwatson> literally, I mean
[17:23] <liw> oh, oops, sorry, I should start reading errors from the top
[17:23] <liw> I had a binary file change in there, too
[17:24] <liw> works now, thanks
[17:31] <saftsack> http://rafb.net/p/guZU8e56.html
[17:41] <cjwatson> saftsack: #ubuntu-kernel, or a bug report
[17:42] <saftsack> cjwatson, kk thank you
[17:48] <kees> jdstrand: that test hangs for me too.  :(
[18:08] <geser> mathiaz: Hi, I've seen that you uploaded apache2 to hardy-proposed. Please do also a rebuild-only SRU of apache2-mpm-itk (universe) so it gets rebuild with apache2 from -proposed.
[18:16] <mathiaz> geser: that needs to be acked by the motu-sru team IIRC
[18:16] <mathiaz> geser: could you file a bug for it (so that it doesn't get lost ?)
[18:23] <geser> mathiaz: can do
[18:26] <jdstrand> kees: ok, is is updating the dchroot (it had 555 updates)
[18:31] <jdstrand> s/is is/IS is/
[18:33] <jdstrand> kees: I'm going to try it on hardy, and in the dchroot on ronne (when it gets done updating)
[18:34] <geser> mathiaz: bug #243012
[18:56] <jdstrand> kees: 1.9.0.2 built fine on hardy
[19:05] <jdstrand> kees: here is the list of packages that were updated http://pastebin.ubuntu.com/22928/ (gcc is among them)
[19:30] <kirkland> slangasek: pitti: hiya, pam+debian_policy question for you......
[19:30]  * slangasek hides under a pile of SRU paperwork
[19:31] <kirkland> :-)
[19:31] <kirkland> slangasek: shall i just email you and you can respond in due time?
[19:31] <slangasek> depends, how deep of a question is it? :)
[19:32] <kirkland> slangasek: i think it's the typical one where i say, "hey i have a way to do $foo", and you say, "nope, that way to do $foo is highly illegal" and you bop me over the head with a whack-a-mole padded bat
[19:32] <slangasek> oh, ok - we can do that on IRC then :-)
[19:33] <kirkland> slangasek: i'd like to know the best way to echo "auth required pam_ecryptfs.so unwrap" >> /etc/pam.d/common-auth && echo "password required pam_ecryptfs.so" >> /etc/pam.d/common-password
[19:34] <slangasek> kirkland: ... by not doing so ;)
[19:34] <kirkland> slangasek: i think that debian policy would forbid me from modifying those files in the ecryptfs pam package
[19:34] <slangasek> yes
[19:34] <slangasek> jdstrand has a package that lets users enable particular pre-formed pam profiles
[19:35] <kirkland> slangasek: interesting, okay, so it absolutely has to be a manual operation by the administrator?
[19:35] <slangasek> I have a plot to reorganize how /etc/pam.d/common-* are managed, which I hope to implement in time for intrepid but this is still up in the air
[19:35] <mathiaz> kirkland: slangasek is refering to the auth-client-config package
[19:36] <slangasek> also, the trivial >> here may not work as expected
[19:36] <kirkland> slangasek: sure, that was for irc-simplicity only
[19:36] <slangasek> ok :)
[19:36] <kirkland> slangasek: the shell script i have greps and seds things around to make sure it gets put in the right place in the stack, that there aren't more than one, etc.
[19:36] <kirkland> slangasek: but it's no where close to being acceptable
[19:37] <slangasek> right, to know what the right place is in an arbitrary stack, you basically need all the information you don't have yet because I haven't done my config rewrite
[19:37] <slangasek> hmm, maybe I could get the design for this fleshed out to where I could pawn the implementation off on you? :)
[19:38] <kirkland> slangasek: :-)  perhaps.........
[19:39] <slangasek> since you seem to have a fetis^W affinity for hard PAM problems ;)
[19:40] <kirkland> slangasek: ugh, yeah, seems that way lately, doesn't it?
[19:42] <ion_> Ew, my fonts became blurry after a fontconfig update. It doesn’t seem to recognize lcdfilterlegacy anymore. :-(
[19:44] <kirkland> mathiaz: okay, thanks for the pointer, i'll go look at auth-client-config
[19:51] <ogra> slangasek, not getting -nsc and -geod in will cost us a lot LTSP users
[19:52] <ogra> (we are the leading distro here, and slowly lose out on others due to not supporting the most commonly used X server since gutsy)
[19:53] <slangasek> ogra: and therefore I should compromise the integrity of the SRU process to shoehorn in a last-minute, badly-done update with no justification given for part of the changes?
[19:53] <ogra> slangasek, a lot of people have tested the packages from Q-Funks PPA and i doubt you can introduce a regression for something that didnt work at all before
[19:53] <slangasek> where does it say that the nsc package didn't work before?
[19:54] <slangasek> that's not written in the SRU bug log, in the changelog, or in the patch header
[19:54] <ogra> slangasek, well, i was hoping it would turn out good in the end, i have a good bunch of users waiting for the 8.04.1 CD for building their new LTSP
[19:54] <slangasek> it says that there's one particular PCI ID that nsc wrongly claims to support
[19:54] <slangasek> I'd be fine if dropping that ID was the only change being made
[19:54] <ogra> geode was completely borkesd since mid of the gutsy cycle
[19:54] <slangasek> I'm not talking about geode.
[19:55] <ogra> nsc and amd as well afaik
[19:56] <slangasek> I still need to review the geode SRU; this one is already in -proposed, and is well on its way - if there are any issues with it, we're better off fixing those now and following through on that SRU
[19:56] <ogra> anyway i just wanted to raise that to your attention ... the decision is yours indeed and i largely agree with you but still am sitting between the chairs here
[19:56] <slangasek> but the nsc upload is not ok to shove in at the last minute
[19:56] <slangasek> not without a more substantial justification, and more substantial evidence that it doesn't regress anything
[19:57] <sbeattie> ogra: it'd be useful if your users could try out the packages and report feedback on the bugs.
[19:57] <sbeattie> (packages in -proposed, that is)
[19:58] <ogra> sbeattie, well, they have systems in production ... people with ltsp test envs are very rare
[19:58] <ogra> and most of them still run feisty because of that breakage
[19:58] <sbeattie> yet they're willing to run a PPA?
[19:59] <slangasek> sbeattie: the package at issue here is one I'm not accepting into -proposed, because it's been uploaded well after the 8.04.1 freeze
[20:00] <slangasek> the -geode package is fine - it looks like it just needs a minor review, another short round of verification, and then a push into -updates; it's the -nsc driver package that's the problem
[20:00] <sbeattie> oh, okay, I'll shut my mis-informed mouth, I assumed this was about bug 219630
[20:00] <slangasek> bug #214119
[20:00] <ogra> sbeattie, it is
[20:00] <ogra> they are both related
[20:00] <slangasek> er, no - you're right, bug #219630 :)
[20:01] <ogra> its pretty much the same
[20:01] <slangasek> 219630 is the one requesting the nsc SRU
[20:01] <ogra> but Koolu is even worse, they ship ubuntu by default and already had probs in gutsy
[20:01] <ogra> and they used to promote us loudly
[20:02] <ogra> not anymore though (even though they still ship with ubuntu afaik)
[20:02] <slangasek> and the fix for that is already in -proposed and on track for inclusion in -updates, so I don't see that there's a problem there
[20:02] <ogra> yeah, thats geode ...
[20:04] <jdstrand> kees: interesting, updated dchroot on ronne worked fine
[20:08] <sbeattie> ogra: feedback for the -geode would still help it get out the door.
[20:08] <ogra> sbeattie, i thought geode was ok already ?
[20:11] <slangasek> I see that the -geode one is already verification-done, and was planning to copy it toda
[20:13] <sbeattie> Oh, okay
[20:13]  * sbeattie wishes tags could be applied to individual tasks rather than only just to bugs as a whole.
[20:17] <kees> jdstrand: hmpf :(
[20:17] <jdstrand> kees: yeah, bit of a head scratcher
[20:17] <jdstrand> kees: feels like a schroot thing
[20:27] <Q-FUNK> slangasek: please see my comments to bug #219630.  I'm really sorry that the fix got so complex, but it involved fixing 3 packages at the same time, plus packaging a new upstream to fix hardware issues.  not an easy task for anyone to handle.
[20:28] <slangasek> Q-FUNK: "avoid PCI ID conflicts in X.org at all cost" - why?  does X crash horribly when it encounters this situation, or does it just pick one of the drivers?
[20:29] <Q-FUNK> slangasek: so far, it seems to simply fail to launch.
[20:29] <slangasek> mm, yuck
[20:30] <Q-FUNK> whether this is because it unfortunately picks the wrong driver at random is beyond me.  I tried investigating this as much as I could and could not come up with a conclusive answer.
[20:30] <slangasek> which PCI IDs are conflicted over, by which sets of drivers?
[20:30] <slangasek> bryce: ^^ do you know the answer to the above, regarding Xorg's behavior when more than one driver tries to claim the same PCI ID?
[20:30] <Q-FUNK> slangasek: it mainly is xserver-xorg-video-nsc that claims ID numbers for hardware covered by -cyrix and -geode
[20:31] <slangasek> ok, but only one of these PCI IDs that you're fixing up in NSC is the -geode ID, right?
[20:31] <slangasek> and the others are covered by cyrix, which so far has had no discussion in the bug log of regression testing
[20:32] <Q-FUNK> to make a long story short, the hardware changed owner 3 times and some legacy (unused) code remains from cyrix time in both -nsc and -geode.  my package of -geode skipped these right from the start, but -nsc kept them.
[20:32] <slangasek> I accept that dropping those PCI IDs from nsc is correct for intrepid, but there are a whole swath of problems with dropping them in an SRU that I don't think have been addressed yet
[20:33] <Q-FUNK> right, because cyrix is presumed to correctly handle cyrix hardware already.
[20:33] <slangasek> which packages support the chips with the 0x1078 vendor ID?
[20:33] <bryce> heya
[20:33] <Q-FUNK> cyrix
[20:33] <slangasek> ok
[20:33] <Q-FUNK> but nsc laso has them, though unused
[20:34] <slangasek> see, "presumed" is why this is a problem, when it would have to be pushed on such short notice that there's no real opportunity for testing
[20:34] <Lightkey> cyrix 686, yay!
[20:34] <Q-FUNK> the main issue is with debian's point and shoot way of generating PCI ID lists.  matching every PCI vendor with every PCI device found in the source code generates false positives.
[20:34] <Q-FUNK>   this is why -nsc needs to be fixed, tlo clear the room for cyrix and geode to claim their hardware.
[20:34] <slangasek> if you updated the nsc SRU to /just/ change the geode ID, I would be willing to accept that
[20:35] <bryce> slangasek: I believe that the behavior with multiple drivers claiming the same id is undefined
[20:35] <slangasek> bryce: well - should it use a random driver, or just fall flat on its face...?
[20:36] <Q-FUNK> I have access to nsc and geode (amd) hardware.  removing the conflicts fixes the behavior. I get X.  without removing those conflicts, I don't.
[20:36] <ogra> i just heard in fedora it does the latter
[20:36] <slangasek> if the answer is "use a random driver", then we've got a fair amount of regression potential with this SRU
[20:36] <slangasek> if the answer is "fall flat on its face", we have a much more critical bug to weigh that against
[20:36] <bryce> slangasek: I would expect that it uses a random driver, but this isn't something I've experimented with so I don't know for certain
[20:36] <slangasek> Q-FUNK: yes, and I'm ok with getting that fixed, for the hardware where it's been tested
[20:37] <slangasek> it's the change in behavior for hardware that hasn't been tested that bothers me
[20:37]  * bryce nods
[20:37] <Q-FUNK> slangasek: in that case, it mostly involves moving one claimed ID from the -nsc to the -geode driver.  versioned conflict needed in -geode against older -nsc packages.
[20:38] <slangasek> among other things, consider the case of a user with a trimmed-down set of packages installed - they know they're using -nsc (even though their chip is Cyrix), so they only have -nsc installed, not -all.  Now they upgrade, and their chip is no loner supported.
[20:38] <slangasek> s/loner/longer/
[20:38] <Q-FUNK> I agree that lack of testing for cyrix hardware could be a gamble. however, most thin client hardware out there uses either nsc or geode(amd) Geodes.
[20:38] <slangasek> Q-FUNK: ok.  Can we try the -nsc NMU again, with only the change for the geode PCI ID?
[20:38] <slangasek> er, s/NMU/SRU/
[20:39] <slangasek> the cyrix stuff, from what I'm hearing, can reasonably be postponed until after 8.04.1, when we can get proper regression testing
[20:39] <Q-FUNK> slangasek: do you also want us to revert debian's build script changes, on aspects where it doesn't involve shipping a fixed static nsc.ids list?
[20:39] <slangasek> Q-FUNK: that is definitely my /preference/
[20:40] <slangasek> since it means less time that I have to spend trying to understand those changes
[20:40] <Q-FUNK> it could be done if needed, but I'm the wrong guy to do it, as I cannot make ends or tails of the XSF scripts. that's how I ended up choosing CDBS to package -geode, way back.
[20:41] <Q-FUNK> bryce: do you think you could look at my last debdiff and skim it into just shipping a different nsc.ids then?
[20:41] <calc> slangasek: do we have a meeting today at normal time
[20:41] <calc> slangasek: i didn't see an email about it this week
[20:41] <bryce> calc: afaik we do
[20:42] <calc> bryce: ok
[20:42] <bryce> calc: it may be a short one though
[20:42] <calc> ok
[20:42] <bryce> Q-FUNK: ok I can do that for you - link me to the debdiff again plz?
[20:42] <Q-FUNK> slangasek: so, beyond the trimmed down delta for -nsc, are my latest debdiffs for -geode and -all suitable for SRU for 8.04.1 ?
[20:43] <Q-FUNK> bryce: starting at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/219630  grab http://launchpadlibrarian.net/15556613/debdiff_2.8.3-2_to_2.8.3-2ubuntu1.txt
[20:44] <slangasek> Q-FUNK: I believe that the only debian/ changes that need to be kept are the ones to debian/control; everything else should be cosmetic with respect to this particular patch
[20:44] <Q-FUNK> slangasek: adding the Conflicts I had forgotten in -geode against -amd, that is.
[20:45] <Q-FUNK> slangasek: ok, fair enough.
[20:45] <slangasek> the geode/all stuff looks good to me, but I'm still digesting parts of it
[20:45] <Q-FUNK> bryce: can I count on you and tjaalton sanity-chekcing all 3 debdiffs -just to be on the safe side?
[20:46] <bryce> tjaalton is on vacation
[20:47] <Q-FUNK> slangasek: the -all part is just to make xserver-xorg-video-all Depends on xserver-xorg-video-geode instead of ﻿﻿ xserver-xorg-video-amd.  this should have already been done in 8.04.0, but we forgot to do it on time.
[20:47] <slangasek> right.  -amd is currently a transitional package, correct?
[20:48] <Q-FUNK> it mostly exists to allow orphaners to drop the transitional package, including possible symbolic links included in older -amd transitional packages that were meant to provide backward-compatiblity for people wiht a static xorg-conf containing "amd" as the driver, but which don't work on debian derivative.s
[20:48] <Q-FUNK> yup
[20:48] <slangasek> I thinkk I'm also confused by the changelog for xserver-xorg-video-geode 2.9.0-1ubuntu2.1
[20:48] <Q-FUNK> 2.1 or 2.2 ?
[20:49] <slangasek> "Removed the GX model's PCI ID from geode.ids to fix LTSP usage case." - is that the same PCI ID that's now being dropped from nsc?
[20:49] <slangasek> or a different one?
[20:49] <Q-FUNK> same
[20:49] <slangasek> so... it's being dropped in both places?
[20:49] <Q-FUNK> we had to temporarily drop it, until -snc was fixed
[20:49] <Q-FUNK> it's back in 2.2
[20:49] <slangasek> ah
[20:49] <slangasek> the 2.2 changelog doesn't mention this
[20:49] <Q-FUNK> hence the versioned conflicts in -geode
[20:49] <Q-FUNK> no?
[20:50] <slangasek> +xserver-xorg-video-geode (2.9.0-1ubuntu2.2) hardy-proposed; urgency=high
[20:50] <slangasek> +
[20:50] <slangasek> +  * Removed the transitional symbolic links for amd_drv.so (LP: #219630).
[20:50] <slangasek> that's the whole changelog
[20:50] <Q-FUNK> argh
[20:50] <Q-FUNK> forgot to mention that
[20:50] <Q-FUNK> the whole cherry-picking method involved in making an SRU has been a hard one on me
[20:51] <Q-FUNK> my debian packages have the whole story, rather than one single line refering to an LP bug as used in SRU
[20:51] <slangasek> if you have time to prepare a 2.2 with a fixed changelog, that would definitely be appreciated too; changelogs are important so users know what's changed, not just so the SRU team does
[20:51] <bryce> (and do de-confusify fellow packagers)
[20:52] <Q-FUNK> slangasek: I initially had that.  pitti suggested that having a multiple-line changelog was unacceptable for an SRU.  he suggested that I should instead rewrite this into a sigle line that closes an LP bug.
[20:52] <slangasek> actually, that's not what pitti meant
[20:52] <Q-FUNK> no?
[20:52] <slangasek> I know that's what he seemed to say :)
[20:52] <Q-FUNK> :(
[20:53] <Q-FUNK> well, ok. misunderstandings do happen
[20:53] <slangasek> what he meant was that the SRU should condense the changes into an entry for a single version
[20:53] <Q-FUNK> especially when trying to make sense of changes in 3 packages, plus a new upstream, to fix one single issue, handled by a part-time maintianer.
[20:53] <slangasek> instead of incorporating, verbatim, the changelog entries for other versions that aren't being uploaded in an SRU
[20:54] <Q-FUNK> ah
[20:54]  * Q-FUNK bangs head
[20:54] <ogra> forcing a single line changelog would be insane :)
[20:54] <Q-FUNK> ok, that's a bit more clear now.
[20:54] <Q-FUNK> heh :)
[20:55] <ogra> my ltsp SRU fixed ten bugs ... that would have been a looong line :)
[20:55] <bryce> ogra, well if you omit spaces and vowels maybe?
[20:55] <Q-FUNK> :D
[20:55] <ogra> heh
[20:55] <Q-FUNK> guys, I appreciate everyone's sense of humor, especially in moments like these
[20:55] <Q-FUNK> this has been a though bug to tackle
[20:56] <bryce> yeah
[20:56] <Q-FUNK> it at least lightens the mood :)
[20:56] <stgraber> ogra: "Fix LTSP (LP: xxx, LP: xxx, LP: xxx, ...). You see, it's not that hard :)
[20:56] <stgraber> ok, not likely to be accepted :)
[20:56] <ogra> yeah :)
[20:57] <Q-FUNK> slangasek: anyhow, if it's ok with you, starting with approving that -all change to drop the transitional package would be a good start.
[20:57] <slangasek> yes, that one is straightforward
[20:58] <Q-FUNK> slangasek: then, with bryce's help, we'll skim -nsc and re-submit.
[20:58] <slangasek> ok
[20:58] <slangasek> will you have time to redo the changelog for -geode?
[20:58] <Q-FUNK> as for -geode, was it ok as such (adding the forgotten Conflicts) ?
[20:59] <Q-FUNK> ööö... i might get around it tonight.  it's already  23:00 here, mind you.
[20:59] <slangasek> the changelog at present is definitely misleading, but if you won't have time to fix it then I'd rather accept it today as-is than wait another day on this
[20:59] <Q-FUNK> thankfully, it's only a one-line addition
[20:59] <slangasek> OTOH, I can afford to wait until you fall asleep to see if you get it done :)
[21:00] <Q-FUNK> ok, then let's get it in. as long as both -nsc and -geode get in at the same time, we'll at least fix the PCI ID conflicts and send -amd into oblivion for good.  that would already be something good.
[21:01] <slangasek> hrm; the transitional symlink is dropped from -geode, but not added to -amd
[21:01] <Q-FUNK> slangasek: can I review the resulting packages from hardy-proposed tomorrow morning and let you know if I notice anythign fishy, before they get pushed into hardy-updates?
[21:02] <slangasek> that means the package description is also wrong, because it says "If you are using a static xorg.conf, edit the Device section and change the Driver value from "amd" to "geode" before purging this package"
[21:02] <slangasek> apparently it should say, edit the Device section before /installing/ this package. ;)
[21:02] <slangasek> Q-FUNK: oh, yes, the packages certainly wouldn't be pushed to -updates that soon
[21:02] <Q-FUNK> slangasek: right. it initially migrated to -amd, but was dropped entirely,  because it creates a whole mess on debian derivatives.  I replaced that with a notice in -amd's Description, advising people to upgrade their static xorg.conf if they have any to use "geode".
[21:03] <Q-FUNK> sync :)
[21:03] <slangasek> Q-FUNK: then perhaps s/ before purging this package// ?
[21:03] <slangasek> since it's not the purging that will break their static xorg.conf
[21:03] <Q-FUNK> "before" rather than "after" sounds good,
[21:03] <slangasek> ok
[21:04] <Q-FUNK> indeed. it's the fact that calling "amd" will produce a dead screen, since there's no such driver anymore.
[21:04]  * Q-FUNK writes himself a TODO
[21:05] <slangasek> it does seem to me that it would be better to include this symlink in the transitional package
[21:05] <Q-FUNK> I used to have it, but it disrupts operation in LTSP
[21:06] <slangasek> if 8.04.1 doesn't install the -amd package (by fixing -all), then it shouldn't disrupt anything
[21:06] <slangasek> whereas the users who have it installed presumably would like things to actually be compatible...
[21:06] <Q-FUNK> if you look at -geode's changelog at debian, I initially moved the symbolic link from -geode to -amd, to make it purgeable. that wasn't enough.  in practice, for as long as two drivers (because of the symbolic link, I guess) claim the hardware, X barfs.
[21:07] <slangasek> ah :/
[21:07] <slangasek> ok
[21:07] <Q-FUNK> that's how i ended up entirely removing the symbolic link.
[21:08] <Q-FUNK> I don't think that there's any ideal way to get people upgrading from << hardy to get their static xorg.conf (if any is used) fixed automagically upon upgrade.
[21:09] <Q-FUNK> or well... I supposed that some postinst sed script could do it, but I find this too scary to rely upon.
[21:10] <Q-FUNK> not being a 'sed' guru, i didn't dare attempt it.
[21:10] <slangasek> yeah... I would dare
[21:10] <slangasek> half the sed evil in the xorg package is my handiwork
[21:10] <slangasek> but it's a little late for that now
[21:10] <bryce> aha!!
[21:11] <bryce> ;-)
[21:11] <bryce> slangasek: I run into your name in the randomest places :-)
[21:11] <slangasek> yeah, funny that
[21:12] <bryce> once I got sick of the silly default names in the game Pioneers, so I patched it to use the names from AUTHORS
[21:12] <slangasek> hahaha
[21:12] <bryce> lo and behold, I fire it up and there I'm playing against you!
[21:12] <Q-FUNK> this being said, patches are welcome.  besides, this would be double-useful as, later this autumn, -geode is supposed to merge back GX1 support and supersede -cyrix and -nsc.
[21:12] <Q-FUNK> it could be fun to parse xorg.conf for either one and upgrade it for the user.
[21:12] <Q-FUNK> however, this would break dexconf configuralibty, since it becomes a manually hacked xorg.conf too.
[21:13] <Q-FUNK> typos r us
[21:13] <bryce> hmm, next time I volunteer for an autoconf cleanup task, someone shoot me first ;-)
[21:14] <Q-FUNK> does a vintage soviet AK47 from a military surplus store suit you? :-P
[21:14] <Q-FUNK> ok, I better head home here.
[21:14] <bryce> that'd be great
[21:15] <ogra> Q-FUNK, well, by authmn this year we shouldnt have any xorg.conf anymore
[21:15] <ogra> *autumn
[21:15] <Q-FUNK> slangasek: thanks for the SRU run-trough.  hopefully, we'll have this fixed within the next few hours.
[21:15] <Q-FUNK> bryce: and thanks for helping out.  it's immensely appreciated.
[21:16] <slangasek> Q-FUNK: sure; thanks for persevering :)
[21:16] <ion_> ogra: Yay
[21:17] <Q-FUNK> it's been an... interesting ride.  I never got around doing any security release at debian for any of my packages, so this SRU is the closest thing I've ever seen to live fire.
[21:17] <Q-FUNK> and trying to keep track of changes in 3 packages was a nice peice of mental  gymnastics.
[21:17] <Q-FUNK> anyhow, 'night everyone :)
[21:18] <bryce> cya
[21:20] <bryce> autoconf is one project I'd actually like to see slow *down*.  some of these changes are fairly gratuitous
[21:22] <slangasek> calc: <popping the stack> yes, I believe we are to have a meeting today at the normal time :)
[21:24] <slangasek> mumble, previous unverified xorg SRU sitting in -proposed for a month
[21:24] <bryce> I think cjwatson's just been uber busy catching up on administrivia
[21:27] <tjaalton> bryce, slangasek: howdy! IIRC the xserver will pick the first driver to support the ID in alphabetical order
[21:27] <bryce> tjaalton: heya!  ok thanks, I wondered if that might be the case
[21:27] <slangasek> tjaalton: hmm, then I wonder why nsc gives problems, g < n :)
[21:27] <bryce> although it makes me wonder why nsc would mess things up, since amd and geode are alphabetically higher
[21:27] <tjaalton> hum, right
[21:32] <tjaalton> actually, by looking at the patch 03_auto_load_driver.diff, IIUI, the _last_ driver to support it would end up being used
[21:32] <slangasek> ah, that makes sense then :)
[21:32] <bryce> reverse alpha.  good to know
[21:33] <bryce> cd /usr/share/xserver-xorg/pci/ ; cat *.ids >> voodoo.ids ; echo "Bwahahahaha"
[21:34] <tjaalton> hehe
[21:34] <tjaalton> *boom*
[21:39] <bryce> slangasek: hum, this is weird, the -nsc package in hardy includes a patch that doesn't actually seem to apply
[21:40] <slangasek> awesomesauce
[21:40] <slangasek> it doesn't seem to /be/ applied, or it tries to apply it and fails...?
[21:40] <bryce> it tries to apply it, but it's already been applied to src
[21:40] <slangasek> whee
[21:41] <bryce> er, something like that.
[21:41] <bryce> anyway, this makes the debdiff finally make sense, I'll get it fixed up.
[21:41]  * ogra hugs bryce 
[21:42] <ogra> ths issue has gone on far to long for that little set of changes thats actually needed
[21:45] <bryce> ogra, it's certainly been a learning experience all around
[21:45]  * ogra hopes so 
[22:07] <cjwatson> bryce: correct; if it's a short meeting tonight, I shall be happy :)
[22:27] <bryce> slangasek: am I correct in that since -nsc is 1:2.8.3-2 in hardy currently, this new upload should be versioned as 1:2.8.3-2ubuntu0.1 ?
[22:33] <bryce> slangasek: anyway I'm guessing yes.  I've finished the packaging
[22:34] <bryce> one last time doublechecking everythign and then I'll upload to hardy-proposed
[22:36] <bryce> slangasek: uploaded
[22:36]  * ogra appluds
[22:36] <ogra> or so
[22:37] <bryce> ogra if you have means to test, it would be mucho appreciated
[22:38] <ogra> i need to dig up the DBE60 thincan i got from martin and set that up for testing, not tonight anymore, but i can give it a go tomorrow
[22:38] <bryce> that'd be great
[22:39] <ogra> should we ping cr3 to trigger someone to test it on koolu ?
[22:39] <liw> does anything in Ubuntu care about Standards-Version in debian/control?
[22:39] <bryce> ogra yeah good idea
[22:39] <bryce> liw not afaik
[22:39] <slangasek> bryce: xserver-xorg-video-nsc/1:2.8.3-2ubuntu1, yes please :)
[22:39] <ogra> liw, the developer after you who has to merge mnually just for the standards change ...
[22:40] <ogra> but nothing apart from that :)
[22:40] <ogra> oh, and lintian
[22:40] <cr3> ogra: what's up dude? xserver-xorg-video-nsc? what would you like me to test exactly?
[22:40] <liw> ogra, well, I'm asking to decide whether to merge the Standards-Version from Debian or to keep the one in Ubuntu :)
[22:40] <ogra> cr3, hardy-proposed
[22:41] <ogra> liw, if its only for the sake of updating the standards i wouldnt ... if its one change among others i would
[22:42] <ogra> generally if its standards only that should be done in debian and be synced imho
[22:42] <liw> ogra, of course
[22:43] <bryce> slangasek: ok well you got 2ubuntu0.1 in there, I hope that's ok
[22:43] <liw> this is part of a larger set of changes; I didn't want to bump the S-V in Ubuntu if Ubuntu follows an older version of policy
[22:43] <ogra> cr3, bottom line is "shuld all work"
[22:43] <bryce> cr3: I've just uploaded a fix to make hardy installable and functional on geode hardware
[22:43] <bryce> cr3: so we would encourage re-running your tests on any geode hardware you have and verify that X now works on them.
[22:46] <cr3> ogra: should it be tested in both desktop and ltsp mode?
[22:47] <ogra> indeed :)
[22:47] <ogra> do you have a thincan ?
[22:48] <cr3> ogra: yep
[22:48] <ogra> ah, well then there too
[22:48] <ogra> i'll test it myself tomorrow on ltsp
[22:49] <cr3> I'll have to test it tomorrow as well
[22:59] <cjwatson> liw: I'd second ogra, just sync S-V with Debian; I'd go so far as to say that S-V should never be changed in Ubuntu unless you are completely repackaging from scratch
[22:59] <liw> yep
[23:00] <cjwatson> liw: the notion of following a version of policy has always been a bit sketchy in Debian anyway - it's really more for the maintainer to say "yup, I've checked up to here"
[23:00] <cjwatson> so it's kind of a bizarre thing to bump :)
[23:00] <liw> yeah, that's what Debian uses it for; I find it useful for myself, to verify against the upgrading list
[23:01] <slangasek> bryce: 0.1 is probably more proper anyway; ubuntu1 was just what had been in the -proposed queue before
[23:02] <bryce> oh, I didn't spot that
[23:03] <cjwatson> liw: *nod*
[23:19] <slangasek> bryce: um, ok; on this 0.1 you've uploaded for nsc, you're still disabling the cyrix PCI IDs, which I explicitly requested not be done in this round due to timing relative to the point release
[23:22] <bryce> slangasek: er, guess I didn't catch that.
[23:23] <bryce> I gathered Q-FUNK simply wanted all the autoconf junk straightened out
[23:23] <bryce> are there any other changes?
[23:23] <slangasek> bryce: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/219630/comments/50
[23:24] <slangasek> straightening the autoconf junk is appreciated, but it's the cyrix change that I consider the blocker due to our inability to regression-test here
[23:24] <slangasek> ScottK: do you have any interest in taking care of the libselinux/libsepol merges, by change?
[23:24] <slangasek> s/change/chance/
[23:27] <ScottK> slangasek: No.  I thought tresys and manoj were going to work so sort stuff out.
[23:27] <ScottK> Without help from them, I'd be tempted to sync and go from there.
[23:28] <slangasek> oh, is that not done yet? :/
[23:29] <bryce> slangasek: ok I see, Q-FUNK had said he was uncomfortable doing the cleanup of the XSF scripts and asked if I would "skim it just shipping a different nsc.ids then" which is what I did.  I assumed the debdiff he gave me was correct other than that.
[23:30] <bryce> *sigh* this is like the sru from hell.  one sec I'll fix it.
[23:31] <ScottK> slangasek: I've ping'ed them a couple of times on #ubuntu-hardened and gotten nods, but no action.
[23:31] <ogra> bryce, well, its intresting to see how it melts down to a handfull of lines once *you* touched it
[23:32] <slangasek> ScottK: well, I'm aware that Manoj has integrated at least some of their changes; maybe a sync wouldn't be the worst outcome
[23:33] <ScottK> It would at least get us rebased from Debian and then we can adjust from there.
[23:34] <bryce> ogra, yeah well it would help if I'd learn to read
[23:34] <ogra> ah, come on you fixed the probelm in 1h while th ebug goes back and forth since 3 months or so
[23:34] <bryce> slangasek: so should this be ubuntu0.2 or ubuntu2?
[23:35] <ogra> without any proper outcome ...
[23:37] <slangasek> bryce: ubuntu0.1
[23:37] <slangasek> bryce: you get to reuse the number because I'm not letting this other one into the light of day ;)
[23:38] <bryce> aw
[23:38] <bryce> ok, so I just need to figure out what the cyrix pciid is.  hmm
[23:39] <slangasek> bryce: it's the line that's been commented out in Makefile.am in the patch
[23:39] <slangasek> this patch disables registration for all devices with cyrix as the vendor ID
[23:40] <bryce> so is the change just uncommenting that line?
[23:40] <slangasek> I believe so
[23:40] <bryce> ok that should be trivial
[23:40] <bryce> however I notice they also reshuffled the ordering
[23:40] <bryce> I'll check if that's significant
[23:47] <calc> bryce: ping
[23:48] <calc> bryce: Benjamin Drung seems to have tested the various methods and it didn't work for him, so he sounds like a good candidate for the new debs
[23:48] <calc> https://bugs.launchpad.net/~bdrung
[23:50] <bryce> ok cool, would you like to ask him to test with that libx11 patch (since you've been the contact on that bug so far), or shall I?
[23:51] <calc> bryce: it would probably be better if you did so if he has questions it would be to the person who has a clue ;-)
[23:51] <calc> i still don't have any idea why it seems that users that have this problem don't have the problem under a new user account, even removing .openoffice.org2 dir doesn't help them
[23:52] <calc> but hopefully removing xcb will help out
[23:53] <calc> they mention removing gtk/gnome ooo addon helps fix the problem so maybe there is a messed up file somewhere in gtk/gnome settings
[23:53] <calc> but i have no idea where to even begin looking in there
[23:54] <bryce> calc, ok will do - hang on a bit though I'm multitasking on a few things
[23:54] <calc> ok np
[23:55] <bryce> yeah the xcb issue seems to be one that gets exposed via race conditions with multiple things trying to get a lock
[23:55] <bryce> that sort of thing can exhibit itself and then go away under very oddball conditions
[23:56] <bryce> like cody found that just delaying when gnome-screensaver starts up suppressed the issue
[23:58] <cody-somerville> bryce, I think it was the two dbus-launch processes attempting to launch session buses at roughly the same time.
[23:59] <cody-somerville> gnome-screensaver uses dbus and would make a dbus call resulting in dbus-launch --autolaunch because we xfce4 (whom use xscreensaver by default) has dbus-launch --sh-syntax --exit-with-session after the launch of the screensaver (and ssh-agent)