[00:00] <manjo> cjwatson, just booted, /target/etc... does not exist
[00:00] <manjo> and I don't see /target/cdrom...
[00:00] <cjwatson> manjo: it won't exist until you run through the installer to the failure point
[00:00] <manjo> do I need to start the install to see that  ? \
[00:00] <manjo> ah I thought so
[00:00] <cjwatson> nothing under /target exists until then
[00:01] <manjo> pita
[00:02] <manjo> cjwatson, install in progress.. will take a few mts
[00:04] <cjwatson> not seeing any relevant changes in apt
[00:12] <manjo> cjwatson, oh! no! it finished install
[00:12] <manjo> cjwatson, it worked this time
[00:13] <manjo> cjwatson, let me try again
[00:16] <manjo> cjwatson, sent you /var/lib/partman/devices/* tgz
[00:18] <cjwatson> thanks
[00:19] <manjo> cjwatson, do you need anything else from that machine? can I power if off ?
[00:22] <manjo> cjwatson, superm1 sorry I can't reproduce it anymore
[00:23] <manjo> cjwatson, superm1, my 2nd time around install going though
[00:23] <cjwatson> manjo: the UEFI one?  go ahead and power it off
[00:23] <manjo> cjwatson, thanks
[00:23] <cjwatson> manjo: those logs match my prediction
[00:23] <cjwatson> so it's a simple matter of programming to fix
[00:24] <manjo> cjwatson, on the hp mini I can reproduce it anymore
[00:24] <cjwatson> manjo: regarding the USB installation: just a hunch, but do/did you have persistence enabled in usb-creator?
[00:24] <cjwatson> I'm reading through apt's code for identifying CD-ROMs
[00:24] <manjo> cjwatson, sorry I don't recall... iirc I think I did
[00:24] <manjo> I always do ... so I must have 90% sure
[00:24] <cjwatson>       // We use a kilobyte block size to advoid overflow
[00:24] <cjwatson>       sprintf(S,"%lu %lu",(long)(Buf.f_blocks*(Buf.f_bsize/1024)),
[00:24] <cjwatson>               (long)(Buf.f_bfree*(Buf.f_bsize/1024)));
[00:24] <cjwatson>       Hash.Add(S);
[00:25] <cjwatson> the code above assumes that CDs are read-only and never change
[00:25] <manjo> ah
[00:25] <cjwatson> but a USB stick with persistence enabled might change its free blocks count
[00:26] <cjwatson> I'd suggest you try another patch and see if it makes a difference, but ...
[00:26] <manjo> cjwatson, let me recreate this USB stick and try again... I will update the bug with that info you assked me earlier about /target/... and mount /target etc
[00:27] <cjwatson> yes, I bet that creating it from scratch will make a difference
[00:27] <cjwatson> this is only a guess - I just can't see anything else that would matter
[00:27] <manjo> right ... I am on it
[00:28] <cjwatson> not entirely sure what to do about it
[00:28] <cjwatson> setting Debug::identcdrom=true during installation would probably avoid it, at the cost of making that entry in apt-cdrom's database invalid for later use
[00:28] <kklimonda> hmm, apt-get autoremove is broken..  debian bug 594689 - is it on the radar?
[00:30] <manjo> cjohnston, creating  persistence of 351 mb
[00:30] <cjwatson> kklimonda: better wait until mvo is aroundd
[00:30] <cjwatson> -d
[00:30] <manjo> cjwatson, creating  persistence of 351 mb
[00:31] <kklimonda> cjwatson: ok, will ask him. thanks :)
[00:37] <cjwatson> manjo: http://paste.ubuntu.com/487007/ applied to /usr/share/ubiquity/plugininstall.py may deal with it
[00:37] <cjwatson> if my hypothesis is true
[00:38] <manjo> cjwatson, ok will try that in a sec ... booting new usb stick with persistance & todays iso
[00:40] <cjwatson> I think it is coffee time
[00:41] <ev> nice catch
[00:42] <cjwatson> does persistence work the way I'm recalling?  the free blocks count on statvfs("/cdrom") would change?
[00:43] <manjo> cjohnston, ok hit the problem now
[00:44] <manjo> cjwatson, ^
[00:44] <Edgan> pitti: Can you tell me what kernel version-release is supposed to have gone into lucid-proposed for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/585092 ?
[00:44] <manjo> cjwatson,  /target/etc/apt/apt.conf.d/00NoMountCDROM exists
[00:45] <manjo> cjwatson, /target/cdrom mounted -- yes
[00:45] <manjo> cjwatson, I have the system live right now if you need me I am around
[00:55] <manjo> cjwatson, with that change to .py does ubiquity needs to be restarted ? if so how do I restart it ?
[00:55] <manjo> cjwatson, I am guessing your ans will be .. new iso needs be created with that change ?
[00:57] <cjwatson> manjo: I'm afraid it's re-create USB stick from scratch, boot to live session, patch that file on the fly, then start the installer
[00:57] <cjwatson> manjo: normally it would be easier, but since this is so delicate with regard to persistence I think we have to be safe
[00:57] <cjwatson> manjo: well
[00:58] <cjwatson> manjo: maybe it would be worth applying it on the fly now and running, since that would be a quicker way to weed out any stupid mistakes I may have made, but it won't be a full test
[00:59] <manjo> cjwatson, ack will try that
[01:01] <cjwatson> maybe best to reboot
[01:01] <cjwatson> so reboot to live session, patch on the fly, start installer; then, re-create USB stick from scratch, boot to live session, patch that file on the fly, then start the installer
[01:02] <manjo> cjwatson, so 2 tests
[01:02] <cjwatson> yeah
[01:02] <manjo> ok
[01:02] <cjwatson> sorry it's time-consuming
[01:02] <manjo> yep np
[01:02] <manjo> glad I can help
[01:03] <manjo> cjwatson, so its way past your bed time I am guessing
[01:03] <manjo> its almost time to wake up and make coffee :)
[01:05] <cjwatson> especially as my stepson starts secondary school tomorrow
[01:09] <manjo> I think I trashed my disk on the last reboot, let me recreate it again
[01:18] <manjo> cjwatson, sorry could not do your 1st test coz my usb stick was trashed by the prev install attempt, so I have to recreate it and patch the file on the fly and start ubiquity -d
[01:18] <manjo> cjwatson, install is making progres ... will update you shortly
[01:18] <cjwatson> ok, the first test was just an optimisation attempt anyway
[01:18] <cjwatson> thanks
[01:22] <manjo> cjwatson, its past that point .. so I think you did it .. will tell you for sure when its done installing
[01:23] <cjwatson> that would be quite a relief if so
[01:27] <manjo> cjwatson, install complete
[01:27] <manjo> cjwatson, do you need any logs ?
[01:28] <manjo> I did start with -d so you could have more info
[01:28] <cjwatson> syslog and installer/debug would be good just to check
[01:30] <manjo> ok
[01:30] <manjo> will mail those to you
[01:31] <cjwatson> thanks so much - I know this has been a time-consuming tet
[01:31] <cjwatson> *test
[01:32] <manjo> cjwatson, no thank you
[01:34] <manjo> cjwatson, logs in the mail
[01:39] <cjwatson> confirmed that that did the right thing
[01:39] <cjwatson> committed
[02:52] <cjwatson> superm1: I have an idea what might be going on.  Will try a few things tomorrow
[03:17] <hv> hi. where should I channel my frustration about idiosyncrasies in maverick's gtk theme?
[03:18] <crimsun_> perhaps a[n existing] bug report on light-themes?
[03:18] <hv> (I have specific lines I would like to change in /usr/share/themes/Ambiance/gtk-2.0/gtkrc)
[03:18] <hv> *sigh*, that does not make me feel any better.  I'll try anyways ...
[03:19] <hv> btw, do they have an irc channel?
[03:21] <crimsun_> perhaps http://lists.ubuntu.com/mailman/listinfo/ubuntu-art and #ubuntu-artwork
[03:21] <hv> thanks.
[03:27] <hv> well, it's a ghost town there.
[03:27] <hv> are both themes (Ambiance and Radiance) designed to be light themes?
[03:34] <crimsun_> hv: IIRC the former certainly isn't
[03:35] <hv> they have hardcoded light colors (e.g., I can see #e2e1e1) in the gtkrc file.  Are there kids designing the themes again?
[03:37] <hv> (few years ago there were a few kids designing the themes)
[03:54] <superm1> cjwatson, re EFI  on the 6410 i'm assuming?  well if you need any additional debugging output from serial console with what you have in mind, just lemme know
[04:13] <superm1> manjo, i've received confirmation that the implementation on the 6410 is not via DUET, it is native.
[04:50] <robert_ancell> Is there an easy way I can get what's in the upload queue?
[04:51] <ejb> what's the easiest way to get the lucid kernel source?
[04:52] <cody-somerville> robert_ancell, https://edge.launchpad.net/ubuntu/maverick/+queue
[04:54] <robert_ancell> cody-somerville, thanks, now I just need to work out if I can get that via launchpadlib
[04:58] <cody-somerville> robert_ancell, I think you need to call getPackageUploads on a distro_series
[04:58] <robert_ancell> awesome, just what I need
[05:13] <robert_ancell> cody-somerville, I get a series_collection_link, how do I convert that into a series collection?
[05:17] <robert_ancell> go it: launchpad.distributions['ubuntu'].getSeries(name_or_version='maverick').getPackageUploads().  Trial and error is the winner of the day!
[05:21] <lifeless> robert_ancell: what do you need the upload queue for?
[05:21] <robert_ancell> lifeless, updating http://people.canonical.com/~seb128/versions.html so it shows packages that are in the upload queue as up to date
[05:39] <TheMuso> ejb: Go to http://kernel.ubuntu.com/git and find the ubuntu-lucid git tree, and clone it.
[05:59] <ejb> Anyone know of good up to date tutorials on writing kernel modules?
[06:37] <ejb> I want to disassemble a function in my kernel but there aren't symbols... is there a symbol file that I can load into gdb?
[06:41] <RAOF> ejb: Yup.  linux-image-$(VERSION)-dbgsym is, or should be, available from the dbgsym repository.
[07:05] <pitti> Good morning
[07:06] <pitti> Edgan: 2.6.32-25.43
[07:21] <ricotz> pitti, good morning
[07:29] <ricotz> hello, could someone have a look at this sru? https://bugs.edge.launchpad.net/docky/+bug/584094
[08:53] <tkamppeter> pitti, hi
[09:48] <iainfarrell> sladen: ping
[09:55] <pitti> hello tkamppeter
[10:09] <cjwatson> kenvandine: any reason for reopening bug 627565 in maverick?
[10:16] <seb128> cjwatson, he's probably sleeping but that seems a bug triaging mistake to me
[10:17] <cjwatson> can wait 'til he wakes up
[10:46] <pitti> ricotz: have a question in bug 584094
[10:47] <pitti> ah, I just got confused about gwibber, seems cjwatson beat me to it
[11:00] <tkamppeter> pitti, I have found a possible apport bug.
[11:02] <tkamppeter> pitti, see bug 628030. Here ghostscript segfaults but probably apport did not pop up therefore, as the user has called apport through the printing infrastructure (probably the failed job pop-up).
[11:25] <ricotz> pitti, i was having lunch, i commented on your question
[11:33] <sladen> iainfarrell: morning
[11:36] <lool> pitti: Could you please remove the lucid-proposed gallery2 package immediately?
[11:37] <lool> the current upgrade path allows for the lucid version's postrm to rm -rf /usr/share/gallery2 /etc/gallery2
[11:38] <lool> LP #578137
[11:44]  * lool is a bit pissed of from that rm -rf /
[11:45] <azeem> lool: "rm -rf /" sounded *really* bad for a second
[11:46] <lool> I think it's pretty much the last straw; I will give up on gallery2
[11:47] <lool> I'm happy that it was in a vm  :-)
[12:08] <pitti> lool: I thouht that was intended, and the preinst makes a backup?
[12:10] <pitti> ricotz: replied
[12:11] <pitti> lool: ah, saw your reply
[12:12] <pitti> lool: done
[12:13] <lool> Thanks
[12:13] <pitti> tkamppeter: hm, I need /var/log/apport.log for that
[12:14] <ricotz> pitti, replied
[12:15] <pitti> ricotz: this needs fixing in maverick, too; do you plan to upload to Debian and have it synced? or direct U upload?
[12:16] <ricotz> pitti, i have planned to do so, but there are some other new mono packages coming which needs some packaging and buildsys changes
[12:18] <ricotz> pitti, so these new packages should go in first which are also needed for banshee 1.7.5
[12:18] <pitti> ricotz: understood
[12:22] <tkamppeter> pitti, I have asked the user in bug 628030 now.
[12:25] <tkamppeter> pitti, when I reproduced bug 628030, I had exactly the same problem as the original poster, only pop-ups for the failed job, not for the segfault. I have mailed my apport.log to you now.
[12:46] <pitti> tkamppeter: "report /var/crash/_usr_bin_gs.1000.crash already exists and unseen"
[12:46] <pitti> tkamppeter: so it seems apport does pick up the crash, but since you didn't look at the previous one yet, you don't get a new one
[12:47] <albertz> hi. is this the right place to ask for help on the xserver? or in #ubuntu-app-devel? i am working on a mouse wheel acceleration patch
[12:57] <seb128> cjwatson, do you have any opinion on bug #618281? ie the update for this cycle?
[12:57] <seb128> cjwatson, I'm just trying to clean the nominated bugs list
[12:57] <cjwatson> keeping ntfs-3g up to date usually works out to be a good plan
[12:57] <seb128> so I accept the nomination
[12:57] <seb128> thanks
[12:58] <cjwatson> it does have new features but they seem mostly mount-option-controlled
[12:58] <cjwatson> or "if you don't have this then your filesystem won't work anyway"
[13:03] <tkamppeter> pitti, reporter of bug 628030 hass attached apport.log.
[13:16] <dholbach> cjwatson, hey Colin - how are you doing? Who can change which packageset a package belongs to? do we still have mismatches between package-in-packageset and seeds every now and then?
[13:19] <cjwatson> respectively: fine, thanks; theoretically TB but in practice me; yes
[13:20]  * dholbach hugs cjwatson
[13:20] <StevenK> cjwatson: Hi, do you have time today to talk about a change I'm doing for initialising a new distroseries?
[13:20] <dholbach> thanks Colin - I just asked because of the current discussion on ubuntu-devel@
[13:22] <geser> dholbach: the owner of the packageset can change it and the owner of most packagesets is the TB (the DMB only owns the mozilla and zope package set). So asking cjwatson is always right :)
[13:23] <dholbach> great, I just didn't want to reply to the mail saying "yeah, just ask Colin to fix it"
[13:23] <cjwatson> StevenK: I would suggest choosing a day other than beta release day
[13:23] <cjwatson> dholbach: I'll catch up on it after beta release
[13:23] <tkamppeter> pitti, it seems that I have found a solution for most of the problems where Ghostscript fails when used with the CUPS Raster device: CUPS should not se a RIP_MAX_CACHE at all, not even a big one like 1/4 of system memory, simply none at all so that Ghostscript determines its memory use by itself. Then Ghostscript always works correctly.
[13:24] <StevenK> cjwatson: Since moving to Launchpad I've lost track of the special Ubuntu days, sadly. Is tomorrow okay?
[13:24] <cjwatson> yes
[13:24] <dholbach> cjwatson, sure
[13:24] <dholbach> geser, cjwatson: thanks
[13:24] <tkamppeter> pitti, in CUPS one can easily implement it by defaulting the cache to an invalid value, like "auto".
[13:27] <soren> Uh... If I'm runnig "apt-get dist-upgrade -fy" I shouldn't be asked about modified conffiles, should I?
[13:28] <kenvandine> cjwatson, thx for gwibber
[13:36] <Keybuk> grr @ bzr
[13:36] <Keybuk> bzr log should invoke $PAGER
[13:39] <Laney> there's a plugin for that™
[13:42] <dholbach> geser, if a package moves into the 'sugar' packageset, who can upload it?
[13:43] <ogra> all the sweet guys and gals :)
[13:43] <chrisccoulson> lol
[13:44] <Laney> the union of sugar packageset uploaders and component uploaders
[13:44] <geser> dholbach: https://launchpad.net/~ubuntu-sugar-uploaders is the uploaders team for that package set
[13:44] <Laney> dholbach: I would love it if I could give the sponsoring page my LP ID and have it filter to the stuff I can upload
[13:45] <dholbach> ok, let me follow up on the thread
[13:45] <dholbach> it's time bug reports get filed
[13:45] <dholbach> I wanted the discussion to be something different :)
[13:45] <Laney> yeah sorry
[13:45] <nigelb> Laney: +1 ;)
[13:46] <Laney> I don't have any tools apart from an alias to wget -q -O- $URL | patch -p1
[13:47] <geser> dholbach: btw do you have any preference on a python templating toolkit? I've started to split the code and the HTML template for the sponsoring page using Mako
[13:47] <dholbach> geser, I expect that once Harvest is up and running the sponsoring page can go away
[13:48] <geser> ah ok
[13:48] <dholbach> maybe it can, maybe it can't, let's see
[13:48] <dholbach> does the templating toolkit need anything special set up on people.c.c?
[13:48] <geser> besides python-mako being installed, no
[13:48] <Laney> really?
[13:48] <dholbach> ok
[13:49] <Laney> can I filter by type of opportunity to recover the original sponsor page?
[13:49] <dholbach> Harvest is currently just waiting on IS right now and looking for contributors :-)
[13:49] <dholbach> Laney, you can, but it's not up and running yet
[13:49] <Laney> cool
[13:49] <dholbach> bzr branch lp:harvest; less harvest/INSTALL
[13:49] <dholbach> it's really trivial to set up
[13:49] <dholbach> (for local testing)
[13:50]  * Laney isn't really a harvesty type of developer
[13:50] <Laney> although maybe I am for certain areas...
[13:51] <dholbach> I'm sure you are ;-=
[13:51] <dholbach> ;-)
[13:51] <G> dholbach: I'll put my hand up to contributing
[13:51] <dholbach> awesome, just propose a merge to lp:harvest and somebody will have a look
[13:52] <dholbach> I also documented the release process, so I hope it'll be easy soon to get new releases out there: https://wiki.ubuntu.com/Harvest/ReleaseProcess … once it's up and running
[13:52] <G> okay, that'll be tomorrow (or more like today)
[13:52] <dholbach> sure sure, take it easy :)
[13:53] <G> dholbach: it's 1am, but the project will also include "learn bzr" :)
[13:53] <StevenK> dholbach: You have two 'lp:~' in your template mail to RT
[13:54] <dholbach> StevenK, fixing
[13:55] <dholbach> G: interesting you should mention that, in the LoCo Directory team we just discussed a "getting started with LD" guide or at least short snippets
[13:55] <G> LD = LoCo Directory or Launchpad Dev? :P
[13:56] <G> I'm assuming LoCo
[14:00] <dholbach> g: loco directory, sorry :)
[14:03] <nigelb> dholbach: nifty release page
[14:15] <G> dholbach: btw, what is your prefered way for merging fixes, 1 branch for each little fix, or 1 branch for a bunch of little fixes?
[14:15] <dholbach> g: exactly
[14:15] <dholbach> and propose a merge
[14:17] <G> yeah, but for little fixes, which is the prefered number of branches (1 or X)
[14:18] <dholbach> G: it's fine to bundle a few fixes if they're all obvious or better fixed in one go
[14:18] <G> dholbach: okay, just wanted to check :)
[15:02] <kklimonda> mvo: is debian bug 594689 on your radar?
[15:02] <mvo> kklimonda: yes, its in the apt ubuntu branch already
[15:02] <kklimonda> thanks
[15:02] <mvo> kklimonda: but thanks for the reminder, I will upload into the queue shortly
[15:17] <ivoks> Keybuk: question; copyright in com.ubuntu.Upstart.Instance.xml; is that a bsd(ish) license?
[15:32] <SpamapS> Keybuk: Is there a good list somewhere of best practices for upstart jobs?
[15:58] <mvo> seb128: re bug #620297 - so did you break vte ;) ?
[15:59] <seb128> mvo, no, but robert_ancell might have
[15:59] <seb128> there is a new version in the queue as well
[15:59] <seb128> if you have a bug please assign to him for investigation
[16:06] <seb128> robbiew, wouldn't be useful to have a meeting after beta to know where we stand?
[16:08] <robbiew> seb128: what would we discuss?  I suppose if there's an OMG bug(s), we could discuss that....but we would be discussing that tomorrow regardless
[16:09] <robbiew> I'm not against having one tomorrow
[16:09] <robbiew> as I'm not running it ;)
[16:10] <seb128> robbiew, rather where we stand, what is the beta status, what issues have been spotted, what should get cracked for final, etc
[16:10] <seb128> I guess we can wait a week for that
[16:10] <seb128> but it puts us a few days before hard freeze
[16:10] <robbiew> hmm
[16:10] <seb128> I would imagine know is the right time to be cracking on issues that will need to be fixed in the 2 weeks coming
[16:11] <seb128> know -> now
[16:11] <seb128> "cracking the whip on the issues", or rather at least making people aware of the priorities
[16:11] <robbiew> right
[16:11] <robbiew> good point
[16:12] <seb128> no skat?
[16:12] <seb128> skaet rather ;-)
[16:12] <seb128> oh
[16:12] <seb128> skaet, hey ;-)
[16:13] <seb128> skaet, how are you? I was discussing tomorrow's meeting with robbiew
[16:13] <skaet> seb128,  heya.
[16:13] <seb128> skaet, do you feel we should have one to check status after beta?
[16:13] <robbiew> seb128: how about we have the meeting, but scale back the agenda
[16:13] <robbiew> to just a status check
[16:13] <seb128> just to make sure we are on track and we discuss things that need to be worked next?
[16:13] <pitti> he just cancelled it, didn't he?
[16:13] <seb128> pitti, well that's what I'm discussing there
[16:14] <seb128> pitti, ie scrollback
[16:14] <pitti> OIC
[16:14] <seb128> it seems that the end of the cycle meeting are the useful ones
[16:14] <lucidfox> dholbach> I don't understand where Ubuntu people get all the money for their plentiful travels all over the world o_O
[16:14] <seb128> we need to make sure everybody knows what we need to do and where we stand
[16:14] <dholbach> lucidfox, it's my first and only holidays this year
[16:15] <seb128> robbiew, I'm fine having just a status check or no meeting, I guess your call and skaet's one
[16:15] <seb128> robbiew, I would just pointing that we only have 2 weeks before hard freeze and a status update could be useful
[16:15] <robbiew> seb128: ack
[16:15] <robbiew> and that was very welcome ;)
[16:15] <cjwatson> personally I'm not going to be much good for anything tomorrow, but ...
[16:16] <robbiew> cjwatson: yeah...I figured that
[16:16] <seb128> I'm sure work is mostly tracked in each team
[16:16] <cjwatson> I'm OK with a status check, would rather not have to prepare a detailed report
[16:16] <robbiew> exaclty
[16:16] <robbiew> and "exactly"
[16:16] <robbiew> I'll shoot out an invite...30min...state of the universe meeting
[16:17] <robbiew> :)
[16:17] <skaet> sounds good.
[16:17] <seb128> yeah, I don't see the point to do a spec etc update
[16:17] <seb128> just a status feedback from beta
[16:17] <seb128> could help to raise some issues which are maybe not tracked
[16:17] <seb128> cjwatson, robbiew, skaet: thanks
[16:18] <robbiew> seb128: no..thank you :)
[16:18] <seb128> ;-)
[16:19] <skaet> seb128,  yup there are likely some that need discussing.   thank you.
[16:29] <tkamppeter> pitti, ping
[16:30] <nigelb> lucidfox: now you get an idea of how much dholbach is paid and/or how stingy he is :p
[16:30] <pitti> tkamppeter: o/
[16:31] <lucidfox> nigelb> That's stingy?
[16:31] <nigelb> lucidfox: well, stingy to save up enough to go there I mean
[16:31] <lucidfox> the only times I've been abroad were on vacations to Turkey funded by my parents when I was younger
[16:34] <tkamppeter> pitti, in CUPS one can easily implement it by defaulting the cache to an invalid value, like "auto".
[16:34] <tkamppeter> pitti, it seems that I have found a solution for most of the problems where Ghostscript fails when used with the CUPS Raster device: CUPS should not se a RIP_MAX_CACHE at all, not even a big one like 1/4 of system memory, simply none at all so that Ghostscript determines its memory use by itself. Then Ghostscript always works correctly.
[16:34] <tkamppeter> pitti, in CUPS one can easily implement it by defaulting the cache to an invalid value, like "auto".
[16:35] <pitti> tkamppeter: that won't provoke any side effects in cups, like error messages?
[16:35] <pitti> but if it works, sounds nice
[16:35] <pitti> I remember this one
[16:36] <tkamppeter> pitti, I have modified GS upstream that with missing or invalid RIP_MAX_CACHE it determines its memory needs automagically and then it works perfectly. The change I have also backported to Ubuntu.
[16:37] <pitti> tkamppeter: hm, is that only read by gs? I thought it was a cups option, not a gs one
[16:37] <tkamppeter> The only other consumer of RIP_MAX_CACHE is imagetops and I have looked in the source and it defaults to 32 MB then. As it worked for years with 8MB this should not be a problem.
[16:39] <tkamppeter> pitti, more a problem is that the CUPS package is also used by Debian, and Debian most probably does not have my patch in GS, so that their GS 8.71 defaults to 8MB with invalid RIP_MAX_CACHE. This means that Debian users will get a lot of problems.
[16:40] <tkamppeter> pitti, so we would need switch between Debian and Ubuntu when applying the patch, or somehow get my GS patch into Debian ASAP.
[16:43] <pitti> tkamppeter: you could apply the patch only in Ubuntu
[16:43] <pitti> tkamppeter: look at e. g. debian/patches/ubuntu-default-error-policy-retry-job.dpatch
[16:43] <pitti> tkamppeter: it has a shell script header which checks lsb_release for Ubuntu
[16:43] <pitti> we already have two ubuntu specific patches there
[16:45] <tkamppeter> pitti, so I make the existing patch for 1/4 of system memory Debian-only and the new patch of auto Ubuntu-only. Later on, when http://bugs.ghostscript.com/show_bug.cgi?id=691586 gets fixed, we can return to 1/4 of memory for all.
[16:46] <pitti> tkamppeter: right, you could change debian/patches/dynamic-default-ripcache-size.dpatch to only apply if we are not on Ubuntu
[16:49] <tkamppeter> pitti, can I do
[16:49] <tkamppeter> [ "`lsb_release -is 2>/dev/null`" = "Debian" ]
[16:49] <tkamppeter> to check whether the distro is Debian or should I better do
[16:49] <tkamppeter> [ "`lsb_release -is 2>/dev/null`" != "Ubuntu" ]
[16:52] <pitti> tkamppeter: !ubuntu, please
[16:52] <pitti> tkamppeter: since we always want one or the other
[16:53] <pitti> and in the other one we test == Ubuntu
[16:54] <ion> There’s dpkg-vendor, too
[16:54] <OdyX> pitti, tkamppeter, you can also use dpkg-vendor snippet
[16:54] <OdyX> (which is more robust than lsb_release IMHO)
[16:55] <pitti> right, it is
[16:55] <pitti> I just didn't switch to that yet because it does not yet backport well
[16:55] <OdyX> tkamppeter: is your gs fix important ? (aka a Release-Critical in Debian ?)
[16:55] <OdyX> pitti: right
[16:55] <pitti> but it's certainly much more elegant
[17:03] <Keybuk> ivoks_away: it's a little known GNU licence :p
[17:07] <tkamppeter> pitti, I will do the changes in the next hour or so, please do not commit to CUPS.
[17:08] <pitti> tkamppeter: I won't touch it until September 13, when I'm back from vacation :) (which starts pretty much "now")
[17:08] <Keybuk> pitti: enjoy!
[17:11] <OdyX> tkamppeter: could you please report a bug with severity > important on the Debian BTS ?
[17:12] <pitti> Keybuk: thanks! looking forward to it -- a week of bicycling, tenting, then Vienna, and no computers :)
[17:13] <Keybuk> pitti: yeah, I just had a very enjoyable weekend with no computer
[17:15] <nigelb> pitti: Have fun :)
[17:59] <seb128> cjwatson, ev: is somebody watching ubuntu slideshow bugs?
[17:59] <cjwatson> I can't say I am
[18:00] <seb128> or rather is somebody working on updating those
[18:00] <seb128> ie bug #628809
[18:01] <ev> seb128: the slideshow is being redesigned for 10.10
[18:01] <seb128> ev, is being? wasn't uif 2 weeks ago?
[18:01] <seb128> or 1 week ago rather ;-)
[18:02] <ev> it's nearly there, we just decided against putting it in beta because we wanted to land a finished product
[18:02] <seb128> ev, do you have any idea when the new design will land? translators will need time to work on those
[18:02] <seb128> ev, hum, ok
[18:02] <ev> of course, but I don't have an ETA
[18:02] <ev> Dylan is working on it with support from Roz
[18:02] <seb128> ok thanks
[18:03] <seb128> can you make sure the f-spot -> shotwell change is included in their work?
[18:03] <ev> absolutely
[18:03] <seb128> ev, thanks!
[18:03] <ev> sure thing
[18:21] <tkamppeter> pitti, still there?
[18:46] <tkamppeter> Is the beta already out (= beta freeze over)? I did not get any e-mail and the Topic tells only FeatureFreeze.
[18:47] <seb128> tkamppeter, no
[18:47] <seb128> tkamppeter, see topic
[18:47] <seb128> tkamppeter, but you can upload, the updates queued will go in after the freeze end
[18:55] <smoser> anyone know, is there any command line interface to blueprints ?
[18:55] <Keybuk> nope
[18:55] <Keybuk> blueprints is the part of Launchpad that got left on the doorstep of the orphanage in a shoebox
[18:56] <smoser> good deal.
[18:57] <smoser> was going to try to hack something like editmoin for blueprints, but didn't want to duplicate any effort.
[19:04] <ScottK> Got roughed up a bit before being dropped off too.
[19:21] <tkamppeter> OdyX, hi
[19:21] <OdyX> hi tkamppeter
[19:24] <tkamppeter> OdyX, for Debian you should merge all Ubuntu changes (= upstream bug fix patches) into the feature-frozen version. These are all my cherry-picked bug fixes (some coded by me) from the 8.71 -> 9.00 development period of Ghostscript. 9.00 missed our Feature Freeze and is also relatively risky as it added ICC support, a big feature addition, therefore the bump of the major number.
[19:24] <OdyX> tkamppeter: for ghostscript you mean ?
[19:25] <tkamppeter> OdyX, in a non feature-frozen Debian version you should directly put Ghostscript 9.00.
[19:25] <tkamppeter> Yes, I mean Ghostscript.
[19:25] <OdyX> yeah sure, but we are in _full_freeze_ in Debian :)
[19:26] <OdyX> tkamppeter: does this fix one of http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=ghostscript&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious&repeatmerged=no
[19:26] <OdyX> or http://security-tracker.debian.org/tracker/source-package/ghostscript <- one of those ?
[19:26] <tkamppeter> OdyX, what does it mean? Also bug fixes not accepted any more, only CD fixes? One week before landing?
[19:26] <OdyX> tkamppeter: this means that Debian only accepts updates that fix "serious bugs" (> important)
[19:27] <OdyX> tkamppeter: the freeze is slightly relaxed these days, so a good rational'ized upload can still get trough, but it has more chance if it fixes bugs without adding "risky" changes
[19:29] <tkamppeter> OdyX, the mentioned bugs are not fixed (no one reported them to Ubuntu), the ones from the first link are fixed in 9.00, so a backport of the fixes could perhaps be done.
[19:30] <OdyX> tkamppeter: we have a big issue here on Debian: ghostscript is basically unmaintained, so any help is greatly welcome. :(
[19:31] <tkamppeter> OdyX, the most important fixes are three or four patches which fix several segfaults when the CUPS Raster output device is used with PDF input and tyhis is quite common in Debian, as CUPS is synced with Ubuntu.
[19:42] <OdyX> tkamppeter: I will try to address those issues next week, but I'll need your assistance. Right now I'm too busy.
[19:43] <El_Presidente> is this possible that this bisection result http://yfrog.com/n2bildschirmfotovp is the problem of my bug i filed here https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/572146
[20:12] <slangasek> kirkland: have you noticed that the update-motd files shipped by base-files aren't marked as conffiles?  lintian warns quite loudly about this now
[20:12] <kirkland> slangasek: i have not noticed that
[20:12] <kirkland> slangasek: is that something you'd like me to fix by RC?
[20:13] <slangasek> kirkland: I think that would be advisable; should just require updates to debian/conffiles in the source package
[20:13] <slangasek> (unfortunately base-files doesn't use the debhelper magic to do this for us)
[20:13] <kirkland> slangasek: yeah, that package is rather old fashioned
[20:36] <tkamppeter> OdyX, OK, let us sort out Ghostscript next week.
[20:36] <OdyX> tkamppeter: thanks
[23:37] <lifeless> marjo: hey, who runs the retracer these days?