[00:00] <slangasek> (other than a question of the distribution of developer time)
[00:04] <superm1> slangasek, there have been a number of failures (not reported to the tracker though)
[00:04] <superm1> slangasek, i'm attempting to see how difficult fixing some of them are.  if it's not doable today, then we'll be skipping A4
[00:04] <slangasek> superm1: ok
[00:05] <Adri2000> slangasek: ok. then the sooner it's in debian unstable and synced to jaunty the better. when do you think it could be uploaded to debian?
[00:06] <slangasek> Adri2000: I don't know, not having looked at it at all yet.  Maybe within the week if left up to me; I can't speak for any of the comaintainers
[00:07] <Adri2000> ok
[00:17] <calc> is there a way to pad a number in shell, eg seq 000 150 and have the numbers show as 001, etc ?
[00:18] <directhex> yes
[00:18] <directhex> -w
[00:18] <calc> thx!
[00:18] <directhex> jms@destiny:~$ seq -w 99 100
[00:18] <directhex> 099
[00:18] <directhex> 100
[00:19] <directhex> and so to bed
[01:59] <freazer> Hi, I need some help with mdadm and update-initramfs, can anybody point me to a channel [on another server if necessary] that can help? my dpkg is completely crippled because it thinks a raid device is missing
[04:35] <d-b> hi i'm not 100% sure of the current status of reporting bugs in launchpad. but last time my friend had an issue he had to login to launchpad to report it (8.10), is this the case and if so would it not be possible to send bugs for users without a launchpad id to another place, like a mailing list ?
[04:39] <LaserJock> d-b: I think the ubuntu-users list has been used for that in the past. I'm not sure though if that's the current recommended process
[04:40] <d-b> LaserJock: ok. but can a user report bugs there atm via the gui bug reporting interface ?
[04:41] <LaserJock> d-b: I don't think so
[04:41] <d-b> LaserJock: do i add this as a wishlist item ?
[04:41] <d-b> and if so where should i best do this
[04:41] <LaserJock> I'm not sure
[04:42] <LaserJock> I think generally we discourage people from using the mailing list
[04:42] <LaserJock> it should be more of a last resort I'd think
[04:42] <d-b> still where should i propose this ?
[04:43] <lifeless> you should start with a discussion, perhaps on the forums, or the ubuntu development mailing lists
[04:44] <lifeless> either MOTU or -devel, probably -devel though the topic lines are a bit grey
[04:44] <LaserJock> -devel would be the most general
[04:44] <lifeless> *if* you get a consensus forming filing a bug on launchpad is appropriate, but honestly, I don't think this is percieved as a problem by the community.
[04:44] <lifeless> Its pretty nice not having spam come in as new bug reports on packages, and knowing you can contact the users that filed reports.
[04:45] <d-b> lifeless: right but there is a group of users who do have a launchpad account and might not want to sign up for one.
[04:45] <d-b> its just the extra effort that they might not want to go to after gnumeric  or oo.o crashes with their work...
[04:46] <LaserJock> d-b: sure, but generally those bugs aren't going to be very useful
[04:46] <johanbr> I don't thin kthere is a problem with a dearth of bug reports.
[04:46] <lifeless> d-b: you are asserting that this group is sufficiently large to generate unique bug reports, and that they will go to the effort of filing the report and working with devs to get it fixed
[04:47] <lifeless> d-b: this is an unsubstantiated claim; the barrier to entry to get an lp account is nearly zero (have an email address, receive one email at it, click on a link).
[04:47] <d-b> lifeless: i do not. i assume that if the bug is not already reported and enough information is able to be reported then it might be worth receiving a bug report.
[04:47] <d-b> sure if it is not going to contain info then .. its pointless.
[04:47] <lifeless> d-b: arguing that this barrier is higher than the barrier to file and work through a bug report in the first place is pretty doubtful as an assertion
[04:48] <d-b> lifeless: right. but ok so lets consider the alternative platform... i dont' need a microsoft account to file a bug when that crashes.
[04:48] <Hobbsee> and does anything happen to those bug reports, most of the time?
[04:48] <d-b> i'm suggesting these bugs could be used differently.
[04:48] <lifeless> d-b: actually, last time I filed a bug with MS I needed a credit card with AUD 280 on it
[04:48] <d-b> Hobbsee: nothing ^^
[04:49] <Hobbsee> (the MS bug reports, i meant)
[04:49] <d-b> Hobbsee: i have no idea. all i know is the software doesn't get much better.
[04:49] <ScottK> d-b: Mailing lists make very poor bug trackers.
[04:49] <lifeless> redhat uses bugzilla, same as lp vis-a-vis accounts
[04:50] <lifeless> novell, same
[04:50] <lifeless> gentoo I haven't filed bugs on
[04:50] <lifeless> gnome use bugzilla, needs an account too
[04:50] <ScottK> Same with KDE.
[04:50] <lifeless> all of sourceforge need accounts
[04:50] <lifeless> savannah needs accounts
[04:50] <LaserJock> lifeless: sourceforge doesn't need an account to file
[04:50] <d-b> ScottK: it was just a suggestion... i agree that the use of an account is useful but perhaps if you submit a bug report and then they click on a validation email it could work better / if the gui allowed the user to sign up quickly for launchpad ?
[04:50] <lifeless> LaserJock: it doesn't?
[04:51] <LaserJock> lifeless: no, you can file as "anonymous"
[04:51] <d-b> like i'm just trying to suggest making it easier for new users to submit bugs...
[04:51] <lifeless> LaserJock: oh, eep, my bad
[04:51] <ScottK> d-b: Also, in comparison to every attempt at a bug report I ever made to Microsoft got zero repsonse.  Here stuff actually gets fixed sometimes.
[04:51] <LaserJock> ScottK: sometimes ;-)
[04:51] <d-b> ScottK: totally agree.
[04:51] <LaserJock> d-b: if we were lacking bug reports I can understand wanting to make it easier
[04:52] <lifeless> d-b: I've said my bit; talk to the larger community, get consensus. I think you'll get a resounding 'not a big issue'. We have lots of bugs
[04:52] <ScottK> d-b: If you have suggestions on improving the Launchpad signup process, you should probably discuss it with Launchpad developers in #launchpad.  We've really got no control over that here.
[04:52] <lifeless> There isn't a perception that we are missing out on important r-c bugs
[04:52] <d-b> lifeless: yeah mostly likely these would be small fidly bugs. sure.
[04:52] <lifeless> (with the number of beta users we get, that do file bugs, missing an rc bug would be a surprise)
[04:53] <ScottK> lifeless: It does seem to me that fewer people are reporting bugs.  I do think there is a problem, but not that LP accounts are too hard to get.
[04:53] <LaserJock> d-b: the problem I see with adding an "anonymous" button is that people will just be lazy and hit that generally
[04:54] <ScottK> Won't help the currenlty not to bad spam situation either.
[04:54] <LaserJock> d-b: if it actually were a "use only if you absolutely can't do a Launchpad" account I could maybe agree
[04:54] <d-b> LaserJock: well i meant like "email here" then you could have them click something in their email...(which could be used to spam people )
[04:54] <lifeless> ScottK: I think we have a bunch of issues in bug reporting and management; as I raised in the MOTU/community sessions at UDS
[04:54] <ScottK> Agreed.
[04:54] <ScottK> I just don't think this is one of them.
[04:54] <LaserJock> d-b: ok, but that's essentially the same thing as getting a Launchpad account, and an account is much more useful
[04:54] <lifeless> ScottK: but adding anonymous accounts is rather orthogonal; and adding unverified email access is just a 'please be a spam multiplier' request
[04:54] <ScottK> Yep.
[04:55] <d-b> ok. i don't think that bug sure. i agree its not that important.
[04:55] <d-b> *remove bug
[04:57] <LaserJock> considering that we're currently at over 43k open bugs I'm not all that eager to add anonymous bug filing :-)
[04:58] <Hobbsee> why not? Then one could make bug stew ;)
[04:58] <LaserJock> over 47k
[04:58] <LaserJock> hmm, and 40k of them are unassigned
[04:59] <d-b> LaserJock: and of those 7k out of interested how many are reported upstream if required...
[04:59] <LaserJock> that I have no idea
[05:00] <LaserJock> I think a decent number get upstream, probably more than are assigned if I had to guess
[05:00] <tritium> LaserJock: speaking of bugs, we want to invite you down to NM to speak to the LoCo.  Maybe we can have a bug jam.
[05:01] <LaserJock> tritium: ok, have your people call my people and set something up ;-)
[05:01] <tritium> LaserJock: roger that ;)
[05:02] <LaserJock> tritium: where is Ubuntu NM HQ?
[05:03] <tritium> LaserJock: Albuquerque is where most of our members are located
[05:03] <LaserJock> nice
[05:03] <tritium> Home of the MITS Altair.  You might say birthplace of the PC, really.
[05:04] <tritium> I won't mention that Microsoft was first headquartered here too.  Well, I guess I just did.  ;)
[05:21] <LaserJock> tritium: well, I'm glad you guys managed to kick them out
[05:48] <tritium> LaserJock: ;)
[06:33] <dholbach> good morning
[06:34] <ion_> ing
[06:35] <dholbach> hi ion_
[06:35] <ion_> What’s up?
[06:36] <dholbach> getting up, sipping my coffee and triaging my inbox - and it's snowing again Berlin
[06:36] <dholbach> how are you doing?
[06:36] <ion_> Quite okay, thanks
[06:37] <ion_> About to go to sleep. :-P
[06:37] <dholbach> :)
[07:19] <pitti> Good morning
[07:20] <pitti> cjwatson: glib pkgstriptranslations> I didn't fix it, I could never reproduce it
[07:21] <pitti> cjwatson: so I'll have another look
[07:23] <slangasek> morning
[07:23] <pitti> hey slangasek
[07:25] <slangasek> pitti: I'm working on shuffling invocation of the hotkey-setup code into modprobe.d, as we discussed; but how should this be future-proofed against the module being compiled into the kernel, or against the module being included in an initramfs?
[07:26] <pitti> slangasek: it'll still have an init script, right? maybe postinst could test whether modinfo thinkpad_acpi exists, and if not, call update-rc.d?
[07:26] <pitti> (just a hack, though)
[07:26] <slangasek> hmm, eew :)
[07:27] <slangasek> there's no way to get udev to trigger it for us? :)
[07:27] <pitti> slangasek: I think there is
[07:27] <pitti> slangasek: but I'd rather have Keybuk's advice for that
[07:27]  * slangasek nods
[07:28] <slangasek> that seems the more reliable way, though - "do this when the hardware is seen by the kernel" rather than "do this when the module is loaded"
[07:28] <pitti> slangasek: if you have a corresponding device in /sys, you can still call something on that
[07:28] <pitti> slangasek: maybe it's in fact better to write this as an udev rule in the first place, rather than a modprobe.d script
[07:29] <pitti> since that's what we actually want (based on device, not based on module)
[07:29] <pitti> slangasek: and since it gets autoloaded, it must have something in /sys that triggers it (see modinfo thinkpad_acpi|grep ^alias)
[07:30] <slangasek> sure, seen that previously :)
[07:48] <pitti> cjwatson: glib> one possible reason is that glib defines DEB_BUILD_OPTIONS_PARALLEL
[07:49] <pitti> cjwatson: and sets MAKEFLAGS; wouldn't MAKEFLAGS apply to debian/rules itself, too?
[07:51] <pitti> it has two dh_testdir etc. as well
[08:00]  * pitti asks soyuz guys
[08:08] <pitti> cjwatson: ok, now I'm pretty sure that the buildds define DEB_BUILD_OPTIONS="parallel=2" or something similar
[08:09] <pitti> however, why does this only happen for glib2.0, and not for any other package, ever?
[08:10] <pitti> ah, because it sets MAKEFLAGS
[08:17]  * scizzo- thinks that someone tried to talk to him in this channel a few days ago but irssi does not have it in backlog.... :(
[08:22] <slangasek> scizzo-: mis-tab-completion
[08:22] <scizzo-> o...right...
[08:22] <scizzo-> now I feel unimportant... :P
[08:22] <slangasek> sorry :)
[08:55] <pitti> cjwatson: ok, fixed pkgbinarymangler uploaded (with locking)
[08:59] <slangasek> pitti: autosyncing from testing grabs us 104 updates; do you want to look them over at all before I commit?
[09:00] <pitti> slangasek: I'll do some random samples, but in theory all of them should be RC fixes
[09:00]  * slangasek nods
[09:01] <pitti> slangasek: I read the changelogs from a to m, they all look sane to me
[09:01] <pitti> so thumbs up from me
[09:01] <slangasek> ack, flushing
[09:02] <pitti> slangasek: for the "eliminate/minimize acpi-support/powernowd/acpid" spec Robbie asked me to contribue to, is there already an existing blueprint?
[09:03] <slangasek> good question
[09:03] <slangasek> doesn't look like it
[09:03] <slangasek> (wiki says BLUEPRINT: TBD)
[09:03] <pitti> ok
[09:04] <pitti> slangasek: btw, HotkeyArchitectureSpec's release note says "removed acpi-support"; I don't think that's feasible, I'll update that
[09:04] <slangasek> right
[09:07] <cjwatson> pitti: yay, thanks. I suspect we'll have to delete that broken binary somehow
[09:08] <pitti> cjwatson: as soon as the new pkgbinarymangler is in the buildd chroots, I'll upload a no-change glib2.0, but I don't know how automatic/manual the buildd chroot upgrade is
[09:08] <pitti> I asked in soyuz, but nobody is really awake yet
[09:09] <pitti> cjwatson: how was it worked around last time?
[09:09] <cjwatson> SQL DELETE
[09:09] <pitti> \o/
[09:09] <cjwatson> Julian should know
[09:09] <cjwatson> buildd chroot upgrade> I don't know offhand either, ask #is maybe
[09:09] <pitti> cjwatson: we can't just reject the binaries from accepted?
[09:09] <cjwatson> but they'll probably recommend waiting for Adam to wake up
[09:09] <cjwatson> I tried that, it refuses
[09:10] <pitti> cjwatson: hm, just worked for me
[09:14] <cjwatson> curious
[09:14] <cjwatson> oh, maybe I forgot to say -Q accepted, duh
[09:14] <pitti> I just bumped the build prio of pkgbinarymangler
[09:14] <pitti> although it seems that there is a more general problem with buildds
[09:15] <pitti> none of the i386 ones grab any
[09:29] <slangasek> siretart: hum, who is Fabian Greffrath?
[09:33] <gaspa> seb128: Hi, saw your comment. I really wanted to do it but I haven't had time ( and I still need an account for bugzilla )
[09:34] <seb128> gaspa: hi, what comment? I do comment on hundred of bugs every week
[09:34] <gaspa> lol, sorry...
[09:34] <gaspa> bug #327003
[09:34] <directhex> he's a busy bunny is seb128
[09:35] <seb128> ah ok, thanks for the work on it, the screen looks good ;-)
[09:35] <dholbach> but normally seb128 remembers all the bug numbers
[09:35] <dholbach> seems like he's getting old :)
[09:35] <slangasek> haha
[09:35] <seb128> directhex: I will look at your sync requests today if nobody else is quicker
[09:35] <directhex> cool, thanks
[09:35] <gaspa> seb128: in the meantime, do you think it can be included? Or it needs review?
[09:35] <seb128> dholbach: don't worry I just got a cold, I should be back to normal in a few days ;-)
[09:36]  * directhex is a little concerned @ debian NEW delays right now. seems the ftp-master team is busy with other things
[09:36]  * dholbach hugs seb128
[09:36] <seb128> gaspa: I would prefer having comments from somebody who has a clue about all that, would it work for people who have no compositor?
[09:36]  * seb128 hugs dholbach
[09:36] <gaspa> seb128: it works for me, without compositor.
[09:36]  * directhex checks seb128's lp account, ensures he's in the dholbach-huggers group
[09:41] <slangasek> jelmer: bzr-svn 0.5.0-1 build-depends on python-subvertpy, not in the archive (Debian or Ubuntu)?
[09:42] <jelmer> slangasek, subvertpy is in NEW atm
[09:42] <slangasek> ok
[09:42] <jelmer> slangasek, there's a package in the bzr PPA
[09:42] <jelmer> slangasek, I was just talking about dholbach about the best way to get it into jaunty
[09:42] <slangasek> one that I can sync into Ubuntu, so I can sync bzr-svn? :)
[09:42] <slangasek> ok
[09:42] <directhex> jelmer, oh, the joys of uploading apps when their deps are in NEW for a few months :)
[09:42] <directhex> jelmer, we've got that problem for finishing off the mono 2.0 transition \o/
[09:43] <dholbach> jelmer: just add the link to the PPA on the bug report
[09:43] <jelmer> dholbach, will do
[09:43] <dholbach> super
[09:45] <slangasek> jelmer: and how about bzr* uploads to Debian unstable? :)
[09:54] <slangasek> jelmer: the version of python-subvertpy in Debian NEW is less than the one in the ppa; what do you think about getting 0.6.1-1 uploaded to Debian NEW, and then fakesyncing it into Ubuntu?
[09:55] <directhex> slangasek, problem is if he doesn't wait for the current one to clear NEW, then it's to the back of the queue with the new version
[09:56] <slangasek> that's not my understanding of the Debian NEW queue ordering
[09:56] <directhex> slangasek, it's my experience.
[10:00] <slangasek> seb128: eh?  it's my archive day and I'm in ~/syncs :)
[10:01] <seb128> slangasek: I did ssh, ls, noticed and closed my ssh ... ie if somebody is hijacking your syncs that's somebody else ;-)
[10:01] <slangasek> hrm
[10:02]  * pitti is innocent
[10:02] <pitti> well, at least wrt. to cluttering syncs ATM :)
[10:02] <seb128> we have 3 new people who have ssh access now, maybe we need to start being carreful with locks
[10:02] <slangasek> seb128: https://bugs.launchpad.net/ubuntu/+source/bzr-svn/+bug/325930/comments/3 - token collision or something?
[10:02] <slangasek> seb128: I was addressing you because yours was the name in the email :)
[10:02] <seb128> urg
[10:03] <seb128> how did that happened?
[10:03] <slangasek> good question
[10:03] <seb128> james_w: hello?
[10:06] <seb128> slangasek: did you run syncbugbot at all today?
[10:06] <slangasek> seb128: yes, that's what I've been using
[10:07] <slangasek> I just don't understand why I'm getting your cookie
[10:07] <seb128> slangasek: it seems you are using my launchpadid for some reason?
[10:37] <siretart> slangasek: a very nice and active contributor to pkg-multimedia.
[10:37] <siretart> slangasek: why do you ask?
[10:37] <lool> siretart: I guess because of his debian-devel@ post
[10:37] <james_w> hello seb128
[10:38] <slangasek> siretart: what lool said; a curious post citing ffmpeg as an example
[10:39] <siretart> ah, right, ffmpeg is a delicate example. we (lool, fabian and I) have been discussing 'weak' build dependencies last week and I suggested that we should raise that topic on debian-devel
[10:39] <slangasek> ah
[10:39] <slangasek> then I repeat here what I said on debian-devel: opportunistic build dependencies are a terrible idea :)
[10:39] <cjwatson> wouldn't hold your breath even if it were a good idea, that idea has been floating around for approximately a decade
[10:40] <directhex> "weak" build deps?
[10:40] <siretart> however the mess with alsa not being available on non linux arch makes the build depends line look horrible as well
[10:40] <directhex> as in build-suggests?
[10:40] <cjwatson> "install this build-dependency if it's available, but don't complain if it isn't"
[10:40] <directhex> build-recommends!
[10:40] <directhex> i like it. make it so, number one!
[10:41] <cjwatson> siretart: my recommendation would be to take the approach used by debian-installer
[10:41] <lool> I didn't know about the control fields proposal and all
[10:41] <siretart> well, in effect that is what ffmpeg needs. In multiverse there are additional libraries ffmpeg can make use of
[10:41] <cjwatson> siretart: build-deps written out line-by-line in debian/control, debian/genbuilddeps can be run manually to sync this into the actual Build-Depends line
[10:41] <lool> (I share the concerns raised on debian-devel@, but saved myself the time to word them properly since others did)
[10:42] <cjwatson> siretart: so when merging you can throw away any changes to the Build-Depends line itself and just run debian/genbuilddeps after resolving all the other conflicts
[10:42] <lool> cjwatson, siretart: Right, we have something like this in gstreamer packages
[10:42] <cjwatson> this makes it a lot easier to deal with complex build-deps
[10:42] <directhex> lool, OOo writes its own buil-deps too
[10:42] <lool> And we allow end users to add some features by rebuilding the packages with some flags
[10:42] <siretart> hm. debian/control is already generated in ffmpeg...
[10:43] <lool> cjwatson: But I guess you need to run that and upload a different source to ubuntu though
[10:43] <cjwatson> lool: yes, I don't regard that as a major problem though
[10:43] <lool> It's not, but one of the goals is to have the same source package in Debian and Ubuntu; I don't think I would mind libfaad-dev | ubuntu-minimal though
[10:44]  * slangasek chuckles
[10:45]  * lool already has some hacks for backports, I think Ubuntu could be supported here as well
[10:45] <cjwatson> aesthetically horrible but probably functional
[10:45] <directhex> cjwatson, it's a delightfully elegant hack, no?
[10:46] <lool> Let's call it pragmatic!   :-P
[10:46] <cjwatson> directhex: your notion of elegance and mine are clearly different :)
[10:46] <directhex> hacks which make you groan & go "that's horrible!" are the best kind!
[10:46]  * slangasek wails and gnashes his teeth at the elegance
[10:47] <directhex> well, not as good as the ones that make you got "oh, that's just..." at a loss for words to convey the beauty of it
[10:48] <cjwatson> my notion of elegance is closely associated with generality
[10:54] <apw> evand, ping
[10:55] <evand> apw: pong
[10:55] <apw> evand, just looking at usb-creator and i see symlinks say "need to fix this"
[10:56] <apw> wondering if you have any context on why its not enabled, security perhaps/
[10:56] <apw> ?
[10:56] <evand> vfat doesn't support symlinks, AIUI
[10:56] <apw> ahhh, its a vfat fs we make
[10:56] <apw> yeah that would break it
[10:58] <evand> the "need to fix this" comment is poorly written :).  It should say something to the effect of "does this subtly break anything?"
[10:58] <apw> well that answer to that is yes :) it breaks the alternate installer
[10:58] <apw> specificlaly the cd upgrade part, but its probabally easier to fix the way it works
[10:59] <evand> hooray
[10:59] <pitti> thekorn: good morning
[10:59] <pitti> thekorn: do you know how to entirely disable cookie caching in ~/.python-launchpad-bugs.conf?
[11:00] <evand> indeed; we're in a bit of a bind from the usb-creator perspective as we want to stick with vfat to ensure compatibility with already formatted by Windows USB disks.
[11:00] <apw> evand, yeah, not sure its sensible to try and fix it, the link thats missing is to a directory too
[11:00] <apw> so the chances of representing it are low
[11:01] <evand> ah, ok
[11:09] <thekorn> pitti, hi, I don't think there is a switch for this (yet), let me look at the code to be sure
[11:10] <pitti> thekorn: ok, thanks
[11:13] <james_w> cjwatson: https://code.launchpad.net/~james-w/ubuntu-seeds/platform.jaunty.apt-transport-https for you to review at your convenience.
[11:13] <james_w> cjwatson: it adds it as Recommends on standard
[11:14] <thekorn> pitti, hmm, no, no such option and no easy way to not write the cookies to thiss file
[11:16] <ogra> seb128, if i delete mail in my inbox my evo reliably crashes, is that known already ?
[11:17] <seb128> jaunty?
[11:18] <ogra> yep
[11:18] <seb128> there is a crasher which is known an seems to be triggered when deleting mails which have images if you have the option to load those
[11:18] <ogra> though i didnt try the delete icon in the toolbar yet ... i'm used to use the del key
[11:19] <ogra> seb128, hmm, doesnt happen with the toolbar icon
[11:19] <seb128> should not make a difference
[11:20] <seb128> it might depends of the emails
[11:20] <ogra> but it was spam that got through which included the last two times at least
[11:20] <ogra> *included pics
[11:20] <seb128> right, that's a known issue
[11:20] <seb128> it tries to load the image and you deleted those before it was done
[11:20] <ogra> ah, k
[11:21] <ogra> ah, it doesnt seem to happen if i'm fast enough (before it starts the download)
[11:21] <ogra> only if the download process actually runs
[11:21] <seb128> right
[11:21] <seb128> known issue no need to open a new bug
[11:21] <ogra> great :)
[11:28] <cjwatson> apw: we should probably just remove our reliance on that symlink. Is it just cdromupgrade? I reassigned that bug to update-manager rather than closing it ...
[11:28] <cjwatson> james_w: merged, thanks
[11:29] <james_w> thanks cjwatson
[11:29] <apw> cjwatson, yeah its still there, i was looking at fixing usb-creator, but thats not going to happen now i know the underlying reason
[11:29] <apw> will look at fixing the script instead
[11:29] <cjwatson> the dists/stable and dists/unstable symlinks are definitely legacy
[11:30] <apw> i assume those refer to the debian aliases for their releases
[11:35] <ogra> cjwatson, is  /build/config/armel/ixp4xx/netboot.cfg originally coming from debian like that (despite your recent changeds indeed) ?
[11:35] <ogra> (in d-i)
[11:37] <cjwatson> ogra: yeah
[11:37] <cjwatson> apw: right
[11:38] <ogra> weird, someone on the debian-arm ML pointed out their ernel is armeb so wouldnt need endianess swapping
[11:38] <ogra> *kernel
[11:39]  * ogra tries to find out why ours doesnt boot at all
[11:39] <cjwatson> ogra: http://bazaar.launchpad.net/~kamion/debian-installer/main/annotate/head%3A/build/config/armel/ixp4xx/netboot.cfg (though that branch needs an update)
[11:40] <ogra> right, both call devio ... strange ...
[11:42] <ogra> i can boot the kernel standalone but not from di-nslu2.bin
[11:43] <apw> is it normal for a package to require you have python-distutils-extra installed for a source build and not tell you?
[11:44] <ogra> should be in the build-deps either by itself or through a dep of something there
[11:46] <jelmer> slangasek: sorry, was away
[11:47] <jelmer> slangasek: I was waiting until squeeze before uploading to sid again, although new RC-bugs would be very unusual at this point
[11:49] <jelmer> directhex: I was under that impression as well, though I've never tried it in fear that my uploads would end up at the tail of the queue
[11:49]  * directhex REJECTs jelmer 
[11:53] <apw> mvo, seems you own update-manager, is that a direct debian sync?
[11:53] <ogra> heh
[11:53] <ogra> is u-m in debian ?
[11:54] <apw> dunno hard to tell, its one of those things where the normal" version number tell you everthing"  rule falls down
[11:55] <apw> to restate things, i have a patch for it, what do i do with it
[11:55] <apw> it behaves oddly as it claims to have a real maintainer, unlike most packages
[11:55] <cjwatson> it's maintained in Ubuntu
[11:55] <ogra> right
[11:56] <cjwatson> (in the absence of mvo telling you otherwise) either attach the patch to a bug report; or create a branch (since it's in bzr), commit your patch there, and send a merge request
[11:57] <ogra> apw, the control file should tell you about the original bzr branch
[11:58] <cjwatson> debcheckout update-manager; cd update-manager; fiddle; bzr push lp:~apw/update-manager/name-of-your-branch
[11:58] <ogra> pfft, always these advanced tools
[11:58] <apw> ahh missed the "its in bxr" whine, its simply not loud enough
[12:02]  * slangasek fixes apt to depend on figlet
[12:14] <directhex> slangasek, figlet is non-free. try toilet
[12:16] <mvo> apw: hello, what is the issue with update-manager?
[12:16] <slangasek> oh, thank you - would've been terribly embarrassing to get the wrong banner printer pulled into the base system ;)
[12:17] <apw> mvo, an issue with cdromupdate when converted to a usbstick.  symlinks get lost, it doesn't work.  simplest solution to avoid using the links.  am just pushing a bzr branch with a proposed fix
[12:18] <mvo> apw: aha, cool. just give me branch location when the push is finished
[12:18] <apw> mvo will do, its a trivial change
[12:18] <directhex> slangasek, well, putting apt into restricted would be awesome, but...
[12:19] <slavik> will evolution come with the libmapi plugin in 9.04?
[12:20] <seb128> slavik: evolution-mapi will be available, not sure if it will be in the default installation or universe though
[12:20] <directhex> evolution-mapi is the non-OWA exchange thing, yes?
[12:20] <slavik> yes
[12:20] <directhex> neato
[12:20] <slavik> it's supposed to be part of gnome 2.26
[12:20] <seb128> that's the new version using openchange
[12:20] <slavik> but it also depends on samba4
[12:20] <slavik> hence me asking
[12:20] <seb128> it's waiting for review right now
[12:21] <seb128> slavik: it will be in universe for sure
[12:21] <slavik> seb128: k, thanks ... I tried building it myself, but couldn't get it to work
[12:21] <slavik> awesome
[12:21] <seb128> there is a package available in a ppa, look to the need-packaging bug on launchpad
[12:22] <slavik> looking, heh
[12:25] <slavik> found it
[12:29] <apw> mvo, branch should be here, hopefully I handled the changelog right, let me know if you need me to change it or have any commentslp:~apw/update-manager/cdromupgrade-avoid-links
[12:30] <mvo> apw: thanks, merging now
[12:31] <mvo> apw: thanks, looks good
[12:32] <apw> mvo, cool
[12:48] <slangasek> cjwatson: can you help me understand why adding '* Extra-Exclude: libjtidy-java-doc' to ubunt.jaunty/supported doesn't appear to have affected component-mismatches?
[12:50] <directhex> woo, m-a 0.4
[12:51] <Laney> synced?
[12:51] <ogra> m-a ? who is using that in times of dkms
[12:51] <Laney> mono-addins not module-assistant
[12:51] <ogra> haha
[12:52] <ogra> yay for abbreviations
[12:52] <cjwatson> slangasek: my guess would be that it needs to be done in kubuntu.jaunty etc.
[12:52] <seb128> Laney: yes, I did the sync now
[12:53] <Laney> :D
[12:53] <Laney> and now we can sync f-spot
[12:53] <directhex> Laney, which means you can become the proud owner of an f-spot sync if you like
[12:53] <Laney> later
[12:53] <seb128> Laney: are you sure?
[12:53] <Laney> actually it might FTBFS, there was some weird problem
[12:53] <Laney> yes
[12:54] <seb128> Laney: http://launchpadlibrarian.net/22054264/debdiff
[12:54] <Laney> is that the one from chriscoulson?
[12:54] <seb128> Laney: that's a pending sponsoring request
[12:54] <Laney> (my internet isn't working)
[12:54] <seb128> Laney: yes
[12:54] <Laney> right, well I've put that into Debian SVN
[12:54] <Laney> so it'll be in -2
[12:54] <seb128> Laney: there is ar4545_locales-import change listed there
[12:54] <seb128> ok so we can't sync yet
[12:55] <seb128> it updates the build-depends too
[12:55] <Laney> grr
[12:55] <seb128> Laney: have you looked at the other suggested changes for notebooks, etc?
[12:55]  * Laney mutters about having been told sooner
[12:55] <Laney> no
[12:55] <seb128> Laney: told what? we can sync but that's as cheap to upload this debdiff for now and sync -2 when it will be uploaded to debian
[12:56] <seb128> being is sync in nice but should not stop bug fixes to be uploaded to ubuntu
[12:57] <Laney> there could always be the next patch
[12:57] <Laney> which leaves us constantly chasing the sync but never getting there
[12:58] <seb128> well, I would sync if the build-depends was correct
[12:58] <seb128> but if we sync f-spot now it will not got to dep-wait for the new version but ftbfs directly
[12:58] <seb128> if you can get that fixed in debian we can sync
[12:58] <Laney> that's in ther etoo ;)
[12:59] <seb128> there being svn or experimental?
[12:59] <Laney> svn
[12:59] <seb128> we can't use that for syncs ...
[12:59] <seb128> anyway let's upload to debian can be synced
[12:59] <seb128> thanks for you work there ;-)
[12:59] <seb128> let's -> nex
[12:59] <seb128> next
[13:00] <slangasek> cjwatson: strange; I can't seem to find jtidy anywhere in germinate-output/{ed,k,}ubuntu/all
[13:01] <slangasek> it's openoffice.org -> lucene2 -> jtidy, but it doesn't show up at all...
[13:02] <slangasek> ohhh, because lucene2 is an obsolete OOo build-dep
[13:02] <slangasek> ok, let's fix it that way then :)
[13:02] <cjwatson> all_edubuntu_jaunty_ia64:classpath-doc                             | classpath                             | libjtidy-java-doc                                | Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>                         |        30605094 |          313984
[13:02] <cjwatson> frex
[13:03] <slangasek> right, which will go away when the ports catch up on OOo
[13:03] <cjwatson> yeah, it shows up only on ia64/powerpc/sparc
[13:03] <cjwatson> which explains why you don't see it on people.ubuntu.com's germinate-output, which is i386 only; I looked in cocoplum:/srv/launchpad.net/ubuntu-archive/ubuntu-germinate/
[13:03] <slangasek> ok
[13:04] <pitti> mvo: thanks for testing metacity-clutter! *hug*
[13:06] <mvo> pitti: cheers
[13:06] <mvo> pitti: having debs would be cool too, its a bit cumbersome though
[13:07] <mdeslaur> Laney: I can't reproduce your vim upgrade bug
[13:07] <mdeslaur> Laney: what packages did you have installed before the upgrade?
[13:07] <Laney> mdeslaur: I think you might need vim-gnome?
[13:07] <Laney> or maybe vim-full
[13:08] <mdeslaur> Laney: ok, will try, thanks
[13:27] <jelmer> slangasek, Am I mistaken to think that I'll lose my position in NEW by uploading a new version of a package?
[13:28] <slangasek> jelmer: I don't know.  In the past I've understood that it would not change the package's position in the queue, but it's possible the current ftpmaster policy perversely punishes uploaders for fixing bugs in packages that are still in NEW
[13:32] <cjwatson> or perhaps just that ftpmasters operate on shiniest/easiest first :-)
[13:40] <pitti> slangasek: just committed the last sleep quirk from acpi-support to hal-info, will do an upload of hal-info; want me to rip out those bits from acpi-support, or want to wait for spec review or something else?
[13:42] <slangasek> pitti: well, please go ahead and at least commit the change to the acpi-support branch.  Which bits are the sleep quirks? suspend.d?
[13:42] <pitti> slangasek: *.config (see the spec I just wrote, I answered to Robbie's mail)
[13:43] <slangasek> ah, the lib/*.config
[13:43] <slangasek> so all of these quirks are known to hal-info?  Rockin'
[13:43] <pitti> there wasn't a lot left, just three commits
[13:43]  * slangasek nods
[13:44] <pitti> and as explained in the spec, ACPI_SLEEP should just go completely
[13:48] <jelmer> slangasek, I've uploaded 0.6.1-1 to NEW and uploaded the matching source to http://people.debian.org/~jelmer/new/subvertpy_0.6.1-1_source.changes; will also mention that in the bzr-svn bugreport
[13:48] <slangasek> jelmer: cheers
[14:06] <slangasek> pitti: you wrote in the spec that you committed your changes to acpi-support bzr - ENEEDSPUSH?
[14:06] <pitti> slangasek: still working on it
[14:06] <slangasek> ok
[14:06] <pitti> (sorry, pressed Enter too fast)
[14:06] <slangasek> :-)
[14:12] <pitti> slangasek: pushed
[14:12] <pitti> need to stop working on this now, I have a job interview soon
[14:12] <slangasek> pitti: ta
[14:13] <slangasek> pitti: as an interviewer or an interviewee? :-)
[14:14] <pitti> slangasek: the former :)
[14:14] <slangasek> oh good, so I don't have to worry with you competing with me for this job I'm applying for at Novell ;-)
[14:16] <jdong> pitti: hope you don't get an answer like "Because ISO/IEC 14882:2003 section 14.1 paragraph 4 said so" from your interviewee....
[14:16] <jdong> :D
[14:17] <jdong> that went down in my books as the most impressive answer for why you can't use float or double literal as a template parameter...
[14:17] <slangasek> pitti: one consequence of rev 109 would appear to be that acpi-support can still be invoked manually for suspend/resume, but will do Wrong Things on the quirked platforms, so we should follow through on nuking the suspend handling completely?
[14:18] <pitti> slangasek: yes, that's the idea
[14:19]  * slangasek nods
[14:19] <pitti> slangasek: but I want to drop it carefully, i. e. for each removal do grep -r's of reverse references
[14:19] <slangasek> sure
[14:19] <pitti> IMHO pm-suspend and friends should be the only supported interface
[14:19] <slangasek> I think we want to take care of the top of the tree before the next upload, at least, to make sure the wrong suspend method doesn't get called
[14:20] <pitti> slangasek: AFAICS, handling the model specific acpi events should be the only thing which we should keep
[14:20] <pitti> slangasek: the most crucial bit to remove is now /etc/acpi/events/sleepbtn and friends
[14:21] <slangasek> ok
[14:21] <pitti> I guess that's what you mean with "accidentally invoke"
[14:21] <slangasek> yes
[14:22]  * pitti reuploads his rejected g-p-m; race condition with apt-get source and another upload
[14:22] <slangasek> pitti: note the Vcs-Bzr field as well, then :)
[14:23] <ScottK> slangasek: Could I have a moment of your time with your archive-admin had on?
[14:23] <slangasek> sure
[14:23] <slangasek> pitti: btw, when ripping out events/sleepbtn, there are probably a few dozen LP bugs to close ;)
[14:23] <ScottK> I've prepared the input for syncbugbot for the clamav rdepend backports.
[14:24] <pitti> slangasek: \o/
[14:24] <slangasek> ScottK: ok
[14:24] <ScottK> http://paste.ubuntu.com/116088/ and my LP cookie should be available.
[14:24] <ScottK> I can go ahead and accept the source backports (which I pre-loaded over the weekend).
[14:24] <slangasek> ScottK: these are intrepid or hardy?
[14:24] <ScottK> The target is Hardy.  These are all from Jaunty.
[14:25]  * slangasek nods
[14:26] <pitti> slangasek: g-p-m uploaded and bzr-pushed
[14:26] <slangasek> pitti: oh, also, please hold off on uploading those acpi-support rip-out-the-guts changes until I have a chance to talk further with Bart Samwel (Debian maintainer)
[14:27] <slangasek> (i.e., until i catch up on my email)
[14:27] <slangasek> pitti: g-p-m> thanks :)
[14:27] <pitti> slangasek: noted; right now it's only half-baked anyway (sleep button still active, etc.)
[14:27]  * slangasek nods
[14:27] <ScottK> slangasek: Thank you.
[14:28] <slangasek> ScottK: no prob
[15:12] <dholbach> slangasek: bug 327209 (for bug 325930)
[15:13] <slangasek> dholbach: right, thanks
[15:13]  * dholbach hugs slangasek
[15:13] <dholbach> gracias
[15:13] <slangasek> (not that we can actually do a sync from NEW, but we'll do something that resembles it :)
[15:13] <dholbach> slangasek: right... put the link to the .dsc file there
[15:13] <slangasek> ok, cool
[15:21] <alex-weej> mvo: hey
[15:22] <alex-weej> you committed a change of mine to compiz-fusion-plugins-main
[15:22] <alex-weej> it's the first time i've done a debdiff properly
[15:22] <alex-weej> i got 4 emails shortly afterwards saying it failed to build! :(
[15:24] <mvo> alex-weej: no worries
[15:25] <ScottK> alex-weej: That'll be due to kernel issues in sparc, ia64, powerpc, and hppa
[15:26] <alex-weej> ok... good :D
[15:28] <mvo> alex-weej: I adjusted the change slightly to make it into a cdbs patch instead of a inline patch, but otherwise it was fine
[15:30] <alex-weej> mvo: yeah i realised it was using cdbs soon after uploading
[15:31] <alex-weej> by the way, do you know much about compiz configuration handling? i opened a bug yesterday about a default value not actually being the default...
[15:31] <alex-weej> the window resize plugin to be precise
[15:32] <alex-weej> in gconf, it is set to 0 (normal), but it clearly behaves as rectangle until i change it then change it back on a fresh intrepid installation
[15:32] <alex-weej> i figured it may also bork for that config file change i submitted
[15:32] <alex-weej> if there's some weird interplay between compizconfig/gconf
[15:33] <alex-weej> (yay for unnecessary abstractions)
[15:34] <seb128> alex-weej: there is different config backend are you sure you are using the gconf one?
[15:34] <alex-weej> i'm not sure of anything with compiz to be honest
[15:34] <mvo> alex-weej: for config default changes, best use the metadata/*.xml files
[15:34] <alex-weej> mvo: that i did for my patch
[15:34] <mvo> alex-weej: they auto-generate gconf schemas
[15:34] <alex-weej> right, that's sort of what i suspected
[15:34] <alex-weej> when does the gconf schema get generated? build time?
[15:34] <mvo> hm, and that did not work?
[15:35] <mvo> yes, build time
[15:35] <alex-weej> i'm not sure i haven't actually tested it -- let me find the bug i reported
[15:35] <alex-weej> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/326690
[15:38] <alex-weej> mvo: at build time of plugins-main or backend-gconf?
[15:53] <ogra_> Keybuk, hey ... you had a hack for bootchart to make it possible to measure desktop startup times iirc, can you explain NCommander how to do that (or point him to a doc)
[15:54] <Keybuk> build the current bootchart from source
[15:54] <Keybuk> boot with bootchart=nostop
[15:54] <Keybuk> then run sudo /etc/init.d/stop-bootchart start once the desktop is up
[15:54] <NCommander> Keybuk, I'm going to guess that requires initramfs support
[15:54] <NCommander> (or is there a way I could modify bootchart not to require that)
[15:55] <Keybuk> no, the current bootchart will work without an initramfs too
[15:55] <Keybuk> but you do have to build it from source, because building java appears to be broken on the builds
[15:55] <NCommander> Oh, very handy
[15:57] <mvo> Keybuk: thanks for the hint for the metacity-clutter branch, it does indeed provide sme additional effects over the stock metacity compositor :)
[15:58] <Keybuk> mvo: did you build it from git?
[15:58] <mvo> Keybuk: yes
[16:01] <kirkland> fresh install of alpha4, logging in through gdm loads the desktop background but just kinda hangs there
[16:01] <kirkland> some noise about pulse-audio in /var/log/messages
[16:01] <lool> cjwatson: Hmm could you advice on how to pull wireless-crda in main?  I don't quite know about hardware specific packages (in this case wifi): how should these be pulled on some installs and upgrades?  bug #325801
[16:13] <kirkland> (compiz was to blame for my problem)
[16:14] <ogra> yeah, thats an easy victim ... as NM is :)
[16:17] <pitti> slangasek: FYI, uploading a new pm-utils now with the last bit of acpi-support-edness dropped (vbetool counterpart)
[16:18] <james_w> pitti: I was just about to prepare a debdiff for pm-utils
[16:18] <james_w> bug 326183
[16:18] <slangasek> damn, I was working on fixing the pm-utils side of 59695 - ok, will queue my patch :)
[16:18] <james_w> any chance you could fold that in?
[16:18] <pitti> oh, wow
[16:18] <james_w> heh
[16:18] <pitti> sorry, I wasn't able that so many people were hammering on it ATM :)

[16:19] <pitti> slangasek: it's not ATM
[16:19] <slangasek> I know
[16:19] <slangasek> :)
[16:19] <pitti> anyway, package should hit https://edge.launchpad.net/ubuntu/+source/pm-utils in one minute
[16:19] <slangasek> ack
[16:20] <pitti> james_w: I'll be happy to sponsor it, or just send it to slangasek if he'll do an upload anyway?
[16:20] <pitti> james_w: otherwise just subscribe me to the bug afterwards, I can sponsor it
[16:20] <james_w> sure, thanks
[16:20] <pitti> ok, before I step on anyone else's toes when doing sponsoring...
[16:21] <pitti> seb128: ok for me to upload totem{,-pl-parser}?
[16:21] <pitti> oh, -ENOSEB
[16:24] <NCommander> Keybuk, I got bootchart setup, but I'm not sure where/if I need to kill the process at the end of the graphical startup (bootchart.org source ball says nothing about killing it, the init.d item for Ubuntu seems to be Ubuntu specifc)
[16:25] <Keybuk> then run sudo /etc/init.d/stop-bootchart start once the desktop is up
[16:27] <pitti> Keybuk: incidentally I was playing around with that as well yesterday
[16:27] <pitti> Keybuk: and I couldn't figure out how to update /etc/bootchart/desktop
[16:27] <pitti> erm, /etc/readahead/desktop, I mean
[16:27] <Keybuk> pitti: I was going to say, somebody's confusing bootchart and readahead there ;)
[16:28] <Keybuk> pitti: you don't have a separate /usr ?
[16:28] <pitti> Keybuk: when I used profile and disabled stop-readahead, it'd make /boot huge, and not touch desktop
[16:28] <pitti> Keybuk: no, I don't; do I need to?
[16:28] <Keybuk> if you don't have a separate /usr, /etc/readahead/desktop is unused
[16:28] <pitti> ah, ok
[16:28] <Keybuk> if you do have a separate /usr, it's update automatically
[16:29] <pitti> that explains why my desktop startup with cold cache is so excrutiatingly slow
[16:29] <Keybuk> to get it to include desktop, rm /etc/rc2.d/S99stop-readahead and run the init script manually when the desktop is up
[16:29] <Keybuk> no it doesn't
[16:29] <Keybuk> the default lists don't include the desktop
[16:29] <pitti> Keybuk: i. e. this puts everything in /etc/readahead/boot (guess that should work fine)
[16:31] <Keybuk> right
[16:34] <seb128> pitti: is your bootchart available somewhere?
[16:34] <pitti> seb128: still need to do a current one
[16:34] <seb128> ok
[16:38] <slangasek> james_w: I have my pm-utils changes merged onto pitti's last upload; feel free to ping me when you have a fix for 326183
[16:57] <james_w> slangasek: http://pastebin.com/f4d3ec233
[16:58] <slangasek> james_w: ah, looks good :)
[16:59] <slangasek> james_w: is there any sort of reference for the 'no longer needed' bit?
[17:00] <james_w> slangasek: will the tinitus and general numbness I feel following the 3 hour discussion between Scott and Colin on clock handling do?
[17:01] <slangasek> heh
[17:01] <Keybuk> it was a complicated topic ;)
[17:02] <james_w> Keybuk: do you have the wiki page?
[17:02] <Keybuk> wiki.ubuntu.com/HardwareClock
[17:02] <slangasek> Keybuk: could you confirm that we don't need to run hwclock on resume for current kernels?  That's what I remember, but my memory is fallible
[17:02] <james_w> thanks
[17:02] <Keybuk> your filesystem may be at risk if you fail to keep your system clock in sync with your hardware clock
[17:02] <Keybuk> slangasek: I can confirm
[17:02] <calc> Riddell: what is the multimedia framework for KDE?
[17:02] <james_w> it was an interesting discussion, but I really didn't want to know that much about clocks
[17:02] <Keybuk> the kernel clearly resets the system clock from the hardware clock on resume, based on the delta it measured on suspend
[17:02] <slangasek> Keybuk: and that's true for resume from hibernate, as well as resume from suspend?
[17:03] <superm1> pitti, regarding http://cgit.freedesktop.org/hal-info/commit/?id=d3509c6af4c939d0b52dc4314b364bd4c4c33228 , I suspect you need more granularity to that quirk.  The system probably ships with multiple different graphics cards, and you may be altering the behavior for all of them with such a quirk
[17:03] <Keybuk> slangasek: as far as the kernel is concerned, they're the same
[17:03] <slangasek> okie
[17:03] <Keybuk> it's in the RTC driver _suspend()_resume() code
[17:04] <james_w> Keybuk: the first section of that page asserts that the system clock is unreliable, and then states that it is reliable two lines later
[17:04] <calc> Riddell: it doesn't use gstreamer directly does it? iirc i had read at one point it can use it but not by default?
[17:04] <Keybuk> james_w: I probably got confused between reliable and accurate ;)
[17:05] <Riddell> calc: currently we use xine via the Phonon API
[17:05] <Keybuk> james_w: ah, no, I just confused myself - fixed
[17:05] <Riddell> calc: Phonon does have a gstreamer backend but I believe it's not very good as well as the usual gstreamer lacking DVD menus
[17:05] <calc> Riddell: ok so if OOo were to somehow grow native multimedia support for KDE it would need to use Phonon?
[17:05] <Keybuk> system clock = accurate, hardware clock = reliable, network clock = both but slow
[17:06] <Riddell> calc: that would be the best way yes, although it could just use gstreamer or whatever directly
[17:06] <calc> Riddell: ok, yea it currently uses gstreamer, just wondering if is is good enough like that or if it would be wishlist to get phonon support
[17:07] <stgraber> ogra: for that ltsp install failure, /cdrom is already mounted in /target, what's the best ? Drop --mount-cdrom ?
[17:07] <ogra> stgraber, yes, that was a temp. workaround anyway
[17:07] <Riddell> calc: it should work fine, just means a second multimedia library on the CDs, not the end of the world
[17:08] <NCommander> Keybuk, I have bootchartd setup, but it seems to immediately return when loaded as init=/sbin/bootchartd
[17:08] <stgraber> ogra: ok, will do in the next upload
[17:08] <calc> Riddell: ok
[17:09]  * calc bbl, finding dinner
[17:09] <Keybuk> NCommander: where did I tell you to load it like that?
[17:09] <Keybuk> NCommander: just boot normally
[17:11] <ogra> NCommander, i'm pretty sure the package works as advertised if Keybuk tells you so ;)
[17:11] <ogra> he's its biggest user
[17:11]  * NCommander has no doubt of the packaging working, it just happens the user in this case should probably not read the upstream docs in favor of asking questions to Keybuk 
[17:12] <Keybuk> well, yes ;)
[17:12] <Keybuk> the only bit of the upstream package we use is the java code to draw the pretty chart
[17:12] <Keybuk> everything else is custom to Ubuntu
[17:12] <NCommander> Ah, I wasn't aware of that
[17:14] <slangasek> james_w: curious how suspend/resume seems faster with this patch applied ;)
[17:14] <Keybuk> slangasek: the hwclock patch?
[17:14] <Keybuk> because you're not sleeping for >1s on suspend to sync the two, and >1s on resume to sync them the other way
[17:18] <pitti> superm1: possibly; but the previous change was a regression, so I wanted to fix the regression first
[17:18] <pitti> superm1: if someone has a similar system, and different graphics card, we can still fix it for that
[17:20] <slangasek> Keybuk: er, yes, I was there all last week, I know why it's faster... :)
[17:21] <superm1> pitti, okay
[17:21] <Keybuk> slangasek: but you're still curious?
[17:21] <slangasek> Keybuk: no, I'm "curious ;)"
[17:22] <Keybuk> ahh
[17:22] <Keybuk> I'm tired
[17:33] <bryce> W: Bizarre Error - File size is not what the server reported 55233 27617
[17:33] <bryce> heh
[17:34] <bryce> (reran apt-get update and it went away, but funny, haven't seen "Bizarre Error" before from apt)
[18:02] <shankhs> hi guys I am learning shell programming and GUI development in Linux , I just made a small program of stopwatch which GUI program you prefer Qt or GTK?Why?
[18:02] <shankhs> The shell program will be the back end for the front end GUI
[18:04] <shankhs> Please help I am really confused ...
[18:04] <shankhs> I know here only ubuntu development related stuff is discussed but isnt Qt and gTK part of ubuntu?
[18:05] <Keybuk> Ubuntu uses GTK+, Kubuntu uses Qt
[18:06] <shankhs> Keybuk: what a beginner should prefer?Do you know any good tutorial for both of them?Thanx
[18:07] <cjwatson> lool: the ship or server-ship seed or something like that would be the usual place, but getting it installed on upgrades is sort of tricky
[18:07] <cjwatson> lool: I don't suppose it would be appropriate for the kernel image package to recommend it?
[18:08] <Keybuk> shankhs: are you more familar with C or C++ ?
[18:08] <shankhs> Keybuk: ya i have been programming in C/C++ for 3 years now
[18:09] <Keybuk> shankhs: which?  they're quite different languages
[18:09] <shankhs> Keybuk: I first learned C and then C++
[18:10] <Keybuk> shankhs: well, GTK+ is pure C; Qt is pure C++
[18:10] <shankhs> Keybuk: hmmm...
[18:11] <shankhs> Keybuk: so I think I will go for GTK+
[18:11] <shankhs> Keybuk: thanx for your help
[18:12] <shankhs> Keybuk: Do you know a good tutorial for GTK+?
[18:12] <ogra> shankhs, http://library.gnome.org/devel/gtk-tutorial/stable/ ... first hit on google for "gtk tutorial"
[18:17] <calc> wow gnome locked up on me again, for the second day in a row
[18:17] <calc> i clicked on the clock applet and it hung hard
[18:17] <calc> the apps i am running still work but it appears the panel at minimum is dead
[18:17] <ogra> dont click on the clock applet then :)
[18:17] <calc> ogra: :-P
[18:17] <jdong> lol
[18:18] <jdong> remember that one bug about clicking panel applets in a certain sequence triggers a mouse-lockup?
[18:18] <calc> jdong: no that sounds fun too
[18:18] <jdong> it always amuses me how people find bugs like that and reproduce it :)
[18:18] <jdong> I believe it's some combination of right and middle clicking
[18:18] <jdong> it locks the cursor into the draggy-hand-thingie
[18:19] <calc> Riddell: mandriva does not have qt support, they just totally turned off qt/kde support entirely
[18:20] <calc> ok well i hope i can brb, need to kill gnome
[18:20] <calc> hmm kill -HUP fixed it
[18:20]  * ogra hands calc a KDE shotgun
[18:24] <slangasek> pitti, cjwatson: hrm, very strange; trying to test the pm-utils fix for bug #59695, and I'm finding that in jaunty, something is overriding the disk pm setting that I'm applying when disconnecting AC... I see only one call to hdparm with the right setting, but when I check afterwards, -B254 is set instead of -B128
[18:24] <slangasek> pitti, cjwatson: and if I call hdparm directly, this isn't the case
[18:24] <slangasek> killing hal and g-p-m appears to make no difference
[18:25] <shankhs> ogra : thanx
[18:30] <slangasek> pitti, cjwatson: ok, no, ignore me; hdparm is being difficult generally
[18:31] <ogra> lets just drop it from the archive ...
[18:31] <ogra> solves all probs with it
[18:48] <CarlFK> anyone know a phone number for Canopus (want to ask some questions about the twinpact)
[18:49] <CarlFK> whops, wrong #chan - sorry
[18:54] <cjwatson> Keybuk: HardwareClock> generally excellent, but --stepsys => --hctosys?
[18:55] <cjwatson> Keybuk: presumably with --hctosys in udev, udevadm trigger becomes especially obvious since your clock changes :)
[18:56] <cjwatson> Keybuk: or is --stepsys new?
[18:56] <cjwatson> yeah, I can't read
[18:57] <cjwatson> I love the phrase "legacy APIs such as stat()" - it clarifies what a useless word "legacy" is
[18:57] <cjwatson> it can mean anything from "will be removed next week" to "your entire system depends on it"
[18:59] <kees> why would stat() be considered legacy??
[18:59] <lool> cjwatson: I guess a recommends on the kernel image package is what we will use then; thanks
[18:59] <cjwatson> kees: time_t rather than struct timespec
[18:59] <slangasek> kees: meet Keybuk
[18:59] <lool> cjwatson: I have no problem with that, just not enough good judgment to take the best decision
[19:00] <slangasek> kees: anything that wasn't invented next week is legacy :P
[19:00] <Keybuk> cjwatson: --hctosys is an existing call that copies the hardware clock to the system clock adding a delta for timezone if necessary
[19:01] <cjwatson> Keybuk: s'ok, I worked it out
[19:01] <Keybuk> since the system clock has already been copied from the hardware clock by the kernel, there's no reason to do that -- all we need to is step the system clock by the timezone delta
[19:01] <Keybuk> slangasek suggesting doing that in hwclock to keep it all in the same place
[19:01] <cjwatson> the only thing I'd say there is that it would be nice, as a sanity check, to read the hardware clock and compare it (roughly!) with the system clock so that we can avoid accidentally stepping twice
[19:02] <cjwatson> we don't need subsecond accuracy for that
[19:02] <Keybuk> by "legacy stat() call" I meant just that
[19:02] <Keybuk> the legacy stat() syscall
[19:02] <kees> ah!
[19:02] <cjwatson> except that POSIX stat() has the same property
[19:02] <Keybuk> POSIX can be legacy ;)
[19:02] <cjwatson> hence my "useless word" comment :-)
[19:03] <kees> *whew*  stat(2) has been time_t for as long as I could find.  okay, syscall.  /me tunes back out
[19:05] <calc> gah, not this vile unforgiven cover again :\
[19:05]  * calc wonders if anyone else from the sprint got exposed to it
[19:07] <Keybuk> yeah, glibc fills in those values for you ;)  the kernel uses struct timespec internally
[19:11] <Keybuk> (of course, then if you read the kernel source you'll find out that time_t isn't compatible with one returned by time() and you'll want to hide in a small hole somewhere and forget about the whole thing)
[19:28] <ogra> Keybuk, oh, you are poking at hwclock ... could you fix it for all arm arches while you're at it ? :P
[19:28] <Keybuk> no, you can do that ;)
[19:29] <ogra> bah :)
[19:29] <Keybuk> what's broken about it?
[19:29] <ogra> times out waiting for the clock ticks ... not sure yet
[19:29] <Keybuk> in which direction?
[19:29] <ogra> i honestly havent had time to look closely yet, NCommander has it on his todo though
[19:29] <ogra> both
[19:29] <Keybuk> pun intended?
[19:30] <ogra> not really, no :)
[19:30] <Keybuk> which /dev/rtcN appear on an ARM? what are their drivers?
[19:30] <ogra> its a sad issue ... since it blocks the system from powering donw on some SoCs
[19:31] <ogra> the devices appear fine
[19:31] <Keybuk> deviceS
[19:31] <Keybuk> ?
[19:32] <ogra> well, on the beagle it uses whatever the defconfig defines ... which i assume is the correct one ... let me check
[19:32] <ogra> grmbl, i dont have the config handy
[19:32] <Keybuk> do you have the system handy?
[19:33] <ogra> CONFIG_RTC_DRV_TWL4030=y
[19:34] <ogra> not set up after the sprint yet
[19:34] <ogra> so its integrated in the TWL4030 chip
[19:34] <NCommander> Keybuk, if you want access to my board to debug, your welcome to it; I traced it to the ioctl call which hangs
[19:35] <Keybuk> I have other things to do
[19:35] <Keybuk> and know about as much as you - so you're already in a better place to fix it ;)
[19:38] <jdong> anyone know what kind of "offensive words" pwgen refers to with regard to the --no-vowels option?
[19:39] <jdong> I've tried reading 5 screenfuls of pwgen with a dirty mind and am wondering whether or not it's a real risk?
[19:39] <directhex> jdong, wndws
[19:39] <jdong> lol
[19:39] <ogra> boobs4u
[19:40] <Mithrandir> fck, possibly?
[19:40] <Keybuk> jdong: you're basically asking us to say very offensive things to you, you know that? :p
[19:40] <jdong> lol
[19:40] <ogra> hehe
[19:40] <Mithrandir> Keybuk: he probably likes it
[19:40] <Keybuk> Mithrandir: it's the opposite way round
[19:40] <jdong> well I am just wondering if using pwgen passwords in password resets will have a bad effect.
[19:40] <jdong> but as Mithrandir points out, seems like there's problems either way :)
[19:41] <Keybuk> for example, it's perfectly possible for pwgen to generate the password "fuckyou"
[19:41] <ogra> that requires some switches though ...
[19:41] <jdong> well considering you're randomly generating "pronouncable" words, the chances that eventually you'll hit an offense-sounding one is probably high.
[19:41] <ogra> no number and no capital letter ...
[19:41] <Keybuk> no it doesn't?
[19:41] <Keybuk> well
[19:41] <Keybuk> FuckY0u then
[19:42] <ogra> yeah, that would work
[19:43] <jdong> I guess debian bug 387461...
[19:43]  * jpds just walked and saw Keybuk's last message and wondered what hit the fan before reading up.
[19:44] <jdong> I guess the given example is not english?
[19:44] <Keybuk> jpds: my phrasing was deliberate ;)
[19:46] <jdong> lol screw it I'm going to use regular pwgen for this
[19:47] <jdong> I don't see anything that bad after a good 20 minutes (famous last words)
[19:47] <jdong> the worst I've seen so far is "Mah8ineU" and you have to read that with a really really really questionable mindset to see anything.
[19:47]  * Keybuk changes his root password
[19:47] <jdong> LOL
[19:48] <Keybuk> we used to have a password generator that simply took two words from /usr/share/dict/words and join them together
[19:48] <Keybuk> that changed when a director got the password boysenberrybuttocks and objected
[19:49] <jdong> LOL
[19:49] <cjwatson> jdong: the given example in the bug is a racist term in English
[19:49] <Keybuk> needless to say, a variation on that became the root password for a while ;)
[19:49] <cjwatson> the last four letters anyway
[19:49] <jdong> cjwatson: well I guess I learned something new today.
[19:49] <jdong> not something useful, but new :)
[19:49] <Keybuk> cjwatson: I've just noticed who _filed_ that bug ;)
[19:49] <Keybuk> elmo: do we run pwgen with --no-vowels? :p
[19:50] <elmo> Keybuk: spads does ;-)
[19:50] <Keybuk> :D
[19:50] <ogra> apparently :)
[19:52] <IntuitiveNipple> cjwatson: I tested and confirmed your patch for Ubiquity/partman_commit silent failure generates an error dialog, and I've added instructions to the other bug (lost partitions) to easily recreate the problem environment in a VM.
[19:53] <cjwatson> IntuitiveNipple: yay, thanks. did the update-dev change help?
[19:53] <IntuitiveNipple> cjwatson: umm... define "update-dev" ? I may be missing something here :)
[19:56] <cjwatson> 17:37 <@cjwatson> IntuitiveNipple: if you fancy doing another test after the partman_commit one, try deleting the "udevadm trigger" line from /bin/update-dev
[19:56] <cjwatson> 17:38 <IntuitiveNipple> okay, will try that... with VMs its easy and quick.
[19:58] <IntuitiveNipple> cjwatson, oh... ok *now* I recall. I'm currently in the first run of the install on a brand new 400G drive... the 200G drive with all my 'stuff' on is cold on the desk so I'm making-do right now
[20:00] <IntuitiveNipple> cjwatson: I'll do that update-dev test once I've got all the VM images copied over.
[20:00] <cjwatson> great, thanks - and thanks for the reproduction recipe, I'll try to get to that
[20:01] <IntuitiveNipple> cjwatson: If you do use the recipe, after doing the partition-table create with fdisk, the interesting bit (which I forgot to list) is to show the partition table using fdisk in 'cylinder' mode - makes the cause more obvious
[20:05] <IntuitiveNipple> iwl3945/NetworkManager - is it known that WPA2 AES+TKIP fails for a (hidden) SSID and then only offers WEP methods for the 2nd attempt?
[20:07] <LaserJock> are MIRs for packages that Main packagers were using an embedded copy generally easier?
[20:08] <cjwatson> LaserJock: yes, if it's just a split-out then it doesn't require explicit approval
[20:09] <LaserJock> it's not a split out exactly
[20:09] <LaserJock> for some reason moodle was using it's own copy of smarty and yui
[20:09] <LaserJock> Debian has removed those and added the deps
[20:10] <LaserJock> so for me to merge I've got to get smarty and yui into Main
[20:10] <ogra> LaserJock, there is an ancient proposal from kees to split the modules out and use their deps instead ... i think you can refer to that
[20:11] <LaserJock> ok
[20:11] <LaserJock> I just wasn't sure how eager people would be to add a couple more php packages to the Main pot
[20:11] <LaserJock> although if moodle already had a copy of the code one would presume it'd be ok
[20:12] <ogra> https://wiki.ubuntu.com/EdubuntuContentServer see the bottom
[20:12] <ogra> effectively these modules were in main already since they enetered with moodle
[20:13] <LaserJock> right
[20:13] <ogra> yui is new though
[20:13] <ogra> (as in: not in the list on the spec)
[20:13]  * ogra needs to go cooking ... back later
[20:14] <mathiaz> james_w: hi - I'm using bzr and bzr-builddeb to merge mysql-dfsg-5.1 from experimental
[20:15] <mathiaz> james_w: is there a way to make bzr bd -S generate a .changes file that includes all the relevant changelog entries?
[20:28] <slangasek> mathiaz: bzr bd -S --builder 'spell out the full command' :(
[20:29] <slangasek> mathiaz: known limitation, has to do with the way bzr plugins parse arguments
[20:49] <mathiaz> slangasek: thanks!
[21:17] <cjwatson> kees: bug 57091 didn't get automatically closed by your procps upload since it wasn't filed on procps; you might want to close it by hand
[21:23] <kees> cjwatson: erk, d'oh, thanks for the catch.
[21:24] <LaserJock> ogra: darn, Jaunty's yui wants to pull in javascript-common, which pulls in wwwconfig-common :(
[22:22] <seb128> soren: could you look at bug #227837 it's on the sponsoring list for some months now
[22:28] <soren> slangasek: Do we respin DVD's for point releases?
[22:28] <slangasek> soren: no
[22:28] <soren> seb128: It's on my list. Somewhere :(
[22:28] <soren> slangasek: How come?
[22:29] <kees> superm1: can you take a look at 323327?
[22:29] <superm1> BUG 323327
[22:30] <slangasek> soren: it's not justifiable in terms of the relative volume of DVD vs CD use, and DVDs take a lot longer to QA.  This is no different than what was done for dapper point releases.
[22:30] <superm1> kees, oh fun fun
[22:30] <superm1> kees, should be an easy enough fix at least
[22:30] <soren> slangasek: Alright. Thanks.
[22:30] <kees> superm1: yeah, ran out of time to test it while sprinting last week
[22:31] <superm1> kees, did you have a diff to test with already then?
[22:31] <soren> slangasek: Is this written down in a policy somewhere?
[22:31] <kees> superm1: nope, wanted to reproduce for sure
[22:31] <superm1> kees, ah.  well i've  got an AMD box at home, i'll try'n double check it with later on then
[22:32] <kees> superm1: cool, thx
[22:32] <slangasek> soren: I don't believe so
[22:32] <soren> slangasek: Alrighty. No worries.
[22:33]  * soren calls it a day
[22:53] <lamont> where did dev-mapper go in hardy, I wonder?
[22:53] <lamont> more to the point, how do I get lvm to just shut up and build the lv?
[22:54] <IntuitiveNipple> lvm2 ?
[22:54] <lamont> ya
[22:54] <IntuitiveNipple> I use lvm2/crypsetup on Hardy... it ain't gone anywhere I know about!
[22:55] <IntuitiveNipple> dm-mod loaded?
[23:00] <andersk> I have been waiting for over two months for a MOTU sponsor in bug 303112, which would be a regression in Jaunty.  Is anyone willing to look at this?
[23:04] <lamont> IntuitiveNipple: that'd be the spelling I hadn't thought of.  thanks
[23:06] <IntuitiveNipple> hehehe
[23:06] <IntuitiveNipple> It confused me in Jaunty... now it is built-in!
[23:42] <james_w> mathiaz: you'll have to add "--builder 'debuild -S -vwhatever'" I'm afraid
[23:43] <mathiaz> james_w: yeah - slangasek gave me the same tip and it works well! :)