[00:06] <lightnin> Trying to upload a new package to my PPA, but dput keeps giving me this error: Checksum doesn't match for ...diff.gz
[00:07] <lightnin> I built the source package with PDE build, signed it with debsign... am I missing something?
[00:11] <maxb> PDE build? You mean pdebuild? That's not an acronym :-)
[00:12] <maxb> that checksum error implies the .diff.gz you've got isn't the one that was built at the time the .changes you are trying to upload was built
[00:18] <lightnin> maxb: Hmmm... thanks. Yeah, sorry -- pdebuild
[00:19] <lightnin> maxb: So would this be a good command to build a source package using pdebuild: DIST=jaunty pdebuild --buildresult ../
[00:20] <maxb> uhm. I've never used --buildresult myself, which makes me wonder if it might be related to your problem
[00:21] <maxb> Typically I won't bother with pbuilder if I'm just building a source package for a PPA upload
[00:21] <lightnin> Oh, ok.
[00:21] <lightnin> So I should probably just use debuild, eh?
[00:24] <lightnin> maxb: Ok, debuild worked. I'm thinking of releasing this package as a download on our website too - so I figured I'd be as kosher as possible and use pdebuild. But I guess it doesn't matter as long as pdebuild is able to build it...
[00:25] <maxb> pdebuild is useful for ensuring the binary packages build in a clean environment
[00:25] <maxb> However for a PPA upload you want a source only build anyway
[00:26] <maxb> I suspect the  --buildresult ../ as the root of your problems, because I can't imagine what else it could be
[00:34] <lightnin> maxb: Many thanks for your help!
[01:11] <IntuitiveNipple> Do I need to subscribe ubuntu-release or ubuntu-sponsors for a Universe package (apt-cacher) bug fix ?
[01:16] <ajmitch> ~ubuntu-sponsors
[01:19] <IntuitiveNipple> thanks ajmitch
[02:17] <asac> jdong: i am trusted to do the right hting
[02:17] <asac> sometimes i add stuff before consulting them
[02:17] <asac> but i always consult them
[02:18] <asac> usually we should consult them first
[02:54] <jdong> asac: thanks for clarifying; I'd assume after some point there'd be a level of trust built where they trust that you will make decisions that are reasonable to them
[02:57] <asac> jdong: right. its officially not that way
[02:57] <asac> inofficially i might act that way if needed though ;)
[02:57] <jdong> right, understandably so :)
[02:57] <jdong> I guess the point is things that sound absurdly bureaucratic in legalese can work out in practice
[02:57] <jdong> (at least the point I was trying to bring up in that discussion)
[02:58] <asac> well. in practive we have this:
[02:58] <asac> we do stuff and have to discuss upstream by first beta
[02:58] <asac> in security updates i really try to avoid any changes so we are safe
[03:00] <jdong> ah
[03:01] <jdong> does that cover just the Mozilla source/codebase, or also things like our debian/ packaging changes?
[03:01] <jdong> (now I'm just asking out of pure curiousity)
[06:34] <Ciemon> Laney: when you've 5 mins, ping me please.
[06:47] <EzraR> there is a command to download a source package from debians repo is there not? anyone know?
[06:58] <persia> pull-debian-source might work.
[06:58] <persia> Alternately, dget from the .dsc URL (found in various places, but always at packages.qa.debian.org if nowhere else)
[07:06] <EzraR> seems pull-debian-source is broken, im pretty sure that is what i was looking for thnx
[07:06] <persia> Please fix :)
[07:06] <EzraR> hehe
[07:06] <EzraR> i was just going to look
[07:21] <EzraR> ok fixed
[07:22] <persia> Excellent.  Do you use bzr?  If so, please submit a merge proposal to lp:ubuntu-dev-tools.  If not, please file a bug with the patch.
[07:25] <EzraR> yeah i will, i just was going through the bug reports to see if it was reproted already etc...
[07:26] <EzraR> i find it strange that it hasent been reported, maybe people dont really use it or it doesnt effect all packages
[07:26] <persia> most of the users of ubuntu-dev-tools are, unsuprisingly, developers, so bugs tend to get swatted on discovery (but not always).
[07:30] <EzraR> persia want to try it out on a random package for me? if you get the error i would feel a little better about it :)
[07:31] <persia> works for me, no error.
[07:32] <EzraR> hmm
[07:34] <EzraR> persia: are you using karmic?
[07:36] <persia> no.
[07:37] <EzraR> what package did you try it on?
[07:37] <persia> hello-debhelper
[07:39] <dholbach> good morning
[07:39] <ajmitch> hi
[07:39] <dholbach> hey ajmitch
[07:41] <Rhonda> wgrant, persia: Haven't heard about the sdl issue in some days and seen no mail to the bug neither - what's the plan? :)
[07:59] <ajmitch> dholbach: bug 559059 is committed if you want to check it out
[07:59] <dholbach> ajmitch: WOW, that was quick
[08:00] <ajmitch> really didn't take long to do
[08:00] <persia> I don't agree with that bug though.
[08:00] <persia> I think we ought align with DIF.
[08:00] <dholbach> good work
[08:00] <persia> pre-DIF, we'd do better to concentrate on SRUs for RCbugs.
[08:01] <persia> Rhonda: I wasn't able to come to any useful conclusions regarding consumers of the regression: do you think we should just push the patch?
[08:01] <dholbach> persia: it had karmic a few minutes before
[08:01] <persia> I know.  It had karmic too long, but I think the fix is too large a hammer.
[08:01] <dholbach> persia: maybe file a separate bug so that we can get a separate view for "sru stuff"
[08:01] <ajmitch> dholbach: that's because I made a mistake in what should still be default, it was meant to be karmic until DIF & then switched
[08:01] <ajmitch> though lucid was always available
[08:02] <ajmitch> persia: the simple way is for me to just disable the part of the cronjob that looks up the current relese from LP
[08:02] <ajmitch> which was as quick & hacky as http://bazaar.launchpad.net/~ajmitch/%2Bjunk/ubuntu-scripts/annotate/head:/ubuntu_series.py
[08:02] <dholbach> thanks a bunch ajmitch
[08:03] <ajmitch> np
[08:03] <persia> dholbach: Every release is available, one just has to enter the right URL.
[08:03] <persia> ajmitch: heh, OK.  If you happen to figure out how to make it work magically, that'd be cool too :)
[08:04] <ajmitch> persia: sure, I could hack something into there now to only run it a certain number of weeks after the current release is open
[08:04] <ajmitch> but that sounds like work
[08:04] <dholbach> I think it makes sense if it defaults to the current development release and has a "nav bar" to the supported releases
[08:05] <ajmitch> dholbach: right, I was going to add that, I should do that now
[08:05] <dholbach> where nav bar is really just "a bunch of links" :)
[08:05] <dholbach> ajmitch: you are a man of awesome
[08:05] <dholbach> rcbugs is such a brilliant tool
[08:06] <persia> Indeed.
[08:07] <ajmitch> it's a shame it's so ugly underneath :)
[08:08] <persia> shhh!
[08:08] <ajmitch> as long as noone looks at the code...
[08:13] <ajmitch> ok, looks ugly, but the links are there for each release
[08:13] <ajmitch> see if the bugs listed match reality
[08:13] <Rhonda> persia: Not sure wether people really complained about the fix that did stir this kind of regression, at least I never heard of any drag'n'drop issues.
[08:15] <persia> Rhonda: So, if you recommend it be applied, I'll apply it (or if you prepare a candidate, I'll upload it), but I'd like a firm recommendation as you've looked into this much more than I.
[08:15] <persia> (unless wgrant is already preparing an upload)
[08:24] <Rhonda> persia: Just in case, gentoo did pick up on that patch already. :)
[08:27] <persia> We should all really grant gentoo the appreciation they deserve: they apply patches faster than most of us, and get testing feedback quickly.
[08:31] <Rhonda> :)
[09:01] <ajmitch> what an amusing cross-post on ubuntu-devel-discuss
[12:04] <arand> I was planning on reporting https://bugs.edge.launchpad.net/ubuntu/+source/virtualbox-ose/+bug/562187 straigt to debian, without testing specifically on a debian install, since it's an upstream issue, is that an ok practice for this case?
[12:08] <persia> I generally prefer to see things tested in Debian if being reported to Debian.
[12:08] <persia> An example of what you haven't tested is whether this issue expresses itself with a Debian kernel.
[12:09] <persia> But there's no reason not to report directly upstream if it's an upstream issue.
[12:12] <arand> persia: True... well, I won't be able to test it, so that'll pretty much be leaving debian to find out for itself...
[12:13] <arand> persia: It's reported already to furthest upstream (vbox), and fixed in SVN there, figured it would apply to debian... but yea, that's just an assumption.
[12:15] <persia> arand: The trick is to send all the bugs we can to Debian without ever sending them a bug that doesn't affect Debian.
[13:00] <Laney> Ciemon: hiya
[13:01] <Ciemon> hiya, ok for a quick msg?
[13:01] <Laney> absolutely
[13:22] <Laney> I just noticed bug 496274 needs a SRU ack and has been sitting for months. Could someone on the team please poke it?
[13:31] <arand> If game for some more SRU, there's Bug #510571 that's a bit mouldy as well.
[15:08] <MTecknology> I ran dput without speficying where it should go and I got this - Rejected: The signer of this package has no upload rights to this distribution's primary archive.  Did you mean to upload to a PPA?
[15:08] <MTecknology> mr. error is right, but where the heck did I try to upload to :S
[15:09] <james_w> ubuntu
[15:10] <james_w> https://wiki.ubuntu.com/UbuntuDevelopment/Uploading#Avoiding%20uploading%20to%20the%20wrong%20place
[15:13] <MTecknology> james_w: thanks
[15:54] <joaopinto> can someone help me getting libuser into a buildable state in the repository ?
[15:54] <joaopinto> the fix is trivial, I would spend too much time research all the required process to get it in :P
[15:55] <james_w> joaopinto: you have a patch?
[15:56] <joaopinto> james_w, kind off, the easier wayt to fix requires to run autoreconf, the patch would be huge
[15:56] <joaopinto> I have added AC_CONFIG_MACRO_DIR([m4]) to configure.in and ran autoreconf
[15:56] <joaopinto> it will build and install file with the updated autoconf* files
[15:57] <joaopinto> the  AC_CONFIG_MACRO_DIR([m4]) was just to fix a warning with the newer autoconf
[15:57] <james_w> right
[15:57] <james_w> but what actually fixes the problem?
[15:58] <joaopinto> the problem is within aclocal.m4
[15:59] <joaopinto> which uses: from distutils import sysconfig; print sysconfig.get_python_lib(0,0)
[15:59] <joaopinto> to detect the python install dir
[16:01] <joaopinto> regenerating aclocal will replace it with a function that detects the proper path
[16:02] <joaopinto> but regenerating aclocal will require to regenerate the automake/autoconf files
[16:03] <joaopinto> my goal is to make usermode installable, I have a requirement to use it :\
[16:05] <james_w> so would a targeted patch to change that function be the best idea?
[16:06] <joaopinto> does it make sense such an effort for a package which does not currently build/install ?
[16:07] <james_w> well, it sounds like you need it?
[16:07] <joaopinto> is there a bug automatically generated because of  FTBFS or should I file a new one ?
[16:08] <james_w> you can file a new one
[16:08] <james_w> we don't need one though
[16:10] <joaopinto> james_w, a smaller patch against configure would make the approval easier ?
[16:11] <james_w> yeah
[16:11] <joaopinto> ufff, ok
[16:11] <james_w> push up a bzr branch and I'll take a look
[16:12] <joaopinto> does any know the equivalent to from distutils import sysconfig; print sysconfig.get_python_lib(0,0) to get site-packages ?
[16:12] <joaopinto> I mean the site-packages path
[16:13] <james_w> the build log from the failure has some code
[16:14] <joaopinto> hum, a simpler fix would be to disable the python module building :P
[16:14] <james_w> no, that uses sysconfig.get_python_lib()
[16:21] <joaopinto> james_w, hum, ok so I need to figure why it is using site-packages instead of the sysconfig return
[16:22] <joaopinto> argh, it's the (0,0 on the get_python_lib()
[16:22] <james_w> no, it's not is it?
[16:22] <james_w> it may be different versions of python
[16:22] <joaopinto> yup
[16:23] <joaopinto> >>> sysconfig.get_python_lib(0,0,prefix='something')
[16:23] <joaopinto> 'something/lib/python2.6/site-packages'
[16:23] <joaopinto> >>> sysconfig.get_python_lib()
[16:23] <joaopinto> '/usr/lib/python2.6/dist-packages'
[16:23] <joaopinto> actually it's the "prefix" parameter
[16:23] <james_w> yes
[16:25] <joaopinto> there is a bug with get_python_lib(, assuming I am reading the docs properly
[16:26] <joaopinto> "If prefix is given, it is used as either the prefix instead of PREFIX, or as the exec-prefix instead of EXEC_PREFIX  if plat_specific is true"
[16:26] <joaopinto> I am not setting plat_specific to try, but setting a prefix will do so
[16:26] <joaopinto> s/try/true
[16:44] <joaopinto> james_w, 4 lines fix: http://pastebin.org/149302
[16:45] <james_w> hmm, please push it to a bzr branch so that I can review a whole fix
[16:47] <joaopinto> hum, I am not used with bzr for packaging, you just want me to import the entire source+debian dir to a bzr branch ?
[16:47] <james_w> bzr branch lp:ubuntu/libuser
[16:48] <james_w> make the changes, commit, push to lp:~joaopinto/ubuntu/lucid/libuser/fix-ftbs
[16:48] <james_w> then propose for merging
[16:48] <joaopinto> ok
[16:52] <joaopinto> james_w, how I do I propose for merging ?
[16:52] <james_w> joaopinto: bzr lp-open and then click the link in the page that opens in your browser
[16:54] <joaopinto> hum, I didn't take care of the changelog
[16:56] <joaopinto> hum, now that I look into the changelog
[16:56] <joaopinto>   * debian/rules:
[16:56] <joaopinto>     - Adapted python2.6, by changing site-package to $(call py_sitename_sh, $*)
[16:56] <joaopinto> it was supposed to be fixed on the previous change
[16:58] <joaopinto> james_w, I need to add a changelog entry and bumpt the version to ubuntu2 right ?
[16:58] <james_w> yes
[16:59] <joaopinto> grr, it uses dpath, is it a requirement to use the existing patch system for the configure patch ?
[16:59] <joaopinto> dpatch
[16:59] <james_w> yes
[16:59] <joaopinto> grr, grr, grr :P
[17:40] <joaopinto> james_w, propose to merge done
[17:47] <joaopinto> james_w, do I need to poke someone else now ?
[18:21] <james_w> joaopinto: so you have confirmed that the package will now build with your change?
[18:22] <james_w> joaopinto: patching just configure is usually bad as changes may be overwritten as it is a generated file. You have confirmed that if it is regenerated it will retain this change or an equivalent one?
[18:22] <joaopinto> james_w, yes, build & installed on lucid
[18:23] <joaopinto> james_w, regeneration should be done with recent tools wich will override aclocal with a correct function to detect the python paths
[18:24] <joaopinto> that was my initial approach
[18:24] <james_w> ok
[18:24] <james_w> where does the macro that is used come from?
[18:25] <joaopinto> from the local alocal.m4
[18:26] <joaopinto> the patch could also be extended to aclocal.m4 but that is also a file expected to be re-gerated
[18:26] <joaopinto> ...generated..
[18:27] <james_w> where does aclocal get that part from?
[18:27] <james_w> aclocal is like a cached copy of macros from elsewhere
[18:28] <joaopinto> hum, good question
[18:28] <james_w> another way to ask would be what statement in configure.ac expands to include the thing you are patching?
[18:30] <joaopinto> I assume it's AM_PATH_PYTHON
[18:31] <joaopinto> which probably uses /usr/share/aclocal-1.11/python.m4 (from alocal-1.10)
[18:59] <james_w> joaopinto: that file still uses prefix= here
[18:59] <joaopinto> james_w, you mean configure ?
[19:00] <james_w> /usr/share/aclocal-1.11/python.m4
[19:01] <joaopinto> ah, hum, I didn't check the alocal.m4 after the regeneration
[19:01] <joaopinto> james_w, aren't we spending too much time for such a simple fix ?
[19:02] <james_w> you wanted to get it fixed
[19:11] <james_w> joaopinto: why don't we just change the packaging to not expect the upstream build system to have put the file in site-packages?
[19:14] <joaopinto> james_w, I want, as long it's a reasonable effort, I really don't see any risk with the current patch, and I can't see the advantage of further effort
[19:15] <joaopinto> there are plenty of other things which I would like to do and I will not be able by spending more time on this package
[19:15] <james_w> joaopinto: well, your patch could easily regress in the future
[19:17] <joaopinto> james_w, I really don't care at this time, a better patch maybe provided when someone else as the time/interest to do so
[19:21] <joaopinto> james_w, IMHO a future-concerned patch would regenerate the entire autoconf/automake/aclocal chain
[19:21] <joaopinto> I did the cherry picked patch to make the review/approval easier
[19:22] <james_w> well, you haven't convinced me that the regeneration would work, as it appears a regenerated file would produce the same code
[19:24]  * james_w has a packaging fix. I'll test and upload after dinner
[19:26] <joaopinto> james_w, uff: bzr branch lp:ubuntu/libuser && cd libuser && autoreconf && ./configure
[19:26] <joaopinto> check the configure output for the detected python modules dir
[20:02] <joaopinto> james_w, will you approve my merge ?
[20:03] <james_w> no, I don't think so
[20:05] <joaopinto> ok, thanks for your effort, I will try to find someone else willing to help
[20:08] <joaopinto> what is the team/group that can approve an univer FTBFS patch ?
[20:10] <joaopinto> how can I file a bug for a package which is not installable ?
[20:13] <james_w> joaopinto: fix uploaded
[20:13] <james_w> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/libuser/lucid/revision/11
[20:15] <arand> joaopinto: Find the package in LP and report the bug there?
[20:19] <blueyed> Is there a convenient way to try applying all debian patches to a source package, before trying to build it? just to see if they fail?
[20:19] <blueyed> At best, something which incorporates info from what-patch and works with any patch system.
[20:20] <james_w> ./debian/rules patch should work for the majority
[20:21] <blueyed> ah. sure. thanks.
[20:24] <blueyed> next one: what's the most convenient way to build from the current dir using sbuild, like sdebuild for pbuilder? Currently I "bzr builddeb -S" then "sbuild -A -d lucid ../*.dsc"
[20:24] <james_w> dunno
[20:24] <james_w> that's the way I use
[20:25] <blueyed> ok. not too bad - but this could be one step IMHO.
[20:26] <blueyed> What apt-caching mechanism are you using? I'm using apt-cacher-ng since a while, and it's really great to get the packages a lot faster when the first sbuild failed! :)
[20:27] <joaopinto> james_w, will you be proposing your patch to fix the FTFBS package ?
[20:30] <joaopinto> james_w, ah, it's already uploaded, thanks
[20:30] <joaopinto> james_w, any idea on how long it takes to get built/available on the repository
[20:30] <joaopinto> ?
[20:31] <james_w> joaopinto: it's already built for some architectures: https://edge.launchpad.net/ubuntu/+source/libuser/1:0.56.9.dfsg.1-1ubuntu3
[20:31] <james_w> it's in NEW though, so will need to be checked and allowed in
[20:32] <joaopinto> ok thanks
[21:20] <micahg> directhex: do you have a PPA for the latest moon/moonlight?
[21:21] <sebner> bdrung: don't forget to merge audacious-plugins or .. or ... or I'll file a bug! :P
[21:21] <bdrung> sebner: don't panic ;) i was away for three hours. this gave audacious enough time to build.
[21:22] <sebner> bdrung: right and br0ke on upgrade :P
[21:23] <bdrung> sebner: time will cure the wounds :P
[21:23] <directhex> micahg, nothing newer than in the archive. upstream's build system is painful enough without throwing svn snapshots into the mix
[21:23] <micahg> directhex: k, someone asked for  a moon PPA, so I thought I'd ask
[21:23]  * sebner hugs bdrung :)
[21:24] <micahg> directhex: did upstream have any idea what is causing xul192 to crash with gluezilla?
[21:24] <directhex> micahg, yeah, bad patch. i uploaded a fixed gluezilla earlier
[21:25] <micahg> directhex: really, awesome :)
[21:25]  * micahg will have to look
[21:49] <bdrung> sebner: uploaded
[21:51]  * sebner ^5 bdrung :)
[21:51]  * bdrung ^5 sebner.
[21:51] <bdrung> sebner: are you audacious user?
[21:52] <sebner> bdrung: from time to time, yes
[21:52] <bdrung> me, too
[21:52] <sebner> bdrung: my main player is banshee but for quick audio stuff I use audacious :)
[21:52] <bdrung> my main player is xmms2
[21:52] <sebner> heh
[21:53] <sebner> bdrung: any good?
[21:53] <bdrung> just look at my debian qa page ;)
[21:53] <bdrung> sebner: any good? what?
[21:53] <sebner> bdrung: xmms2
[21:54] <sebner> bdrung: gui gui giu
[21:54] <bdrung> sebner: i control it mainly with my remote control and use xmms2-notify
[21:55] <bdrung> sebner: lxmusic is quite promising. gxmms2 works (but doesn't look nice).
[21:55] <sebner> bdrung: any difference to audacious?
[21:56] <bdrung> gapless playback was my reason to switch.
[21:56] <bdrung> IIRC
[21:56] <sebner> ah Ic
[21:57] <bdrung> and: cover support for flac files
[21:57] <bdrung> xmms2-notify shows the covers embedded into the flac files
[21:57] <bdrung> sebner: you remind me that i want to package xmms2-notify
[21:58] <bdrung> damn, eclipse is still fucked up
[21:58] <ajmitch> how badly broken?
[21:58] <bdrung> some user have problems with xulrunner (freezing, etc)
[21:59] <bdrung> and i cannot reproduce it
[21:59] <sebner> bdrung: haha, glad to hear
[21:59] <bdrung> sebner: glad?
[21:59] <kliango> is it still possible to synch a universe packages with the appropriate version from unstable?
[21:59] <sebner> bdrung: that I could remind you of something
[21:59] <ajmitch> kliango: possible, depending on what changes there are
[22:00] <bdrung> sebner: aha, that wasn't the response to eclipse
[22:00] <sebner> bdrung: of course now! I will give eclipse a deeper test tomorrow, let's see if I can reproduce anythin
[22:00] <bdrung> kliango: bug fix sync: yes
[22:01] <kliango> is a bug report enough or is there a standard way for a request?
[22:01] <kliango> bdrung^^^
[22:02] <bdrung> kliango: a bug report is enough
[22:03] <bdrung> kliango: ping me and it will be fast processed
[22:10] <kliango> bdrung, thx, is this always possible or only until the release ?
[22:11] <bdrung> kliango: until some days before the release. after that point you have to follow the SRU process. then you will cherry-pick fixes instead of syncing a version.
[22:13] <kliango> bdrung, thx, i will do a rebuild to test everything works fine, then you will get an email
[22:14] <bdrung> kliango: email?
[22:14] <kliango> no?
[22:15] <bdrung> kliango: just paste the bug links here in irc
[22:24] <YokoZar> Is it still possible to do a sync request for a new version of a game?
[22:26] <simon-o> YokoZar, I don't think so. which game and version?
[22:27] <YokoZar> simon-o: Hedgewars made a new release and it's needed for online play (version 0.9.13) -- upstream says they were specifically targeting this release for Lucid too.
[22:28] <YokoZar> simon-o: I could make another upload myself but I'd prefer to just use the Debian package
[22:28] <bdrung> YokoZar: you need a FFe: https://wiki.ubuntu.com/FreezeExceptionProcess
[22:29] <YokoZar> bdrung: right right of course but would syncing be a good idea or would a normal upload just be the right solution
[22:29] <bdrung> YokoZar: syncing/merging is preferred over a normal upload
[22:30] <simon-o> YokoZar, see bug 555082. There's a discussion
[22:30] <YokoZar> bdrung: Right, but at this point we've been frozen for a good enough period of time I'm worried we've diverged
[22:30] <bdrung> YokoZar: make a diff of the debian directories and compare the sync to the normal upload
[22:31] <YokoZar> bdrung: I'll make sure the debian version works right and put it in the bug report and then mark it as a FFE request
[22:32] <bdrung> yes
[22:34] <jpds> micahg: Ping.
[22:34] <micahg> jpds: pong
[22:35] <jpds> micahg: Hi, any idea why xul-ext-noscript has been removed from the archive?
[22:35] <micahg> jpds: too fast of a moving target as they do a release about twice a month
[22:35] <jpds> micahg: Hmm, OK. Shame.
[22:36] <micahg> jpds: usually security fixes, so it really should be updated through -security often which is too problematicv
[22:36] <micahg> jpds: I've been using the version frmo addons.mozilla.org without issue for quite a whil;e
[22:36] <jpds> Would be nice if https://launchpad.net/ubuntu/lucid/+source/mozilla-noscript had such a message.
[22:37] <micahg> jpds: https://edge.launchpad.net/ubuntu/+source/mozilla-noscript/+changelog
[22:38] <jpds> micahg: Aha, hmm.
[22:38] <jpds> Thanks for the info.
[22:38] <micahg> jpds: we might do an extensions PPA at some point, that seems the only sane way to do it
[22:41] <joaopinto> is it acceptable for a package to generate/change an /etc file on it's postinst ?
[22:50] <Nafallo> micahg: do you know if adblock-plus will be dropped as a package as well?
[22:51] <bdrung> Nafallo: it will stay
[22:53] <Nafallo> interesting
[23:03] <sebp> hi, I tried to upload a package to my ppa, but if I run dput I get: Please select a .changes file to upload. Tried to upload: build
[23:03] <sebp> I provide the .changes file, though
[23:20] <domibel> hi, it would be nice if a motu could take care of bug #562609
[23:31] <blizzkid> Hi ppl, when packaging, in a control/rules file is it possible to have another package removed? "Conflicts" only indicates it conflicts apparently?
[23:32] <micahg> blizzkid: http://www.debian.org/doc/debian-policy/ch-relationships.html
[23:32] <bdrung> blizzkid: you want remove a package in debian/rules? it's possible to conflict with an package on build time.
[23:34] <blizzkid> bdrung: let me clarify: if I install eg wicd, it'll remove network-manager. Now if I install my-own-package, it has to remove some-other-packge. Is that done through "control" or through "rules"?
[23:34] <bdrung> blizzkid: in debian/control
[23:34] <bdrung> conflicts
[23:35] <blizzkid> bdrung: I guess automatic removal only works with apt-get/aptitude?
[23:35] <domibel> bdrung, please fast process 562609
[23:35] <bdrung> blizzkid: yes
[23:36] <blizzkid> ok, thx bdrung, will try adding it to my ppa then to test ;)
[23:36] <bdrung> blizzkid: already commented ;)
[23:37] <blizzkid> bdrung: what? *confused*
[23:37] <bdrung> domibel: already commented ;)
[23:38] <bdrung> blizzkid: the last message was for domibel
[23:38] <blizzkid> oh, ok :)
[23:38] <bdrung> it's too late -> my brain needs a rest
[23:39] <domibel> bdrung, thanks for taking care of this
[23:42] <bdrung> domibel: can you test a sync and tranform the bug in a sync request?
[23:45] <domibel> bdrung. a sync might break things, the provided patch is minimal and already included in unstable, i prefer the patch
[23:45] <bdrung> k
[23:46] <bdrung> domibel: but you have to add breaks & replaces, because you move a file from one package to another
[23:47] <quidnunc> Can someone confirm for me that ifhp doesn't show up in the repositories (e..g apt-cache search)
[23:49] <bdrung> quidnunc: confirmed
[23:50] <quidnunc> bdrung: Is that expected?
[23:50] <bdrung> quidnunc: https://launchpad.net/ubuntu/+source/ifhp
[23:51] <quidnunc> bdrung: What should I take away from that?
[23:52] <bdrung> quidnunc: you see that it should be in lucid and that it wasn't removed
[23:52] <bdrung> i am still confused
[23:56] <bdrung> quidnunc: you might ask this question in ubuntu-devel
[23:56] <quidnunc> bdrung: Will do, thanks.
[23:57] <bdrung> quidnunc: i have no explanation why it's missing