[03:50] <X3MBoy> Good night
[03:55] <cody-somerville> Do you have to use conflicts and replaces together or will replaces just by itself do the job?
[03:56] <RAOF> Conflicts + Replaces has a different meaning to just Conflicts or Replaces.
[03:57] <cody-somerville> So in this situation, upstream has changed the name of the package
[03:57] <RAOF> Replaces allows one package to replace files in another package without dpkg throwing a screaming hissy fit.
[03:57] <RAOF> Conflicts prevents both packages being installed at the same time.
[03:57] <RAOF> Conflicts + Replaces means "This package is the successor to the other one; remove it and install this shiny new thing".
[03:58]  * cody-somerville nods.
[03:58] <cody-somerville> Awesome
[04:03] <dlynch> I found a bug in the new Ubuntu notification system: which package should I report it against?
[04:04] <RAOF> dlynch: Notify-osd.  In fact, you want to run 'ubuntu-bug -p notify-osd', so apport can attach all sorts of funky info to the bug.
[04:04] <dlynch> thanks!
[04:05] <imbrandon> evening all
[04:07] <RAOF> Woah.  Howdie imbrandon.
[04:10] <imbrandon> :)
[05:31] <cody-somerville> RAOF, ping
[05:33] <cody-somerville> It isn't working quite so nicely. Apt is opting not to install the new package because the old package has a reverse dependency (the package's debugging symbols package).
[05:34] <cody-somerville> Or sorry, this is dpkg
[05:34] <cody-somerville> I'm wondering if apt is smart enough to do the Right Thing (TM)
[05:45] <jdong> cody-somerville: the install and dist-upgrade commands have no regret to uninstall a revdep to obey your command.
[05:45] <jdong> the upgrade command will not do so
[05:46] <cody-somerville> okay
[06:49] <cpscotti> Hello there, is there any magic to sign .dsc and .changes files? I am using "dpkg-buildpackage -sa -k<<myKeyNumber>>".
[06:49] <cpscotti> It asks me for my passphrase but then reports: dpkg-buildpackage: warning: Failed to sign .dsc and .changes file
[06:49] <cpscotti> without -k<<myKeyNum>> it simply wouldn't find the key
[06:50] <NCommander> cpscotti, what are you trying to do?
[06:50] <cpscotti> uploading my package to revu
[06:51] <cpscotti> apart from the signing part, it seems nice (no lintian warnings nor errors)
[06:51] <cpscotti> also, my .changes file is empty (only the .dsc contains something since this is the first time I package it)
[06:51] <NCommander> Well, the reason -k usually needed is if your sponsoring an upload, or your name, and the name on your GPG key is incorrect (and to successfully upload to REVU, you need -S, for source only upload, -sa just makes sure the original tarball is generated)
[06:53] <cpscotti> hmm nice, changed that and forgot the -k thing. Now it tells me "clearsign failed: secret key not available"
[06:53] <NCommander> How did you generate your GPG private key?
[06:53] <cpscotti> does this means the name/email on the control files is different from the one in my key?
[06:54] <cpscotti> gpg --gen-key
[06:54] <NCommander> the name/email in the control is not used for determining what key is used
[06:54] <NCommander> What type of key did you generate?
[06:54] <cpscotti>  (1) DSA and Elgamal (default)
[06:55] <NCommander> and do you see it in gpg --list-secret-keys ?
[06:55] <cpscotti> yes
[06:55] <cpscotti> the only difference from the ones listed and the one that dpkg-buildpackage doesn't find is the comment
[06:55] <NCommander> And the name on the key is exactly the same as it is in debian/changelog?
[06:56] <cpscotti> yes..
[06:56] <NCommander> Very odd
[06:56] <cpscotti> apart from the comment thing
[06:56] <hyperair> check the email
[06:56] <hyperair> =\
[06:56] <NCommander> What email?
[06:56] <RAOF> The comment thing matters ;)
[06:57] <cpscotti> hmm!!!
[06:57] <cpscotti> that's the magic
[06:57] <hyperair> for me it's Chow Loong Jin <hyperair@gmail.com>. if the email changes in debian/changelog, it won't find the key
[06:57] <hyperair> so i export DEBEMAIL in my bashrc
[06:58] <cody-somerville> :S
[06:58]  * NCommander notes that he has all his emails as GPG uids :-)
[06:58] <cpscotti> I did that too
[06:58] <hyperair> NCommander: all my emails are listed in GPG too. but if i don't set DEBEMAIL, it ends up as hyperair@hyperair-laptop
[06:58] <NCommander> hyperair, right, mine ends up mcasadevall@blacksteel.local
[06:58] <cpscotti> now that I added the comment to the changelog it found the key
[06:58] <NCommander> cpscotti, cool
[06:59] <hyperair> what comment?
[06:59] <hyperair> ._.
[06:59] <NCommander> Now just dput the source changes file
[06:59] <cpscotti> Clovis Peruchi Scotti (used at harpia) <scotti@ieee.org>
[06:59] <hyperair> aaaah
[06:59] <NCommander> rofl
[06:59] <hyperair> i see
[06:59] <NCommander> You can make it ignore that
[06:59] <hyperair> mine doesn't have a comment =\
[06:59] <NCommander> One of mine did
[06:59] <cpscotti> this between () is the "comment" gpg asks for
[07:00] <NCommander> Obvioulsy that's not idle
[07:00] <NCommander> cpscotti, if you create ~/.devscripts, you can set the keyid there
[07:00] <NCommander> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc"
[07:00] <NCommander> DEBSIGN_KEYID="9DA2DA9B"
[07:00] <NCommander> That's what's in mine
[07:01] <NCommander> (the -us -uc disables the autosigning, so you have to do it with debsign)
[07:01] <cpscotti> hmm
[07:01] <cpscotti> I was using -us and -uc before
[07:01] <NCommander> Once you set DEBSIGN_KEYID, it will always try to sign, which is annoying
[07:02] <cpscotti> hehe
[07:02] <cpscotti> well, I'll try all these regarding the comment thing now
[07:02] <NCommander> I also don't like to sign until I'm sure I'm ready to upload (safeguard between dput ubuntu and dput ppa:hi :-))
[07:02]  * hyperair has it always sign =\
[07:02] <hyperair> but yeah, that's true
[07:02] <hyperair> a signed .changes file is a security concern =p
[07:02] <cody-somerville> I find having to type the hostname for ubuntu safeguard enough
[07:03] <NCommander> cody-somerville, I do the same here, but I like being paranoid
[07:03] <NCommander> Its healthy
[07:03] <cody-somerville> To a degree ;)
[07:03] <hyperair> cody-somerville: how do you make it not trigger automatically?
[07:03] <NCommander> hyperair, edit /etc/dput.cf
[07:03] <hyperair> ah
[07:03] <cody-somerville> or more correctly, I modify ~/.dput.cf :)
[07:04] <NCommander> cody-somerville, I didn't realize you could change the default in ~/.dput.cf
[07:04] <cody-somerville> yup
[07:05] <hyperair> is there a way to completely remove the default/
[07:05] <cody-somerville> hyperair, What do you mean exactly?
[07:05] <NCommander> I just set mine to ENODEFAULT
[07:05] <hyperair> ah okay
[07:05] <cody-somerville> yea
[07:05] <cody-somerville> you can set it to something bogus
[07:06] <cody-somerville> Thats what I do too
[07:06] <cody-somerville> that way I *have* to specify where I'm uploading to
[07:06]  * NCommander listens to the Blood Gluch Blues
[07:06] <hyperair> alright
[07:06] <hyperair> thanks =p
[07:07] <cody-somerville> np
[07:12] <cpscotti> me again: "gpg: problem with the agent - disabling agent use; debsign: gpg error occurred!  Aborting..."
[07:12] <cpscotti> does this problem with gpg-agent may be the issue?
[08:08] <savvas> is there a command that returns a look-alike debian package link if I provide the name of the package?
[08:08] <cody-somerville> a what?
[08:08] <savvas> I mean "fast-user-switch-applet" -> "f/fast-user-switch-applet"
[08:09] <savvas> or libapache2-mod-auth-pam -> liba/libapache2-mod-auth-pam :)
[08:10] <cody-somerville> You're just looking for the path relatively to the root of the pool?
[08:11] <savvas> cody-somerville: yes :)
[08:12] <cody-somerville> savvas, There isn't a command for that
[08:12] <cody-somerville> However, it would be easy to whip one up with python-apt
[08:12] <savvas> darn
[08:13] <cody-somerville> why do you say darn?
[08:13] <savvas> ah wait, python-apt might do the trick
[08:14] <cody-somerville> as I just mentioned, yes.
[08:14] <cody-somerville> :)
[08:15] <savvas> yes, thank you :P
[08:22] <savvas> package=backport-util-concurrent; grep-aptavail -P $package -s Filename -n | sed -e 's#^pool/[^/]*/##' -e 's#/[^/]*$##'
[08:22] <savvas> :P
[08:22] <savvas> yay!
[08:50] <savvas> can someone fix python-cheetah debian/control ? "XSBC-Orginal-Maintainer:" -> "XSBC-Original-Maintainer:"
[09:03] <StevenK> savvas: It's in the archive?
[09:55] <fransman> who is able to confirm bug #330150
[10:03] <Nafallo> when did they release the Feature Freeze? :-)
[10:04] <iulian> Oups, bad wording.
[10:05] <iulian> Nafallo: Is it better now?
[10:09] <iulian> fransman: Hmm, I remember we discussed about that bug.
[10:09] <iulian> fransman: We came to the conclusion that it should wait for Karmic.
[10:10] <fransman> Are you gonna change that in the bug?
[10:10] <fransman> It still can be confirmed?
[10:13] <iulian> fransman: Yes, sure.  I'm surprised that no one commented on it.
[10:13] <iulian> fransman: OK.  Would you like to take care of it when Karmic opens its doors?
[10:14] <fransman> iulian: does it the same for bug #319204 ?
[10:15] <fransman> and sure maybe I have to be more patient with my bugs
[10:16] <fransman> iulian: i am a end user not a coder!
[10:18] <iulian> fransman: No worries.  flumotion will need an FFe.  Please see https://wiki.ubuntu.com/FreezeExceptionProcess.
[10:19] <fransman> Gonna read it now, that sound cool
[10:29] <iulian> fransman: I've just commented on asterisk.
[10:30] <fransman> may I say thank you?
[10:32] <iulian> Don't mention it. ;)
[10:35] <fransman> Oo I just did
[11:34] <savvas> StevenK: yes, jaunty
[11:38] <savvas> https://launchpad.net/ubuntu/jaunty/+source/cheetah or http://packages.ubuntu.com/source/jaunty/cheetah :)
[11:42] <francescomrl> hi
[11:43] <RainCT> hi
[11:44] <StevenK> savvas: Sorry, I was out. Lemme take of it for you
[11:49] <talex> Hi. I'm trying to get a bug fixed in Jaunty.
[11:49] <talex> https://bugs.launchpad.net/ubuntu/+source/zeroinstall-injector/+bug/336317 . The problems are fixed in Debian. Who do I have to talk to get the fixed version into Jaunty?
[11:50] <StevenK> savvas: cheetah uploaded
[11:55] <StevenK> talex: It shouldn't be Fix Commited in Ubuntu, if Debian has fixed it.
[11:56] <StevenK> talex: If Debian has a new upstream version, you'll need a Feature Freeze exception. If not, figure out what Ubuntu bugs it closes, and files a sync request.
[11:56] <StevenK> s/files/file/
[11:57] <talex> Yes, Debian has a new upstream version. It closes Ubuntu bug #336317. Where do I file a sync request? Thanks.
[11:58] <StevenK> talex: Whoa there. First you need a Feature Freeze exception
[11:58] <talex> How do I get that?
[11:59] <talex> (if it helps, the package's own test suite doesn't pass in the current Jaunty version)
[12:02] <a|wen> talex: it is describet here https://wiki.ubuntu.com/FreezeExceptionProcess
[12:02] <talex> Thanks
[12:03] <a|wen> talex: but first of all, start by changing the status of the bug to confirmed ... ("fix committed" means that a fix is uploaded in ubuntu and is just on it's way to the archive)
[12:04] <savvas> StevenK: thank you! :)
[12:24] <talex> StevenK, a|wen: Thanks. I've updated the bug report with a feature freeze exception request.
[12:25] <StevenK> talex: Comfirmed means the FFe is approved, I've set the bug status back to New
[12:25] <StevenK> Sigh, Confirmed
[12:27] <bjarkef> Just a quick question. After the feature freeze of jaunty, no new packages accecpted? Not even after it is realeased? And all new packages will have to go into the next ubuntu release (9.10) ?
[12:28] <a|wen> bjarkef: as a rule, yes ... and there needs to be very very good arguments for breaking that rule
[12:28] <wgrant> New packages can go into -backports.
[12:30] <a|wen> ahh you're right, after release was part of the question
[12:30] <cpscotti> how those backports work?
[12:30] <cpscotti> another repository u can add to sources.list?
[12:30] <bjarkef> a|wen & wgrant: Okay, thanks. I'm just trying to understand how new packages gets accecpted. I guess only releasing new packages each half year is a good idea. So as a rule only new versions of existing packages gets accecpted?
[12:31] <wgrant> bjarkef: After release, most people see no new versions except for security updates and critical bugfixes.
[12:31] <wgrant> Newer versions and new packages will sometimes be put in the backports repository, which people can enable if they wish.
[12:32] <a|wen> cpscotti: it's called "unsupported updates" in synaptics
[12:32] <cpscotti> thanks!
[12:35] <bjarkef> Alright. This also means that if I want to work on getting a new package included in ubuntu, I am heading for 9.10, for which I have not possibly of testing before later this year? Or should I head for jaunty-backports right away?
[12:36] <wgrant> bjarkef: You won't get it backported without it being in 9.10 first.
[12:36] <wgrant> bjarkef: But you can easily test in 9.10 early on.
[12:37] <bjarkef> wgrant: Okay. When is early on, I have not really been able to find a release schedule for 9.10?
[12:39] <wgrant> bjarkef: Remember that 9.10 will start out exactly as 9.04 will be when it is released.
[12:41] <bjarkef> wgrant: Aha, I get that. I think I understand the process now, and I found the release schedule (https://wiki.ubuntu.com/KarmicReleaseSchedule). Thanks for the help.
[12:55] <cpscotti> wgrant & bjarkef: helped me too
[12:55] <cpscotti> hehe
[13:57] <fransman> If I did clone a git, how do I create a tar-ball and build a package?
[13:57] <fransman> For example git://git.debian.net/git/debian/openerp-server.git .
[14:07] <Ampelbein> fransman: with git-buildpackage you can build the package
[14:07] <fransman> Ampelbein: may I say thank you?
[14:12] <Ampelbein> fransman: perhaps http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html might be a good place to learn more about using debian-packages with git
[14:13] <fransman> Ampelbein: Thanks, I am gonna read it now.
[14:48] <cemc> is there a way to create a jaunty chroot with pbuilder?
[14:48] <cemc> on intrepid
[14:50] <RainCT> cemc: sudo aptitude install ubuntu-dev-tools; pbuilder-dist jaunty create   :)
[14:50] <pochu> and install debootstrap from intrepid-backports I think
[14:51] <RainCT> and then  pbuilder-dist jaunty build <file>.dsc to build, etc. You can also do «sudo ln -s /usr/bin/pbuilder-dist /usr/local/bin/pbuilder-jaunty» and then just use «pbuilder-jaunty <whatever>» instead of «pbuilder-dist jaunty <whatever>»
[14:52] <cemc> yeah, I think that's the one what pochu said. I have other chroots, for dapper, hardy etc, but couldn't build one for jaunty, because there isn't a script for that in the debootstrap for intrepid (naturally)
[14:53] <directhex> hm. i wonder whatever happened to "UDS details by the end of the week"
[14:58] <Laney> yeah :(
[14:58] <Laney> some people need to book time off
[14:59] <directhex> i don't need lots of notice, but she who must be obeyed does, and she's under pressure, which means I'M under pressure
[14:59] <directhex> http://www.youtube.com/watch?v=d-xVb1qsPCw
[15:01] <cemc> pochu: it worked, thanks
[16:29] <goshawk> hi, i'm going to create a package
[16:29] <goshawk> can i use http://wiki.debian.org/Proposals/CopyrightFormat as a debian/copyright template?
[16:35] <iulian> goshawk: Yes
[16:35] <goshawk> thx iulian
[17:16] <Kaushal> hi
[17:16] <Kaushal> is Firefox 3.0.8 being released in Ubuntu Repository ?
[17:17] <jpds> Kaushal: Yes, it's in Jaunty.
[17:17] <Kaushal> ok
[17:17] <dtchen> and {hardy,intrepid}-security
[17:18] <Kaushal> what about Hardy ?
[17:18] <dtchen> it's already in hardy-security (and hardy-updates)
[17:18] <Kaushal> dtchen, so it should be available in hardy too
[17:18] <Kaushal> right
[17:19] <Kaushal> great
[17:20] <Kaushal> dtchen, is there a list online mentioning about it ?
[17:20] <dtchen> there are the -changes mailing lists
[17:20] <dtchen> you can also use the LP web page
[17:21] <dtchen> or (my preferred) `rmadison -uubuntu firefox-3.0'
[17:21] <jpds> Kaushal: Maybe https://edge.launchpad.net/ubuntu/+source/firefox-3.0/+publishinghistory too.
[17:22] <Kaushal> jpds, Thanks
[17:23] <Kaushal> jpds, what about the -changes mailing lists as dtchen mentioned
[17:23] <Kaushal> what is it exactly
[17:23] <Kaushal> I did not understand
[17:23] <Kaushal> is there a mailing list of -changes ?
[17:23] <jpds> Kaushal: https://lists.ubuntu.com/#Package+Upload+and+Automatic+Notification+Lists
[17:24] <Kaushal> great
[17:24] <Kaushal> what is rmadison -uubuntu firefox-3.0 ?
[17:26] <Kaushal> ah got it
[17:27] <Kaushal> rmadison means Remotely query the Debian archive database about packages
[17:27] <Kaushal> so if i do apt-get install rmadison should work ?
[17:27] <Kaushal> right
[17:27] <Kaushal> on Hardy
[17:27] <jpds> It's in the devscripts package.
[17:27] <dtchen> no, devscripts
[17:28] <Kaushal> ok
[17:28] <Kaushal> so i need to apt-get install devscripts ?
[17:28] <Kaushal> right
[17:30] <Kaushal> jpds, Thanks
[17:30] <Kaushal> dtchen, thanks you too :)
[17:32] <dtchen> np
[18:15] <lfaraone> how do we determine the urgency of an upload, or is it not relevent in Ubuntu?
[18:15] <lfaraone> (ie a bugfix which fixes a bug which prevents the package from being installed)
[18:16] <jpds> You mean in debian/changelog?
[18:17] <lfaraone> jpds: yes.
[18:18] <jpds> lfaraone: Irrelevent in Ubuntu, it's just how long the package has to wait to move into testing from Debian.
[18:18] <lfaraone> jpds: kk.
[18:25] <lfaraone> jpds: you in a sponsoring mood? :)
[18:25] <jpds> lfaraone: What is it?
[18:26] <lfaraone> jpds: "sugar", for bug 350712. it's a one line fix.
[18:32] <jpds> lfaraone: Jarabe is part of sugar or a seperate thing?
[18:32] <jpds> Oh, it's in src/, nevermind.
[18:32] <lfaraone> jpds: pat of sugar.
[18:33] <lfaraone> *part
[18:34] <jpds> lfaraone: http://paste.ubuntu.com/140208/ - -json appears to get pulled in already.
[18:36] <lfaraone> jpds: json != cjson :)
[18:36] <jpds> lfaraone: Very odd: http://paste.ubuntu.com/140209/
[18:37] <jpds> Damn, sorry.
[18:37] <lfaraone> jpds: different sugar parts use different JSON libs. we prolly should all standardize rahter than using 4 different packags, but that's a problem for upstream.
[18:45] <jpds> lfaraone: OK; I'll upload a fix after supper.
[18:48] <lfaraone> jpds: thanks.
[19:17] <jpds> lfaraone: All done.
[19:18] <lfaraone> jpds: saw, thanks.
[20:22] <binarymutant> whats the difference between Architecture: any and Architecture: all in the control file?
[20:23] <jdong> binarymutant: any means the same .deb works on every architecture (i.e. a bash or python script), all means "please build .debs for each architecture supported"
[20:23] <binarymutant> thanks jdong :)
[20:25] <lfaraone> What are the inclusion criteria for multiverse?
[20:25] <lfaraone> *is
[20:25] <jdong> lfaraone: I believe as long as mirrors are allowed to redistribute it.
[20:25] <jdong> and of course repackaging is legal.
[20:26] <a|wen> jdong: i suppose you wanted to reverse that statement?
[20:26] <a|wen> jdong: any = build for all supported archs ... all = build once, works on all
[20:26] <jdong> a|wen: jeez I need more coffee
[20:26] <a|wen> binarymutant: ^^
[20:26] <a|wen> jdong: hand me a cup, when you find one ;)
[20:27] <jdong> to prevent further jdong brain melting: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture
[20:28] <lfaraone> jdong: ok, would a package which as a rule does not allow binary/source modification (unless you change the package's name) but a special exception has been made for Ubuntu packaging (anybody else who made further changes would have to rename the package) be acceptable in univ. or multiverse?
[20:28] <lfaraone> *universe, or
[20:28] <binarymutant> I gotcha, someone told me that all means per-arch recompiling and that helped a lot, the debian-policy wording was confusing me. But thanks all for the help
[20:28] <jdong> lfaraone: I don't know that much;the archive admins should have your authoritative answer
[20:29] <lfaraone> jdong: ok, where could I find such a being? :)
[20:29] <jdong> lfaraone: #ubuntu-devel, check launchpad team ~ubuntu-archive for a list of victims.
[20:29] <jdong> (and don't tell them I sent you!)
[20:30] <lfaraone> jdong: hehe... *me gets out his sword and prepares to do battle*
[20:30] <lfaraone> */me
[21:04] <lfaraone> Hi, I'm upgrading to jaunty and it's telling me beanshell (bsh) is being removed. I checked, and it's A) set to manually installed and B) in jaunty, so what gives? (why is it being removed as an "obsolete package"?)
[21:48] <manolo06> holaaa
[23:39] <sparr> there is a bug in jaunty where a library's postinst script dies when a new version of python is installed.  i would typically expect that postinst script to get fixed.  instead, the solution is to CONFLICTS the library with the new version of python.  might the impending release of jaunty have something to do with that approach?
[23:45] <cody-somerville> sparr, what package is this?
[23:57] <sparr> cody-somerville: libboost-python-dev
[23:58] <sparr> Bug #339100
[23:59] <sparr> I understand that the rules change around release time, so I am not overly worried by this solution, but after the release that solution is going to be unsatisfactory