[12:33] <mneptok> have to learn to live. reach into the light. changing all the time.
[12:47] <TomaszD> Hi. I'm looking for Michael Vogt or someone responsible for displayconfig-gtk
[12:47] <TomaszD> I was wondering why isn't a translation template available for this application
[12:47] <Kmos> talk to mvo
[12:48] <TomaszD> mvo, if you are responsible for displayconfig-gtk, why isn't there a translation template available?
[12:48] <TomaszD> is a translation still considered a moving target?
[12:49] <mvo> TomaszD: let me have a look
[12:49] <TomaszD> mvo, sure. It's just that it stands out terribly among other, translated modules in the menu
[12:50] <TomaszD> and it's an essential part of the system now, so it should be available for translation, I guess
[12:54] <mvo> TomaszD: its missing from launchpad (the translation template)?
[12:54] <TomaszD> mvo, https://translations.launchpad.net/~displayconfig-gtk/
[12:54] <TomaszD> it's not there or am I looking in the wrong place?
[12:56] <beuno> TomaszD: it's the wrong URL, but it still seems not to have translations: https://launchpad.net/displayconfig-gtk/
[12:56] <mvo> it looks like some missing magic in the debian/rules file
[12:56] <TomaszD> ah, I see. "Translation setup needed"
[12:57] <TomaszD> mvo, thank you! I'll be going now, it's 1AM...
[12:57] <mvo> TomaszD: yeah, for me too
[03:58] <alex-weej> doko: you up?
[05:22] <ion_> An entertaining talk about version control systems (with emphasis on git, obviously) from Linus Torvalds: http://youtube.com/watch?v=4XpnKHJAok8 (http://ash-v131.ash.youtube.com/get_video?video_id=4XpnKHJAok8). Not exactly on-topic, sorry for that.
[05:23] <realist> Is that a link to his google talk?
[05:24] <ion_> Yes.
[05:25] <realist> Way off topic - way old news :-)
[05:25] <realist> Still a good presentation though!
[05:26] <realist> Especially where he ridicules code.google, and svn - knowing that the developers for both are in the audience
[05:50] <Toadstool> nice any call to hwclock on my tx1215nr makes the system freeze with "/dev/rtc does not have interrupt functions. Waiting in loop for time to change in /dev/rtc." :/
[08:52] <RAOF> It's hobbseemaster flash!
[08:53] <Hobbsee> RAOF: coming to slug tomorrow?
[08:54] <RAOF> Awesome.  What an excellent conjunction.    Cool.
[08:58] <Hobbsee> nice
[08:59] <highvoltage> RAOF: where is that?
[08:59] <RAOF> highvoltage: http://maps.google.com.au/maps?f=q&hl=en&q=173-185+Sussex+Street,+Sydney+NSW+2000
[09:00] <RAOF> High-performance python!
[09:22] <moyogo> hi, anybody in charge of xkeyboard-config around?
[09:23] <Hobbsee> probably a little aerly for that
[09:24] <moyogo> ok :-)
[09:44] <Hobbsee> good morning seb128, fabbione
[09:45] <seb128> hey Hobbsee
[09:48] <fabbione> morning
[09:52] <seb128> hi fabbione
[09:52] <seb128> Hobbsee: do we have a list of bugs nominated for gutsy and waiting to be approved or not somewhere?
[09:53] <Hobbsee> seb128: um, there would be a list somewhere yes, but like i siad on that bugmail, we really dont use it
[09:53] <Hobbsee> we tend to only use it a little for tribes - but choose to use the milestone stuff instead
[09:53] <seb128> what bugmail?
[09:53] <seb128> what tribe?
[09:53] <seb128> maybe my question was not clear ;)
[09:54] <seb128> you know, you can nominate a task for gutsy
[09:54] <seb128> and then it's listed with an approve or decline option
[10:04] <seb128> re Hobbsee
[10:59] <Riddell> RAOF: what standard does KDE not follow?
[10:59] <RAOF> Viewports, IIRC.
[11:00] <RAOF> Making the KDE workspace switcher get freaked out under Compiz
[11:00] <Kmos> can someone have a look at bug 129572
[11:00] <ubotu> Launchpad bug 129572 in powertop "Please sync powertop (universe) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/129572
[11:01] <Hobbsee> Kmos: is it urgent?
[11:01] <Kmos> Hobbsee: ups, it's already acked 2 times
[11:01] <Kmos> Hobbsee: no
[11:01] <Hobbsee> Kmos: and why would the general motu-uvf people be here?
[11:02] <Hobbsee> Kmos: i thought seb128 told you about bringing up bugs that were not urgent, but that were $yourpetbugs.
[11:02] <Kmos> Hobbsee: because you don't check my bugs? and jono told me to ask anything I want here
[11:02] <Hobbsee> Kmos: i do, occasionally.
[11:03] <Hobbsee> i prefer not to, but i do regardless.
[11:03] <Kmos> Hobbsee: i just want to finish these ones, because I won't file syncs anymore.
[11:03] <Hobbsee> they will be finished. just be patient, and accept that people have other things to do too.
[11:03] <Kmos> Hobbsee: yeah, like me now.. need to go, and getdeb will have more updates today.
[11:03] <Hobbsee> cool
[11:04] <seb128> Kmos: ubuntu-archive has been subscribed less than 1 day ago, you need a little patience ;)
[11:04] <Kmos> seb128: I see that 1 minute ago, sorry.. i just need to wait now
[11:05] <seb128> right
[11:09] <doko> iwj: please could you review the MIRs for drac and libwpg?
[11:12] <Kopfgeldjaeger> hi
[11:16] <ogra> doko, if you rebuild mknbi, you might want mkelfimage as well
[11:17] <ogra> (even though i suspect there are not many netbooting lpia machines with LinuxBIOS yet :) )
[11:17] <doko> ogra: already built for lpia
[11:17] <ogra> oh, ok
[11:17] <ogra> i just saw the mknbi one, sorry
[11:31] <iwj> doko: Sure.
[11:32] <iwj> (Morning)
[11:36] <doko> iwj: thanks, I asked tkamppeter to to write one for cupsddk (b-d of splix) as well
[12:12] <doko> seb128: who's usually doing the Gtk Perl stuff?
[12:18] <wolfe> input hot plugging!
[12:18] <wolfe> hell has froze over!
[12:18] <wolfe> I can't wait for Version 1.4 of the X server :) maybe I'll just built it myself
[12:25] <TomaszD> glatzor_, hey I noticed you're also responsible for displayconfig-gtk. I told mvo yesterday that there's no translation template in rosetta available and he said he'll fix it but nothing changed in Rosetta, so I'm thinking that maybe he forgot and you could do this, there seems to be some missing debian/rules magic missing. The webpage is https://translations.launchpad.net/displayconfig-gtk/
[12:25] <TomaszD> *-missing
[12:25] <TomaszD> :]
[12:26] <glatzor_> TomaszD: thanks. we just need to upload it.
[12:26] <TomaszD> glatzor_, ok, ETA on this? This is quite urgent you know :]
[12:27] <glatzor_> TomaszD: perhaps tomorrow. I want to fix some bugs before.
[12:27] <TomaszD> glatzor, alright. Thanks.
[12:27] <TomaszD> just keep in on the radar please, this isn't a thing to forget ;]
[12:30] <glatzor> TomaszD: you don't need to be afraid of this
[12:32] <glatzor> TomaszD: if you want to keep track of this issue subscribe to LP #134576
[12:32] <TomaszD> glatzor, great tip, thanks
[12:32] <Riddell> seb128: upstream says there's a fix to the gtk API change, do you know where I could find it? http://bugzilla.gnome.org/show_bug.cgi?id=463773#c10
[12:34] <TomaszD> subscribed
[12:37] <seb128> doko: nobody
[12:37] <seb128> Riddell: there is no gtk API breakage
[12:37] <seb128> Riddell: it's just making issues with incorrect usage where it was not
[12:38] <seb128> it's on my list of things to look at though
[12:38] <Riddell> ok, there's a fix to the change which makes flash and acroread break :)
[12:38] <seb128> that's not upstream
[12:38] <seb128> I think this guy is working for some non major distro
[12:38] <seb128> or bsd or something
[12:38] <Riddell> anyway, if you help me find that patch I can test it
[12:38] <seb128> dunno what he patched and where
[12:39] <jdstrand> hi infinity
[12:40] <jdstrand> in the ubuntu-server meeting the other day, they suggested I issue a bug report for the LAMP test page
[12:40] <seb128> Riddell: well the comment is clear enough, how do one trigger the bug? I can test a change if I know how to test
[12:40] <jdstrand> if you haven't seen it yet, it is bug #135624
[12:40] <Riddell> seb128: testcase is here https://bugzilla.novell.com/show_bug.cgi?id=294385#c55
[12:40] <jdstrand> bug 135624
[12:41] <ubotu> Launchpad bug 135624 in php5 "should provide LAMP test page" [Low,Triaged]  https://launchpad.net/bugs/135624
[12:41] <ubotu> Novell bug 294385 in GNOME "glib2 busyloops, blocking Konqueror and Opera on flash sites" [Blocker,Assigned]
[12:42] <seb128> Riddell: have you seen http://people.mandriva.com/~boiko/patches/kdebase-3.5.7-fix_flashplayer_nsplugin.patch ?
[12:42] <Riddell> seb128: yes, but adding a dependency from kde to gtk is an ugly ugly workaround
[12:42] <saispo> lol seb128 :)
[12:42] <seb128> hi saispo
[12:42] <seb128> saispo: why "lol"?
[12:43] <saispo> hi ;)
[12:43] <saispo> you use mandriva patches ? :p
[12:43] <Riddell> we use patches from wherever they come from, if they fix problems
[12:43] <seb128> Riddell: the comment you pointed shows that libflashplayer is buggy, it doesn't give a way to trigger the bug
[12:44] <seb128> saispo: why not? ;) In fact I don't, GNOME works fine, I suggest a workaround for kubuntu
[12:44] <saispo> seb128: yes i see :)
[12:45] <moyogo> anybody in charge of xkeyboard-config around?
[12:45] <Riddell> seb128: novell 294385#c55?  it has test code in it to recreate the issue (regardless of who's fault the issue is)
[12:45] <ubotu> Novell bug 294385 in GNOME "glib2 busyloops, blocking Konqueror and Opera on flash sites" [Blocker,Assigned]  https://bugzilla.novell.com/show_bug.cgi?id=294385
[12:46] <seb128> Riddell: right, I was being lazy and wondering if that happens with real world applications in Ubuntu
[12:46] <moyogo> it would be nice to have the latest xkb-data to have the new keyboard layouts in gusty
[12:46] <seb128> like something I can install, run, notice it's buggy
[12:46] <Riddell> seb128: well yes, flash in non gtk browsers and acroread
[12:46] <moyogo> like gn which allows to type Nko for example
[12:46] <moyogo> that would help localizers to work with gusty
[12:47] <cjwatson> moyogo: I'll have a look in a bit - on the phone now
[12:47] <moyogo> thanks
[12:47] <cjwatson> (I don't do xkeyboard-config as such but I do console-setup which is related)
[12:47] <seb128> bah
[12:47] <seb128> "expr: syntax error" when running acroread
[12:49] <seb128> Riddell: acroread is not the same issue and will not be fixed by this change
[12:49] <seb128> they access to GTK+ internal structure in a non documented way
[12:49] <seb128> and bad luck for them there is no stability guaranty for those
[12:49] <Riddell> seb128: ok, try opera or konqueror with flash then
[12:49] <seb128> and the tooltip API has been deprecated and replaced by a new one
[12:49] <seb128> k, will do that
[12:55] <moyogo> ArneGoetje: ping
[01:08] <doko> iwj: cupssdk MIR is now available as well
[01:13] <iwj> Uh, Apple's CUPS is GPLv2-only ?
[01:19] <iwj> doko: Also approved.
[01:19] <iwj> I like these nice simple packages.
[01:20] <doko> iwj: do you want something more demanding, including license review?
[01:21] <iwj> Perhaps.  What would I be letting myself in for ? :-)
[01:22] <cjwatson> licence review is an archive admin function, surely
[01:22] <cjwatson> it shouldn't be in universe if its licence isn't free
[01:22] <iwj> cjwatson: That was my understanding.
[01:23] <iwj> I've certainly not really been looking at licensing.  (My comment above was an aside, prompted by happening to stumble across a GPLv2 notice.)
[01:23] <cjwatson> not to say it isn't worth sanity-checking, but I don't think it's worth spending lots of time on deciphering legalese at the MIR stage ...
[01:24] <cjwatson> (some "free" licences have obviously had rather too many lawyers involved.)
[01:25] <doko> iwj: icedtea
[01:26] <iwj> OMG
[01:56] <Riddell> seb128: gtk compile errors "/home/jr/src/gtk/gtk+2.0-2.11.6/modules/printbackends/cups/gtkcupsutils.c:638: error: dereferencing pointer to incomplete type"
[01:59] <manchicken> Anybody know who may be able to fix network-manager issues?  I'm having a heck of a time with bug #93360.
[01:59] <ubotu> Launchpad bug 93360 in dhcdbd "Dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth1 for sub-path eth1.dbus.get.reason" [Undecided,Confirmed]  https://launchpad.net/bugs/93360
[01:59] <thom> manchicken: asac
[02:12] <asac> manchicken: what wifi chipset?
[02:14] <Treenaks> Also, anybody around to look at bug 119266? I haven't had out-of-the-box sound since I upgraded this box to gutsy
[02:14] <ubotu> Launchpad bug 119266 in linux-source-2.6.22 "Intel HDA Sound device doesn't work in gutsy" [Low,Fix committed]  https://launchpad.net/bugs/119266
[02:16] <jwendell> Treenaks, it works now, since last linux-ubuntu-modules
[02:16] <Treenaks> jwendell: oh, I see the reboot icon now..
[02:27] <ogra> cjwatson, i'm trying to rework my udeb scripts for ltsp http://paste.ubuntu-nl.org/35650/ results in a ot of text output "... return: ... Illegal number" in the debconf screen, do you have any hints why that happens or where it comes from ?
[02:59] <cjwatson> ogra: sounds like your debconf communication has got out of sync
[02:59] <cjwatson> or something else is interfering with stdio
[02:59] <ogra> oh, ok
[02:59] <cjwatson> I'm prepared to bet large sums of money it's not debconf's fault
[03:00] <ogra> surely my fault :)
[03:00] <cjwatson> I'm on the phone but I see one problem
[03:00] <cjwatson> will let you know in a bit
[03:00] <JanDM_> hi, since alsa 1.0.14 I had a problem with my sound card. So I asked on alsa-devel, and they created a patch,
[03:00] <JanDM_> but this patch is not included in ubuntus current alsa version
[03:00] <JanDM_> so i have to compile alsa myself with every kernel update,
[03:01] <JanDM_> can I ask to include it somewhere?
[03:02] <ogra> JanDM_, i guess best is to discuss that in #ubuntu-kernel
[03:02] <JanDM_> okay, thank you!
[03:02] <ogra> (not sure though, depends if its for a module)
[03:03] <JanDM_> ogra: yes it's a kernel module
[03:03] <ogra> then -kernel should be right
[03:03] <cjwatson> ogra: ok, your problem is probably that 'cat $FIFO | while read line' uses stdio, which is getting in the way of using debconf
[03:03] <ogra> oh, ok
[03:03] <cjwatson> ogra: I encountered this same problem in the past in archive-copier
[03:04] <cjwatson> ogra: what you should do instead is:
[03:04] <ogra> so i need to redirect that as well
[03:04] <cjwatson> while read line <&9; do ...; done 9<$FIFO
[03:04] <ogra> ah, right
[03:04] <cjwatson> ogra: also why is it all within 'while true'? you should probably remove that otherwise it'll just sit in an infinite loop - the 'while read line' is good enough as a loop
[03:05] <ogra> yeah, thats for playing
[03:05] <cjwatson> ogra: you also might want to put 'rm $FIFO' before 'exit 0' ;-)
[03:05] <ogra> i had that in two scripts initially, echoing stuff to the fifo :)
[03:05] <ogra> yeap, what i have here locally evolved already a bit :)
[03:08] <ScottK> Mithrandir: If you have a minute to look into a licensing question, I've consulted a couple of other MOTUs and were are unsure if http://revu.tauware.de/details.py?upid=139 would be suitable for multiverse or not.  Technically the package is ~OK, so I wanted to get a read on if it could be accepted in the archive before I pushed on the packager to fix it up some more.
[03:10] <Riddell> "It is NOT PERMITTED to distribute ANY OF THESE FILES for commercial (or profit) purposes." I think that's ok for multiverse, although elmo will know for sure
[03:10] <ogra> cjwatson, works (outside of d-i at least) thanks a lot :)
[03:12] <cjwatson> ogra: you're welcome
[03:13] <ScottK> Riddell: Thanks.
[03:14] <elmo> Riddell: that's ok for multiverse, assuming permission for non-{commercial,profit} purposes is granted
[03:14] <ScottK> elmo: That's, I think, the real question.
[03:14] <ScottK> If it says you can't distribute for commerical purposes, can one infer permission to do it for non-commercial?
[03:15] <elmo> ScottK: no
[03:15] <ScottK> elmo: Thanks.
[03:32] <StevenK> Could someone wave the magic stick at zziplib's sparc build and raise it's priority? I'd like to see if it builds so it can rescued from NEW.
[03:44] <Mithrandir> ScottK: I'll take a look
[03:45] <ScottK> Mithrandir: elmo said he thought not, but a second opinion would be useful.  Thanks.
[03:48] <ogra> cjwatson, i assume archive-copier doesnt chroot into a sub-chroot in /target .... seems it doesnt work for me as soon as ltsp-build-client starts to run stuff inide the chroot
[03:48] <ogra> *inside
[03:49] <cjwatson> ogra: that's irrelevant to debconf
[03:50] <cjwatson> probably a red herring
[03:50] <cjwatson> perhaps you lost stdout somewhere else
[03:50] <ogra> well... somehow the chrooted commands end up on the debconf screen again
[03:50] <ogra> yeah
[03:50] <cjwatson> debconf couldn't care less whether you've chrooted
[03:50] <ogra> obviously ...
[03:50] <cjwatson> we do it all the time
[03:50] <cjwatson> all you need to do is send commands down the right fd
[03:51] <lamont> seb128: gnome-power-manager still hates some architectures:
[03:51] <lamont> gpm-profile.c:342: warning: cast increases required alignment of targgpm-profile.c:342: warning: cast increases required alignment of target typeet type
[03:51] <lamont> gpm-profile.c:342: warning: cast increases required alignment of target type
[03:51] <lamont> stupid mouse
[03:51] <cjwatson> from the code you showed me earlier, it would in fact be unable to tell whether ltsp-build-client is chrooting itself or not
[03:51] <ogra> cjwatson, right, that means ltsp-build-client needs internal redirects ...
[03:51] <cjwatson> err
[03:52] <cjwatson> surely absence of internal redirects
[03:52] <cjwatson> if you don't redirect, fds get left alone
[03:52] <cjwatson> basic Unix
[03:52] <ogra> right, and the chrooted commands use stdout it seems ...
[03:52] <ogra> instead of my redirect
[03:52] <cjwatson> so? it's the same stdout that you redirected to the fifo
[03:52] <cjwatson> no
[03:52] <cjwatson> that is not possible
[03:52] <ogra> hmm
[03:53] <cjwatson> "stdout" is just an fd
[03:53] <cjwatson> when you redirect, you *throw away* the old fd
[03:53] <cjwatson> ltsp-build-client doesn't have it
[03:53] <ogra> /usr/share/debconf/confmodule: line 42: 3: Bad file descriptor
[03:53] <ogra> thats what i got now
[03:53] <ogra> after it extracted templates for apt from the CD#
[03:53] <doko> go thunderbird!
[03:54] <cjwatson> does ltsp-build-client talk to debconf anywhere?
[03:54] <cjwatson> oh, it's installing packages, isn't it?
[03:54] <ogra> indeed
[03:54] <ogra> andits setting the frontend iirc
[03:54] <cjwatson> so you cannot do this whole scheme
[03:54] <cjwatson> it will be a race condition
[03:55] <cjwatson> you can't run ltsp-build-client in the background and simultaneously talk to debconf from somewhere else
[03:55] <ogra> hmm
[03:55] <cjwatson> ltsp-build-client needs to handle the debconf interaction itself, and it probably needs to use in-target to chroot
[03:55] <cjwatson> which will deal with the debconf passthrough gubbins you need
[03:55] <ogra> no, i dont have in-target in normal installs, wont work
[03:55] <cjwatson> check whether it's there then
[03:56] <ogra> phew ... thats a lot of plugins to change then
[03:56] <cjwatson> that's probably not the right approach
[03:56] <cjwatson> pick apart in-target and do its chroot setup stuff at the top level if you're being called in a context with a debconf frontend already running
[03:57] <ogra> ok
[03:57] <mjg59> http://www.ubuntu.com/getubuntu/download - the language on the second option "64 bit AMD and Intel computers" seems potentially confusing
[03:57] <cjwatson> and, on the same condition, have ltsp-build-client source the confmodule and do the progress output itself
[03:57] <mjg59> Someone just told me they interpreted it as (64 bit AMD) and Intel computers
[03:57] <cjwatson> mjg59: I think there's an ubuntu-website project for bug reports on that
[03:58] <mjg59> Cool.
[04:16] <Riddell> ogra: I had to sync the usplash-theme-ubuntu.c in kubuntu usplash with ubuntu to fix verify CD, edubuntu may need the same
[04:17] <ogra> Riddell, thanks fo rteh hint
[04:28] <bddebian> Heya
[04:38] <jwendell> seb128, around?
[04:46] <iwj> This is quite tedious.  My shiny disk-full logging libc doesn't seem to be very happy.
[04:48] <bddebian> Is the archive closed off for NEW already or not?
[04:50] <bddebian> ScottK: Cool, help me fix up sdlmame then ;-P
[04:50] <ScottK> Sorry, trying to do $WORK right now.
[04:50] <bddebian> pfft, work, schmurk :-)
[05:22] <alex-weej> doko: ping
[05:40] <seb128> jwendell: yes
[05:41] <jwendell> seb128, did you see my comment on bug 34805?
[05:41] <ubotu> Launchpad bug 34805 in vino "ALT GR key don't work." [Medium,Confirmed]  https://launchpad.net/bugs/34805
[05:42] <seb128> jwendell: now I did, do you want to get the Ubuntu package patched with it?
[05:42] <jwendell> seb128, no, i want to commit it in upstream in order to get it ready for 2.19.92
[05:43] <jwendell> seb128, but i'd like to see some tests before commit
[05:43] <mjg59> seb128: mixer_applet2 still seems to be causing wakeups
[05:43] <seb128> mjg59: yes, we got a bug about that, I need to check if the current gstreamer tarball already has the required API or if that's CVS only
[05:44] <seb128> jwendell: gutsy is a good way to get testing ;)
[05:44] <mjg59> seb128: It's in the released version, AFAICT
[05:45] <seb128> mjg59: let me have a look
[05:52] <Artimus> Is anyone able to get in touch with the people that run the Ubuntu Mailing Lists?  It's not honoring my unsubscribe requests, it's been 3 days and I still haven't gotten the confirmation email.  My inbox is being flooded, I'd like to unsubscribe, but mailman won't honor my choice.
[05:54] <cjwatson> Artimus: #canonical-sysadmin
[05:57] <jwendell> seb128, the problem is that the patch is insane, and i don't know if i or mark is able to fix some side effect
[05:57] <jwendell> seb128, so, if i detect something is wrong, i won't apply it
[05:58] <seb128> k
[06:12] <dholbach> fabbione: who do you think I should assign bug 61151 to?
[06:12] <ubotu> Launchpad bug 61151 in system-config-cluster ""separated" spelt incorrectly" [Low,Fix released]  https://launchpad.net/bugs/61151
[06:13] <fabbione> dholbach: is fix released?
[06:13] <dholbach> fabbione: oh sorry - it's all good then
[06:14] <fabbione> dholbach: eehheh
[06:16] <dholbach> calc: is bug 133793 ok?
[06:16] <ubotu> Launchpad bug 133793 in openoffice.org-voikko "Please sync openoffice.org-voikko from Debian" [Medium,Incomplete]  https://launchpad.net/bugs/133793
[06:17] <dholbach> lamont: how does bug 33586 look to you?
[06:17] <ubotu> Launchpad bug 33586 in nmap ".desktop file cleanup for nmapfe" [Wishlist,Incomplete]  https://launchpad.net/bugs/33586
[06:19] <lamont> dholbach: it looks like a bug in lp that I should review. :-)
[06:21] <seb128> mjg59: ok, the patch is not working
[06:21] <mjg59> seb128: Hm. How so?
[06:21] <seb128> mjg59: it has "#ifdef HAVE_GST_MIXER_NOTIFIES"
[06:21] <seb128> and I'm not sure what should define HAVE_GST_MIXER_NOTIFIES
[06:22] <seb128> greping for it in /usr/include doesn't return anything
[06:22] <mjg59> seb128: Can you try just making that true?
[06:22] <lamont> dholbach: I'll be working on my packages this weekend (postfix, bind, nmap, packit, etc.)  all of which have some bugs to be fixed... This should get in then.
[06:22] <lamont> if it's still open next week, please poke me.
[06:23] <dholbach> lamont: you ROCK
[06:23] <dholbach> lamont: hope you don't mind me assigning that bug to you
[06:23] <lamont> please do
[06:23] <dholbach> I just thought you were the best one to get it done ;)
[06:24] <lamont> dholbach: generally speaking, if I'm the debian maintainer, you're welcome to assign it to me.
[06:24] <dholbach> the bug patch lists are quite long, so I'll try to badger people some more
[06:24] <lamont> and I'll either assign it back to you, or fix it. :-)
[06:24] <lamont> and yes, I'm in a bit of an interesting mood today
[06:24] <seb128> mjg59: yes, looks like the gst-plugins-base0.10 version we have is enough, I'll do the change and upload
[06:24] <mjg59> seb128: Thanks!
[06:25] <seb128> no problem ;)
[06:25] <dholbach> iwj: what do you think about bug 63506?
[06:25] <ubotu> Launchpad bug 63506 in adduser "Mistake in deluser.conf manpage" [Undecided,Confirmed]  https://launchpad.net/bugs/63506
[06:27] <dholbach> thanks lamont
[06:33] <iwj> dholbach: I think we should send the patch to the Debian BTS and we shouldn't bother with it.  It's hardly the kind of thing worth carrying a diff for, surely ?
[06:33] <iwj> I mean, shouldn't bother patching our package.
[06:33] <dholbach> iwj: ok
[06:33] <iwj> Do you agree ?  I'm happy to forward it if you like.
[06:34] <iwj> ("hash" is the correct term.)
[06:34] <dholbach> I think that the patch author could do that
[06:34] <iwj> Yes.
[06:34] <iwj> :-)
[06:34] <dholbach> ok good
[06:35] <dholbach> calc: can you add the patch on bug 134112 to your next upload?
[06:35] <ubotu> Launchpad bug 134112 in openoffice.org "added Xb-Npp-xxx tags accordingly to "firefox distro add-on suport" spec" [Undecided,New]  https://launchpad.net/bugs/134112
[06:35] <dholbach> it looks quite straight forward
[06:36] <dholbach> we need more people going through the sponsoring queue and assigning reviews to people
[06:36] <dholbach> and I need to fix http://daniel.holba.ch/sponsoring/ - I'll do that next week, when I'm home again
[06:38] <seb128> ah, you changed the team to send mails on a list
[06:38] <seb128> that explain why I didn't get sponsoring mails for some time
[06:38] <dholbach> yeah, we talked about that a week or two ago
[06:38] <dholbach> that was decided in the meeting
[06:38] <seb128> right, I didn't notice it would stop it to send me mails
[06:39] <dholbach> I didn't think it'd do that
[06:39] <seb128> well, when a team has no list all the members are mailed
[06:39] <TomaszD> hello, I'm the editor of a special edition Linux+ magazine about the upcoming Ubuntu 7.10. I'm currently writing articles about it and I need to get one answer. Will downloading language packages during installation work for the final version? Because it does not work at the moment
[06:40] <seb128> TomaszD: that's likely a bug we will fix yes
[06:40] <TomaszD> seb128, ok, thanks.
[06:40] <dholbach> calc: also please check out the patch on bug 5462, if you have the time?
[06:40] <ubotu> Launchpad bug 5462 in mc "Dutch translation: wrong shortcut" [Medium,Confirmed]  https://launchpad.net/bugs/5462
[06:40] <seb128> TomaszD: I don't work on ubiquity though, is that known in launchpad?
[06:40] <seb128> TomaszD: maybe evand or cjwatson know about it
[06:41] <TomaszD> seb128, I'm not sure, but it's a bug that kind of stands out
[06:41] <TomaszD> so they probably know about it
[06:41] <TomaszD> I think I even saw it mentioned somewhere, but that's as vague a statement as they get
[06:43] <cjwatson> TomaszD: I hadn't noticed that bug, but I'd like to fix it; could you file it with details (attach /var/log/syslog to the bug)?
[06:43] <TomaszD> cjwatson, no problem, does the syslog stay after installation on the drive where I installed ubuntu?
[06:43] <evand> I believe it's bug 131294 , which is assigned to me, but I haven't had a chance to review yet.
[06:43] <ubotu> Launchpad bug 131294 in ubiquity "does not install language packs for the target language" [High,Confirmed]  https://launchpad.net/bugs/131294
[06:44] <TomaszD> ahh, I knew I saw it somewhere!
[06:44] <cjwatson> TomaszD: /var/log/installer/syslog after installation
[06:45] <TomaszD> cjwatson, I'll attach that to this bug report soon
[06:58] <TomaszD> cjwatson, attached
[06:58] <TomaszD> oops, mixed up your names, requested by cjwatson not seb128
[06:58] <TomaszD> I have to go now, bye
[06:58] <seb128> TomaszD: that's ok, thanks
[07:05] <seb128> mjg59: the new patch is still buggy, the volume icon is not updated correctly
[07:05] <mjg59> seb128: Hm.
[07:05] <mjg59> seb128: I'll look into it.
[07:05] <seb128> thanks
[07:06] <mjg59> seb128: If you could put your package somewhere, that would help
[07:06] <seb128> mjg59: I'll upload the package with the buggy patch for now
[07:06] <mjg59> Ok, cool
[07:06] <seb128> if you have a fix feel free to apply and upload ;)
[07:06] <mjg59> Will do
[07:12] <snikker> why if a "filename.templates" in (in the po folder) start with a comment (#) or a blank line, the templates file in the packaged version (with debuild) start with 2 blank lines?
[07:26] <gustavold> hi, where the glib's function g_log() sends the data to? stdout? Is there a way to modify it, for example sending it to syslog ?
[07:27] <snikker> why if a "filename.templates" in (in the po folder) start with a comment (#) or a blank line, the templates file in the packaged version (with debuild) start with 2 blank lines? This happen in dapper
[07:28] <ion_> Does it echo in here, or is it just me?
[07:29] <seb128> gustavold: that's not really the right chan to ask coding questions
[07:29] <gustavold> seb128: where should I?
[07:29] <seb128> gustavold: by default it sends the log to stdout or stderr, depending of the level
[07:29] <seb128> you can g_log_set_handler () to change the behaviour
[07:30] <seb128> gustavold: not sure, #gnome on gimpnet maybe
[07:31] <gustavold> seb128: ok, thank you
[07:32] <ion_> utt
[07:32] <ion_> Whoops
[07:33] <ion_> I was typing :screen mutt, but in the middle of that, the screen window closed and the rest of the line went to the program in the remaining window, namely irssi. :-)
[07:37] <mathiaz> ogra: do you remember why pitti doesn't want ot use dbconfig-common for moodle ?
[07:38] <mathiaz> ogra: and also why not use wwwconfig-common ?
[07:38] <ogra> first of all he didnt want it ust for moodle in main
[07:38] <ogra> second he didnt want to *just replace* a security broken system with one thats only slightly better (in his opinion)
[07:39] <mathiaz> ogra: you're talking about dbcommon-config or wwwconfig-common ?
[07:39] <ogra> the clear advice he made was to replace wwwconfig-common with plain scripts for mysql and postgres creation
[07:39] <ogra> mathiaz, both
[07:40] <mathiaz> ogra: ok. Thanks for the clarification.
[07:40] <ogra> wwwconfig-common was refised by the security team
[07:40] <ogra> *refused
[07:40] <ogra> dbconfig-common would only replace it ... have a slightly better security but wouldnt really gain anything
[07:40] <ogra> but we'd still have that extra dep
[07:41] <mathiaz> ogra: ok. But it seems that there is a need for a common way to handle database setup.
[07:41] <ogra> mathiaz, i personally really dont care if it has either, i just want it in main
[07:41] <mathiaz> ogra: I see your point. I'll discuss that with pitti when he's back.
[07:42] <ogra> and i dont want pitti to freak out if he comes back and throw it out again :)
[07:42] <ogra> so the directive from my side was, replace the helper scripts with plain postinst stuff ones
[07:42] <ogra> -ones
[07:43] <ogra> seems moquist made some good progress n the mysql fron here ...
[07:43] <mathiaz> ogra: that makes sense then.
[07:43] <mathiaz> ogra: do you wanna get it into main for gutsy ?
[07:43] <ogra> but we have tons of postgres users out there ... so that needs to be supported as well
[07:43] <ogra> mathiaz, i wanted it in main for breezy :P ... indeed i do :)
[07:44] <mathiaz> ogra: I see... Why not drop mysql then ?
[07:44] <mathiaz> ogra: and just support postgresql
[07:44] <ogra> postgres you mean
[07:44] <ogra> moquist doesnt have any postgres support in yet
[07:44] <ogra> and there are likely as many postgres as mysql users
[07:45] <mathiaz> ogra: well. I've seen some code about posgres.
[07:45] <mathiaz> ogra: ok. So you wanna support both explicitly.
[07:45] <ogra> yep
[07:46] <moquist> ogra: I uploaded a version with postgres support last night.
[07:46] <ogra> until now i always said i'll rather leave it in universe than having it crippled ... but we have some projects where i'll need it in the future
[07:46] <moquist> ogra: I uploaded a version with *tested* postgres support last night.
[07:47] <moyogo> cjwatson: did you get a chance to look at updating xkeyboard-config?
[07:47] <ogra> moquist, depends if you can please iwj with them :)
[07:48] <moquist> ogra: See your inbox when you get a chance. I've got questions in there that somebody needs to answer, sometime. There are three questions, and I think that only the first one absolutely *must* be answered before this package can get into main.
[07:48] <ogra> i'll have a look
[07:53] <ogra> moquist, apache2 as a conf.d dir afaik
[07:53] <ogra> *has
[07:54] <ogra> as well as sites-available and mods-available ...
[07:54] <ogra> moquist, so we should be able to just drop moddle configs in there and use the native apache tools to enable them
[07:55] <ogra> moquist, i dont really care about old apache ... and ssl in the 2 version shouldt behave differently to the non ssl variant, its just some config change
[07:57] <moquist> ogra: I hadn't checked until now, but the package is already using apache2/conf.d correctly. I believe the preinst script is just trying to clean up from older versions of the package (of apache?) that didn't use a conf.d directory [correctly] .
[07:57] <ogra> moquist, for point 2 just dont ask for these values if you dont need them :)
[07:57] <ogra> ah, k
[07:57] <ogra> i think we can ignore apache1 ...
[07:57] <moquist> ogra: Right, which is what I figured, except that if they want postgres running somewhere other than localhost then we need to know so we can bail. Or maybe we just don't ask, and the package assumes localhost for postgres. ?
[07:58] <ogra> have a question for it ("you run postgres, by default we do that locally, do you want a different setup")
[07:59] <ogra> preseed that and make sure it doesnt get asked on CD installs
[07:59] <ogra> (since we'll have a defined setup there anyway)
[08:01] <ogra> moquist, for point 3 we have dependencies ;)
[08:01] <moquist> The question should also inform them that they'll have to set up the DB manually if they don't take the default. It's always annoying when software says "Do you want the default?" and you say "no" and then it says "Fine then, I'm going to stop helping you."
[08:01] <moquist> ogra: Right; I wasn't sure if we could/should change them.
[08:01] <ogra> right, something in that direction
[08:01] <ogra> sure, lets change them as we need
[08:01] <moquist> great
[08:02] <ogra> you should in any case have a: postgresql-client|mysql-client in the deps ...
[08:02] <ogra> the servers in a similar way in Recommends
[08:03] <ogra> if we need more we'll do that through edubuntu-server
[08:03] <ogra> (thats what it's for :) )
[08:04] <ogra> did upstream ever answer your mailping ?
[08:04] <moquist> Hmm. These deps are already a bit messed up; we're always getting postgresql-client and libdbd-mysql-perl. That doesn't seem right.
[08:04] <ogra> (upstream == debian here)
[08:04] <moquist> ogra: No, but I only pinged once.
[08:04] <moquist> And I didn't really have anything done at the time.
[08:04] <ogra> well, if we're done lets offer him code :)
[08:05] <mayeco> when we have a kde4 project in launchpad?
[08:05] <ogra> ready made code is more tempting :)
[08:05] <moquist> *when* we're done. we definitely aren't yet.
[08:05] <iwj> ogra: I was redoing the cryptsetup MIR and I saw a statement presumably from you saying `note that there are some motu tools that even generate MIRs from the template page'.  Can you point me at those please ?
[08:05] <iwj> ogra: Because I don't think that's a very good idea.  The point of a report is to summarise the results of investigation and analysis, not just to repeat some formula.
[08:05] <ogra> iwj, LaserJock wrote some stuff but dropped them again when the format changed
[08:06] <iwj> Oh, good.
[08:06] <iwj> I'm not trying to make life difficult, obviously.
[08:07] <iwj> In fact, that's almost precisely it.  The point of the report isn't just a hoop to jump through, it's to document the results of the investigation so that we can make a sensible decision, and so on.
[08:07] <ogra> right :)
[08:08] <iwj> If the formatting of the report is harder than the figuring out what to write in it, then we're doing something wrong.
[08:08] <ogra> we should even have deeper discussions about the apps we include imho ... but thats a matter of time to invest we still lack manpower for imho
[08:08] <iwj> I think we'll have to realise that we're constantly going to lack manpower.
[08:09] <ogra> well, but compare the clean small main of warty with what we have today :)
[08:10] <iwj> I don't think it's a huge problem to have much stuff in main.  Having it installed by default is a different matter.
[08:11] <ogra> well, but a constantly growing main has indeed some relation to constant lack of manpower
[08:11] <iwj> True.
[08:11] <iwj> But that's just the world of software, really.
[08:12] <ogra> indeed
[08:12] <Riddell> mayeco: what would you need one for?
[08:13] <iwj> siretart: Could you please try the cryptsetup .debs from http://www.chiark.greenend.org.uk/~ian/d/cryptsetup/ ?  I think it shouldn't break anything for you but I haven't tested it at all so beware.  I hope you don't mind me using you as alpha-testers :-).
[08:13] <iwj> sladen: ^
[08:13] <mayeco> Riddell: hi you are the kde mantainer, dont you thing will be more easy to find kde4 bugs?
[08:14] <iwj> If and when I get a `yes' from you I'll upload and I think that will allow us to promote the package.
[08:14] <mayeco> Riddell: dont you think?
[08:17] <Riddell> mayeco: I don't think it's very useful to report upstream kde 4 bugs to launchpad, you can report packaging bugs of course
[08:18] <mayeco> Riddell: ahhh... so bug should go to kde.org?
[08:19] <Riddell> mayeco: bugs.kde.org if you think it'll be helpful to them (but given the state of kde 4, there's plenty needing fixed without bugs being reported)
[08:20] <mayeco> Riddell: yeah... do you build kde4 is very buggy?
[08:20] <mayeco> Riddell: but is really kool
[08:38] <LaserJock> Riddell: do you know who's archive day it is today?
[08:39] <Riddell> LaserJock: nobody's
[08:39] <Riddell> nor tomorrow either since pitti is away
[08:39] <LaserJock> Riddell: well, NewPakackageFreezeUniverse just happened
[08:40] <LaserJock> and there was some confusion as to the actual time it went into effect
[08:40] <LaserJock> should an email to ubuntu-devel suffice to let ubuntu-archive know when we declared it frozen?
[08:41] <Riddell> LaserJock: ubuntu-devel-announce I'd say
[08:41] <Riddell> LaserJock: but I don't see any point in setting a to-the-minute deadline
[08:41] <Riddell> just let people have until the end of their day
[08:42] <LaserJock> well, the release schedule says that all deadlines are 00:00 UTC
[08:42] <Mithrandir> ScottK: no, it's not ok.  It doesn't give redistribution rights.
[08:43] <ScottK> Mithrandir: Thanks.
[08:52] <Mithrandir> I think specifying the freeze down to the minute is silly.
[08:52] <LaserJock> well, I know
[08:52] <LaserJock> but with Feisty we had some problems
[08:52] <LaserJock> and packages that were supposed to get in didn't etc.
[08:52] <LaserJock> so we need to be clear with ubuntu-archive what packages they need to review
[08:52] <LaserJock> and if we don't set a hard deadline we tend to get people pushing it and pushing it
[08:52] <LaserJock> for the New Packages Freeze anyway
[08:52] <Mithrandir> from -archive's point of view, anything _not in_ by a freeze doesn't matter, and needs an exception.
[08:52] <Mithrandir> whether it's uploaded half a year or a day in advance doesn't matter.
[08:52] <LaserJock> in the past we've considered that anything uploaded to NEW by freeze should be reviewed
[08:52] <Mithrandir> then there is a disconnect there.
[08:52] <LaserJock> yes, which causes problems like every release
[08:53] <bddebian> Doh
[08:53] <LaserJock> it's a big deal for contributors when the *finally* get their package through REVU
[08:53] <LaserJock> and then it sits in NEW and doesn't make it into the release
[08:53] <sistpoty> hm... imo the gist of new freeze is to get devs focussed on bug fixing, right? so processing everything in the new queue until package freeze seems like a good idea to me
[08:54] <bddebian> Mithrandir: Are you saying from the archive admins point of view anything not already accepted into the archive by the freeze is out?
[08:55] <Mithrandir> bddebian: that's always been my understanding as a member of both the release and the archive team, yes.
[08:56] <LaserJock> that hasn't been the MOTU understanding for the last 2 releases anyway
[08:57] <bddebian> Yikes that would have been good to know
[08:58] <Mithrandir> ScottK: mailing -archive with a list should be fine.
[08:58] <LaserJock> well, I think the key is that whatever MOTU decides to do that the archive team needs to be informed
[08:58] <ScottK> Mithrandir: OK.  I'll find a co-conspirator in motu-uvf and do that.
[08:58] <ion_> So, seems like qtpfsgui (in the depomaniak repository) isnt going to get included. :-(
[08:58] <ScottK> soren: Are you awake/online?
[08:58] <Mithrandir> _MMA_: without an exception, you will not have your thing accepted, with it, you might have it accepted, but you don't have any guarantees.
[08:58] <asisak> ion_: we have uploaded it well before the freeze
[08:59] <bddebian> LaserJock: Doesn't that need to work the other way?  We can't "inform" the admins of anything, they have the power, no?
[08:59] <_MMA_> Mithrandir: Because of the work involved, especially for new contributors, it should.
[08:59] <LaserJock> bddebian: well, that's the thing
[08:59] <ion_> asisak: Very recently? Thats great to hear.
[09:00] <asisak> ion_: 2007-08-28 13:20 CEST
[09:00] <LaserJock> the problem is that there is a disconnect (sometimes a big one) between what gets uploaded and what actually makes it in
[09:00] <LaserJock> it's very harmful for contributors if they get something all the way through REVU
[09:00] <LaserJock> it's good packaging and it's all set
[09:00] <_MMA_> It's very deterring just to go through the packaging work. Then to have to go through the exception process and it _still_ not get in. That wont keep people contributing.
[09:01] <LaserJock> and it doesn't make it in because ubuntu-archive couldn't get to it in time
[09:01] <Mithrandir> _MMA_: I don't have 24 hours a day extra to pull out of my magic hat.  Do you?
[09:01] <asisak> ion_: it sits in the NEW queue
[09:01] <LaserJock> Mithrandir: you don't need an extra day
[09:01] <_MMA_> Mithrandir: Sure, but if you're the only one shouldering this, things are very wrong.
[09:01] <Mithrandir> really, it's not like -archive is conspiring to not have packages in the archive, it's just that we don't have the time to do so.
[09:02] <asisak> Mithrandir: I was sure packages uploaded in time will be processed.
[09:02] <Mithrandir> _MMA_: I'm not, but all of the archive team has other things to do too.
[09:02] <LaserJock> but that's the deal though Mithrandir
[09:02] <LaserJock> if it goes by upload time then you don't have to worry about it so much
[09:02] <_MMA_> Thats where I think we're failing. People are taking on too much.
[09:03] <ion_> asisak: Ok, thanks.
[09:03] <Mithrandir> asisak: I don't know where you got that impression from, since it was certainly nothing like what I was trying to communicate when I was release manager.
[09:03] <LaserJock> we just need to know what will get processed, not *when* it will get processed
[09:03] <LaserJock> Mithrandir: that has been the MOTU understanding since dapper
[09:04] <Mithrandir> LaserJock: that has not been discussed with those who actually process packages, nor with the release team.
[09:04] <Mithrandir> LaserJock: hence, send a list from a member of motu-uvf granting an exception for the packages that should go in.
[09:04] <Mithrandir> there's still no magic in them being accepted, but they might be processed then.
[09:04] <Mithrandir> _MMA_: if you think that I should resign from the release and archive teams, I could do that, sure.  I don't think that'd make more packages get through.
[09:04] <_MMA_> LaserJock: But shouldn't "what" be determined by a date? Since getting involved I was under the impression that what the freeze dates were for. (looks like you were as well)
[09:05] <LaserJock> Mithrandir: which packages need exceptions then?
[09:05] <_MMA_> Mithrandir: You're taking this personally. There's no need.
[09:05] <Mithrandir> _MMA_: no, I'm explaining to you what the consequences of your suggestions would be.
[09:06] <bddebian> I still think it would be ideal if we could have a Universe archive admin but I don't know if that is feasible given the resources
[09:06] <Mithrandir> LaserJock: http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/new/ is the current NEW queue.
[09:07] <_MMA_> I made no specific suggestions. My only one would to be that we take on less and have specific jobs that we can complete as expected.
[09:07] <Mithrandir> bddebian: we don't have the infrastructure to be granting per-component archive admin privileges.
[09:08] <bddebian> Mithrandir: I know.  As I said, it would be nice.
[09:08] <Mithrandir> yeah.  Like ponies.
[09:08] <LaserJock> Mithrandir: so you're saying everything that is currently in the NEW queue needs an exception?
[09:08] <bddebian> ponies!!
[09:09] <Mithrandir> LaserJock: anything source, I'd say.
[09:10] <Mithrandir> I don't think we're going to have a freeze for binaries.
[09:10] <LaserJock> ok, but that's clearly unacceptable
[09:10] <LaserJock> we gotta figure something out here
[09:10] <_MMA_> lol. Great.
[09:10] <LaserJock> there is a package from the 7th in there
[09:11] <sistpoty> Mithrandir: imo using exceptions to get a fixed date for new packages freeze is a workaround of the policy. Hence we should fix the policy instead.
[09:11] <Mithrandir> if you want to grant a blanket exception, find out what's from before the freeze and mail that list to -archive.
[09:11] <Mithrandir> it really doesn't seem that hard to me.
[09:12] <sistpoty> if it's only about getting that list, let's make that policy that motu-uvf could take care of, what do you think?
[09:13] <sistpoty> Mithrandir: should I send a mail to -devel for further discussion on the topic?
[09:14] <Mithrandir> sistpoty: sure, feel free.
[09:14] <Mithrandir> I'm not going to be able to respond before Monday, but others might.
[09:14] <sistpoty> Mithrandir: ok, will do.
[09:15] <sistpoty> sure, I've got quite a mail backlog here as well ;)=
[09:19] <_MMA_> Mithrandir: So say the list sent to -archive contains everything in NEW? Or even half? What then? The work involved there can be the same as just processing it now.
[09:20] <mjg59> seb128: Ok, I see the breakage you're referring to
[09:20] <Mithrandir> _MMA_: "just processing" NEW in the current state is probably a full day's work.
[09:21] <_MMA_> Ok.
[09:22] <LaserJock> well, there's not a huge rush in getting it processed
[09:22] <LaserJock> people just want stuff they uploaded before the Freeze to make it to Gutsy
[09:23] <bddebian> People in Hell want ice water ;-P
[09:23] <_MMA_> Thing is, if its not processed in a timely manner they can miss the date to even file an exception.
[09:23] <Mithrandir> and people in Ubuntu want ponies.
[09:24] <LaserJock> it's not that big of a deal
[09:24] <LaserJock> just process what's in the queue up until Freeze
[09:24] <LaserJock> if that takes a week, fine
[09:24] <_MMA_> Well it was for us. ;) We had to resort to using our own repo because of it.
[09:24] <LaserJock> 2 weeks, I'm ok with that
[09:25] <LaserJock> _MMA_: no, that wasn't the problem
[09:25] <_MMA_> Even after freeze exceptions our packages weren't processed. Thats what happened.
[09:29] <_MMA_> We relied on "the system" instead of being the "squeeky wheel" like this time around. (which sux)
[09:30] <seb128> _MMA_: "us" being?
[09:30] <_MMA_> Ubuntu Studio
[09:30] <seb128> you are in such in a hurry than waiting a few days for new packages is not acceptable?
[09:31] <_MMA_> No. Im commenting on my personal experiences with the freezes and exception process I went through with Feisty.
[09:32] <seb128> the ubuntu-archive team got new member this cycle so it should be better
[09:32] <_MMA_> And thats the thing. :) With Feisty we did "wait a few days". Then that turned into weeks. Then we needed exceptions. Ant still the packages didnt make it into the archives.
[09:33] <LaserJock> seb128: he's saying that the packages *never* got processed for that release, even after an exception
[09:33] <asisak> seb128: I guess the issue is not that you have to wait. It is that you submit new packages before the appropriate freeze.
[09:33] <asisak> seb128: and they are not processed, though.
[09:34] <LaserJock> yes, we aren't complaining about how long it takes to get them processed
[09:34] <_MMA_> seb128: Oh sure. It has been better totally. Thanx to Riddlel and us not relying on "the process" we go all our packages in this time. I just worry about new people coming in now and what they will take from this if they hit what I did the 1st time around. ;)
[09:34] <LaserJock> we just need know that they *are* going to get processed at some point before release
[09:34] <_MMA_> s/go/got
[09:36] <sistpoty> if you wait a few more minutes, you can proofread my mail to get this sorted out ;)
[09:36] <seb128> LaserJock: that's weird
[09:36] <seb128> asisak: well, don't summit it 1 hour before the freeze and except having an archive admin around to jump on it
[09:36] <mjg59> seb128: Ah, got it
[09:36] <mjg59> seb128: cb_volume needs to force a refresh
[09:36] <seb128> mjg59: ah, cool
[09:37] <seb128> mjg59:   http://bugzilla.gnome.org/show_bug.cgi?id=370937 if you want to comment on the upstream bug
[09:37] <ubotu> Gnome bug 370937 in mixer "Exessive CPU Utilisation" [Minor,New]
[09:37] <mjg59> Previously it didn't need to, since that would arrive after the scheduled update
[09:37] <LaserJock> seb128: we've got packages going back to the 7th in NEW!
[09:37] <seb128> LaserJock: it's not even 1 month and it's middle of summer with people on holiday
[09:38] <seb128> LaserJock: I don't think it's really an issue
[09:38] <asisak> seb128: sure. I think it still would be more reasonable to have a deadline that means: I can upload packages, and they will (eventually) get processed.
[09:38] <seb128> asisak: that's the case now, no?
[09:39] <seb128> we usually try to clean the queue before a freeze
[09:39] <asisak> seb128: no. :)
[09:39] <_MMA_> seb128: from the chat here obviously not.
[09:39] <_MMA_> :(
[09:39] <seb128> asisak: example of package which had issues this cycle?
[09:40] <asisak> As far as I understand the words of Mithrandir mean exactly the opposite. Packages in the NEW queue at the moment of the freeze need an exception.
[09:40] <LaserJock> seb128: look at NEW! Mithrandir says that none of the source will get processed with an exception
[09:40] <LaserJock> *without
[09:40] <asisak> seb128: not a concrete package. Only in theory...
[09:41] <mjg59> seb128: I'll comment upstream and upload
[09:41] <seb128> mjg59: thanks
[09:41] <bddebian> Damn are we still arguing this? :-)
[09:41] <sistpoty> ok, anyone want to proofread http://paste.ubuntu-nl.org/35700/ ? (and any good ideas welcome, though of course you could also follow up then *g*)
[09:41] <_MMA_> bddebian: Who's arguing?
[09:41] <seb128> asisak: if you want my opinion people complain too much ;)
[09:41] <seb128> that could use clarification though
[09:41] <asisak> s/cries/hacks/
[09:41] <seb128> I don't think there is a clear policy
[09:42] <sistpoty> seb128: yes, and that's imo the source of problems ;)
[09:42] <seb128> I did NEW processing until late yesterday and I don't think we have such of an issue
[09:42] <LaserJock> seb128: there are packages weeks old in NEW
[09:42] <_MMA_> seb128: How so? I'm sure Laserjock and people in -motu think it pretty clear.
[09:43] <seb128> LaserJock: against, it's summer and people tend to take holidays, you can't blame them for that
[09:43] <seb128> it creates some delay
[09:43] <ScottK> sistpoty: Dunno if you want to deal with it in this mail or not, but I think there are two issues: 1.  What to do for gutsy since there clearly is a misunderstanding.  2.  What to do for Hardy Herron and follow.
[09:43] <LaserJock> seb128: what the heck are you talking about?
[09:43] <seb128> LaserJock: NEW processing is made by people, not robots
[09:43] <LaserJock> I'm not complaining about them not getting reviewed in a timely fashion
[09:43] <seb128> if it takes some time it's because some people are not there and other are busy
[09:44] <seb128> so stop saying that items are weeks old there
[09:44] <LaserJock> I *said* several times, the issue is what happens at the freeze
[09:44] <seb128> that's not really an useful information
[09:44] <LaserJock> they are that old!!
[09:44] <_MMA_> seb128: There is.
[09:44] <seb128> yes, and I'm telling you why
[09:44] <LaserJock> I uploaded a package on the 22nd
[09:44] <seb128> because people are on holidays for some weeks
[09:44] <LaserJock> I want assurance that it will get proccessed
[09:44] <_MMA_> But the "why" shouldnt matter.
[09:44] <LaserJock> I don't care *when*
[09:44] <LaserJock> I just want it in Gutsy
[09:44] <Daviey> There should be more people doing it then.. there is the talent
[09:44] <seb128> LaserJock: ok, so the fact they are weeks old doesn't matter there
[09:45] <LaserJock> seb128: no
[09:45] <Daviey> holiday's etc are not an excuse imo
[09:45] <seb128> what we need to define is if the upload or the processing counts
[09:45] <asisak> seb128: exactly.
[09:45] <LaserJock> but Mithrandir was saying that they won't get processed without an exception
[09:45] <_MMA_> If the people involved in processing, cant process, why are they doing it? Its such a crutial part.
[09:45] <seb128> LaserJock: we need a policy, we don't have one for that at the moment afaik
[09:45] <_MMA_> *crucial
[09:45] <Daviey> ompaul is here to sort it out.. don't worry :)
[09:46] <seb128> _MMA_: everybody deserves some holidays, you are not fair there
[09:46] <LaserJock> seb128: MOTU have had one, but it seems ubuntu-archive didn't know/understnad
[09:46] <ThorstenSick> Hi I am new to ubuntu development, but _maybe: I got a good idea: is it possible to priorize packages of new software ? So new contributors will not be disappointed. Software where older versions have already been checked will have to wait in the queue...
[09:46] <bddebian> haha
[09:46] <seb128> LaserJock: maybe MOTU didn't communicate it clearly out of their land? ;)
[09:46] <Daviey> seb128: true!  not saying that..  but if holidays are getting in the way - there *needs* to be more people.. Ubuntu has the talent
[09:46] <mjg59> ThorstenSick: Packages that are already in the archive do not need reviewing
[09:46] <_MMA_> seb128: Sure. I never said that. If someone goes, someone else takes over.
[09:47] <seb128> _MMA_: easy to say, not easy to find people trusted, not too busy, etc
[09:47] <seb128> _MMA_: and I don't think the current delay is that bad
[09:47] <sistpoty> ScottK: ok, thanks for the suggestion, will put it in
[09:47] <seb128> we just need to say we allow packages uploaded before the freeze
[09:47] <LaserJock> seb128: well, we understood that ubuntu-archive had the same policy
[09:48] <Daviey> Yes.. /me grabs his lighter fluid to squirt on the ML
[09:48] <_MMA_> seb128: Again. The issue isnt the delay. Its things not getting processed period. :)
[09:48] <seb128> LaserJock: I'm telling you that I'm not aware of a policy
[09:48] <seb128> _MMA_: things always get processed
[09:48] <seb128> _MMA_: the queue was empty one month ago
[09:48] <_MMA_> Not true at all.
[09:48] <seb128> we have nothing waiting for over a month there
[09:48] <seb128> and everything get either accepted or rejected
[09:49] <seb128> _MMA_: well, I've access to the queue and do NEW work almost every week
[09:49] <seb128> I can tell you it was empty some weeks ago
[09:49] <seb128> and that I look quite often at it
[09:49] <joejaxx> ScottK: +m ftw?
[09:49] <LaserJock> seb128: this happens every release though it seems
[09:49] <Daviey> GOTO $(now-10mins)
[09:49] <seb128> LaserJock: can't speak for previous cycle, I'm one of the new members
[09:50] <seb128> the team was too small previous cycle
[09:50] <seb128> it should somewhat scale now
[09:50] <_MMA_> Sorry man. You havnt seen everything Ive said. :) I had 4 packages sitting in NEW that werent processed for Feisty. Nobody touched them then I was told they would need exceptions. Still were never processed. Same thing will happen now.
[09:50] <Daviey> seb128: and it seems that the team is still too small - if holidays are an issue
[09:51] <seb128> Daviey: holidays and distro team workload create some delay
[09:51] <_MMA_> Daviey: +1 but like he said, "easy to say, not easy to find people trusted, not too busy, etc"
[09:51] <seb128> that's not that of an issue thoufg
[09:51] <seb128> though
[09:51] <seb128> we will catch up soon
[09:51] <seb128> don't base your opinion on previous cycle though, the team was too small
[09:52] <seb128> it should be better now
[09:52] <_MMA_> seb128: So _you're_ saying everything currently in NEW _won't_ need an exception?
[09:52] <sistpoty> ok, mail sent to -devel, I guess it might be a good thing to follow up for the discussion *there*
[09:52] <ogra> and for the policy as far as universe is concerned the motu council should define whats the deadline (upload or build)
[09:52] <mjg59> _MMA_: Seb is not in a position to say that.
[09:52] <Chipzz> seb128: sure it matters that they are weeks old. If they are weeks old, that implies that other packages got processed right away
[09:53] <ScottK> CRON: "ScottK quietly suggests people stop arguing on IRC and we take this to the mailing list."
[09:53] <_MMA_> mjg59: Sure. And who is?
[09:53] <sistpoty> ogra: MC has until now merely acted to discuss new applications, since the motu team can make decisions during meetings
[09:53] <mjg59> _MMA_: The archive team as a whole should determine this policy, probably in conjunction with the release team.
[09:54] <Chipzz> seb128: since you claimed you had been doing archive duties yesterday
[09:54] <ogra> sistpoty, imho defining procedures and freze dates if part of the MC work
[09:54] <mjg59> If no policy currently exists, then arguing on IRC will not achieve anything
[09:54] <ogra> *is
[09:54] <mjg59> Chipzz: Correct, NEW is not processed as a fifo
[09:54] <Chipzz> and that's exactly one of the complaints I think
[09:54] <Chipzz> starvation
[09:54] <Daviey> mjg59: why not?  that would seem logical?
[09:54] <mjg59> Some packages are more important than others
[09:54] <mjg59> Some packages are easier to process than others
[09:55] <sistpoty> ogra: sure, but only together with MOTUs not merely from a place above... but imo that's a completely different discussion ;)
[09:55] <mjg59> That's not going to change
[09:55] <_MMA_> mjg59: I dont feel we're arguing. :) There seems to be a slight miss-communication and lack of man-power in the end.
[09:55] <Chipzz> mjg59: sure I understand that. but that doesn't mean that less important/easy packages should be delayed again and again
[09:55] <Chipzz> mjg59: you need to do them at one point
[09:55] <mjg59> They will be done at some point
[09:55] <ogra> sistpoty, right, i just wanted to point out that the issue for a universe freeze should be brought to the MC instead of having a wild discussion in -devel ;)
[09:55] <_MMA_> mjg59: "miss-communication" as far as policy.
[09:56] <Daviey> Chipzz: I apprciate that some packages are show-stoppers if not done first
[09:56] <Daviey> Ie halting an beta release
[09:56] <Chipzz> I didn't say I didn't (appreciate that). I'm saying you cannot keep using that as an excuse
[09:57] <ScottK> I really don't think all this finger pointing is helpful.
[09:57] <soren> ScottK: Wazzup?
[09:57] <Chipzz> may be a hard limit on how long packages can be in the new queue
[09:57] <mjg59> Chipzz: Do you have any evidence that there are packages that have never been processed?
[09:57] <ScottK> soren: I'll PM you...
[09:57] <Chipzz> mjg59: I wasn't saying never
[09:57] <sistpoty> ogra: sure, but archive admins have something to say to this as well ;)
[09:57] <soren> ScottK: Uh, is it secret? Cool!
[09:57] <bddebian> heh
[09:57] <LaserJock> mjg59: there are some that get dumped to the next release
[09:58] <Chipzz> mjg59: I'm guessing that the complaint is about too long delays
[09:58] <sistpoty> sheesh, that was denglish again
[09:58] <mjg59> Chipzz: No, the complaint is nothing to do with delays
[09:58] <ogra> sistpoty, about their job of processin probably, but the MC should set the dates and policies for the devs
[09:58] <ogra> sistpoty, as the TB does for main
[09:58] <mjg59> The complaint is whether packages in NEW before UVF should still enter the release
[09:59] <Chipzz> but anyway, something like: sure there may be showstoppers, but if a package is longer in the queue than say 2 weeks (arbitrary number), you have to do that first?
[09:59] <sistpoty> mjg59: not uvf, but npf... we got a new tla there ;)
[09:59] <mjg59> sistpoty: Eh, whichever :)
[09:59] <sistpoty> hehe
[09:59] <mjg59> But it's a legitimate question, and one that should be discussed with the archive, release and motu bodies
[09:59] <bddebian> sistpoty: ach the acronyms.. my eyes....
[09:59] <Chipzz> which may be an incentive to do the less important packages sooner rather than later
[09:59] <mjg59> Not argued on IRC
[09:59] <CharlesEdwardPax> Hi, folks, I'm hoping someone can help me get started with the new PPA system on Launchpad.
[10:00] <CharlesEdwardPax> I have a handy little application in Python using libglade called Gladex (http://www.openphysics.org/~gladex/), which is hosted in Launchpad bzr. I hacked together a Makefile that will output a binary package when the user types "make package"; this is located in the bzr repository. This is fine for personal use and distribution to those who don't mind poking around a bit. However, in the hopes of distributing to a wider
[10:00] <CharlesEdwardPax> The problem I'm having is making a source package that won't make PPA's automated build system puke. All the tutorials and documentation I've found are more complex than I would hope for.
[10:00] <CharlesEdwardPax> Does anyone have an example or can point me to some good information on how I need to structure the code in the bzr repository and what files must be included in the bzr repository?
[10:00] <Daviey> s/argued/discussed
[10:00] <Kmos> CharlesEdwardPax: ask on #launchpad
[10:01] <mjg59> CharlesEdwardPax: My understanding was that PPA packages need to conform to the same standards as normal distribution packages
[10:01] <seb128> re
[10:01] <seb128> Chipzz: sure I process feature goals before random games
[10:01] <Daviey> CharlesEdwardPax: keep in mind that PPA won't currently sign packages
[10:01] <seb128> Chipzz: you think we should not apply a priority for goals?
[10:02] <Chipzz> seb128: it's a simple question of scheduling
[10:02] <Chipzz> even the kernel has the same principle
[10:02] <seb128> Chipzz: it's a simple question of being overworked already
[10:02] <seb128> I wanted to 1 hour of NEW handling
[10:02] <seb128> I started with things blocking people
[10:02] <Chipzz> sure there may be important processes, but to prevent starvation, sometimes less important processes get processed first
[10:03] <CharlesEdwardPax> I'm new to packaging, so I don't really know where to start. I've looked at the Ubuntu Packaing Guide, but I can't quite figure things out.
[10:03] <seb128> right, when we are processing "random" things waiting it makes sense to use order
[10:03] <asisak> CharlesEdwardPax: #ubuntu-motu is better place for this
[10:03] <Daviey> CharlesEdwardPax: join #ubuntu-mot --- they will help more
[10:03] <seb128> when you know what is blocking people or what is a gutsy goal you start with those though
[10:03] <Chipzz> seb128: in this concrete example (Ubuntu Studio), packages actually *were* blocking people...
[10:03] <seb128> Chipzz: ubuntu studio packages are not old in the queue
[10:04] <asisak> It seems e.g. we are blocking seb128 now...
[10:04] <Chipzz> seb128: the example was from the feisty release
[10:04] <Chipzz> seb128: I'm sure you can find examples for this release too
[10:04] <seb128> Chipzz: I was not in the team by then and as said don't compare with feisty, the team got several new people since and should scale better now
[10:05] <mjg59> Chipzz: You're being needlessly aggressive. Please tone this down a bit.
[10:05] <seb128> there is 3 items which are 3 weeks old in the queue
[10:05] <seb128> every else is newer than 2 weeks
[10:05] <Chipzz> seb128: btw, please understand, I'm not critisizing you personnally btw ;)
[10:05] <seb128> in the middle of holidays I don't think it's that of an issue
[10:05] <seb128> s/every/everything
[10:05] <seb128> Chipzz: I understand that, don't worry ;)
[10:05] <CharlesEdwardPax> Which would be a better place #launchpad or #ubuntu-motu ?
[10:05] <Kmos> CharlesEdwardPax: both
[10:05] <seb128> I don't think that 2 weeks of waiting in august is an issue though
[10:05] <asisak> CharlesEdwardPax: for development issues #ubuntu-motu
[10:06] <LaserJock> CharlesEdwardPax: if you want to learn how to package #ubuntu-motu
[10:06] <Daviey> CharlesEdwardPax: packaging #ubuntu-motu / #launchpad for PPA
[10:06] <Chipzz> seb128: but who's to say that throwing more resources (ie people) at it actually solves the fundamental problem?
[10:06] <LaserJock> I don't think 2 weeks is bad normally at all
[10:06] <LaserJock> a lot of times Debian is 2 weeks-1month
[10:06] <CharlesEdwardPax> I'll check them out. Thanks, everyone.
[10:06] <Daviey> but 2 weeks right before UVF?
[10:07] <seb128> Chipzz: what do you mean? saying what?
[10:07] <ScottK> CRON: "ScottK quietly suggests people stop arguing on IRC and we take this to the mailing list."
[10:07] <sistpoty> thanks ScottK
[10:07] <LaserJock> but on a 6month release cycle does mean that we need to get stuff processed at some point
[10:07] <seb128> Chipzz: it's easy to say "we need extra volunteers", that's now how it works though
[10:07] <Chipzz> seb128: saying that as ubuntu grows, the new queue may grow bigger and you'll need to add more people again
[10:07] <asisak> Chipzz: Sure, as "Adding manpower to a late software project makes it later"
[10:08] <seb128> Chipzz: we did add several people this cycle
[10:08] <bhale> I don't expect to see Canonical allow volunteers to process NEW
[10:08] <seb128> Chipzz: we added the people who are fit for the job and wanting to do it
[10:08] <seb128> Chipzz: if you know of other people we match the description let we know though
[10:08] <Chipzz> bhale: I was not suggesting that at all; quite the contrary
[10:09] <Chipzz> bhale: pls read what I said
[10:09] <sistpoty> bhale: why not (if no access to the DC were needed)?
[10:09] <Chipzz> 22:06 < Chipzz> seb128: but who's to say that throwing more resources (ie people) at it actually solves the fundamental problem? 22:07 < Chipzz> seb128: saying that as ubuntu grows, the new queue may grow bigger and you'll need to add more people again
[10:09] <bhale> sistpoty: oh, I am thinking of the bad old days. you are correct.
[10:09] <mjg59> Chipzz: If the queue gets impractical for the current team to handle, then the order of processing will make no difference.
[10:09] <sistpoty> bhale: well, we're not there yet ;)
[10:09] <seb128> Chipzz: ?
[10:10] <seb128> Chipzz: there is also ton of bugs without a reply
[10:10] <seb128> sure we could do with extra contributors
[10:10] <Chipzz> what I was implying is rather than adding more people you may also need to impose some rules on how what gets processed
[10:10] <seb128> the things is that volunteer decide by themself what they want to do
[10:10] <mjg59> Chipzz: No, that doesn't help.
[10:10] <pkern> What's the policy for syncing new Debian revisions (for both main and universe, and taking the current point in time into account)?
[10:10] <seb128> that's not up to us to pick somebody and assign him tasks
[10:11] <Kmos> pkern: man requestsync
[10:11] <Chipzz> pkern: make sure there is a valid reason other than "It's new"?
[10:11] <seb128> Chipzz: "stop processing things blocking people or which are goals and process random games nobody cares first because they are waiting longer"?
[10:11] <Chipzz> ;)
[10:11] <Daviey> seb128: That's quite extreme.. that's not what Chipzz means
[10:12] <seb128> Daviey: well, either you force a "first uploaded, first processed" rule which means that
[10:12] <seb128> or you let people act in function of what think should have the priority
[10:12] <seb128> which is what we do now
[10:13] <Chipzz> seb128: what I was proposing was something in between actually ;)
[10:13] <seb128> Chipzz: how would you define it then?
[10:13] <Daviey> But the bottom line is that the team shouldn't be that stretched that they need to prioritise
[10:13] <seb128> Daviey: well, and we should not have bugs without a reply
[10:13] <Daviey> v. true
[10:14] <seb128> Daviey: the issue is that we have too much to do for the number of people we have
[10:14] <Daviey> Some go back to 2005!
[10:14] <LaserJock> Daviey: we'll always be stretched
[10:14] <seb128> and that's not something a rule will make better
[10:14] <Chipzz> seb128: a hard limit on how long something should be in the queue
[10:14] <seb128> Chipzz: how long would be the limit?
[10:14] <Daviey> then it gets dumped if it goes past the hard limit :)
[10:15] <joejaxx> ScottK: i do not think people are getting your hints :(
[10:15] <pkern> Kmos: Thanks. This means that I need to wait for the next Debian mirror pulse at the earliest.
[10:15] <ScottK> No, they aren't.
[10:16] <Chipzz> seb128: say, package n (not-important) is uploaded one week ago, and the (for the sake of argument, here arbitrary chosen) limit is 2 weeks, and you package i (important) which is uploaded now
[10:16] <seb128> what hints?
[10:16] <EvanCarroll> I hope the fonts get a comlete overhaul before gutsy is released. Merge FB puts my DBI at 110,65, dropping all my default font sizes down to 6, still leaves them entirely too big for my liking.
[10:16] <seb128> IRC != mail
[10:16] <EvanCarroll> DPI*
[10:16] <pkern> Kmos: And I don't have my GPG key available on my gutsy QEMU image.
[10:16] <seb128> I don't get those mails yet
[10:16] <joejaxx> ScottK: yeah it is quite unfortunate
[10:16] <Kmos> pkern: that's bad :)
[10:16] <Chipzz> package i gets precedence because it's important and there are no non-important packages in the queue older than the limit (2 weeks)
[10:16] <seb128> Chipzz: we have freezes going on a week for tribe, I don't think 2 weeks is a reasonable delay
[10:17] <seb128> it means people have to process everything in the week after the freeze
[10:17] <pkern> Kmos: Actually the packages I want to sync are currently transitioning from universe to main but I just added missing translations to the Debian packages. (One-line change.)
[10:17] <Chipzz> seb128: like I said, 2 weeks is arbitrarily chosen and meant just to be an example. work with me here
[10:17] <Kmos> pkern: ask in #ubuntu-motu about that
[10:17] <pkern> Kmos: So even if I get a component mismatch currently motu is still my point of contact? Fine.
[10:17] <Daviey> ScottK: naa
[10:18] <Chipzz> scenario b: package n (non-imp) is in the queue for 3 weeks and thus exceeds the limit. even though package i is important, package n gets precedence to prevent starvation
[10:18] <seb128> ScottK: I think 3 weeks is already a long delay for things in NEW this cycle
[10:18] <seb128> almost every is processed before that
[10:18] <seb128> I don't think have to wait 10 days is that of an issue
[10:18] <seb128> most of the time we process new uploads in the week
[10:18] <ScottK> NEW has been much better this time than in Feisty.
[10:18] <ScottK> Agreed.
[10:18] <seb128> ScottK: the team got new member, that's going in the good direction
[10:19] <ScottK> Absolutely.
[10:19] <seb128> so what is the issue?
[10:19] <sistpoty> Chipzz: scheduling strategies don't have humans to interact. ;)
[10:19] <Mithrandir> which has something to do with having three and four archive admins rather than.. just me.
[10:19] <Mithrandir> :-P
[10:19] <Chipzz> sistpoty :)
[10:19] <snikker> why if a "filename.templates" in (in the po folder of a source code) start with a block comment (#), the templates file in the packaged version (build with "debuild -uc -us") is replaced with a blank line?
[10:19] <ScottK> We had a disconnect this time around about what exactly New Package Freeze means.  We've had it before.  We'll muddle through this time like we always do.
[10:19] <Chipzz> seb128: also note that scenario b could be proactively prevented
[10:20] <ScottK> The imporant thing is to have a clear/coordinated policy for next time around.
[10:20] <seb128> I agree that we need to decide how the freezes applies
[10:20] <Kmos> snikker: #ubuntu-motu
[10:20] <seb128> if that's the upload of processing which counts
[10:20] <seb128> and that will be fixed
[10:20] <seb128> I'll raise the issue
[10:21] <seb128> anything else that should be discussed in your opinion?
[10:21] <snikker> Kmos: i've already asked there, but with not answer...
[10:21] <Mithrandir> Chipzz: seriously, trying to enforce that would a) not work and b) make at least me much more liable to quickly find a reason to reject the unimportant package rather than finding all the problematic bits of it.
[10:21] <Kmos> snikker: wait for someone to answer you..
[10:21] <snikker> Kmos: ok
[10:22] <Chipzz> Mithrandir: I was afraid of something like that ;)
[10:23] <Chipzz> Mithrandir: you could come up with variants of it though
[10:23] <Chipzz> say, if there are n packages exceeding the limit you only have to process one
[10:23] <seb128> trying to enforce rules over overworked people doesn't work
[10:23] <seb128> you will like just lead them to stop volunteering for the work
[10:23] <Chipzz> or have the uploader do part of the work (like with sync requests)
[10:24] <seb128> s/like/likely
[10:24] <Mithrandir> Chipzz: really, that's not how it works.  Do you think we should be blocked on upstream replying to concerns about a package and block everything on that?
[10:25] <Chipzz> Mithrandir: I indeed don't think we should. but what I'm referring to is working on the new queue, not letting as many packages through as possible ;)
[10:26] <Chipzz> seb128: likewise the argument was that if new contributors don't get their packages processed in a reasonable amount of time, they will stop volunteering too
[10:26] <_MMA_> "seb128: you will like just lead them to stop volunteering for the work" And whats wrong with that? My feeling is if you cant do the job why take it on? There's nothing wrong with that.
[10:27] <mjg59> _MMA_: Then nobody does the job. Which is kind of bad.
[10:27] <seb128> Chipzz: I think the delay has been reasonable through this cycle and that there is no reason for such a discussion
[10:27] <Chipzz> in which case I guess it boils down to: well, I guess a MOTU volunteer is more dispensable than an archive admin...
[10:27] <seb128> as said we had 3 packages in NEW for 3 weeks
[10:27] <seb128> everything else is 2 weeks or newer
[10:27] <seb128> and that's probably a busy time in the cycle
[10:27] <_MMA_> mjg59: Something close to what's being said now anyway right?
[10:28] <seb128> _MMA_: nobody else is going to do it ;)
[10:28] <Mithrandir> Chipzz: it's certainly a tradeoff between spending time on making sure we get new blood and doing other work.
[10:28] <mjg59> _MMA_: No.
[10:28] <EvanCarroll> right. I think that is the default.
[10:28] <EvanCarroll> m/t
[10:28] <seb128> _MMA_: you think that no processing NEW is better than having a few weeks of delay, I don't think there is lot to discuss there
[10:28] <Chipzz> seb128: but then, I'm just throwing in some idea's on how *possibly* to make it more fair :)
[10:29] <Chipzz> seb128: if you think there is no problem, then we (I) should stop this discussion ;)
[10:29] <seb128> well, I would like to be proved that is has been an issue this cycle first
[10:29] <_MMA_> seb128: You keep focusing on a delay. Thats not the issue _at_all_. Its things making it in before freeze and not being processed.
[10:29] <seb128> _MMA_: did you read the chan?
 if that's the upload of processing which counts
[10:30] <seb128>  and that will be fixed
[10:30] <seb128>  I'll raise the issue
[10:30] <seb128>  anything else that should be discussed in your opinion?
 I agree that we need to decide how the freezes applies
[10:30] <LaserJock> _MMA_: seb128 is on to discussing delays with Chipzz  :-)
[10:30] <seb128> _MMA_: I think that things uploaded before the freeze should be accepted and that will be discussed
[10:30] <seb128> anything else?
[10:32] <_MMA_> Well thats fine but its been said its not up to you. :( If it actually happens then yeah, that great. ;)
[10:32] <xtknight> i've encountered quite a weird problem (firefox failing on 64bit after updates all the time).  any ideas??  Bug 133786
[10:32] <seb128> _MMA_: I didn't say I would decide, I wrote that I would raise the issue for discussion
[10:32] <ubotu> Launchpad bug 133786 in ubuntu "Bus error when running Firefox or Epiphany" [Undecided,New]  https://launchpad.net/bugs/133786
[10:32] <_MMA_> seb128: ;)
[10:33] <cjwatson> in the past, ISTR things that were in place before freeze generally getting an exception on that basis
[10:33] <cjwatson> just throwing my oar in a bit late
[10:33] <cjwatson> as an archive admin I have certainly accepted things on that basis
[10:33] <seb128> I was going to do that
[10:33] <cjwatson> whether it happened for feisty or not, I don't know
[10:33] <seb128> but I'll raise the point at the distro team meeting for clarification
[10:34] <bddebian> w00t cjwatson is here now, fresh meat!!
[10:34] <Chipzz> bddebian: .net? :)
[10:34] <bddebian> Hrm?
[10:34] <Chipzz> freshmeat.net ;)
[10:34] <Chipzz> don't know it?
[10:34] <bddebian> Oh, hehe
[10:35] <mjg59> seb128: Fixed, uploaded
[10:35] <seb128> mjg59: thanks
[10:49] <EvanCarroll> I'm not sure how to file a bug report on the gutsy fonts that will help it seems like a few people have a good idea of the problem
[10:49] <EvanCarroll> has something to do with the DBI scaling mechanism of the new X
[10:49] <EvanCarroll> I just can't my fonts down to a reasonable size.
[10:50] <EvanCarroll> I'm using mergefb (as are most poeple wth dual monitors) so my resolution is 1024*2 x 768
[10:50] <mjg59> system/preferences/appearance/fonts/details
[10:50] <EvanCarroll> it totally rapes my fonts, even if i edit the libgnome default down to 7
[10:50] <EvanCarroll> mjg59: they are at 6.
[10:50] <EvanCarroll> mjg59: can't go any lower.
[10:50] <mjg59> EvanCarroll: No. That gives you the DPI setting.
[10:50] <EvanCarroll> 158
[10:50] <EvanCarroll> thats it i bet
[10:50] <mjg59> bryce: He's right, though. The default DPI is horrifically horked.
[10:51] <mjg59> Even on single monitor setups.
[10:51] <EvanCarroll> thanks a ton, I saw suggestions for this feature and didn't see any note of it being implimented
[10:51] <mjg59> My user name doesn't actually fit in the gdm box
[10:51] <EvanCarroll> I think you guys are shooting yourself in the foot if this "Feature" is in launch... Regression time if you ask me.
[10:51] <EvanCarroll> hahahahah
[10:51] <EvanCarroll> I've got a better one, my gvim holds 29characters.
[10:51] <EvanCarroll> maximized.
[10:52] <ion_> Gnome shouldnt override the DPI value IMO. Instead, we should make X guess it better. For instance, the displayconfig-gtk monitor database could contain their physical sizes and add a DisplaySize setting to the config.
[10:52] <EvanCarroll> I had to go down to vritual-line 7 to edit the libgnome2 file
[10:52] <ion_> That is, for monitors that report it incorrectly.
[10:54] <EvanCarroll> anyone know how one resets the fonts to the original-factory settings
[10:55] <EvanCarroll> I forget what the normal ubunte sizes are 10/10/11/11/10 top to bottom ?
[10:58] <deadwill> any news on bug #124775 ?
[10:58] <ubotu> Launchpad bug 124775 in vmware-player-kernel-2.6.15 "No kernel modules for the 2.6.22 kernel" [High,Confirmed]  https://launchpad.net/bugs/124775
[10:59] <mjg59> It's filed against an utterly bizarre package
[11:01] <EvanCarroll> found it, font size settings are stored in ~/.gconf/desktop/gnome/interface/%gconf.xml
[11:01] <EvanCarroll> actually only 3 of the 5 that you can configure are stored there
[11:01] <EvanCarroll> grr!!! gnome and your inconsistancies
[11:02] <EvanCarroll> window font and fixed fonts not in there
[11:02] <EvanCarroll> I'll delete my whole gconf I suppose
[11:02] <tepsipakki> EvanCarroll: just use gconf-editor and set the default from there
[11:02] <EvanCarroll> tepsipakki: I don't know what the default is =[
[11:03] <tepsipakki> right click on the setting, then choose the one that reverts to the default
[11:03] <tepsipakki> don't know what it's called in english/your locale :)
[11:03] <EvanCarroll> I just know I want the default font sizes on everything again, and I only want to change my DPI because having all of my fonts set to 6 and my dpi correctly set to the 95ish half of what it was detected at, makes all of my font-size 6 look like a font-size 6 now
[11:03] <EvanCarroll> ah
[11:04] <EvanCarroll> i didn't know gconf editor had that option
[11:04] <EvanCarroll> wonder where it stores therem /etc/skel maybe
[11:04] <tepsipakki> no, /var/lib/gconf
[11:05] <tepsipakki> oh wait, /usr/share/gconf is better
[11:06] <seb128> tepsipakki: what are you trying to do?
[11:06] <tepsipakki> seb128: help :)
[11:06] <tepsipakki> seb128: EvanCarroll wants to reset the font sizes to the default values
[11:07] <lizet> HELLO
[11:07] <EvanCarroll> I butchered every font-size in gnome to 6, rather than changing my borked dpi value
[11:07] <EvanCarroll> I'm sure this will be a FAQ on launch lol
[11:07] <seb128> gconftool-2 --unset /desktop/gnome/interface/document_font_name /desktop/gnome/interface/font_name /desktop/gnome/interface/monospace_font_name
[11:08] <tepsipakki> yes, that's the cool way to do it :)
[11:08] <EvanCarroll> awesome, thats most of them.
[11:08] <EvanCarroll> I'll wiki it tonight.
[11:09] <EvanCarroll> still a few more. that I borked as far as individual applications, the move to resolution independence is surely the right step, I'd go with a year of datacollection on monitors though
[11:10] <EvanCarroll> capture the name of the monitor from DPMS and the users size-preference in gnome at least the big 6 to infer you are in the right ballpark
[11:11] <EvanCarroll> seb128: tepsipakki thanks again.
[11:11] <seb128> you're welcome
[11:14] <tepsipakki> bummer, he left already
[11:16] <cjwatson> Riddell: do you think you could grab amarok2 out of NEW and frob it to fix debian/copyright? It needs to list the LGPL and the GFDL
[11:16] <LaserJock> cjwatson: is the make-web-indices script in ubuntu-cd what's used to create the pages on cdimage.ubuntu.com, etc. ?
[11:17] <cjwatson> LaserJock: yes
[11:17] <cjwatson> LaserJock: some of them are tweaked a bit by hand though
[11:17] <Riddell> cjwatson: ok, I'll do that now
[11:19] <LaserJock> cjwatson: if I want to make some changes to the Edubuntu descriptions can I give you a patch or would you rather handle it yourself?
[11:20] <cjwatson> LaserJock: mail me a patch
[11:20] <cjwatson> Riddell: thanks!
[11:24] <Caesar> Is there a way to see all bugs that effect Feisty?
[11:24] <Caesar> Or is launchpad package-oriented?
[11:25] <cjwatson> Caesar: https://bugs.launchpad.net/ubuntu/feisty but obviously that's only bugs that have been explicitly annotated as affecting feisty
[11:25] <cjwatson> launchpad doesn't have version tracking
[11:25] <Caesar> :-(
[11:26] <cjwatson> (not my idea, I put it in the original design ;-))
[11:30] <ogra_> cjwatson, al my work on the udeb was moot :( i cant get any output from mksquashfs through any pipe at all so i have to find another way... (that was the main reason to touch the udeb)
[11:30] <ajmitch> good morning
[11:30] <Riddell> cjwatson: amarok2 -0ubuntu2 uploaded
[11:47] <noah__> Hey! In Ubuty Gutsy, /etc/mysql/my.cf, the last line says !includedir /etc/mysql/conf.d, but settings in here doesn't get applied.. bug?
[11:48] <soren> noah__: Possibly. File a bug with some more information and I'll look at it tomorrow.
[11:48] <mathiaz> noah__: what are you trying to set in conf.d ?
[11:50] <noah__> mathiaz: default-character-set=utf8 for [mysqld]  and [client]  amongst others
[11:50] <noah__> soren: can i email you a remind? i'm too lazy to write a bug report right now.
[11:50] <noah__> reminder*
[11:50] <mathiaz> noah__: you'd better file a bug - so that we can track it.
[11:51] <soren> noah__: WEll, the e-mail you send to me would have to contain more information as well.
[11:52] <noah__> soren: i'll give you a test case.. can't figure out which email i used for registering on launchpad and i don't feel like reregistering atm
[11:52] <soren> noah__: You remember your username?
[11:52] <noah__> no
[11:54] <soren> noah__: What's your name?
[12:01] <noah__> soren: https://bugs.launchpad.net/ubuntu/+bug/136225
[12:01] <ubotu> Launchpad bug 136225 in ubuntu "my.cnf includedir not working as expected" [Undecided,New]
[12:18] <pygi> asac, we need to talk (preferably once I wake up) ... I didn't hear from you in few days o.O
[12:19] <asac> pygi: yeah ... i somehow lost the current/state/idea :)
[12:20] <pygi> asac, you know that's not good :p
[12:20] <pygi> asac, we can't *really* update libswfdec since it depends on unrelease libming
[12:22] <asac> thats really a shame
[12:23] <asac> how could that happen?
[12:23] <asac> what does debian do?
[12:23] <asac> (they have swfdec 0.5.x, right?)
[12:27] <pygi> asac, they have debian 0.5.1
[12:27] <pygi> we can get that as well
[12:27] <pygi> but can't get 0.5.2
[12:28] <asac> whats the difference?
[12:28] <asac> why does 0.5.2 pull in a new lib, pygi ?
[12:28] <asac> maybe its just testcases? which we can exclude from build?
[12:29] <pygi> asac, it's due to vivi
[12:29] <pygi> and yes, we could exclude it
[12:29] <pygi> but: a)we gotta have it ready by *yesterday* b)I'm going to trip tomorrow, early morning (00:10AM)
[12:29] <pygi> and I won't be at home for most of the day :-/
[12:30] <pygi> so much to do :(
[12:30] <seb128> pygi:  what about swfdec?
[12:30] <pygi> seb128, we are talking about swfdec now =)
[12:31] <seb128> I noticed
[12:31] <pygi> well, trying to get new release in :)
[12:31] <pygi> if you don't mind :p