[01:35] <cpscotti1> bug 480772
[01:35] <cpscotti1> ping cpscotti
[01:36] <cpscotti1> (sorry)
[01:36] <cpscotti1> Hey, could anyone sponsor/judge/give a look the sru refered in bug 480772 ?
[02:59] <mhall119> quick question, if I have a package installed at qimo-desktop_2.0.0, and then one goes into the repos at qimo-desktop_2.0.0-ubuntu1, will that new package over-write the currently installed one?
[02:59] <ScottK> mhall119: Yes.
[02:59] <mhall119> awesome, thanks
[08:09] <dholbach> good morning
[08:10] <baddog_> mornin'
[08:29] <TheMuso> slytherin: Were you planning on doing the jack-audio-connection-kit merge? If not, I understand, and I'm happy to do it if you don't want to.
[08:29] <slytherin> TheMuso: I haven't yet setup maverick chroot. Busy with personal life. So please go ahead.
[08:32] <slytherin> TheMuso: Also since jack has moved to main, I do not have upload rights.
[09:36] <stefanlsd> nigelb: heys
[10:27] <eagles0513875> morning everybody
[11:33] <kaushal> hi
[11:33] <kaushal> is there a deb package available for 1.36 on Ubuntu hardy ?
[11:33] <kaushal> for libboost-dev
[11:36] <Rhonda> kaushal: Why do you want that?
[11:37] <Rhonda> No, it looks like hardy has only 1.34 of boost.
[11:38] <kaushal> yeah
[11:38] <kaushal> but scribe requires 1.36
[11:38] <kaushal> is there a ppa available for it ?
[11:38] <Rhonda> I fear that would be the killer point for a backport of scribe to hardy.
[11:40] <kaushal> Rhonda: is it available in backports ?
[11:44] <Rhonda> kaushal: If it requires boost 1.36 then I don't think so, that's what I meant by that statement. Sorry if that wasn't clear enough.
[13:08] <jetienne> dh_make -e jerome.etienne@gmail.com -p neoip-get_0.0.1 -s <- this prompt the user for confirmation, is there a way to prevent it ?
[13:13] <jetienne> yes | dh_make -e jerome.etienne@gmail.com -p neoip-get_0.0.1  <- this is the answer :)
[13:46] <jetienne> to sign package is required for ppa ?
[13:47] <jpds> Yes.
[13:50] <ricotz> Laney, fyi, it is been 3 weeks since the last stable docky release, so docky 2.0.4 bugfix-release is coming soon
[13:50] <Laney> oh
[13:50] <Laney> i totally dropped the ball on that sru
[13:52] <ricotz> Laney, would be nice if you keep on it, we are still getting bug reports for fixed ones regarding 2.0.2
[13:53] <Laney> yep eyp
[13:53] <Laney> yep*
[13:53] <ricotz> ok ;-)
[13:57] <mb__> hello
[13:57] <mb__> i have a quick packaging related question
[13:58] <mb__> i packaged a software with debhelper 7, but i want to be able to support debian lenny also
[13:58] <mb__> how do i handle the override_dh_ stuff so i can use it in lenny?
[14:00] <Laney> mb__: bpo has a sufficient version of debhelper
[14:00] <jetienne> https://help.launchpad.net/Packaging/PPA/Uploading <- say "Simply follow the instructions in the Uploading packages to this PPA section of your PPA overview page." but where is this page ?
[14:01] <mb__> Laney: i cannot rely on my users to use bpo :(
[14:01] <Laney> you expect your users to be building the package?
[14:04] <jetienne> ok trying pre-9.10 version of ppa uploading then
[14:05] <Laney> PPA support in #launchpad
[14:06] <BlackZ> when I do the modify of a debian package, (-0ubuntu1, for example), should I modify the mantainer's address?
[14:07] <tumbleweed> BlackZ: -0ubuntu1 isn't modification, it's a new upstream version bypassing debian
[14:08] <mb__> Laney: not really, i expect the to run it only, but if there were an easy way to support building, i'd like to include it
[14:08] <Laney> "enable the backports repo" :)
[14:08] <Laney> BlackZ, tumbleweed: It is, and yes you should
[15:33] <tarzeau> hello
[15:33] <tarzeau> does anyone have time to check a revu package?
[15:33] <cpscotti> tarzeau: I can't advocate but I can check if I see something wrong
[15:34] <cpscotti> which is the package?
[15:34] <tarzeau> cpscotti: http://revu.ubuntuwire.com/p/fracplanet
[15:34] <tarzeau> cpscotti: like i could also check other packages, and comment them?
[15:34] <tarzeau> does that help people that can advocate packages there?
[15:34] <cpscotti> yep..
[15:35] <cpscotti> sometimes you can stop a simple flaw quickier and thus everything gets faster
[15:35] <tarzeau> cpscotti: i see, well it's one of my first packages
[15:36] <tarzeau> if i can see some progress, commenting other packages, i'll continue using it
[15:36] <tarzeau> but for the moment revu feels like mentors.debian.net (like nothing happens)
[15:36] <cpscotti> for example, your changelog should link to a launchpad bug number
[15:36] <tarzeau> people find their sponsors elsewhere, certainly not there
[15:37] <tarzeau> cpscotti: i don't have a launchpad bug, i only got a debian itp bug
[15:37] <cpscotti> (and the bug should say something like "needs packaging"
[15:37] <cpscotti> maybe it would be cool to add one
[15:37] <tarzeau> i see, well either i'll automate changelogs of new packages for debian+ubuntu, or i just don't do new packages for ubuntu
[15:37] <tarzeau> but wait, ubuntu does NOT want people to do work twice
[15:37] <tarzeau> that's what they state on their webpages about package development help
[15:37] <cpscotti> if the package comes from debian
[15:38] <cpscotti> there is a slightly different procedure
[15:38] <cpscotti> seems you can only upload to debian
[15:38] <tarzeau> i think i just stay with debian, and get them in there
[15:38] <cpscotti> and then file a bug like "needs to fetch from debian"
[15:38] <tarzeau> yes but this can take quite some time
[15:38] <tarzeau> debian has some problem called "lack of sponsor time"
[15:38] <cpscotti> yehp.. I agree
[15:39] <cpscotti> to bypass this you can package it directly for ubuntu
[15:39] <tarzeau> i thought ubuntu was better in this part, since i've find quite a bunch of packages in there, not yet in debian
[15:39] <tarzeau> yeah but that sucks, since i'd have to create a different changelog
[15:39] <cpscotti> (yep.. seems to me that the community is more active
[15:39] <tarzeau> i got two debian sid boxes i create/test debian packages on
[15:39] <tarzeau> and i'll have to use another box to make new packages on ubuntu
[15:40] <tarzeau> doesn't for me, however i'd prefer ubuntu using/allowing debian itp bug closings/changelog entries
[15:40] <cpscotti> well.. probably there's more people here with specific knowledge on this debian/ubuntu thing
[15:40] <tarzeau> instead of wanting their own thing, just because it's NIH
[15:41] <tarzeau> when i look at the revu.ubuntuwire.com webpage, i can see multiple pages of uncommented, unadvocated packages
[15:41] <tarzeau> so it doesn't look much better than in debian
[15:41] <cpscotti> well.
[15:41] <cpscotti> when I had to pass my app through REVU it was pretty fast
[15:41] <cpscotti> and responsive
[15:41] <tarzeau> is revu also for upgrading existing packages?
[15:41] <Rhonda> tarzeau: how should lack of sponsor time be much better in ubuntu than in debian? are there more sponsors in ubuntu?
[15:41] <cpscotti> (indeed I had to make some noise here )
[15:42] <tarzeau> Rhonda: i had no idea, i just hoped so. but as your rhetorical question says, it's not the case
[15:42] <tarzeau> ok 3 more days, and i've got holidays :)
[15:43] <cpscotti> tarzeau: if you continue with the ubuntu packaging, another thing is to change "Maintainer: Gürkan Sengün.." to "Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>"
[15:44] <cpscotti> your name comes in "Original-Maintainer: Gürkan Sengün.."
[15:45] <tarzeau> cpscotti: i see, ok ok, you don't have to look any further
[15:45] <tarzeau> cpscotti: there's no script to convert between new debian package to new ubuntu package the debian/* part?
[15:46] <tarzeau> that'd make sense, actually i could write that script, but i'm not sure it's worth it
[15:46] <cpscotti> probably there IS such thing already
[15:46] <tarzeau> how would i find it?
[15:46] <tarzeau> iulian: ping
[15:47] <cpscotti> google.. :)
[15:57] <eagles0513875> hey guys i have a packaging question and im already looking at the guide if i want to make a package for the current version of kubuntu ill obviously need to repackage it according to the ubuntu conventions. but what if i want to package something for maverick then what?
[15:57] <eagles0513875> do i use a lucid environment to package for maverick or a maverick environment
[15:59] <bilalakhtar> eagles0513875: use a chroot for maverick
[16:00] <bilalakhtar> eagles0513875: to do this, use pbuilder
[16:00] <bilalakhtar> eagles0513875: ask others for more info on how to build packages for maverick in a chroot running on a lucid host
[16:00] <eagles0513875> bilalakhtar: isnt the packaging guide detailed enough to get the basic idea of how to do it
[16:01] <bilalakhtar> eagles0513875: use this guide https://wiki.ubuntu.com/PbuilderHowto
[16:01] <eagles0513875> bilalakhtar: ok im not quite ready to do any packaging but thanks
[16:36] <shadeslayer> hey,i have .install files in my debian/ folder , do i need to specify dh_install --sourcedir=debian/tmp seprately in debian/rules?
[16:41] <carstenh> shadeslayer: iirc only if you use an old debhelper version, dh 7 sets this option automatically, but man debhelper is less errorprone than random people in irc
[16:42] <shadeslayer> carstenh: i did see man dh_install but i was unsure whether or not i was required to put it in
[16:42] <carstenh> shadeslayer: man debhelper, search for V7
[16:42] <carstenh> ... by typing /V7enter
[16:43] <carstenh> and then n to skip the first hit
[16:43] <shadeslayer> carstenh: ah thanks :)
[17:12] <nigelb> stefanlsd: will you be free over the week to help me with documentation?
[17:25] <jetienne> this ppa stuff is not easy for a beginner :)
[17:25] <Ng> for an autofoo based project, would one expect to be doing the autogen.sh invocation as part of the build, or should that already be done in the creation of the upstream release? (I'm actually packaging something that has no release, from its git repo)
[17:26] <Laney> Ng: upstreams usually run `make dist' to create their tarball
[17:26] <Laney> which runs autogen.sh
[17:27] <Ng> Laney: k, ta
[17:28]  * Ng sitting outside with his laptop for the first time in forever, so it seems like an appropriate time to have a package of mbm-gpsd ;)
[17:57] <jetienne> q. is it possible to add comment in the control file ?
[18:01] <persia> tumbleweed: My apologies.  I hope you'll come back next week, and given the discussed new structure, it's likely you'll be significantly nearer the start of the meeting :)
[18:03] <tumbleweed> persia: np, I'll be there again in two weeks
[18:03] <tumbleweed> I had a feeling the agenda was full
[18:04] <tumbleweed> I don't have the strongest application, anyway :/
[18:07] <persia> tumbleweed: Well, with two more weeks, you have every opportunity to improve it :)
[18:07] <tumbleweed> heh yes
[18:16] <c_korn> jetienne: I think all lines beginning with # are comments
[18:16] <jetienne> c_korn: thx. indeed i found the answer meanwhile
[18:17] <jetienne>  this file may also contain comment lines starting with # without any preceding whitespace. <- http://www.debian.org/doc/debian-policy/ch-controlfields.html for a precise reference
[18:45] <jetienne> i got compilation running, even some linking :)
[18:52] <jetienne> it built!!!
[20:13] <randomaction> We normally don't SRU new upstream versions (from stable branch), do we?
[20:13] <andreserl> randomaction, SRU are minimal diff's which means only bugfixes
[20:13] <andreserl> randomaction, you can backport though
[20:14] <randomaction> In this case the delta between upstream versions is 5 bugfixes, 1 of them critical.
[20:15] <persia> We can SRU entire upstream versions if we want.
[20:16] <persia> But to avoid people claiming we're crazy, we usually drop the bit of the diff that actually updates the version number.
[20:16] <cpscotti> persia: lol
[20:16]  * Laney is about to prepare exactly such an SRU
[20:16] <Laney> …but was going to change the version number ;(
[20:17] <persia> Doesn't matter that much, but some end-users will complain whichever way you do it.
[20:18] <persia> Some people want "stability" and get worried when versions change.  Some people want "fresh" and get worried when versions don't change.  I believe the majority just want it to work and are glad for the fixes, but they don't seem to write as much email instructing us on how we should do things.
[20:18] <cpscotti> So.. in order to please the ones in favour of minimal bug fixes, can someone check the SRU in  bug 480772 ? It is as minimal as possible :)
[20:20] <cpscotti> persia: there are even the guys that although liking fresh & stable, when something breaks they just feel bad because they were not beta testers before...
[20:20] <cpscotti> like.... "its my fault"
[20:20] <cpscotti> hehe
[20:20] <persia> cpscotti: That's a nice clean small diff, but one also needs to take care to err on the side of being complete (I don't have enough background on that bug to know if it's correct from a quick glance)
[20:21] <cpscotti> persia:  what do you mean by "err"
[20:21] <persia> cpscotti: Those are wonderful users, to be treasured.  They are often willing to test, and help make sure it works.  In most cases, I've found they quickly learn to care more about "Does it work" than the version numbers.
[20:21] <cpscotti> Yup!
[20:22] <persia> cpscotti: err: (v) :
[20:23] <persia> to make a mistake or be incorrect; stray: wander from a direct course or at random
[20:23] <cpscotti> ahh ok
[20:24]  * persia suddenly wonders if erratrix is a valid word, although is unable to come up with an application in English due to unsexed nouns
[20:25] <Laney> Where are the UDD branches for SRUs?
[20:25] <Laney> ubuntu/$release-proposed/$package?
[20:26] <persia> I thought it was ubuntu/$release/$package
[20:26] <Laney> no pocket separation?
[20:26] <persia> But I can see the argument for it not being so.
[20:26] <Laney> -proposed doesn't work, so I'll just go with ""
[20:26]  * persia is relatively uninformed about UDD, so defers to someone more knowledgeable
[20:27]  * Laney wonders if this is even a good workflow
[20:27] <Laney> (merge from development, commit, fix up to be SRUable, push)
[20:28] <kklimonda> Laney: I've seen ubuntu/$release-proposed/$package linked to sru bugs but I couldn't push branch into lp:~login/ubuntu/$release-proposed/$package
[20:28] <Laney> james_w: can you advise?
[20:29] <james_w> kklimonda: you need to add a branch name at the end
[20:29] <james_w>  /sru-for-bug-12345 or something
[20:35] <kklimonda> james_w: will it be possible to push branches to lp:ubuntu/$pocket/$package in the future? and can I read somewhere about current plans for packaging branches and similar things? for example are you planning on dropping patching systems and doing all patching using vcs mechanisms? I can't find anything substantial about that and it's really interesting subject
[20:35] <james_w> kklimonda: you can push to lp:ubuntu/$pocket/$package if $package has already been uploaded to $pocket
[20:36] <james_w> allowing you to create it should be possible, would you file a bug against 'udd' please?
[20:36] <james_w> as for dropping patching systems, that's the long term goal, but it's not easy to get right, and a bunch of code has to be written to make it possible
[20:37] <kklimonda> james_w: but I still have to upload source package anyway, right? I still can't just push a branch to the lp:ubuntu/$pocket/$release and make LP build package from it?
[20:37] <james_w> not yet
[20:38] <persia> It's probably easier to make a Format: 3.0 (quilt) -> Format: 3.0 (bzr) translator, and just wait for the arrchive to transition.
[20:38] <james_w> that work is underway though
[20:38] <persia> Some things you can do with some of the patch systems aren't currently replicable in a VCS.
[20:39] <persia> (e.g. running sed as the first part of a dpatch prior to patch application, when the source filed against which sed is run is unknown, or produced by an earlier line in the dpatch)
[20:39] <kklimonda> huh, do you have an example of that? :)
[20:39] <persia> Not offhand, no.
[20:39] <kklimonda> or a better explanation - it sounds.. magical ;)
[20:40] <kklimonda> or maybe hacky is a better world
[20:40] <kklimonda> word*
[20:40] <persia> I know that one of the packages I touched back when I was adding .desktop files to evreything constructed a .png in a dpatch.
[20:40] <persia> (which .png is only available at build-time, and not visible at package-construction time (although it may have onece been)
[20:41] <kklimonda> but wouldn't it be the same as making the .png file in the debian/rules as a part of build process?
[20:41] <persia> No, because this was a CDBS package, and had no make entries in debian/rules
[20:41]  * persia has encountered any number of folk who package software and prefer to avoid using make syntax whenver possible.
[20:41] <ScottK> Also it'd be really nice to get Format 3.0 (bzr) accepted in Debian so we could be assured we wouldn't end up with two different versions of the format.
[20:42] <persia> I remember one case where someone wanted to use a shell script, and got stuck, and I sent them a patch to do it in deboian/rules, and they used this patch to determine how to do it in an external shell script.
[20:42] <kklimonda> persia: :D
[20:43] <kklimonda> I agree that Makefile syntax isn't the nicest one but still.. :)
[20:44] <persia> Right.  Anyway, for the awkward bits (like dpatch or odd source manipulation in the build rule, etc.), it's probably better not to try to abstract some way to turn that into VCS revisions.
[20:44] <persia> it's too easy to get wrong.  For the case where it's known how it works (e.g. 3.0 (quilt), it makes more sense.
[20:47] <Laney> If an SRU is essentially a backport from M, and a patchsys has been added, should this be kept or reverted to keep the changes "minimal"?
[20:48] <kklimonda> Laney: I'd keep changes minimal.
[20:49] <Laney> as it's a new upstream release, the diff isn't really 'minimal' anyway ;)
[20:49] <Laney> but I don't really mind
[21:09] <Guest22063> Hi all, I just got my package released into Debian sid and i would like to know the process to register it in Ubuntu
[21:09] <Guest22063> I understood it is automatic but I am not sure
[21:14] <geser> it's semi-automatic, an archive admin has to run a script
[21:14] <Guest22063> ok
[21:15] <Guest22063> Where do i have to ask about it? Is there a special bug repport?
[21:17] <Laney> you can file a sync request to make sure it gets done
[21:17] <Laney> !sync
[21:18] <Laney> http://dpaste.com/199146/ ← why does this talk about maverick? do I need to care?
[21:19] <Guest22063> Many thanks for those informations
[21:20] <james_w> Laney: nope
[21:20] <james_w> Laney: it's using the maverick branch's revision data where possible
[21:20] <Laney> oh, that's cool
[21:20] <Laney> thanks for the clarification
[21:20] <james_w> np
[21:20] <ScottK> Laney: There's really no need for a sync bug.
[21:21] <ScottK> Guest22063: Up until Debian Import Freeze, if it's in Debian it will get imported.
[21:21] <Laney> ScottK: For a NEW package, I believe they're not being processed regularly
[21:21] <ScottK> There's nothing you need to do.
[21:21] <ScottK> Laney: That's true, but they are still processed.  A sync bug is just pointless paperwork priori to DIF.
[21:22] <ScottK> Filing a sync request probably won't get it done any sooner.
[21:23] <Laney> I was under the impression that it would as the new-source list isn't being seriously done (I've seen Colin asking for pokes if folks care for specific NEW syncs), but I defer
[21:24] <ScottK> Laney: If it's specifically urgent for some reason, yes, but just to make sure it gets in it's absolutely not needed.
[21:24] <Laney> right
[21:26] <Guest22063> So I should not ask anything... I hope it will be import before the debian freeze....
[21:27] <Legendario> i'd like to ask why a package leaves the repositories. Can anyone tell me the policy for that?
[21:30] <geser> in most cases when it's unmaintained and too buggy
[21:35] <ajmitch_> morning
[21:37] <Laney> ricotz: we still need test cases for this sru
[21:37] <Laney> i've done the packaging part
[21:45] <cpscotti> Another potential SRU (I believe it is ready.. but you all know how things are..) : bug 480772 ; A User app that is unusable, fix is minimum and regarding parameters to a gcc call.
[21:48] <ScottK> Legendario: If there is a specific package you have questions about we can help you find the reason it was removed.
[21:52] <ajmitch_> cpscotti: why is it marked as fix released in lucid?
[21:53] <cpscotti> ajmitch_:  well.. I meant "the fix itself" is there.. attached.. for lucid-proposed
[21:53] <ajmitch_> fix released is only for when it's hit -updates, it'll be overlooked otherwise :)
[21:53] <cpscotti> oh.. sorry
[21:54] <cpscotti> ajmitch_: I misunderstood whats written on the sru page then
[21:54] <cpscotti> did u change it?
[21:54] <cpscotti> (should I?)
[21:54] <ajmitch_> I just changed to in progress
[21:54] <cpscotti> thanx
[21:54] <ajmitch_> which may not be right, but it'll show up on bug searches :)
[21:55] <ajmitch> has it been fixed in maverick?
[21:55] <cpscotti> yes
[21:55] <ajmitch> great
[21:55] <cpscotti> but maverick is using the next upstream version
[21:55] <cpscotti> the attached debdiff aims at being totally minimal
[21:55] <ajmitch> thanks, that'll help it get SRU approval
[21:56] <cpscotti> I believe I included all the descriptions/test case there... let me know if there is something missing
[21:56] <ajmitch> I'm not in the SRU team, but I'll subscribe them
[21:57] <cpscotti> ok
[21:57] <ajmitch> I see you're part of upstream for it?
[21:57] <cpscotti> yes
[22:04] <Laney> did we agree on a suffix for fakesyncs?
[22:04] <Laney> fakesync1 wasn't it?
[22:06] <imbrandon> afternoon all
[22:07] <ari-tczew> Laney: XfakesyncY is alive, why not?
[22:07] <Laney> is "alive"? I was just wondering what the result of the recent discussion was.
[22:08] <ari-tczew> ubuntu-devel has discussed this question since February, IIRC
[22:09] <ari-tczew> Laney: have you got any objections cosidering to fakesync versioning?
[22:10] <Laney> no, I just want to know what to use for the one I'm about to upload :)
[22:10] <geser> IIRC the discussion calmed down without any decision
[22:11] <ari-tczew> I remember that we have discussion in February/March about it with bdrung and sebner and they prefer to use XfakesyncY
[22:11]  * sebner shows up
[22:11] <sebner> TADAAAAAAAAAAAAA
[22:11] <sebner> ari-tczew: full ack
[22:11]  * sebner waves at geser and Laney :D
[22:11] <Laney> hello
[22:12] <ari-tczew> e.g. https://launchpad.net/ubuntu/+source/polkit-qt-1/0.95.1-1fakesync1
[22:13] <ajmitch> sebner: shall we hide now?
[22:13] <jpds> sebner: tada.mav*
[22:13] <jpds> wav*
[22:13]  * sebner prepares rotten tomatoes for ajmitch :P
[22:13] <sebner> jpds: :)
[22:14] <ajmitch> sebner: you make me feel so welcome
[22:15] <Laney> if only they were fresh ones you could make a lovely soup :(
[22:15]  * sebner reigns with fear and terror!
[22:15] <sebner> Laney: I don't like tomatoe soup :D
[22:16]  * ajmitch wishes this lucid ISO would just download faster
[22:16] <Laney> subject: [ubuntu/maverick] agda-stdlib 0.3-3fakesync (Accepted)
[22:16] <Laney> tada
[22:16] <Laney> (.wav)
[22:16] <sebner> Laney: fakesync1?
[22:16] <Laney> nein
[22:16] <ajmitch> fakesyncs are so ugly
[22:16] <Laney> there can not be more than one fakesync
[22:16] <sebner> Laney: rebuild of a fakesync :P
[22:17] <Laney> +build1!
[22:17] <ari-tczew> Laney: no
[22:17] <sebner> Laney: nope, not for fakesyncs
[22:17] <ajmitch> +reallynoimeanthistime
[22:17] <Laney> what?
[22:17] <sebner> Laney: 1fakesync1 -> rebuild -> 1fakesync2
[22:17] <ari-tczew> if md5sum of ubuntu's  tarball is not the same as md5sum debian's tarball, then you should use Xfakesync1
[22:17] <Laney> 1fakesync -> rebuild -> 1fakesync+build1
[22:18] <sebner> Laney: nope
[22:18] <ari-tczew> +1 sebner ^^
[22:18] <ajmitch> sebner: 0.3-3fakesync can be renumbered to have a a number on the end anyway
[22:18] <Laney> why am I being noped?
[22:18] <Laney> it really matters very little
[22:18] <sebner> Laney: because you are wrong
[22:18] <sebner> Laney: policy! ftw
[22:18] <sebner> even if he don't have an official one xD
[22:18] <Laney> show me this policy
[22:18] <sebner> ^_^
[22:18]  * Laney rolleyes
[22:18] <geser> sebner: http://googlethis.blogs.linkbucks.com/files/2009/05/attack_of_the_killer_tomatoes.jpg :)
[22:19] <sebner> geser: lol :D
[22:19]  * ajmitch gets back to doing a messy merge stuff, tomatoes would be nice
[22:20] <sebner> Laney: grep the mail discussion from February about it. We finished it, it's just not official (yet)
[22:20] <ajmitch> because everyone loves version numbers like 1.4.0~git20100322.dfsg.2-4ubuntu1
[22:21]  * geser waits for the first upload of -Xfakesync1ubuntu1build1 :)
[22:21]  * sebner prepares loads of rotten tomatoes for that person!
[22:21] <ajmitch> gah, 37MB orig.tar.gz
[22:21]  * ajmitch does not want to have to upload this
[22:21] <sebner> ajmitch: I'm feeling with you
[22:22] <ari-tczew> geser: maybe -+nmuXfakesync1ubuntu1build1-10.04 :>
[22:22] <geser> ajmitch: be lucky not to have merge texlive-extra
[22:22] <ajmitch> I'll upload from a VPS which can fetch the orig.tar.gz
[22:22] <ajmitch> geser: that one is 150MB or more?
[22:22] <geser> 494 575,9 kB
[22:22] <ajmitch> ...
[22:22] <ajmitch> ok, you win
[22:23]  * sebner thinks pulseaudio has the longest versionsstrings in the archive
[22:23] <sebner> 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu15
[22:23] <sebner> ftw!
[22:23] <ajmitch> ugly
[22:23] <sebner> think about he possibilities when adding -Xfakesync+ rebuild :D
[22:24]  * ajmitch is not going to fakesync heimdal
[22:24] <Laney> I don't see many possibilities
[22:24] <sebner> Laney: add git versioning too :D
[22:25] <Laney> s'alright, there will be no fakesync next time
[22:26] <ajmitch> Laney: we'll just blame the debian maintainer then :)
[22:26] <Laney> blame the Ubuntu uploader
[22:26] <Laney> …same person :'(
[22:26]  * ajmitch had seen that
[22:27] <ajmitch> but didn't you upload to ubuntu first & get the debian upload sponsored?
[22:27] <Laney> yes
[22:27] <Laney> actually, you're right
[22:27] <Laney> Joachim failed to use pristine-tar correctly!
[22:27]  * Laney celebrates
[22:27] <ajmitch> heh
[22:27]  * sebner facepalms
[22:29] <Laney> something wrong?
[22:35] <Legendario> ScottK, envyng-gtk
[22:42] <geser> Legendario: "superseded by jockey" (topmost entry at https://edge.launchpad.net/ubuntu/+source/envyng-gtk/+publishinghistory)
[22:45] <ScottK> geser: Thanks.
[22:45] <ScottK> As long as only rebuilds are being done, there's no reaon not to just increment fakesyncX
[22:45] <Legendario> geser, the problem is that sometimes jockey doesn't recognize the video card
[22:46] <Legendario> and we can force the installation by using envyng
[22:46]  * sebner full acks with ScottK :D
[22:48] <ScottK> Legendario: Then file bugs against jockey so it can be fixed.
[22:49] <kklimonda> Legendario: envy has never been a solution but a hack. in Lucid, due to changes made to the drivers infrastructure in Ubuntu it was no longer possible to support it.
[22:50] <kklimonda> and the right approach is to fix jockey as ScottK suggested :)
[23:26] <Legendario> kklimonda, i am asking that because a friend told me he wasn't been able to install it from jockey. So I told him to do it through envy but it wasn't in the repos anymore. I don't know about this driver change but besides it being a hack, it used to work pretty well on this cases
[23:28] <imbrandon> Legendario: i would file a bug as to why it dident work, as Canonical hired the author of Envy some time back just to make sure it did work
[23:28] <Sarvatt> Legendario: what situation does jockey not recognize the video card? that should only happen if the person was silly enough to remove the modaliases (like say with a sudo apt-get purge nvidia*)
[23:49] <Legendario> Sarvatt, imbrandon, i dont know what happened but what he reported me was that it was an install or update. I don't know. I just wondered what made the package go away. But this kind of problem already happened to me. Although it was a long time ago
[23:49] <Sarvatt> it's pretty common for people to sudo apt-get purge nvidia* which screws up jockey unfortunately :(
[23:50] <Sarvatt> i'm sure thats what happened