[00:26] how do I sign something with my gpg key if the changelog has somebody else? [00:27] debsign -k0xyourkeyid the_package_source.changes [00:28] thanks === traveller__ is now known as traveller [01:30] I installed a newer package from a ppa; but I don't want that anymore so I tried to remove the package, remove the ppa, update apt, install that package again [01:30] it still wants to install that newer version [01:31] You guys know how I can make it stop trying to install that version? === asac_ is now known as asac [01:54] MTecknology: For that sort of thing, #ubuntu is probably better. I think there's a way to reinstall from the archive, but I don't remember the commands. [01:54] persia: alrighty thanks [01:55] hmmmm, I did a dput to revu yesterday and it never showed up on the web site [01:55] no email or nothing, and now when I try to dput again it says its already up ther [01:56] What package? [01:56] persia: hdhomerun-config-gui [02:00] rhpot1991: Well, it's not most of the common mistakes. I'm looking a bit more. [02:03] rhpot1991: I can't find your key on the Ubuntu keyserver (http://keyserver.ubuntu.com:11371/pks/lookup?search=B1C7AfA8&op=vindex) [02:03] Have you pushed your key to the keyservers? Does LP know about it? [02:04] persia: yes, I did change the primary email address though, not sure if that should matter [02:05] I can still push to my bzr and ppas all the same [02:05] bzr is the ssh key, rather than the gpg key. I don't know how ppas work. [02:05] ppas are gpg I think, I could be wrong [02:05] But the package was clearly signed with B1C7AFA8, and I don't see that (see URL above), so I'm guessing REVU didn't see it, which would explain why it's in rejected/ [02:06] http://keyserver.ubuntu.com:11371/pks/lookup?search=0x64218F18CFA01CA04B85257C2B496BF2B1C7AFA8&op=index [02:06] thats the key in mention right there [02:07] LP knows that key too: https://launchpad.net/~rhpot1991 [02:07] Grumble. The search should really show that. [02:10] persia: want me to force a dput and you can see what happens? [02:10] rhpot1991: Won't make any difference. [02:10] I have the package, [02:11] I7m just not sure why it fails. The checksums in the ,.changes file match, and you havce a valid signture. [02:12] I'll toss it back in the queue, and see if it gets rejected again. If it does, someone else will have to fix it. [02:12] (because none of the things I usually see wrong are wrong) [02:12] persia: you push the .changes file with revu right? [02:12] want to double check I didn't do something wrong [02:12] with dput that is [02:13] hmmm I have a hdhomerun-config-gui_20100121-0ubuntu1_source.revu.upload hanging around [02:13] It's not an issue with dput. You successfully uploaded. [02:14] Yes, that is the record dput created after successfully uploading. [02:14] ya, and the timestamp matches [02:14] toss it back in the queue, I'll check on it later [02:14] thanks for the help again :) [02:16] * persia finds another rejected package, and preemtively investigates [02:22] rhpot1991: http://revu.ubuntuwire.com/p/hdhomerun-config-gui [02:23] what's a good way to debug c/c++ in linux? [02:24] jsplice: All sorts of options, depending on is actually wrong. gdb is generally a good start, though. [02:25] gdb...cool, I'll check it out..thanks [02:59] thanks persia [03:47] if I want one target to go to another in a rules file, how do I do that? [03:47] You make the second target depend on the first. [03:47] MyDependantTarget: ThisTargetWillGetRunFirst [03:49] there's no way to do it the other way around? [03:50] * micahg thinks he'll make a new target that just runs both... [03:51] You want one target to run after the other, right? [03:51] yep [03:51] Making A run before B is exactly equivalent to making B run after A. [03:51] but it's weird to run the second one on the command line [03:51] Ah. [03:51] * micahg just added a target to run both :) [03:51] thanks RAOF [03:54] micahg: You've got the right idea with the target to run both -- If what you want is to "replace" the old "A" rule with "A then B" while retaining the name "A", then you should rename the original "A" to "originalA" and then add a new rule "A: originalA B". [03:54] kamalmostafa: yeah, that didn't quite work either, the name for the first is good :) [03:55] what's the equiv of sed -p -n on ubuntu? [03:56] micahg: versus on what other platform? What's "-p" supposed to do? [03:56] print matches [03:56] is that by default? [03:57] * micahg read an old shell scripting book :) [03:57] micahg: sed -n : suppress automatic printing of pattern space Default is that pattern space would be printed. [03:58] kamalmostafa: right, but it still prints matches, right? [03:58] * micahg guesses that's the whole point... [03:58] * micahg wonders why that option ever existed [03:58] micahg: Yes. Like this: [03:59] $ sed s/foo/bar/ [03:59] foozoofoo [03:59] barzoofoo [03:59] That wasn't clear. I typed "foozoofoo" -- sed *printed* "barzoofoo". [04:00] Had I done "sed s/foo/bar/g" (note the added "g" for global" then both instances of foo would have been replaced. === nhandler_ is now known as nhandler [04:01] ok, so now I get warned that my %: target is being run after it [06:02] I was beginning to upload packages for the liblo transition, but the builds are still getting the old liblo0-dev package. AFAIK, the new liblo-dev provides the old liblo0-dev packages, so it should be used automatically, right? Or liblo0-dev should be deleted first from the archive? [09:12] Hello everyone! Anyone up to advocate/review qt-shutdown-p? (I've got one advocate XD ) http://revu.ubuntuwire.com/p/qt-shutdown-p [10:50] What does a dependency of "default-jdk" mean exactly? I'd expect that it would work with both openjdk and sun jdk, but that doesn't seem to be the case [10:51] I've got the sun jdk installed. When I try to debuild a package that depends on default-jdk, it complains. When I do apt-get install default-jdk, it wants to pull in openjdk [11:02] How can I make a package that doesn't care which jdk there is, and works with anything that is installed? [11:07] amarillion, piped build-depends tend to be a really bad idea [11:07] amarillion, so you need to distinguish between what you build against and run against [11:08] Right, I wasn't clear about that [11:08] amarillion, in the general case, you can have a binary depend on (for example) java6-runtime [11:08] Right now my control file has [11:08] Build-Depends: debhelper (>= 5), ant, default-jdk [11:08] Depends: Depends: default-jre | sun-java6-bin | sun-java5-bin [11:08] that's not a good depends line. [11:09] But that means if I want to test building the package on my own computer with debuild, I have to install openjdk, right? [11:09] for binary depends, think more along the lines of "preferred | general-alternative" - for example, openjdk-6-jre | java2-runtime [11:09] for building... i wouldn't ever use debuild personaly to compile binaries so no comment [11:09] What do you prefer to use then? [11:10] Is this a good depends line then: [11:10] pbuilder. since it ensures that the build-depends are sane, by reinstalling them for every package [11:10] Depends: default-jre | java2-runtime [11:10] Ok, I'll try it with pbuilder [11:18] directhex: There is no package named java6-runtime [11:18] nor java2-runtime [11:43] amarillion, i know. that's what Provides: is for [11:51] Hey all, [11:51] I want to look at dependancies for jaunty vs lucid, does anyone have a jaunty machine they could check for me? === lukjadOO7 is now known as lukjad007 [11:52] I need to know if they have a python-lazr-restfulclient or python-lazr.restfulclient package available. (note the dot insteadof hyphen) [11:53] <_ruben> you can check on http://packages.ubuntu.com [12:13] _ruben: Is there a way in the control file I can specify 'this-package or this-other-package' ? [12:13] <_ruben> this-package | this-other-package [12:13] thanks [12:41] directhex: thanks. So to recap, [12:41] I should do Depends preferred | general-alternative [12:41] So I'm going to do [12:41] Depends: sun-java6-bin | java6-runtime [12:41] And Build-Depends should remain [12:41] Build-Depends: debhelper (>= 5), ant, default-jdk [12:42] And I shouldn't use debuilder :) [12:43] I mean, I shouldn't use debuild for binary packages. [12:49] Woo-hoo, my first Ubuntu package is uploaded and ready for review! [12:49] https://bugs.launchpad.net/ubuntu/+bug/514936 and http://revu.ubuntuwire.com/p/python-nltk [12:49] Ubuntu bug 514936 in ubuntu "[needs-packaging] nltk (Natural Language Toolkit)" [Wishlist,In progress] [12:50] It's my first time creating a "real" Debian or Ubuntu package (as opposed to training exercises), so please tell me if there's any important steps I missed... Thanks! [13:17] rmunn: does the b in 2.0b8 stand for beta ? [13:19] rmunn: If it does I would suggest to prefix the b with a ~ so that when 2.0 final gets released you won't have to use an epoch or other means to have increasing version numbers. :) [13:20] c_korn, Yes, it's "beta". [13:21] Rhonda, Thanks, I'll do that. I'm guessing I'll need to reupload after that, right? [13:23] Sure, before anyone uploads your package and you have to deal with the version woes. :) [13:35] Done, the source package at http://revu.ubuntuwire.com/p/python-nltk now has version number 2.0~b8-0ubuntu1. Thanks for the catch, Rhonda and c_korn. === nixternal is now known as Guest10887 === Guest10887 is now known as nixternal [13:49] rmunn: is the priority for the package really extra ? I would set it to optional: http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities [14:04] Huh. I meant to make it optional, don't know when it got changed to extra. Thanks. [14:10] OK, new upload at http://revu.ubuntuwire.com/p/python-nltk now has Priority: optional. [14:33] rmunn: good, you would have my vote if I was a motu :P [14:46] statik: thanks for the review of my cnetworkmanager package. [15:01] rmunn: it's not in the archive yet?! Then it should be -0ubuntu1 [15:04] are those motu videos still valid. I have been using them and never got succeeded [15:07] om26er: I haven't seen them, but I guess they should be. What problem do you have? [15:09] sebner, the version I have on http://revu.ubuntuwire.com/p/python-nltk is -0ubuntu1 -- which one are you looking at that isn't? [15:10] rmunn: That's true but it should be the _only_ changelog entry [15:11] Why so? [15:11] Why would one have to strip history? [15:11] sebner, I originally uploaded a 2.0~b7-0ubuntu1 package, then upstream released 2.0b8 before I had gotten 2.0b7 reviewed. Since 2.0~b7 was my original upload, I left it in the changelog. Should I go back and edit the changelog so *only* the 2.0~b8 entry remains? [15:11] Rhonda: because it has no history when it's not in the archive [15:11] rmunn: exactly [15:11] sebner, Will do... new REVU upload will be coming shortly [15:11] sebner: Isn't it allowed to have a history outside the archive? I consider that a pretty narrow point of view. [15:12] Or are debian changelogs stripped off from before the first sync into ubuntu? :) [15:12] Rhonda: The one and only changelog entry before entering the archive is always "Initial Release" as it's the initial archive release [15:12] Rhonda: It's got plenty of history outside the archive, but the changelog in debian/ only refers to the history of the package -- so the first entry should be the first version of the package, I guess. [15:12] Rhonda: that's something different [15:12] It hight have been hosted someplace else before. [15:13] Rhonda: sure but a new package that enters the archive doesn't have a archiv history and is not necessary therefore [15:13] rmunn: I still consider that a pretty narrow stand and would challenge it. There is valid reasons to have previous history documented. [15:13] Rhonda: that's against packaging policy though ;) [15:13] sebner: Not an archive history within ubuntu. But it might have an archive history someplace else. [15:14] I would highly disagree with that impression, please show me that piece. [15:14] Rhonda: that doesn't matter for the package entering Ubuntu for the first time [15:14] sebner: That's no always true [15:14] ScottK: so? [15:14] Rhonda: I think what sebner is saying is a good general rule, but I also think there are exceptions. [15:15] ScottK: I've never seen of any "exception" like that before, mind providing an example? [15:15] sebner: To take it on from a slightly different POV, I took on the klamav package in Debian. It was unmaintained and broken. [15:15] Look at debian/changelog. [15:15] sebner: When one works with a sponsor it is valid to "request" from the sponsoree to bump the versions so that it's easier to check just the differences and not check the whole thing again. [15:15] ScottK: well, that's more like a special special case [15:15] Even though it's uploaded in Debian, it's got the Ubuntu history in it. [15:16] Rhonda: On our tool for this (REVU) it will give you diffs of successive uploads with the same version. [15:16] Ah, sounds convenient. :) [15:16] Rhonda: as I said, in 95% of the cases it has to be the one and only entry [15:17] s/has to be/should be/ [15:17] Rhonda: must be :P [15:17] If it's 95% there isn't any "has to be … but". Either it has to, or it doesn't have to. [15:18] has to equals must be [15:18] A guideline and suggestion must not be written explicit. ;) [15:19] Rhonda: It's not a suggestion imho, except this special case ScottK mentioned it always has to be the only entry. Also with rmunns package. [15:19] hmmmmm [15:20] rmunn: Who is Robin Munn? I thought this is the initial version of the package? [15:20] I suppose it's him ^^ [15:20] I'm Robin Munn. [15:20] Oh, right. [15:21] Why aren't you in Maintainer but XSBC-Original-Maintainer? Is that the way it should be? . o O ( and that might very well be my naive approach to not knowing it :) ) [15:21] Packages in universe should have "ubuntu-motu" as maintainer, I believe. [15:22] So I put myself as original-maintainer so that any MOTU with questions about the package would know who to contact. [15:22] rmunn: it's Ubuntu Developers [15:23] Hm? https://wiki.ubuntu.com/DebianMaintainerField says (at the end) that it should be ubuntu-motu... has this changed? [15:24] Oh wait, that's the previous rules. [15:25] Yet another re-upload coming to fix the Maintainer field... I guess this is why we have a review process. :-) [15:25] That particular one isn't critical, but may as well get it as fixed as you can right now. [15:26] ScottK: I'm wondering about this wiki site though. Also the "updated" version says Ubuntu MOTU Developers . I'll change that?! [15:26] Please [15:26] aye [15:27] # [15:27] Otherwise, the Maintainer field will be set to Ubuntu Developers [15:27] sebner: Where do you see ubuntu-motu? [15:27] Or did you already change? [15:28] Hmmm, any way to tell dput "Yes, I'm forcing an upload with -f, but you don't need to re-upload the .orig.tar.gz since it hasn't changed"? This .orig.tar.gz is only about 830k so it's not a big deal, but if I was maintaining OpenOffice or something that might get rather tedious... [15:28] Hmm, no, it's still the same old version from colin. [15:28] Rhonda: ScottK updated [15:29] Okay, newest version at http://revu.ubuntuwire.com/p/python-nltk now has ubuntu-devel-discuss in maintainer field. [15:29] rmunn: I don't think REVU likes uploads without .orig.tar.gz === RainCT_ is now known as RainCT [15:29] https://wiki.ubuntu.com/DebianMaintainerField?action=diff&rev2=20&rev1=19 [15:29] eeeks [15:29] sebner: Your change doesn't make any sense at all :) [15:30] Rhonda: thanks :P [15:30] Rhonda: why? ;) [15:30] Now the "Previous rules" section doesn't make any sense to me. [15:30] It says the exactly same for main and universe, at least mail address wise? [15:30] ah [15:30] * sebner brokes something [15:30] RainCT, In this case there's an .orig.tar.gz with the same md5sum already in the REVU queue, a more "clever" dput could potentially check the MD5sum and/or use rsync. Not a big deal, probably. [15:30] You changed the _previous_ rules? [15:31] sebner: Don't change the previous rules. [15:31] ScottK: sorry, mistake -.- [15:31] ScottK: We are there already. ;) [15:31] rmunn: REVU is Free software. Patches welcome (it's written in Python). [15:32] rmunn: If you upload without the .orig.tar.gz (which you can do using debuild with the -sd option, btw, iirc) it won't be listed in the .changes file, which REVU uses to know which files the package has [15:32] sebner: I think just reverting your change would be the sensible way to do? [15:32] (but as ScottK just said, if anyone wants to fix this so that REVU looks for previous .orig.tar.gz files when one is missing, I'd be happy to review the patch) [15:32] ScottK, Hey, my favorite language! Mental note made, and filed in the Copious Free Time category. (Which, sadly, means "probably not anytime soon...") [15:32] Undertsand [15:33] Although, the relevant code for this is a shell script, not Python [15:33] Rhonda: yeah done already. I'm a little bit confused today ^^ [15:33] No worries. :) [15:33] (or maybe it is Python.. meh, haven't touched REVU since too long :P) [15:33] sebner: Reviews everywhere. :P [15:35] ScottK: but the maintainer for universe *is* Ubuntu Developers nowadays?! update-maintainer proposes [15:35] sebner: That's correct. [15:35] ScottK: so my change was right?! [15:35] Not as part of the previous rules. [15:35] That's current rules [15:36] ahhh [15:36] I misread [15:36] I'm sorry :( [15:36] Now I'm confused to. If I submit a package to REVU for Universe, Maintainer: should be Ubuntu Developers, not Universe Maintainers? [15:37] it should be Ubuntu Developers (and REVU lies about it) [15:37] mr_steve: Yeah [15:38] Okay, thanks. [15:38] rmunn: it you want to exclude orig.tar.gz from upload, tell debuild about it (-sd) [15:51] randomaction: fixed (MOTU -> Ubuntu Developers) [15:51] RainCT: thank you :) [15:51] * Laney nibbles at RainCT [15:52] Laney: I'm not a cookie! [15:55] * iulian remembers RainCT's cookie game. [15:55] I was too stupid to play it. :( [15:55] packages.ubuntu.com also lies about maintainer, e.g. http://packages.ubuntu.com/lucid/claws-mail-extra-plugins says MOTU, apt-cache says ubuntu-devel-discuss [15:56] iulian: heheh That was great, wasn't it? :P I may still have it somewhere... [15:56] Not that I'm not anymore... [15:56] RainCT: Oh, really? [15:58] iulian: Actually no, (unless it's in some backup CD, but I haven't done backups for ages). "find | grep -i cookie" didn't find it :(. [15:58] randomaction: It was probably not updated somewhere yet. Not all packages have been changed. [15:59] ScottK: package was built 11 days ago [16:00] randomaction: Does p.u.c use the development release or the current release for that data? [16:01] ah, indeed, it may differ. I'll apt-cache it in karmic [16:02] u-d-d in karmic as well. Maybe it uses oldest release or something? [16:04] hi - I need some help with a developer level question: http://stackoverflow.com/questions/2208400/apt-get-environment-variables-when-spawning-make [16:14] ... or is there a more appropriate channel for my question? [16:28] jldupont, it tends to be quiet here [16:28] but I don't think you should do user-specific things like that in a deb package, they're for system-wide installation [16:29] aye. Why is apt-get spawning make anyway? [16:34] how is debian/rules spawned by apt-get during installation btw? [16:34] has anyone seen this build failure before: dpkg-genchanges: failure: cannot read files list file: No such file or directory [16:46] jldupont, I've answered on stackoverflow [17:08] So this is the place to be if you want to upload a package to archive.ubuntu.com/universe [17:09] yes [17:10] It gives me the impression I ought to keep tabs of other packages as well once I become part of the team. [17:40] persia: xorg-edgers xvfb now has RANDR [17:41] Hurrah! [17:42] Now just a couple more steps, and I can press the give-back button lots of times :) [17:45] Hi again. New liblo ships liblo-dev as dev lib, that 'provides' liblo0-dev (old dev package). Shouldn't be liblo0-dev deleted from Lucid to avoid using old version for packages using liblo0-dev? I rebuild one of the dependent packages, and it's still using old lib :-/ [17:46] !info liblo0-dev | lucid [17:46] lucid: liblo0-dev (source: liblo): Lightweight OSC library -- development files. In component universe, is optional. Version 0.23-2.2 (karmic), package size 71 kB, installed size 580 kB [17:46] !info liblo-dev | lucid [17:46] lucid: Package liblo-dev does not exist in karmic [17:46] fabrice_sp: liblo0-dev is in NBS. [17:47] But there's lots of source changes needed. [17:47] You might want to try to contact ScottL, who was also looking into this. [17:47] ok: I created a bug for the transition [17:47] I thought he did also, so there may be two. [17:48] But they're surely dupes, if so, and can be collapsed. [17:48] I checked the rdepends before [17:48] ok. I'll check with him [17:48] most packages should be buildable if liblo0-dev were deleted ,anyway [17:48] Well, he should see the highlight in backscroll :) [17:49] yes :-D [17:49] liblo0-dev won't be deleted until all the packages build-depending on it are gone. [17:49] wow, its soname jumped up by 7 [17:49] If you really want to push it, go hassle the archive-admin-of-the-day in #ubuntu-devel [17:49] even if the new liblo-dev provides it? [17:49] Yeah :) [17:49] yeah :-) [17:49] it's bug 517416 ;-) [17:49] Launchpad bug 517416 in xsynth-dssi "liblo0ldbl -> liblo7 transition" [Undecided,New] https://launchpad.net/bugs/517416 [17:50] Right, because it takes someone to investigate before it gets removed: the archive-admins typically wait until someone else investigates unless they have lots of extra time. [17:50] (and the newer liblo just entered NEW about 20 hours ago) [17:50] they sometimes have extra time? :-D [17:51] Rarely :) [17:51] :-D [17:52] * fabrice_sp will reboot so that Xorg frees the 1Gb memory hostage it has right now [17:54] ScottL, fabrice_sp: I'm happy to take a bunch of those rebuilds (like 10 or so) and just do them [17:58] ScottL, fabrice_sp: I'm happy to take a bunch of those rebuilds (like 10 or so) and just do them (reprise) [17:59] * persia thinks today is such a rare day [17:59] StevenK, cool: I think that before rebuilding them, we should delete the old dev lib (liblo0-dev), as it's providedby the new liblo-dev package [17:59] We can do that [18:00] some of them will FTBFS, as reported to Debian, but it's an easy patch :-) [18:00] Surely that's just ABI transitions [18:00] * persia puts 5 on StevenK vs. Soyuz [18:00] Done. I win. [18:01] * persia collects [18:01] great! :-) [18:01] fabrice_sp: So I'm happy to take a bunch and do rebuilds on them [18:03] StevenK, ok: so how will we proceed? You submit the rebuilds, and if it FTBFS, we reopen the task in the bug 517416 ? (and I'll invalid them now?) [18:03] Launchpad bug 517416 in xsynth-dssi "liblo0ldbl -> liblo7 transition" [Undecided,New] https://launchpad.net/bugs/517416 [18:05] fabrice_sp: So I can sort out rebuilds (as soon as the publisher runs) and see how many fail [18:06] StevenK, ok. The ones that have versioning dependency on liblo0-dev will fail. I saw at least 3 of them (don't remember which ones right now) === asac_ is now known as asac [18:08] fabrice_sp: Right. I'll get started in about an hour. [18:08] ok. Thanks :-) [18:11] StevenK: can you please remove the old texlive-base-bin debs (NBS)? the packages listed in http://people.canonical.com/~ubuntu-archive/NBS/texlive-base-bin have an unversioned dependency on texlive-base-bin (now provided by texlive-binaries). the only exception is jadetex and a fix waits already on sponsoring. That would unblock some TeXlive related FTBFS as the buildds tries the old (now [18:11] uninstallable) real package. [18:11] geser: Sure, I'll kill it now [18:12] thanks [18:16] Well. Now ish. Sigh. [18:20] geser: texlive-base-bin{,-doc} or just -base-bin? [18:33] I haven't checked -doc yet, I only checked -base-bin for now [18:36] fabrice_sp, ping [18:37] fabrice_sp, about liblo transition: I think that no-change rebuilds is not enough. We should replace build-dependencies on liblo0-dev with another on liblo-dev [18:39] fabrice_sp, otherwise the transition won't bring benefits :) [18:48] quadrispro, pong. That's because we needs to delete first the old liblo0-dev (done by StevenK :-) ), provided now by liblo-dev. I saw you uploadednekobee. By the way, some packages FTBFS in Debian too [18:49] StevenK will do rebuilds on some of them [18:49] Well, I'll see which just build and upload them [18:49] see 48 minutes ago ;-) [18:49] fabrice_sp, sure, they FTBFS because new liblo is in experimental and liblo-dev is not available in sid [18:50] Quadrispro, see Debian bug 530852 [18:50] Debian bug 530852 in rosegarden "rosegarden: build-depends on versioned liblo0-dev" [Minor,Open] http://bugs.debian.org/530852 [18:50] it seems it's because of versioned dependency [18:52] (also debian bug 530859 and some others in that list) [18:52] Debian bug 530859 in sineshaper "sineshaper: build-depends on versioned liblo0-dev" [Minor,Open] http://bugs.debian.org/530859 [18:52] ok, should we wait for new liblo entering in unstable? [18:54] don't know: some bugs has been opened a quite long time ago, and nothing happened (even if it was safe to update the package with non versioned dependency) [18:55] as most (if not all) packages are maintained by Debian Multimedia Team, we should perhaps update the packages first in Debian [18:55] and sync them after [18:56] My fear there is Alpha3, because a number of these packages ship on the Studio DVD. [18:58] and it's likely to be hard to get them fixed in debian (then synced in ubuntu) before FF being in effect === arand_ is now known as arand [18:59] So do both. [18:59] Fix here and Debian and then sync. [18:59] I agree [18:59] just what I saw going to write :-D [19:00] * quadrispro going to choose a kind of pasta [19:02] StevenK, dssi still get dependency on old liblo package [19:03] fabrice_sp, already fixed [19:03] * StevenK starts [19:04] right. Sorry: it was another transition :-/ [19:05] fabrice_sp, please re-upload whysynth [19:06] fabrice_sp, you didn't change the build-dep on liblo0-dev [19:06] http://launchpadlibrarian.net/38782264/buildlog_ubuntu-lucid-i386.whysynth_20090403-1build1_FULLYBUILT.txt.gz [19:07] quadrispro: I should drop whysynth from my list? [19:08] StevenK, whysynth is not fixed [19:08] and I think it's the same for xsynth-dssi [19:08] yup -> http://launchpadlibrarian.net/38781708/buildlog_ubuntu-lucid-i386.xsynth-dssi_0.9.0-2ubuntu3_FULLYBUILT.txt.gz [19:10] guys, let's use the "Assigned to" feature :D [19:12] hey, anyway, I would like to fix this bug: https://bugs.launchpad.net/ubuntu/+source/pgadmin3/+bug/347256 [19:13] Ubuntu bug 347256 in pgadmin3 "pgadmin3 has ugly icon" [Undecided,Confirmed] [19:13] pretty easy to fix, but I never fixed a bug in a package in Ubuntu [19:13] would need some help (either *take me by the hand* or *point me the appropriate docs*) [19:14] *anyway -> anyone [19:14] AntoineLeclair, see https://wiki.ubuntu.com/MOTU/Contributing [19:15] it will explain you how to prepare a debdiff [19:16] fabrice_sp_: thanks, I'll read this and come back for questions, if any (there will probably be some ;)) [19:16] you're welcome ;-) [19:25] AntoineLeclair, by the way: if you are working on this bug, assign it to yourself, with status 'In progress' so that other users knows you are working on it [19:27] fabrice_sp_: ok, I'll do that when I know I have learned enough to fix it [19:27] ok [19:27] lol === fabrice_sp_ is now known as fabrice_sp [19:27] fabrice_sp_: could you check whether do I have correct debdiff for fakesync? bug 517297 [19:27] Launchpad bug 517297 in ttf-sil-scheherazade "Fake sync ttf-sil-scheherazade 1.001-6 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/517297 [19:28] fabrice_sp: lol!! don't laugh :P [19:29] :-D [19:31] ari-tczew, it's in main: I prefer to let a Main sponsor to have a look. Anyway, and in general, I'm not sure about the value of a fakesync. If there are differences, you can always replicate the Debian changesi in the Ubuntu package [19:31] what is a fakesync [19:31] ? [19:32] statik, it's when you can't sync a package from Debian because the orig tarball is different [19:33] oh wow. when does that happen? [19:33] so you take the Ubuntu orig tarball, and 'copy' the Debian debian directory [19:33] * statik nods [19:34] when you repack the tarball, for example, or for some reason, the tarball has one change (last fakesync I looked, it was the date of one directory) [19:34] so you either wait a new upstream release to do the sync, and maitain the package in paralell or do a fakesync [19:35] i see. thanks for explaining me! [19:35] you welcome ! :-) [19:35] * fabrice_sp discovered the fakesync not so long ago :-) [19:36] it's an undocumented feature [19:36] right: even ubottu doesn't know about it :-D [19:36] !fakesync [19:36] ubottu> Sorry, I don't know anything about fakesync [19:36] Error: I am only a bot, please don't think I'm intelligent :) [19:36] ubottu is really weak in this area [19:36] Error: I am only a bot, please don't think I'm intelligent :) [19:37] !sync [19:37] Helpful information for filing a sync request can be found at https://wiki.ubuntu.com/SyncRequestProcess [19:37] Aha, not so much anymore! [19:37] :-D [19:37] ScottK, i've built all (i think) packages on the liblo0-dev NBS list, what can I do to help you and fabrice_sp ? [19:37] built them in pbuilder, that is [19:37] * randomaction thanks whoever taught ubottu this [19:37] I am confused: where do I drop the ".desktop" file upon installation of my package? I can see .desktop file being dropped at multiple places: /usr/share/app-install , /usr/share/applications [19:37] ScottL: I think you wanted StevenK [19:38] I fixed bug 479131 in a 0.2 upload, but because the error occurs on package removal or reinstallation (when the service is stopped), people who have already installed the package will continue to have problems. How should I go about fixing this? [19:38] Launchpad bug 479131 in autokey "Autokey crashes on post-install, "stop" action checks the return message rather than the return code." [Medium,Fix released] https://launchpad.net/bugs/479131 [19:38] jldupont: /usr/share/applications : the ones in /usr/share/app-install are used for something else entirely. [19:38] persia: like what? [19:38] I think it's now called "Software Centre" [19:38] ScottL, I think the transition is quite well advanced (see bug 517416) [19:38] Launchpad bug 517416 in wsynth-dssi "liblo0ldbl -> liblo7 transition" [Undecided,Fix released] https://launchpad.net/bugs/517416 [19:38] (or should I just tell people to "LANG=C apt-get upgrade" first?) [19:38] persia, lol, yeah, [19:39] persia: so if I only care about an apt-get install flow, I can safely disregard /app-install ? [19:40] fabrice_sp, okay [19:41] even "rhythmbox" gets 2 entries i.e. /usr/share/applications and /usr/share/app-install [19:41] Is it like a "copy" of /usr/share/applications being made by "Software Center" in the /usr/share/app-install ?? [19:43] amarok, a typical KDE based application, gets two entries too... [19:46] what about icons? I can see lots of apps have entries in /usr/share/app-install/icons and /usr/share/icons [19:47] * persia hunts up the spec [19:47] * jldupont appreciates persia is hunting for answers [19:48] http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html is the closest I find. [19:48] I tend to just throw everything in pixmaps, but I know that to be wrong [19:51]