[00:00] I think the reason we keep the snapshots is primarily to ensure we can satisfy the license requirements for the point release ISOs after the fact [00:00] fbond: that's not published either, except in the .manifest and .list files that accompany the ISOs (which are the only packages we care about for the snapshot, really) [00:00] slangasek: I see. [00:01] slangasek: What is the likelihood of at least making a list of package versions public? [00:01] (I'll even write the script if you want. ;) [00:03] fbond: you really care about the full list of packages, including those not included in the point release ISOs? I could publish the Packages files somewhere, I'm just confused why you would want that list [00:03] the manifests for the ISOs are already public [00:04] slangasek: My builds may pull any package from the archives, and they do not build ISOs. [00:04] fbond: but then, why do you want the lists for those particular snapshots? [00:04] slangasek: Mostly because it is a convenient way to declare release points. [00:04] hmm [00:05] well, let me grab those Packages files out for you, then and publish them somewhere [00:05] which archs do you care about? [00:05] slangasek: I only care about x86 right now. [00:06] slangasek: I'd rather not have to bug you again after every release. [00:06] "x86" as in "i386", or as in "i386 and amd64"? [00:06] i386, sorry. [00:06] well, you can always pull the Packages files yourself the day of the point release then? :) [00:06] I would only want to trouble you with this if you feel it is something that is appropriate to do both now and in the future. [00:06] slangasek: Ah, sure, I don't mind doing that. [00:06] How long is the window where I am guaranteed to have correct contents? [00:08] given that security updates can happen at any time and be published to -updates, not long [00:08] slangasek: Right, that is my concern (and maybe I'm being nitpicky). [00:08] is it really a bad thing if you end up with an extra security update in your snapshot compared to the Ubuntu point release? [00:09] slangasek: Um, no, I suppose not. Okay, you're right, I can live with that. [00:09] In that case, I only need the most recent release now. [00:09] (I'm not making retroactive releases.) [00:09] I can pull it myself for future releases. [00:10] slangasek: Err, not the most recent. [00:10] The most recent hardy point release. [00:11] 8.04.3, then. [00:19] fbond: http://people.canonical.com/~vorlon/8.04.3 === bdrung_ is now known as bdrung [00:26] slangasek: Thanks, that's perfect! [00:26] TheMuso: i've rolled a newer git snapshot of PA due to the last-minute fixes; it WFM in lp:~ubuntuaudiodev/pulseaudio/ppa [00:27] dtchen: Ok thanks. [00:28] dtchen: I'll fetch the orig from the ppa and use what you committed to bzr. [00:29] TheMuso: great, thanks [00:35] bryce: bah, xorg-server upload failed to build due to: libdrm-dev: Depends: libdrm-radeon1 (= 2.4.12+git20090801.45078630-0ubuntu1) but it is not installable [00:36] sbeattie: fixed archive-side; should succeed if retried in ~1.5 hours [01:29] cjwatson: could you do a promotion of libpolkit-gtk-1-dev to main? the source (https://edge.launchpad.net/ubuntu/+source/policykit-1-gnome) is already in it and it is needed for the gnome-system-tools build to start. [01:30] Ampelbein: I think he has gone to bed. [01:31] GOing by a comment he made in #ubuntu-installer. [01:31] TheMuso: oh, ok. i think it can wait till tomorrow. [01:31] thanks [01:33] how often does the NEW queue get reviewed by AA? [01:43] jtimberman: AA queue is processed daily, but source and binary NEW can take longer sometimes. [01:43] kees: I only ask because I'm eager for my packages to get into Universe before Karmic Feature Freeze. [01:45] jtimberman: I suspect if they're uploaded before FF, you'll be okay, but I'm not an archive admin, so I may be wrong. [01:47] kees: Here's hoping. They were advocated / uploaded to new by at least one AA each, so I'd think they're fine at this point :-) [01:53] * ccheney didn't realize until today that url icons could be animated [02:15] siretart: the new ffmpeg package build-depends on openjpeg, which is not in main. Are you preparing an MIR for that? [02:20] siretart: or should the build-dep be dropped? (I notice --enable-libopenjpeg is specifically not set in debian/confflags) [03:07] mathiaz, ping. are you planning on bringing 38_scripts__mysqld_safe.sh__signals.dpatch to mysql server 5.1? [03:07] superm1: hmmm - yes. [03:08] superm1: could you open a bug task for mysql-dfsg-5.1? [03:08] mathiaz, sure [03:09] bug 418396 [03:09] Launchpad bug 418396 in mysql-dfsg-5.1 "need to port 38_scripts__mysqld_safe.sh__signals.dpatch from mysql server 5.0" [Undecided,New] https://launchpad.net/bugs/418396 [04:18] slangasek: siretart is just about to leave/just left for 3 weeks of vacation. I believe sistpoty volunteered to help out, but I'm pretty sure it didn't include that exact question. === jtimberm1n is now known as jtimberman === pace_t_zulu_ is now known as pace_t_zulu [04:58] doko: I just uploaded the python2.5 fix in 395321, but I don't have access to your bzr repo, so please don't forget to update it. [05:04] ebroder: python2.5 uploaded. Thanks for pointing it out. [05:08] as a heads-up, 2.6.31-7-generic breaks encrypted lvm really, really badly. [05:15] ScottK: ah. well, my best guess in his absence is that the openjpeg build-dep should be dropped [05:16] * StevenK grumbles at readline-common now wanting a version of dpkg that doesn't exist in Ubuntu [05:19] Oooh, it's better. A version of dpkg that doesn't even exist in Debian. [05:22] uh oh. I think i upgraded my karmic yesterday, with encrypted lvm [05:23] Hobbsee: You'd be fine, since 7-generic would have only been deployed a few hours ago. [05:23] oh, excellent [05:23] If that. [05:25] slangasek: Have you heard about the readline-common issue? [06:02] StevenK: only what you've said here; but looking at the dep, I see only that it wants dpkg (>= non-existent-version) | install-info [06:02] StevenK: so where is this failing? [06:46] good morning [06:48] good morning dholbach [06:48] hola highvoltage! [06:53] Good morning [07:00] slangasek: I've already dropped the build-dep on openjpeg in my packaging branch [07:01] doh, I've dropped yasm, not openjpeg. but yasm is in the same situation... [07:14] siretart: hmm, I didn't notice yasm in components-mismatches, but ok:) [07:14] slangasek: uploading new package with same version number now [07:15] what do you mean, same version number? [07:15] ffmpeg wasn't in new, reuploading with the same version number will be rejected [07:16] oh, doh [07:16] * siretart just wike up. sorry [07:18] uploading ffmpeg_0.5+svn20090706-1ubuntu2 now... === emonkey-t is now known as emonkey === tkamppeter_ is now known as tkamppeter [08:17] Any bluez expert around? [09:25] kees: Assigned you to LP #418223; good to go for me but related to web services security so I'd prefer if you'd have a look [09:25] Launchpad bug 418223 in rampart "MIR for rampart" [Undecided,New] https://launchpad.net/bugs/418223 [09:25] (C library) [09:32] doko, the deps in readline-common on dpkg 1.15.4 break image builds, are you updating dpkg too ? [09:32] doko, (we have 1.15.3.1ubuntu1 atm) [09:38] ogra: hope not, it's not released upstream yet [09:38] ouch [09:38] well, then the dep needs to be bumped down [09:39] (if that doesnt break readline indeed) [09:39] be careful of http://wiki.debian.org/Transitions/DpkgToGnuInstallInfo [09:40] hrm, all that extra fun ... [09:41] do we actually *need* the new readline ? [10:10] Could someone please moderate my mail sent to ubuntu-desktop? === mdz_ is now known as mdz === dholbach_ is now known as dholbach [10:19] cjwatson, ogra: this is lintian's suggestion. should we just turn around the dependency for now? [10:20] i'd be fine with that but dont know how the install-info changes cjwatson referred to might break then [10:22] lintian may be running a little ahead of implementation [10:23] ah, well, then lets just give it a try [10:23] * ogra prepares a package with flipped dep [10:49] ogra,doko: see also http://bugs.debian.org/538665 which was the policy bug [11:16] james_w: hi! are you around here? [11:16] yeah [11:19] james_w: regarding bug #417631, I received a mail from Harry Rickards right now, he updated the debian/control again and I need to re-upload the package, so please drop lives from the queue [11:19] Launchpad bug 417631 in ubuntu "Sync lives 1.0.0-4 from debian sid (main)" [Wishlist,Fix committed] https://launchpad.net/bugs/417631 [11:19] cjwatson, hmm, d-i seems not happy with the new naming scheme of imx51 [11:19] quadrispro: what queue? [11:19] karmic NEW, I think [11:20] i wonder why it picks up dove just fine with the high abi number [11:21] ogra: dunno, can one of you guys figure it out? [11:21] just looking [11:21] I just updated my desktop machine and now X won't start. Failed to load module "nvidia". === fddfoo is now known as fdd [11:22] cjwatson, looks like NCommander hardcoded all armel versioning to 2.6.31-200 ignoring subarches :/ [11:22] * ogra digs around [11:23] commenting out the nvidia line in xorg.conf gets me X [11:24] ah, no i'm wrong, phew [11:24] ogra: no, not as far as I can see - he put it in build/config/armel/dove.cfg [11:24] yep [11:25] james_w: the package is lives_1.0.0-4ubuntu1 [11:25] rejected [11:25] thanks! [11:25] SteveA: What happens when you 'sudo modprobe nvidia' ? [11:26] StevenK: sorry -- too late. I got X working by commenting out the line mentioning nvidia in xorg.conf, then started x with startx. Then I tried turning on Visual Effects in the Appearance Preferences [11:27] it asked me if it's okay to download and install a driver, so I clicked okay, entered my sudo password [11:27] and it's downloading and installing a driver [11:28] it's now asking me to restart the computer in a very confusing an round-about way [11:29] StevenK: I just stopped x. If I do "sudo modprobe nvidia" I get the response FATAL: Module nvidia not found. [11:30] SteveA: This is on Karmic? [11:30] yes, latest packages from the archive [11:30] 64 bit [11:39] StevenK: after rebooting, I still don't get X. X tries to load the nvidia module, but cannot, because it is not found. [11:40] SteveA: Is the 'nvidia-common' package installed? [11:40] sigh, why doesnt bzr tags spit out its list ordered by commit ? [11:40] yes, apt-cache policy reports 0.2.15 [11:40] ogra: | sort -k 2 ? [11:41] pfft, it should do that iself [11:41] instead of ordering by tag [11:43] SteveA: That's odd. File a bug using 'ubuntu-bug nvidia-common' [11:44] tkamppeter: I removed hal-cups-utils from karmic FYI, no reverse dependencies any more, and it's obsolete [11:44] pitti, OK, thanks. [11:45] pitti, others to remove are foomatic-db-hpijs and cupsddk [11:45] Keybuk: FYI I'm just uploading a debhelper 7.3.15 merge now, mostly because it has a bunch of other stuff I want, but it also includes some changes to dh_installudev. I've merged it very carefully and test-built it with two packages one of which uses --priority and one of which doesn't; some autoscript code changes but I think the changes are correct. If you notice any weirdness, though, please let me know ... [11:45] ok will do [11:45] tkamppeter: cupsddk not before the new cups is uploaded, no? [11:46] pitti, yes [11:46] tkamppeter: the printconf and ebox-printers packages still depend on foomatic-db-hpijs (plus some *-desktop packages which are just seed fixes) [11:48] pitti, do printconf and ebox-printers depend on foomatic-db? The functionality of our current foomatic-db-hpijs package is completely replaced by foomatic-db. [11:49] tkamppeter: they do apparently [11:49] pitti, if so, it is enough to let printconf and ebox-printers depend only on foomatic-db. [11:49] tkamppeter: ok, so I'll remove the package; would you mind uploading these two with the dependencies dropped? [11:49] (both universe) [11:50] pitti, I can do so. [11:50] tkamppeter: thanks; removed [11:50] pitti, are the two maintained upstream? [11:50] tkamppeter: I don't know, but it's a packaging-only change anyway, I guess [11:51] I don't know whether that functionality merging was done in debian, though [11:51] printer setup tools directly depending on Foomatic smell like CUPS 1.1.x. [11:51] printconf sounds stale, ebox I'm not sure about [11:52] tkamppeter: I blacklisted it now, so that it won't come back through autosyncs [11:52] cjwatson: do you maintain p-a-s for ubuntu? If so, could you please restrict faumachine to amd64 i386 lpia? (needs to get ported to non-x86 arches, which is sadly non-trivial) [11:52] * ogra thought we dont have our own p-a-s [11:53] ogra: we certainly do, as faumachine is restricted to amd64 i386 in debian [11:53] (and I still get failed build logs from ubuntu from time to time) [11:53] pitti, printconf (source package name foomatic-gui) is synced with Debian and it seems that Debian is also upstream, as there is no .diff.gz. [11:54] cjwatson: heh, looks like automake1.11 clobbers the old automake1.10 package [11:55] Keybuk: I just sponsored a merge of the updated automake1.10 from Debian that creates an automake1.10 binary [11:55] ahh [11:55] I was about to do one [11:55] heh [11:55] sistpoty|work: 'bzr checkout lp:~ubuntu-core-dev/packages-arch-specific/ubuntu' [11:56] and suddenly your 11:16 mail turns up [11:56] sistpoty|work: please forward any changes made there to Debian [11:56] cjwatson: oh, cool, thanks! will do [11:56] StevenK: thanks. bug 418521 [11:56] Launchpad bug 418521 in nvidia-common "On upgrade, X did not start because nvidia module is not available" [Undecided,New] https://launchpad.net/bugs/418521 [12:03] pitti: grr, I'd like to but I can't provide the information you need (comment 42, external SATA USB thing) [12:04] sebner: oh, still broken even with the udev rules moved aside? [12:04] pitti: no, moving aside the rules worked *always* but this is still the "workaround" and I can't provide you information to debug it :\ [12:05] sebner: why? calling skdump doesn't work? [12:05] how odd... my machine isn't shutting down properly either [12:05] pitti: yep, I told you some weeks ago: Failed to open disk /dev/sdb: No such file or directory (sdb is sane, but safely tried sdb1 too) [12:06] sebner: if you still get USB timeouts even with the udev rules moved aside, this seems like a completely different problem then, and a real kernel bug [12:06] hmm [12:07] If I p-a-s ghc6 to non-ia64, will I also have to list all of the rdeps too? [12:07] Keybuk: (reviewing sreadahead) uh, you really don't like patch systems, do you? [12:08] pitti: no [12:08] I like revision control systems [12:08] pitti: It was working some time ago though [12:08] bzr diff lp:sreadahead lp:~ubuntu-core-dev/sreadahead/ubuntu [12:09] Keybuk: it's promoted now; should I demote or remove readahead? [12:09] you can remove if you like ;-) [12:09] it's just the metapackages sucking it in, no real rdepends [12:09] yeah [12:10] ok, then away with it :) [12:12] so i'll rebuild meta once the main promotion gets published [12:13] pitti: ok, strange thing. Pluggin in works now. pops up in /media etc. But if I run skdump etc it get's ejected etc. I can use it if I power off the the external harddrive and re-plug [12:13] sebner: right, that behaviour of skdump is what upstream is interested in (together with the output) [12:13] is jmicron:/dev/sdb any better? [12:14] pitti: both suck. Either Failed to open disk jmicron:/dev/sdb: No such device or Failed to open disk /dev/sdb: Invalid argument [12:14] ok; well, if /dev/sdb isn't even present it won't work at all, of course [12:16] Laney: yes, as ghc6 then won't be available on ia64... [12:16] pitti: As I said, I start the commands, disk gets ejected, fail messages appear [12:16] sebner: right, please copy the output and dmesg and describe the behaviour in the bug report, I'll forward it to upstream [12:17] pitti: dmesg before or after the eject? [12:17] after [12:17] pitti: aye aye Sir [12:18] Laney: however we still have 6.8.2 (binary) on ia64 available, so I don't think p-a-s for ghc6/ia64 is the right thing [12:25] pitti: grr LP is slow :P· done :) [12:28] HAHA! I get a Timeout Error whenever I visit bugs.lp/~scott [12:28] no more bug fixing for _me_ today :D [12:29] Keybuk: I can send you a screenshot :P [12:30] Keybuk: AFAIK .lp isn't a TLD.. so no wonder you are having issues. :) [12:31] Daviey: well, ICANN are saying they'll let anyone buy TLDs [12:31] then we *could* have .lp [12:31] and .egg [12:31] ! [12:31] * Daviey hides. [12:41] bdmurray: is Pedro away today? === The_Company is now known as Company [12:57] sistpoty|work: I thought a b-d on a p-a-sed package would have that effect [12:57] and I'm just a bit wary about having an outdated binary that we can't fix [12:58] Laney: a b-d is only a b-d. it will fail if the package is unavailable. Otherwise you'd need to have a b-d with an arch-restriction ala ghc6 [amd64 i386 ... ] [12:58] Laney: but there aren't any plans to drop support for ia64 entirely in ghc6, are there? [12:59] no [12:59] Laney: having the old version is imho still better than nothing, as otherwise we'd need to bootstrap ghc6 on ia64 again (or rather pester a buildd admin with that), once it's working ok [13:00] nah, ghc's buildsystem can handle that [13:00] oh, cool, so that changed nowadays :) [13:00] it builds itself in two stages [13:00] stage 1 can use an existing ghc, but I don't think we do that for our builds anyway [13:01] https://lists.ubuntu.com/archives/ubuntu-devel/2008-December/027076.html - see from "But please aware" [13:01] makes me think that it does cascade through build-deps [13:04] Laney: I don't think so, but that this rather refers to an arch restricted b-d line of mono [13:04] dunno === cjwatson_ is now known as cjwatson === freeflyi2g is now known as freeflying [13:31] pitti: the error with jmicron was done *after* unplugging/replugging the drive ;) [13:36] urgh [13:37] pitti: the majority of bugs filed against udev are now keyboard related [13:37] lol [13:40] pitti: btw, new bug filed #418571 [13:40] pitti: grr, bug 418571 [13:40] Launchpad bug 418571 in libatasmart "Can't use external Harddrive because lots of USB Resets" [Undecided,New] https://launchpad.net/bugs/418571 [13:45] sebner: hm, I thought you said that'd make /dev/sdb appear [13:45] sebner: thanks [13:46] pitti: nope, with both commands, the drive disappears/gets ejected [13:47] sebner: ah, so /dev/sdb existed before, and if you do the skdump jmicron:/dev/sdb you actually get that "doesn't exist" error message, even though it did exist before? [13:48] why .pc files are included in *-dev packages? [13:48] sea-gull: where else would they be? [13:48] pitti: right ^^, I move the rules thing away and the plug the harddrive in and it appears in /media which means that /dev/sdb is present. If I run these commands sdb is ejected which (I think?) leads to this error messages [13:49] sebner: ah, ok; thanks; that wasn't clear; can you please get an strace of the jmicron one as well? [13:49] pitti: sure [13:49] pitti: for example, why pango.pc is included in libpango-dev, no in libpango? [13:49] pitti: if we're installing lib then it should be possible to link them [13:50] pitti: why do I need *-dev package if I don't change the sources? === MacSlow is now known as MacSlow|lunch [13:51] sea-gull: the .pc file isn't necessary at runtime [13:51] just if you build apps against a library, in which case you'll need the other files in -dev as well (header files, and the .so at least, but also the pkgconfig file) [13:52] pitti: hm, right. I forgot about header files: it's logical that they're in -dev. [13:52] pitti: attached [13:53] sebner: danke [13:54] pitti: gerne :), Why do I have a different problem but the same error messages (-71), moving rules works around etc? [13:57] sebner: you said that after moving the udev rules away, pluggin in the device would still get timeouts and missing /dev/sdb for you [13:57] that isn't what this bug is about [14:02] pitti: nah, I said moving udev rules away and plugging in makes the drive to appear and make it usable so no timeouts. xD You should really read more carefully xD === epuzarne1 is now known as epuzarne [14:04] sebner: right, and the other issue is that other people didn't get their hd ejected with skdump; the command actually succeeded, but caused usb resets afterwards [14:04] pitti: right [14:05] well, this bug has become pretty confusing anyway, with different people having different results, so it's easier to track each problem separately [14:06] right [14:07] pitti: anyways, I'm off now. still thankful for all your work === rickspencer3-afk is now known as rickspencer3 [14:19] ubuntu-archive: I reviewed component-mismatches for any Eucalyptus-related MIR that I would have missed -- I don't get why the old "eucalyptus-javadeps" stills shows in the list, however. It generates a lot of bogus entries. [14:19] it says [Reverse-Depends: eucalyptus-cloud] but it's no longer true [14:20] since when? [14:20] since Monday. and eucalyptus was added to seed after that. [14:20] "Generated: Tue Aug 25 13:35:02 BST 2009" [14:20] ok === MacSlow|lunch is now known as MacSlow [14:21] /scary/ bogus entries, I might add. [14:24] because it's out of date on ia64. component-mismatches checks all architectures. [14:25] Oh? I didn't think it ever built on ia64. [14:26] I only checked i386, amd64, lpia. [14:26] cjwatson: How do you check that easily? rmadison only shows amd64 and i386. [14:26] lp_archive@cocoplum:/srv/launchpad.net/ubuntu-archive/ubuntu-germinate$ grep ^eucalyptus-javadeps all_* [14:27] :-) [14:28] cjwatson: Ah :) [14:28] (only ask questions whose answers you believe you will like) [14:29] * soren needs to adjust his expections [14:39] I hate looking at e2fsprogs git [14:40] it's so utterly confusing [14:40] I think Ted does it deliberately [14:40] he has three branches "master", "next" and "maint" [14:40] and ALL THREE are tagged with the release number [14:40] but the release may be off any one of them [14:44] you'd prefer a naming scheme like "donut" "eclair" and "flan"? [14:45] he would [14:45] yummy [14:46] Any AA able to accept for upload new packages chef, merb, stompserver for Karmic? [14:46] jtimberman: They just need to be uploaded by feature freeze, they can go through New after. [14:47] directhex: I'd prefer names like "stable" or "v1.14" ;) [14:47] and I'd prefer "patches that are headed for 1.14.x go into one branch, and ALL 1.14.x releases are made off that branch" [14:48] ScottK: If there's any last minute / final changes required, that's okay? [14:48] jtimberman: Bug fixes can come after. [14:48] That includes getting rejected and having to upload again. [14:48] ScottK: Cool. It wasn't clear to me. [14:49] ah, feature freeze [14:49] aka "upload new broken stuff and claim everything afterward is just a bug fix" :) [14:50] Let's see, compiz hacker, right? [14:50] * Amaranth hides [14:50] ScottK: We've been stuck on that second step for a couple years ;) [14:52] which reminds me, better get my arse in gear with man-db 2.5.6 [14:53] Amaranth: Hopefully not for Chef! I work for the company that wrote it, and I've tested it w/ the packages *quite* extensively. [14:53] jtimberman: oh, not talking about your stuff specifically [14:53] but there are two times my karmic system is most likely to stop working: initial debian import and feature freeze :P [14:53] Amaranth: I'm sure, I was interjecting anyway ;) [14:54] Hopefully not due to optional packages in universe :D === bdrung_ is now known as bdrung === ivoks_ is now known as ivoks [15:07] dholbach: hi! so, I've got ufw being translated in LP (https://translations.launchpad.net/ufw/trunk) and want some advice. As an upstream, I'd like to include these translations in my upstream tarball. However, some are far from complete. In your opinion, is it better to include only the mostly translated ones or to include all (to possibly encourage others to participate)? [15:08] jdstrand: you could ask pitti, afaik there's some sniplet of code that takes care of that [15:08] hey mako [15:08] pitti: where was that code again - was it in ubuntu-docs? [15:10] dholbach: hey there [15:16] dholbach: thanks, I'll wait for pitti :) [15:24] siretart: ping ? [15:25] Tonio_: pong [15:25] siretart: don't know if you saw my messages yesterday, but there is a pretty hdge problem with ffmpeg... [15:26] siretart: seen them ? [15:27] siretart: the unstripped packages have been removed, but there are still internal deps on it [15:27] Tonio_: note sure, but did you recheck after my latest uploads have been accepted? and did you read my recent mail to ubuntu-devel? [15:27] siretart: see for example : sudo apt-get install libavformat-dev libavformat-unstripped-52 [15:28] siretart: hum no I didn't check out today, let me have a look :) [15:28] Tonio_: if you have some time, please change ubuntu-restricted-extras to depend on 'libavcodec-extra-52'. The other packages (avutil, avformat) are pretty identical to their counterparts in main. no need to depend on them AFAIUI [15:29] it might still make sense to help apt's dependency solver, though [15:29] siretart: yes that was my plan (also with kubuntu) [15:29] thanks [15:29] but probably the conditional deps on the unstripped packages hould be dropped from the control file in ffmpeg package right ? [15:30] they are auto generated by dpkg-shlibdeps [15:30] siretart: nope :) [15:30] they are :-) [15:30] ah, not in the metapackage, right [15:31] siretart: Depends: libavcodec52 (>= 4:0.5+svn20090706-1ubuntu2) | libavcodec-unstripped-52 [15:31] this comes from the .shlibs file [15:32] siretart: hum you don't get my point I think :) afaics, this is simply manually added to the control file [15:33] tell me the line, then [15:33] siretart: 161 for example [15:34] hey can someone help me write a driver for the xbox 360 hori ex2 fighting stick. [15:34] oh, for the -dev packages only. right [15:34] doh, you're right. after the rename these deps need to be updated as well. my bad [15:34] siretart: yep [15:35] siretart: will you do that or should I ? [15:35] I'll take care of the ubuntu restricted packages [15:35] I'm on it [15:35] great [15:36] OTOH, the provided transitional packages should prevent further damage... [15:39] siretart: Did you see slangasek's question last night about ffmpeg depends? [15:40] ScottK: I've seen his mail on the mailing list... [15:40] OK. [15:40] He also had another on last nigh. [15:40] t [15:40] Let me see if I can find it. [15:40] ScottK: ah, that was about libopenjpeg. already fixed this morning [15:41] OK. Good. [15:41] That's the one. [15:49] jdstrand: for my projects I usually just download the entire translation tarball for my project and add them [15:49] jdstrand: but if you want to go ahead and only select well-translated ones, that's possible of course [15:49] ScottK or siretart, any idea where the sources for the restricted-extra packages are stored ? [15:50] jdstrand: it won't affect the langpacks, though, they just take everything [15:50] pitti: re langpacks> ack [15:50] it is structure like a seed package, so I suspect there's a bzr branch somewhere, but I can't find it, therefore not fix it :) [15:50] jdstrand, dholbach: I'm not aware of a script; however, nowadays LP can create a "translation branch" for you which you can just merge from [15:50] pitti: what is your reasoning to import all of them? [15:50] jdstrand: partly "common practice", partly "I don't want to check and judge" [15:51] pitti: heh, fair enough. I'll do the same. thanks! :) [15:51] Tonio_: apt-get source kubuntu-restricted-extras works just fine for me [15:52] siretart: yep, sure, I was just wondering if there's a place to commit to :) [15:53] no VCS field, no commit [15:53] jdstrand, pitti: http://bazaar.launchpad.net/%7Eubuntu-core-doc/ubuntu-docs/ubuntu-karmic/annotate/head%3A/debian/rules [15:54] Tonio_: I'm pretty sure there sin't [15:54] isn't [15:54] dholbach: cool, thanks :) [15:55] Riddell: oki :) [15:55] dholbach: how does that fetch translations from LP? [15:55] pitti: I have uploaded foomatic-gui and ebox-printer without foomatic-db-hpijs dependency now. foomatic-gui is not completely obsolete. It is not recommended for CUPS 1.2 and newer, nowadays it servs for users of non-CUPS spoolers, like the LPRng in Debian and in Ubuntu Universe. [15:55] tkamppeter: I saw, thank you [15:56] pitti: I dunno [15:57] superm1: hi [15:59] tkamppeter: oh, can you please put your cups 1.4 orig.tar.gz somewhere? (I guess it's an svn snapshot with autoconf etc. run, but I'd rather use your tested one) [16:01] pitti, should be on http://www.linuxfoundation.org/~till/tmp/cups_1.4.0~svn8773.orig.tar.gz now. Please wait for my upload to complete. [16:07] tkamppeter: I'll use "pkg-config --atleast-version=0.11 poppler", that should suffice as test whether to apply the patch, right:? [16:15] pitti, yes. Only Ubuntu-only dependency of pdftoopvp is Poppler 0.11.x. [16:21] pitti, the tarball is completely uploaded. Did you already download it? [16:21] Tonio_: Just in the archive, AFAIK [16:21] ScottK: yup seems like :) [16:22] tkamppeter: got it [16:23] tkamppeter: I re-added the ubuntu check to ubuntu-disable-browsing.dpatch, too; should be okay now [16:28] pitti, sorry, I have overlooked that there was a check in the patch when I have regenerated all the patches. [16:31] pitti, please remove the entry "Everything except the handling of the now integrated CUPS DDK is done." from the beginning of the debian/changelog, I have forgotten to remove it. [16:33] tkamppeter: done [16:34] tkamppeter: hm, package FTBFSes for me [16:35] pitti, what did you change in debian/control? [16:35] tkamppeter: I added the pkg-config b-dep [16:35] tkamppeter: http://people.canonical.com/~pitti/tmp/cups_1.4.0~svn8773-1_i386.build -> do you get the same? [16:36] pitti, I have built it without your changes (my commit of yesterday evening) on my current Karmic and there it works. [16:38] tkamppeter: hm, i just reenabled pdftoopvp === nxvl_ is now known as nxvl [16:38] something seems to be utterly wrong with the test sutie [16:38] E [25/Aug/2009:17:38:06.297790 +0200] [cups-driverd] Bad driver information file "/usr/share/ppd/openprinting/Kyocera/ReadMe.htm"! [16:38] E [25/Aug/2009:17:38:06.587960 +0200] [cups-driverd] Skipping "/usr/share/ppd/1-local-admin": loop detected! [16:39] pitti: I'm wondering if both traces are useful for you. jmicron one is a funny one with: write(2, "Failed to open disk jmicron:/dev/sdb: Success\n", 46) = 46 [16:39] This has nothing to do with the presence of pdftoopvp. Problem is the following: [16:40] lrwxrwxrwx 1 root root 20 2009-07-31 20:59 /usr/share/ppd/1-local-admin -> /usr/local/share/ppd [16:40] eww, that looks wrong [16:41] ah, you removed them from postinst already [16:41] The links /usr/share/ppd/1-local-admin and /usr/share/ppd/2-third-party make parts of the PPD repo read twice by CUPS. CUPS finds inodes which it has already read and thinks there is a link loop. For this it logs an error message. [16:42]