[00:09] <apostols__> Hi
[00:09] <apostols__> I have problem with upgrade timezone in Ubuntu Dapper
[00:12] <apostols__> This dont have tzdata package and i need upgrade Venezuelan timezone (like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443202)
[00:12] <ubotu> Debian bug 443202 in tzdata "Venezuelan time zone change, September 2007" [Normal,Fixed]
[00:13] <Kmos> apostols__: do you have -proposed active on dapper ?
[00:13] <apostols__> Kmos, No
[00:13] <Kmos> 2007j-0ubuntu0.7.10
[00:14] <Kmos> this is the lat one in -updates and -propopsed
[00:14] <Kmos> -proposed
[00:15] <Kmos> it has the changes for venezuela
[00:15] <Kmos> * Replace tzdata2007i.tar.gz with new version tzdata2007j: - Updates DST rules for Venezuela.
[00:15] <Kmos> https://edge.launchpad.net/ubuntu/+source/tzdata
[00:15] <Kmos> as you can see here
[00:16] <apostols__> Kmos, This dont workfor Dapper
[00:16] <apostols__> Kmos, tzdata package dont exist in Dapper
[00:16] <apostols__> Kmos, Just exist locales package
[00:19] <Kmos> apostols__: it must exist
[00:20] <apostols__> Kmos, dont exist in Dapper
[00:20] <Kmos> you have all repositories active?
[00:20] <RAOF> Kmos: He's right.  tzdata was introduced in Edgy.
[00:20] <StevenK> Kmos: tzdata was split out from locales in Edgy
[00:20] <apostols__> Kmos, http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=tzdata&searchon=names&subword=1&version=dapper&release=all
[00:21] <Kmos> ups.. he's right..
[00:21] <Kmos> StevenK: you're right
[00:21] <Kmos> as always =)
[00:21] <apostols__> How to fixed its?
[00:23] <StevenK> apostols__: Make sure a bug is filed in Launchpad and has a task open against locales in Ubuntu Dappper
[00:23] <apostols__> Oh
[00:23] <apostols__> :S
[00:23] <Kmos> !info locales dapper
[00:23] <ubotu> locales: common files for locale support. In component main, is required. Version 2.3.18.7 (dapper), package size 3208 kB, installed size 12788 kB
[00:24] <slangasek> apostols__: have you checked whether version 2.3.18.7 of locales in dapper-updates includes this fix?
[00:24] <Kmos> https://edge.launchpad.net/ubuntu/+source/langpack-locales
[00:24] <Kmos> slangasek: that version has the fix..
[00:24] <Kmos> and it's at -updates
[00:29] <apostols__> slangasek, I have installed Version: 2.3.18.7
[00:30] <apostols__> slangasek, in my source.lists have deb http://ve.archive.ubuntu.com/ubuntu/ dapper-updates main restricted
[00:30] <apostols__> slangasek, this package is in main tree
[00:30] <slangasek> apostols__: and this version has the wrong timezone data for Venezuela?
[00:30] <apostols__> slangasek, yes
[00:31] <apostols__> slangasek, one second. I try test the timezone
[00:34] <apostols__> slangasek, This work
[00:35] <apostols__> root@arismendi:~# date
[00:35] <apostols__> Sun Dec  9 02:59:53 VET 2007
[00:35] <apostols__> root@arismendi:~# date
[00:35] <apostols__> Sun Dec  9 02:30:01 VET 2007
[00:37] <apostols__> slangasek, Thanks for you help
[00:37] <slangasek> apostols__: are you saying that it works now? I don't understand what you're showing, all I see is that your clock jumped back in time by a half hour. :)
[00:38] <apostols__> sladen, Yeah, this change of timezone back in time half hour (the change is -04:00 to -04:30)
[00:38] <apostols__> slangasek, Yeah, this change of timezone back in time half hour (the change is -04:00 to -04:30)
[00:38] <apostols__> sladen, excuseme
[00:40] <slangasek> ok
[01:04] <stratus> slangasek, please come back w/ my vorlon!
[02:01] <infinity> geser: Have you filed a bug about the versioned build-dep thing?
[02:01] <infinity> geser: Would be nice to have a way to track it.
[02:11]  * Hobbsee waves
[04:00] <pwnguin> which is the best way to measure a program's memory usage in GNOME?
[06:11] <dholbach> good morning
[08:09] <pitti> Good morning
[08:11] <dholbach> hey pitti
[08:15] <\sh> moins
[08:18] <dholbach> hey seb128
[08:18] <seb128> hello dholbach
[09:31] <seb128> pitti: can you give a build retry to evolution?
[09:31] <pitti> seb128: done
[09:31] <seb128> pitti: danke
[09:39] <seb128> pitti: ditto for nautilus? ;-)
[09:39] <pitti> done
[09:39] <seb128> thanks!
[09:51] <TheMuso> If an archive admin is around and doing duties, could they please promote python-pyatspi from universe? Its source package, at-spi is in main. Python-atspi is needed by gnome-orca to function. Otherwise, I assume I need to file a bug to get this taken care of?
[09:51] <pitti> TheMuso: no, that's fine
[09:52] <pitti> TheMuso: done
[09:55] <TheMuso> pitti: Thanks.
[09:58] <StevenK> pitti: It seems gcrypt is still causing havoc
[09:58] <StevenK> creating libqgis_core.la
[09:58] <StevenK> /bin/sed: can't read /lib/libgcrypt.la: No such file or directory
[09:58] <pitti> meh; can libtool finally decide where it wants to look for the .la?
[09:59] <StevenK> It seems not
[09:59] <StevenK> Should we put the .la in /lib, and have a symlink from /usr/lib?
[10:01] <pitti> StevenK: I thought Riddell already did something like that?
[10:01] <StevenK> He did?
[10:01] <pitti> ah, that was in libgpg-error
[10:02] <pitti> so, yes
[10:02] <pitti> (bwah)
[10:03] <StevenK> So, should I do the same for gcrypt?
[10:03] <pitti> StevenK: either that, or we give up and revert all our patches *sigh*
[10:04] <StevenK> pitti: I daresay adding a symlink should be simple-ish
[10:04] <pitti> it is
[10:04] <TheMuso> Is libtool just not realizing that .la files it needs to fnd or packages have moved or something?
[10:04] <TheMuso> find
[10:04] <StevenK> pitti: I think we need to ask for battle pay, and go on a rampage hurting the libtool authors
[10:04] <pitti> TheMuso: it's behaving bizarre
[10:05] <pitti> TheMuso: the basic problem is that libtool seems to have no way to install a lib into /lib
[10:05] <TheMuso> pitti: No kidding.
[10:05] <pitti> so, if it's there, it sometimes looks for the .la in /usr/lib, and sometimes in /lib
[10:05] <TheMuso> Right.
[10:06]  * StevenK hacks libgcrypt11
[10:06] <StevenK> pitti: Real file in /lib or /usr/lib?
[10:07] <pitti> StevenK: /usr/lib, I'd say, but it shouldn't matter much
[10:07] <pitti> just for consistency with libgpg-error
[10:13] <soren> dpkg uploaded.
[10:13]  * soren starts to sweat uncontrollably
[10:13] <pitti> wooo!
[10:14] <StevenK> Hah
[10:14]  * pitti congratulates soren for being TIL now
[10:14]  * seb128 hugs soren
[10:15] <soren> pitti: :p
[10:17] <StevenK> pitti: Giving libgcrypt11 a nice hard test build before uploading
[10:20] <soren> I've been looking into kvm and qemu a lot lately, and I've stumbled upon bug 64501.
[10:20] <ubotu> Launchpad bug 64501 in openhackware "FTBFS" [Critical,Triaged] https://launchpad.net/bugs/64501
[10:20] <soren> It's an arch: all package that needs to be built on powerpc.
[10:20] <soren> Would be acceptable to change that package to be arch: powerpc, build it, and make an arch: all package that ships the resulting files (kind of like ia32-libs for amd64)?
[10:22] <pitti> eww
[10:22] <soren> I know :)
[10:22] <pitti> soren: why not just keep it as Arch: powerpc?
[10:22] <soren> Better suggestions?
[10:22] <soren> Because it's a BIOS image that qemu needs on other archs as well.
[10:22] <pitti> ah
[10:22] <soren> ..to be able to emulate powerpc.
[10:23] <soren> And it only builds on powerpc.
[10:23]  * pitti rolls back to "Eww"
[10:23] <StevenK> Hah
[10:23] <pitti> soren: do you know why it can only be built on powerpc?
[10:23] <pitti> does it actually compile the bios?
[10:23] <soren> AFAIR, yes.
[10:24] <TheMuso> soren: I can test build on PowerPC if you need it tested before you upload.
[10:24] <soren> TheMuso: I have access to a powerpc machine, but thanks for the offer!
[10:24] <TheMuso> soren: Ok no problem then.
[10:25] <soren> pitti: It might just be the case that my crossbuild-fu isn't strong enough.
[10:25] <StevenK> Or that dpkg stole it
[10:25]  * StevenK sniggers, and feeds soren's complex
[10:26]  * soren whimpers
[10:28] <StevenK> pitti: libgcrypt11 uploaded, and I've upped my bounty on the libtool developers.
[10:28] <pitti> great, thanks
[10:28] <pitti> /msg StevenK let's have a good beating at it in the afternoon
[10:29] <StevenK> The bounty, the developers or libtool? :-)
[10:29] <Treenaks> StevenK: hmm.. are those devs in paris?
[10:29] <pitti> libtool; I'm not *that* cruel :)
[10:29] <StevenK> Treenaks: I'm only naming the guilty party.
[10:29] <StevenK> :-P
[10:30] <pitti> StevenK: for the developers, my evil plan is to lock them into a room with libgpg-error and libtool, and not allow them to come out again until they made it work right
[10:30] <StevenK> pitti: Add libgcrypt11 and cryptsetup with /usr on a seperate partition, and you have my vote.
[10:33] <Hobbsee> soren: how the *hell* did you manage to bork dpkg like that?
[10:33] <soren> Hobbsee: :p
[10:33] <Hobbsee> YOU BROKE IT!  BAD SOREN!
[10:34] <soren> Hobbsee: You should at least until the thing has actually built and been published before trying that :)
[10:34] <Hobbsee> soren: haven't you heard that buildd admins can see, even before others can, and can smell breakage almost immediately?
[10:35] <soren> Hobbsee: No, I must have missed the memo.
[10:35] <Hobbsee> soren: now you know.
[10:35] <soren> Noted :)
[10:36] <soren> You know... One day, a long time from now, I'll stumble upon that note, and wonder why "buildd admins have superhuman sense of smell".
[10:37] <soren> I could make it even more cryptic and make it say "buildd admins smell really well".
[10:37] <Hobbsee> haha
[10:37]  * Hobbsee has uploaded dpkg before, and only just survived to tell the tale
[10:38] <StevenK> soren: You could make it an in-joke and s/ really well//
[10:38]  * StevenK hides from Hobbsee, pitti and Mithrandir
[10:38]  * Hobbsee beats StevenK 
[10:38] <StevenK> Ouch!
[10:38] <soren> Hobbsee: That's odd. I don't see your name in the changelog?
[10:39] <Hobbsee> soren: i sponsored a change
[10:39] <soren> Hobbsee: Oh.
[10:39] <Hobbsee> then had iwwj attempting to eat me
[10:40] <StevenK> Who's change did you sponsor?
[10:40] <StevenK> Oh damn
[10:40] <StevenK> pitti: Can you reject libgcrypt11?
[10:41] <pitti> StevenK: no
[10:41] <StevenK> Drat
[10:41]  * StevenK quickly uploads a new version
[10:41] <pitti> StevenK: nowadays sources wander straight into DONE
[10:41] <pitti> no reject-from-accepted any more
[10:42] <StevenK> Bad Soyuz
[10:42] <StevenK> There we go, uploaded
[10:42] <Hobbsee> StevenK: no, it's just more efficient now :P
[10:43]  * StevenK raises an eyebrow.
[10:43] <Hobbsee> you're complaining about it being more efficient?
[10:43] <StevenK> It introduces that you can't reject uploads, and besides, it seems to wait until sources are published before creating build records
[10:45]  * StevenK idly wonders if Soyuz deals with Pending -> Superseded
[10:46] <StevenK> Hrm. So far both -2ubuntu6 and -2ubuntu7 are Pending
[10:50] <ogra> urgh, somewhitng really weird happened to my fonts since the last update
[10:51] <ogra> ah, restarting FF helps :)
[10:51] <pitti> StevenK: no, it doesn't; build records can be created immediately after upload
[10:52] <pitti> of course it actually takes eons, but it's not tied to publishing
[10:52] <StevenK> Oh right, so it the build machinery just taking that long, and not waiting for the publisher
[10:54] <pitti> right
[10:55] <pitti> StevenK: ideally build records would be created immediately on accepting, and that's in fact the plan
[11:07] <lool> Is it easy to run my own local CD builds, perhaps with locally modified packages or package lists, to have ISOs to run in emulators?
[11:08] <lool> Or are you people using daily images and pushing changes via hardy to see how they affect the live CD? :)
[11:09] <soren> Hmm... I'm trying to determine what changed in debian-policy between 3.7.2.2 and 3.7.3... The changelog lists only bugfixes afaics, but that would usually cause the version to be bumped to 3.7.2.3 rather than 3.7.3.0 wouldn't it?
[11:10] <lool> soren: Well there are some changes in upgrading-checklist such as using ${binary:Version} instead of ${Source-Version} which are required by the new version
[11:11] <lool> soren: Or the recommendation to link to the GFDL in /usr/share/common-licenses instead of copying it
[11:12] <soren> lool: Hm.. Ok. That's it?
[11:13] <lool> soren: There are other things as well; upgrade-checklist lists some stuff which you probably wouldn't want to care about, but it has some useful bits I think
[11:14] <lool> I don't think it's very useful to mention "may do" stuff when it's already widely done for example :)
[11:14] <soren> lool: I'm just looking for a list of functional changes (not just fixed typos or whatever), so that I can tell if I can update my package to "Standards-Version: 3.7.3". :/
[11:14] <lool> soren: Well upgrade-checklist is meant to be exactly this
[11:15] <soren> lool: Ah...
[11:15] <soren> lool: Ok, now I get it. :) Thanks.
[11:15] <lool> It's a bit too long to my taste, but it's supposed to list effective things you should check when upgrading to a newer standard-versions
[11:16] <lool> On my packages, I'd probably double-check binary:Version, check copyright for GPLv3 or GFDL, check menu sections (but probably lintian would tell me anyway), and that's probably all I'm using
[11:16] <soren>       * The Source field in a .changes file may contain a version number
[11:16] <soren>         in parentheses.
[11:17] <lool> Yeah, that's really a lot of chatter for something probably two people care about
[11:17] <soren> That sounds odd.
[11:19] <soren> lool: Ok. Thanks for pointing out upgrade-checklist a sufficient number of times for me to actually get it. :)
[11:19] <lool> soren: Ah you didn't know about the fiel?
[11:19] <soren> lool: Nope.
[11:20] <lool> I discovered it after a lot of time too; but it's mentionned in the changelog this time around :)
[11:20] <soren> Oh, really?
[11:21] <TomaszD> who can I speak with about whitelisting a laptop for acpi?
[11:21] <cjwatson> lool: it's unfortunately tedious to run one's own CD builds
[11:21] <cjwatson> the code's all there, but it's something of a pain to set up
[11:21] <cjwatson> if you need it, I can help you
[11:22] <cjwatson> you also need a full local mirror, at least of main and restricted
[11:22] <soren> lool: Well, even if it did, I wouldn't have considered looking at it. I think I expected it to be a checklist for when upgrading packages, like: "Make sure if files move, you put conflicts: and replaces:" or something. I didn't put much thought into the matter, clearly.
[11:22] <cjwatson> the Source thing is support for dpkg experiments I think
[11:23] <TomaszD> someone resigned from triaging my bug and I've been waiting for nine months
[11:23] <TomaszD> https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/92806
[11:23] <ubotu> Launchpad bug 92806 in linux-source-2.6.22 "N340S8 laptop needs to have ACPI enabled" [Undecided,Confirmed]
[11:23] <lool> cjwatson: Is it ok to have a http_proxy like squid?
[11:23] <cjwatson> lool: no, it really needs a mirror on disk
[11:23] <lool> Ah
[11:23] <lool> That sounds like many intermediate steps to reach the point where I can do actual tests; I think I'll defer that a little then
[11:24] <cjwatson> I suppose you could mount one with something to do with fuse over a squid proxy but argh
[11:24] <lool> cjwatson: Is it easy to override packages or package lists -- bit still keeping the mirrors a clean true mirror?
[11:24] <lool> s/bit/but
[11:25] <cjwatson> lool: the cdimage code has some (unused for some time) support for local packages
[11:25] <cjwatson> back when we were doing warty it took a while to get Ubuntu itself into shape, so I had local overrides of a few packages in cdimage in order to be able to build installable CDs
[11:25] <cjwatson> that would be easier than changing the mirror
[11:26] <lool> Ok; perhaps I'll just boot a CD and use casper USB persistence if that's still available to install my experiments and see how to do that properly later
[11:26] <cjwatson> typically I just modify things on the fly if I need to do this sort of test, I must admit
[11:26] <lool> Ok; thanks for the info
[11:26] <cjwatson> I do think it would be useful to have a facility for this eventually, but no capacity for it for hardy ...
[11:27] <cjwatson> (as in a proper user-oriented facility for customising CD images; we talked about it at UDS)
[11:28] <lool> cjwatson: If I wanted to look into building hardy daily images, where should I start?  I think it's "ubuntu-cd"?
[11:28] <cjwatson> http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ and also check out the bits listed in configs/devel
[11:28] <soren> cjwatson: How do you usually test stuff like gfxboot and isolinux then? Extract an existing iso, replace the relevant files, re-mkisofs, test?
[11:29] <cjwatson> soren: I have a little manually-driven test suite for the gfxboot theme
[11:29] <lool> cjwatson: Noted, thanks
[11:29] <cjwatson> it's just a thing where I can do 'make -C test' and it fishes stuff out of known places in my local directory layout
[11:30] <cjwatson> I don't use a full tree for it, just a few files that are enough to test the theme
[11:30] <soren> cjwatson: Alright.
[11:30] <cjwatson> soren: http://people.ubuntu.com/~cjwatson/tmp/gfxboot-test.tar.gz
[11:31] <cjwatson> bit dated but hasn't changed much either
[11:31] <cjwatson> pitti: I assume you'll want another d-i for dapper-proposed?
[11:31]  * soren looks
[11:32] <pitti> cjwatson: yes, please; if that lbm ever condescends to build
[11:32] <pitti> but yeah, having d-i in the queue would be great
[11:32] <LongPointyStick> where's my supersonic jet?
[11:33] <soren> cjwatson: Ah, clever.
[11:33] <cjwatson> pitti: heading queuewards now
[11:33] <soren> LongPointyStick: Where are you going in that?
[11:50] <pitti> Riddell: do you know about libkarma? the MIR (https://wiki.ubuntu.com/MainInclusionReportlibkarma) is almost useless
[11:50] <pitti> Riddell: does it actually work on a standard Ubuntu kernel? the cited pmount bug is long obsolete
[11:50] <Riddell> pitti: I'm told it does yes
[11:55] <cjwatson> TomaszD: the bug was confirmed so there was no longer a need for a triager anyway
[11:55] <cjwatson> TomaszD: odd though, the patch for your system still seems to be there
[11:56] <TomaszD> cjwatson, indeed, but it doesn't work :(
[11:56] <TomaszD> after dapper or edgy I have to acpi=force in menu.lst
[11:57] <cjwatson> TomaszD: yeah, it's just that you explicitly said the patch was removed and I don't see that it was
[11:57] <cjwatson> so trying to work out what happened
[11:58] <TomaszD> cjwatson, ok. You know IANAE, but I thought that once I don't have the functionality the patch must have been dropped by mistake
[11:58] <cjwatson> TomaszD: to be clear, we're talking about ACPI sleep, right?
[11:58] <pitti> asac: xulrunner MIR> when we will switch firefox to 3 by default?
[11:58] <cjwatson> (you just said "ACPI" in the bug)
[11:58] <TomaszD> cjwatson, we're talking about turning on ACPI at all
[11:59] <TomaszD> cjwatson, because I get the message about the bios being to old and going under the bios cut-off age
[11:59] <cjwatson> err, acpi-support doesn't have one of those
[11:59] <TomaszD> cjwatson, so it's not whitelisted then?
[11:59] <cjwatson> perhaps it would help if you copied the *exact* message you're seeing into the bug
[12:00] <asac> pitti: in january i guess ... there is still too much work going on upstream to not cause any confusion ... for now i need xul 1.9 in main to update all the other rdepends.
[12:00] <seb128> mdke: any news about the yelp layout patch update?
[12:01] <asac> pitti: maybe b2 will be good enough though (which will be next week i guess)
[12:01]  * pitti switches his desktop to ffox 3 for testing love
[12:01] <TomaszD> it appears just for a second, it says your bios falls under the bios cut-off age, because it's older than 1998 (which isn't true, it's 2002), so acpi functions will have to be forced to be enabled cjwatson
[12:01] <pitti> asac: ah, I see; but we'll definitively drop 2 for hardy
[12:01] <cjwatson> TomaszD: I've commented on the bug; it's not an acpi-support problem, it's a kernel problem
[12:01] <asac> pitti: yes. we cannot support ffox 2 for such a long time
[12:02] <TomaszD> whenever I install a new version of ubuntu cjwatson I just go menu.lst and acpi=force there, I got used to it, but acpi was working in dapper
[12:02] <asac> pitti: as proposed in https://wiki.ubuntu.com/XulrunnerGecko ... we will allow universe rdepends to switch to xulrunner 1.8 ... in case they don't get ready in time.
[12:03] <cjwatson> I imagine the kernel got stricter
[12:03] <pitti> asac: ah, so in ffox 3 I don't have those ugly typewriter fonts (as broken by recent fontconfig), but I don't have the smooth fonts either; but slightly better, I'd say :)
[12:04] <asac> pitti: yeah ... there is a request to patch xulrunner for subpixel stuff (bug 164640) ... maybe thats the problem?
[12:04] <ubotu> Launchpad bug 164640 in xulrunner-1.9 "Build Firefox 3 against a subpixel-patched cairo" [Undecided,Confirmed] https://launchpad.net/bugs/164640
[12:04] <pitti> asac: I guess so
[12:05] <pitti> asac: ok, promoted
[12:05] <asac> pitti: rock!
[12:06] <pitti> asac: but what's wrong with switching to 3 early? after all, testing is why we all run hardy now?
[12:07] <seb128> xulrunner1.9 promoted?
[12:07] <seb128> which means we can build the GNOME packages using it now?
[12:07] <asac> seb128: yeah ... if you apply the patches i have ;)
[12:08] <asac> seb128: https://code.edge.launchpad.net/~mozillateam/xulrunner/xulrunner-porting
[12:08] <asac> there is yelp, devhelp and epiphany ... though epiphany is against current trunk
[12:09] <asac> i will add the python gtkmozembed today i hope (after cleaning things up)
[12:09] <asac> seb128: ah ... totem is in that xulrunner-porting thing as well
[12:10] <pitti> cjwatson: WDYT about libssh? There's a MIR for it, but I have some concern about having two ssh implementations in main
[12:10] <asac> pitti: i wanted to fix xulrunner to consider all the needed plugins/extensions directories before making firefox-3.0 default ... otherwise we will end up installing plugins in a place that is not ment to be the final one.
[12:11] <pitti> asac: ah, that's a good point, yes
[12:11] <seb128> asac: do you want to do the upload or should have a look to that? I've nothing special to do this afternoon so I'm fine looking at the changes and the wiki page I said I would read the other day and upload the xulrunner versions ;-)
[12:12] <asac> seb128: i would prefer if you could take the uploading part and maybe even upstream submission
[12:13] <asac> seb128: before you touch a package better ask me for any regression i know of ... so you can decide if its good enough for initial upload
[12:14] <asac> to start with: yelp patch has no known regression for me
[12:17] <seb128> asac: ok, will do that after lunch then, thanks
[12:18] <asac> seb128: nothing to hurry ... you need to wait till the xulrunner-1.9 package i uploaded today is build because it changed the names of the .pc files to the final ones
[12:22] <seb128> asac: ok
[12:24] <cjwatson> pitti: since openssh is never likely to provide a library, it doesn't hugely bother me
[12:24] <pitti> cjwatson: yeah, but it just feels...wrong
[12:25] <cjwatson> your call
[12:26]  * gicmo yawns
[12:46] <LongPointyStick> for the love of the great green arklesneezer, this is absolutley ridiculous!
[12:46] <LongPointyStick> grr!
[12:46] <Nafallo> hmmm
[12:47] <Nafallo> LongPointyStick: what now?
[12:47] <LongPointyStick> my system has frozen 4 times in the past 10 minutes!
[12:47] <LongPointyStick> that's a new low for hardy.
[12:48] <LongPointyStick> tjaalton: where should i start looking as to why it's freezing?
[12:48] <dholbach> MOTU Q&A session in 11 minutes in #ubuntu-classroom
[12:52] <tjaalton> LongPointyStick: well, there have been no updated x-packages lately, to my knowledge :)
[12:53] <LongPointyStick> tjaalton: this has happened for a while, but seems worse atm.
[12:53] <LongPointyStick> oh, interesting.  compiz is showing 100% cpu
[12:53] <ogra> compiz was updated today :)
[12:54] <ogra> and yesterday
[12:54] <tjaalton> well, there you go :)
[12:58] <LongPointyStick> and now it behaves, with another machine ssh'd in
[13:00] <Hobbsee> or not.
[13:00] <StevenK> Heh
[13:01] <asac> hmm on lpia i get a strange build failure for xulrunner-1.9 : http://paste.ubuntu.com/2524/
[13:01] <Nafallo> compiz doesn't do the newer Intels yet, right?
[13:03] <Hobbsee> Nafallo: this isnt' really a newer intel
[13:03] <Nafallo> Hobbsee: was more of a general question dear :-)
[13:04] <Nafallo> GM965 / X3100 or so.
[13:04] <Hobbsee> oh
[13:06] <asac> pitti: maybe the promotion in the mids of a xul build caused these "failed to upload" errors? https://edge.launchpad.net/ubuntu/+source/xulrunner-1.9/1.9~b1+nobinonly-0ubuntu2
[13:06] <Hobbsee> tjaalton: actually, i don't think you get blamed for this.  it appears that compiz shows 100% CPU and locks up (while the programs all still run), when more than 1 active "notify me" window is there.
[13:06] <pitti> asac: right; let me give them back
[13:06] <Hobbsee> asac: yes, that's correct
[13:06] <asac> pitti: thanks!
[13:07] <torkel> Nafallo: they removed the blacklistning of 965 in -0ubuntu3
[13:07]  * asac lunch
[13:07] <Nafallo> torkel: cheers. sounds scary 'nough to update according to Hobbsee though ;-)
[13:08] <Nafallo> ...and Fujitsu
[13:17] <Hobbsee> Fujitsu: you still around?
[13:23] <pitti> asac: is there a way to tell gnome to use ffox-3 as my prefered application? it opens ffox 2 on clicking on a link ATM, but ffox 2 doesn't appear in gnome-default-applications-properties
[13:23] <lool> pitti: You can set a manual command?
[13:24] <lool> pitti: %s for the URL
[13:24] <pitti> yeah, of course
[13:24] <pitti> but it shuold still appear there
[13:24] <lool> It needs to be patched in control-center IIRC
[13:24] <seb128> pitti: how is the binary called?
[13:24] <pitti> firefox-3.0
[13:24] <pitti> oh, it's hardcoded there?
[13:24] <lool> Yeah
[13:24] <pitti> I thought it was some .desktop file somewhere
[13:25] <pitti> after all, even lynx appears there :)
[13:25] <lool> I think it has a mapping
[13:25] <seb128> pitti: /usr/share/gnome-control-center/gnome-default-applications.xml has the list of known applications
[13:25] <pitti> seb128: aah, I understand; thanks
[13:25] <seb128> need to patch gnome-control-center
[13:25] <seb128> I'll do it
[13:25] <pitti> seb128: well, shouldn't be necessary in the end
[13:26] <pitti> seb128: once we ship 3 by default, the binary will be 'firefox' (hopefully :) )
[13:26] <seb128> if the binary is renamed firefox no need to rename
[13:26] <seb128> right
[13:26] <pitti> I just wondered by which mechanism a package appears there
[13:26] <pitti> so I was concerned that ffox-3 needs to ship a .desktop file for that, or so
[13:27] <seb128> that would be a better way to do things
[13:27] <seb128> but at the moment the list is in gnome-control-center
[13:27] <pitti> seb128: ok; nevermind then
[13:27] <pitti> and thanks for the explanation
[13:27] <seb128> you are welcome
[14:30] <xhaker> seb128, can i discuss default torrent client for Ubuntu with you?
[14:32] <seb128> xhaker: if you want too, I'm not sure I'm the best person for that discussion though since I don't know the alternatives nor use bittorrent
[14:33] <xhaker> seb128, just thought you were appropriate since you are a "gnome" guy. My take is that gnome-btdownload + bittorrent should step back
[14:34] <xhaker> I've been thinking to myself, that Transmission is very much the best for a default torrent client
[14:36] <xhaker> While trying out fedora8 live through an usbkey, i noticed they have transmission there. :) I wish we could do the same.
[14:36] <seb128> xhaker: maybe mail ubuntu-desktop or ubuntu-devel-discuss list about some rational on why you think transmission is better
[14:36] <seb128> I think some people did in the past but other users replied that transmission was not stable and crash all the time, etc
[14:37] <xhaker> seb128, it might be true.. but i've been following the development.. they're really active.. and they're running up for the 1.0 release.. last version on the repositories is 0.95
[14:37] <xhaker> Will send my rationale to ubuntu-desktop ml
[14:37] <seb128> xhaker: is there anybody looking at the launchpad bugs for transmission? like an upstream guy?
[14:37] <azeem> just because they call it 1.0 doesn't mean it's bug-free
[14:38] <seb128> that would show they have interest to have it used in ubuntu ;-)
[14:38] <seb128> xhaker: thanks
[14:39] <xhaker> azeem, it means they're pretty confident it'll be good.. check their trac page.. they look into HIG, and there are lots of worrying with memory leaks :D
[14:44]  * ogra wonders if there is a way to compile dillo with xulrunner now :P 
[14:47]  * xhaker is not smart enough to understand why debian and ubuntu build-depend differently in respect of xulrunner-dev and firefox-dev
[14:47] <poningru>  xhaker please also add deluge to the possibility of default torrenting clients
[14:48] <xhaker> poningru, don't get me wrong.. I'm using deluge right now.. I have both clients installed.. but Transmission is leaps ahead in ease of use
[14:48] <ogra> xhaker, lawyers will uderstand that :)
[14:49] <xhaker> poningru, it just downloads, and does a good job at that. :) hence the proposal for shipping in the default install
[14:49] <poningru> xhaker, ah k
[14:50] <poningru> someone also needs to solve the natting problem with those things
[14:50] <poningru> as in some client program that works with routers that automatically adds a port
[14:50] <poningru> forwarding
[14:52] <xhaker> Transmission will use http://miniupnp.free.fr/ projects.. provides upnp and natpmp
[14:52] <xhaker> It will maybe handle more routers than their solution now
[15:33] <pitti> seb128: I assume totem-pl-parser should go into main?
[15:33] <seb128> pitti: yes
[15:33] <seb128> pitti: totem will depends on it when it's accepted
[15:34] <seb128> pitti: danke ;-)
[15:34] <pitti> seb128: looks good to me, accepted
[15:35] <pitti> *whistle* NEW is empty again
[15:37]  * Hobbsee uploads more
[15:37] <ScottK> pitti: Did you figure out how to remove crack from partner yet?
[15:38] <pitti> ScottK: yes, it's actually gone; I just didn't close the bug yet
[15:38] <ScottK> pitti: Great.  Thanks for that/
[15:38] <ScottK> /.
[16:00] <Nafallo> ehrm
[16:00] <Nafallo> "remove crack for partner". that can be quite misunderstood ;-)
[16:03] <pitti> BenC: re lbm patch> I sent a mail about that this morning with a pointer to the patch
[16:03] <BenC> pitti: oops, must have missed that, sorry
[16:04] <pitti> BenC: no problem; it's attached to bug 164449, so you can grab it from there
[16:04] <ubotu> Launchpad bug 164449 in linux-backports-modules-2.6.15 "undefined symbols in mptspi driver" [High,Fix released] https://launchpad.net/bugs/164449
[16:04] <Hobbsee> BenC: can i ask when we get l-u-m for .24?
[16:04] <BenC> Hobbsee: before monday
[16:04] <Hobbsee> BenC: \o/
[16:30] <pitti> cjwatson: wrt. getting the noptrace group into base-passwd; do you think we should discuss abusing an existing group and put that into a meeting (TB or whatever), or shall I file a bug about adding 'noptrace' to base-passwd?
[16:32] <cjwatson> I'd like it to be discussed on debian-devel
[16:32] <cjwatson> base-passwd is one package I really don't want to be out of sync
[16:33] <cjwatson> and I want complete propriety in how changes to the master files happen
[16:33] <pitti> ok, I'll send a mail there
[16:34] <cjwatson> thanks
[16:37] <ScottK> Nafallo: Pick a better word that characterizes uploading software to a public repository with known remote code exploits unpatched?
[16:40] <keescook> mornin'
[16:41] <Nafallo> ScottK: foolness. what did I do now?
[16:45] <ScottK> Nafallo: Not you.  I was responding to your comment about crack and partner.
[16:45] <Nafallo> ScottK: ah :-)
[16:47] <lool> I don't understande why some uploads to hardy-changes aren't signed
[16:47] <cjwatson> lool: syncs are unsigned
[16:48] <lool> 3.16.0-4ubuntu1 => probably not a sync; I think the body of the mail has in fact a signature, but Mutt doesn't recognize it as such
[16:48] <cjwatson> we just copy those from Debian, and they're done on a trusted system and inserted through basically a back door in the queue system rather than inventing a fake key to sign them with
[16:48] <cjwatson> ah
[16:48] <lool> Either an encoding issue or a Mutt bug
[16:49] <cjwatson> ScottK: not that it was the right thing to do; but we did know that the problems in openssl097 did not affect vmware
[16:50] <ScottK> cjwatson: I understand that.  That was no where publically documented and certainly doesn't help a bit when people (our competition) says ubuntu-server isn't secure enough to take seriously.  The percpetion (if not the fact) was very poor.
[16:50] <ScottK> It also pained me personally after investing a lot of time in getting it removed from Universe.
[16:51] <lool> Ah it's UTF-8
[16:51] <lool> That's the data confusing Mutt
[16:52] <cjwatson> ScottK: I know, we still have work to do on a proper response that includes documentation on what will be allowed in partner; it's in progress ...
[16:52] <ScottK> cjwatson: Good to hear.  Thanks.
[16:52]  * ScottK grumbles again that it'd be better if Partner were more clearly a Canonical production than an Ubuntu one.
[16:53] <cjwatson> what can we do to make that clearer?
[16:54] <cjwatson> or, perhaps a fairer question, in what places is it currently unclear?
[16:54] <ScottK> In LP it's not clear at all.
[16:54] <ScottK> For example, bugs against things in Partner are described as "in Ubuntu"
[16:54] <cjwatson> hmm, I didn't realise that packages in partner showed up under Ubuntu
[16:54] <cjwatson> I agree that that's unfortunate
[16:55] <cjwatson> (or perhaps I did know and forgot)
[16:55] <ScottK> If you go to the front page for the 7.10 release, Partner is listed as just another repository.
[16:55] <ScottK> cjwatson: There's an LP bug.  Let me find it.
[16:56] <cjwatson> I don't see partner mentioned on /ubuntu/gutsy
[16:56] <ScottK> cjwatson: Bug #153798
[16:56] <ubotu> Launchpad bug 153798 in soyuz "canonical partner repo packages showing as "in ubuntu"" [Undecided,Confirmed] https://launchpad.net/bugs/153798
[16:56]  * ScottK looks again
[16:57] <cjwatson> ah, it's on /ubuntu
[16:57] <ScottK> Yes.  Sorry about that.
[16:57] <ScottK> That's actually worse.
[16:58] <cjwatson> followed up to the bug
[16:58] <ScottK> cjwatson: Thanks.
[16:58] <cjwatson> (not with good news, I'm afraid)
[17:00] <ScottK> cjwatson: I understand your answer, but as a non-Canonical developer, it's very frustrating.
[17:50] <blueyed> mjg59`: are you planning to merge powernowd? I've collected a whole bunch of fixes in the last days, which are attached to bug 67341. If you like, I could do the merge and include those - then you could just sponsor it.
[17:50] <ubotu> Launchpad bug 67341 in powernowd "powernowd doesn't use /etc/default/powernowd anymore" [Low,Triaged] https://launchpad.net/bugs/67341
[18:03] <geser> pitti: please give-back: compiz-fusion-plugins-extra
[18:11] <cjwatson> ScottK: some things are frustrating both inside and outside Canonical ...
[18:14] <ScottK> ;-)
[18:18] <pitti> cjwatson: d-devel@ mail about ptrace() sent; let the flamefest begin :)
[18:23] <pitti> keescook: ^ I BCCed you to that FYI
[18:23] <keescook> pitti: cool; thanks.
[18:28]  * pitti blinks
[18:29] <pitti> cjwatson: I just wanted to add a gutsy task to your SRU bug, but guess which release is missing on https://bugs.edge.launchpad.net/ubuntu/+source/finish-install/+bug/174689/+nominate
[18:29] <ubotu> Launchpad bug 174689 in finish-install "hvc/hvsi consoles not handled" [Undecided,New]
[18:29] <pitti> cjwatson: any idea why?
[18:29] <cjwatson> because I targeted it myself 10 minutes ago or so
[18:30] <pitti> ah, heh; sweet race
[18:30] <pitti> thanks
[18:30] <pitti> I stared at the check boxes for at least 10 seconds until I realized :)
[18:30] <cjwatson> might be worth a Malone bug
[18:44] <geser> pitti: please give-back: gdome2-xslt
[18:50] <geser> pitti: please give-back: ocamlgraph
[18:50] <pitti> geser: both done
[18:55] <geser> pitti: please give-back: compiz-fusion-plugins-extra
[18:57] <pitti> done
[18:58] <geser> thanks
[19:06] <Eckzillor> Hello
[20:01] <sistpoty> hi folks
[20:03] <pochu> hiya sistpoty
[20:03] <sistpoty> hi pochu
[20:14] <geser> should build-dependencies on gs-common be replaced with ghostscript or is build-depending on gs-common still ok (especially for a package in main)?
[20:40] <tjaalton> any hal experts around?
[20:42] <Burgundavia> tjaalton: you might be better to ask in #hal or #gnome-hackers on gimpnet
[20:44] <tjaalton> Burgundavia: right, I'll do that if I can't figure it out myself eventually
[20:44] <tjaalton> the problem, that is
[22:29] <AgentHeX> i've got a bug in the gnome power manager where the display brightness will "dim" to a value higher than what i manually set with the keyboard shortcut when it thinks i'm idle.  i would like to fix this bug.  what should i download to take a look?
[22:29] <ScottK> AgentHeX: I have a vague recollection that there was a bug on this already.  Dunno if it's been fixed in Hardy or not.
[22:30] <AgentHeX> ScottK: i'm on gutsy right now.  i was kind of looking for an introduction to developing in ubuntu.  i'm a C++ coder but i have little experience coding in linux, and i'm looking for a way i can explore.  any hints?
[22:31] <ScottK> Sorry.  I'm a KDE person.
[22:31] <AgentHeX> ScottK: i'm pulling eclipse atm, so i'll have that soon, and i figured the gpm bug might be a good start
[22:31] <AgentHeX> ScottK: how might i go about getting the source for the gnome power manager?
[22:32] <ScottK> I'd suggest looking for the gdm bug and seeing what's already there (it had a proposed patch, dunno how good it is).
[22:32] <slangasek> "apt-get source gnome-power-manager"
[22:32] <AgentHeX> ah
[22:32] <AgentHeX> slangasek: i was looking in synaptic.
[22:33] <ScottK> AgentHeX: First lesson is developers will taunt you if you insist on using GUI tools and not command line.
[22:33] <slangasek> they will?
[22:34]  * slangasek covers up his update-manager
[22:34] <Nafallo> hmm. I use sudo update-manager from a terminal ;-)
[22:36] <AgentHeX> ScottK: i would *rather* use a GUI IDE, but i *could* use a CLI
[22:37] <ScottK> You'll get over it ;-)
[22:37] <AgentHeX> ScottK: i'm familiar enough with vim that i prefer it to a generic text editor (gedit, notepad, et al), and it's proably a good thing since i'm on a laptop and the touchpad is kinda annoying
[22:37] <ScottK> Excellent.
[22:38] <ScottK> I think your basic strategy of find stuff that annoys you and try to fix it is a good one.
[22:38] <AgentHeX> ScottK: but i'd still rather use a gui.  if there was a gui version of vim, i'd be in heaven.
[22:38] <ScottK> I think there is, but I don't recall for sure.
[22:38] <tkamppeter> pitti. hi
[22:39] <AgentHeX> ScottK: i'm kinda kidding.  what's the point of having a gui version of vim anyway?  it's designed to be lightweight.  that gui adds tons of cruft
[22:39] <AgentHeX> ScottK: now once i actually have the source for the package, how do i go about compiling it?  will i need source for all the dependencies as well?
[22:39]  * ScottK has no idea, but it's FOSS, so all it takes is one coder who feels liek it.
[22:42] <AgentHeX> i'm pretty sure apt-get source will drop the source in my /usr/src path.  can you confirm?
[22:43] <ScottK> No, it'll drop it into the current working directory.
[22:43] <AgentHeX> ah...  do not want in home
[22:43] <ScottK> https://wiki.ubuntu.com/PackagingGuide/Howtos/BuildingTheSourcePackage?highlight=%28build%29 is a start on how to compile it.  It'll lead you to other quesitons, but I have to run.
[22:44] <Kopfgeldjaeger> n8
[22:48] <tophat> has anyone used git instead of svn?
[22:51] <tkamppeter> doko, did you upload hplip and hal-cups-utils for me?
[22:53] <geser> tkamppeter: is the new dpkg already built?
[22:53] <geser> tkamppeter: the current version of hplip needs the newer dpkg for building
[22:53] <AgentHeX> ScottK: how might i go about running a modified gpm?  do i need to replace the original and hope i don't bork my system?  how might i debug something like gpm?
[22:55] <slangasek> AgentHeX: anyway, "vim-gnome" :)
[22:56] <doko_> tkamppeter: yes
[22:58] <AgentHeX> slangasek: hah.  nice
[23:00] <tkamppeter> doko_: Thank you very much
[23:06] <AgentHeX> oh snap.  i can't see my appearances window to turn off compiz.
[23:06] <AgentHeX> HAH!  i did it blind!
[23:07] <tkamppeter_> geser, I have taken HPLIP from the Debian RPM as I am working together with Mark Purcell from Debian on the maintenance and so our packages and Debian's are the same.
[23:07] <tkamppeter_> On this build I had a problem and I had to remove "--dpkg-shlibdeps-params=--ignore-missing-info" from dh_shlibdeps in debian/rules.
[23:07] <tkamppeter_> My system is a Hardy which I have updated today.
[23:07] <tkamppeter_> geser, would this mean that I can reintroduce this "--dpkg-shlibdeps-params=--ignore-missing-info" on dh_shlibdeps as soon as the newest dpkg hits Hardy?
[23:07] <tkamppeter_> dpkg --version
[23:07] <tkamppeter_> Debian `dpkg' package management program version 1.14.12ubuntu1 (i386)
[23:07] <tkamppeter_> s/Debian RPM/Debian SVN/
[23:12] <geser> tkamppeter_: if I understand it all correctly, yes
[23:12] <tkamppeter_> geser, so which version dpkg must be so that I can re-introduce  "--dpkg-shlibdeps-params=--ignore-missing-info" on dh_shlibdeps?
[23:12] <geser> --ignore-missing-info was introduced around .8 or .9 and .12 is getting build now
[23:13] <slangasek> tkamppeter_: if you're working with hplip, how about fixing it so that it has a proper shlibs file and doesn't *need* the --ignore-missing-info?
[23:13] <geser> according to the changelog --ignore-missing-info works since dpkg 1.14.8
[23:14] <tkamppeter_> So strange that it did not work with 1.14.12ubuntu1
[23:14] <slangasek> I don't know what possessed the maintainer to do that instead of looking at the reason why dpkg-dev thought the package was wrong :P
[23:15] <tkamppeter_> Mark Purcell has introduced --ignore-missing-info. I do not even know for what that is good for.
[23:15] <slangasek> it's to stop dpkg-shlibdeps erroring out with a message about missing shlibs for a library dependency
[23:16] <slangasek> and the reason dpkg-shlibdeps was erroring out was because he has a library that's missing a shlibs file (required by policy), which means the package interdependencies are wrong
[23:16] <tkamppeter_> HPLIP seems to build and install fine without --ignore-missing-info.
[23:17] <slangasek> not with the new dpkg
[23:17] <geser> should build-dependencies on gs-common be replaced with ghostscript or is build-depending on gs-common still ok (especially for a package in main)?
[23:18] <tkamppeter_> geser, I think this can be moved to ghostscript. ghostscript has a transitional package gs-common, but things should depend on the main package.
[23:20] <slangasek> note that the "ghostscript" package doesn't exist in dapper, so this will affect ease of backporting
[23:22] <geser> slangasek: it's a change for graphviz, see bug #174749
[23:22] <ubotu> Launchpad bug 174749 in graphviz "[hardy] Drop libttf-dev from Build-Depends" [Undecided,New] https://launchpad.net/bugs/174749
[23:22] <geser> gs-common is in universe but ghostscript provides gs-common so build-depending on it should work, but to be on the safe side I changed it
[23:24] <slangasek> there's no need here to be "on the safe side".  It's perfectly valid to build-depend on virtual packages
[23:24] <slangasek> and as I said, build-depending on "ghostscript" is an additional change that has to be made for backports (as well as increasing the size of the Ubuntu delta here, of course)
[23:25] <ScottK> slangasek: If it doesn't exist in Dapper, then I'd just backport ghostscript first (no regression risk).
[23:25] <geser> so I should revert it back to gs-common?
[23:26] <slangasek> ScottK: uh?  in what sense is there no risk of regression?  it's a complete reorganization of the source packages
[23:26] <geser> ScottK: I guess ghostscript was called gs-somehting in dapper
[23:26] <ScottK> slangasek: I haven't actually looked at it, but generally if a package doesn't exist, it's good for backporting (I do check before I actually approve these things).  Nevermind then.
[23:28] <slangasek> ScottK: right; this isn't a "ghostscript doesn't exist in dapper", it's a "someone thought it would be clever to rename all the ghostscript-related packages in Debian because renaming is FUN"
[23:28] <ScottK> slangasek: Ah.  Yes.  That'd be totally different.
[23:29] <ScottK> slangasek: I'd say you got the first two letters right.
[23:30] <slangasek> sorry for my hash collision
[23:30] <slangasek> :)
[23:32] <tkamppeter_> geser, gs-common is in Universe? I thought we have taken it from the distro? It does not make sense any more with the new ghostscript. ghostscript contains everything now. So please remove gs-common from the Universe.
[23:33] <tkamppeter_> geser, in dapper the default ghostscript was gs-esp, as alternative there were also gs-gpl and gs-afpl.
[23:34] <ScottK> tkamppeter_: Does it have any rdepends left?
[23:35] <tkamppeter_> slangasek, we decided on renaming it /the Debian maintainer and me) to make it searchable more easily. Searching for ghostscript gives better results than for gs.
[23:36] <tkamppeter_> and with the merger of ESP and GPL Ghostscript (http://www.cups.org/espgs/) which I have done this year all gs-... got obsolete.
[23:37] <tkamppeter> ScottK, what are rdepends?
[23:37] <slangasek> tkamppeter_: a) gs-common is being built from the ghostscript source as a dummy package, to facilitate smooth upgrades; I'm not sure why it needs to be a transitional package instead of just the gs-gpl and gs-esp packages, but that's the rationale given. b) "apt-cache search ghostscript" already worked fine?
[23:40] <tkamppeter> slangasek, is it not the case that for every package which my new package replaces I have to provide a transitional package? And ghostscript replaces gs-common.
[23:40] <slangasek> tkamppeter: you just said "please remove gs-common from the Universe", how exactly do you expect it to be removed and still be a transitional package?
[23:41] <slangasek> the gs-common package in universe /is/ the transitional package
[23:41] <slangasek> as for whether every package needs a transitional package, no; you generally only want transitional packages for things that an end-user is likely to install directly
[23:52] <tkamppeter_> slangasek, so "apt-get dist-upgrade" would work also without transitional packages? Only "apt-get install gs-common" needs them?
[23:53] <tkamppeter_> slangasek, then with the gs-common in Universe being the transitional package everything is OK. Nothing needs to be removed.
[23:54] <slangasek> tkamppeter_: "apt-get dist-upgrade" would not do what you want without /some/ transitional packages.  But I think users are unlikely to have gs-common alone installed, right?  They're likely to have gs-esp or gs-gpl installed?
[23:54] <slangasek> tkamppeter_: in which case, you only need to provide transitional packages for gs-esp and gs-gpl, since gs-common would be sorted out according to dependencies
[23:57] <tkamppeter_> slangasek, I understand, gs-common is like a lib... package which does not make sense alone. So can I take it out on the next ghostscript packaging then?
[23:58] <slangasek> tkamppeter_: since ghostscript also has a Provides: gs-common that will meet the needs of reverse-deps, that's what I would suggest, yes
[23:58] <tkamppeter_> slangasek, OK and thanks for the help.
[23:59] <slangasek> sure