[00:15] <warp10> albert23: FYI, I have just requested the sync for enthought-traits. Please, go ahead with enthought-traits-ui at your will.
[00:16] <albert23> warp10: ok, good to know. I will look at e-t-u tomorrow.
[00:16] <warp10> albert23: great, thank you. :)
[02:03] <ScottK> freeflying: Welcome back.
[02:21] <freeflying> ScottK: thanks :)
[03:35] <grantgm> i'm having some problems packaging a python package that has a compiled module...is this the right place to ask for help?
[03:38] <ScottK> Yes
[03:39] <ScottK> But not from me, I'm heading out for a while.
[03:39] <grantgm> ok, thanks
[03:41] <grantgm> the compiled module is built with a simple makefile, which seems to build, but dpkg-buildpackage errors out: "unrepresentable changes to source"
[03:42] <persia> grantgm: Can you pastebin your debian/rules and your buildlog?
[03:44] <grantgm> debian/rules: http://pastebin.ca/1045660
[03:45] <grantgm> output: http://pastebin.ca/1045662
[03:46] <grantgm> debian/control: http://pastebin.ca/1045664
[03:47] <grantgm> persia: would anything else be helpful?
[03:47] <persia> No.  That's sufficient.
[03:48] <grantgm> ok. thanks a lot having a look
[03:48] <grantgm> *for having
[03:48] <persia> To me, it appears the issue is that you have build it once in the tree, and your clean isn't deleting the generated files.
[03:55] <grantgm> you're right: it appears that the makefile isn't cleaning the files built in the test directory
[04:38] <tonyyarusso> Say, I need to test certain packages from -proposed, but don't want to upgrade everything.  I know I could enable it, upgrade the one package, then disable the repo again, but could someone tell me how to properly say "only upgrade packages foo, bar from -proposed, all else use these other repos" ?
[04:38] <ajmitch> apt pinning
[04:39] <ajmitch> 'man apt_preferences' says it better than I can sum up
[04:40] <persia> http://wiki.debian.org/AptPinning is also a good reference
[04:55] <wgrant> Sigh. Why do applications like Banshee feel they need to reimplement GTK?
[04:56] <ajmitch> are you referring to the custom widgets & the human theme?
[04:56] <wgrant> Yes.
[04:56] <persia> wgrant: Remember.  Newer is better.
[04:56] <wgrant> They seem to reimplement GTK's ListView for the sole purpose of combining selection bubbles.
[04:57] <wgrant> And it's about the slowest UI I've ever seen.
[04:57] <ajmitch> it's a microvell conspiracy
[04:58] <wgrant> Ah, and there's some strange effect on the play queue when you add something to it.
[04:58] <wgrant> I'm sure GTK could be altered to do that without rewriting the whole thing in ridiculously slow Cairo.
[05:10] <RAOF> wgrant: You obviously need a better video driver :)
[05:10]  * RAOF also agrees with gtk reimplemenation bitching.
[05:11] <wgrant> RAOF: It's an i915. It runs Compiz fine.
[05:12] <wgrant> But it can't render a *media player*'s interface quickly.
[05:12] <RAOF> That's because intel doesn't have a nice XRender backend (yet).
[05:13] <RAOF> No one accelerates EXA well.  Except nouveau.
[05:13] <persia> RAOF: Does nouveau display a normal desktop well yet?
[05:13] <RAOF> persia: Yes.  It has done for _ages_.
[05:13] <wgrant> Yes.
[05:13] <wgrant> I use it at work.
[05:14] <wgrant> It's rather nice, as long as you don't want Compiz.
[05:14] <persia> Then why isn't it in the repos yet?
[05:14] <wgrant> The multimonitor is infinitely better than the blob.
[05:14] <RAOF> Because I'd need to break libdrm to do it.
[05:14] <RAOF> wgrant: Oh, _hell yes_.
[05:14]  * persia can't use compiz anyway, because compiz + cairo + nVidia binary blob + old graphics card = extra heat
[05:14] <wgrant> RAOF: How's 3D coming along?
[05:15] <persia> RAOF: What's the bad part about breaking libdrm?
[05:15] <RAOF> persia: It's at the bottom of the X stack.
[05:15] <wgrant> RAOF: NVIDIA does it, no?
[05:15] <ajmitch> the nvidia blob doesn't use libdrm
[05:15] <RAOF> wgrant: Break libdrm?  No.  They just ignore it.
[05:15] <wgrant> Right.
[05:15] <RAOF> Like they ignore _every other_ piece of X infrastructure.
[05:15] <RAOF> :(
[05:16] <RAOF> Elisa no longer segfaults.  It now doesn't display any video, but it does'nt segfault.
[05:17]  * ajmitch wonders when we'll see kernel modesetting in mainline
[05:17] <wgrant> Fedora's testing it, right?
[05:18] <persia> From what I can find, Fedora seems to so some rough equivalent of dpkg-divert for the alternate libdrm
[05:18] <persia> s/so/do/
[05:18] <RAOF> nouveau is sitting in Debian experimental NEW, too.
[05:19] <RAOF> If libdrm gets a release that supports it before FF, I'll totally be syncing stuff accross.
[05:20] <persia> RAOF: Is my understanding correct that nouveau_libdrm can support most things, as long as the user is using nouveau, and only breaks things for other people?
[05:20] <RAOF> persia: Actually, it shouldn't break anything.  But it's a git snapshot of a lib at the base of the X stack, so I'm not interested in pushing it to Intrepid.
[05:21] <wgrant> RAOF: So it's just new, not Nouveau-specific?
[05:21] <persia> RAOF: Hrm.  OK.
[05:21] <RAOF> wgrant: Correct.
[05:21] <persia> Do the PPA packages work cleanly?
[05:21] <ajmitch> does it assume different kernel interfaces as well?
[05:21] <RAOF> persia: Yup.
[05:22] <RAOF> ajmitch: No.  It provides the kernel interfaces.
[05:22] <ajmitch> I can't recall if you can mix & match old drm modules & a new libdrm
[05:22]  * persia encourages RAOF's intrepidation, especially the bit about fearless audacity.  Finding out if the latest git snapshot works is what Alpha releases were designed to do :)
[05:22] <RAOF> I don't think you can.  Or, rather, you can't build nouveau against an old libdrm.
[05:23] <ajmitch> RAOF: right, that was more my point with it, seeing what else would have to be updated to bleeding edge snapshots :)
[05:24] <RAOF> ajmitch: Just libdrm.
[05:26] <ajmitch> how's the work with gallium progressing?
[05:26] <RAOF> If people _really_ want, I'll ask for a sync/merge of experimental's libdrm, ask to add the kernel module to linux-ubuntu-modules, and sync xserver-xorg-video-nouvea.
[05:26]  * ajmitch may hold off from upgrading for awhile 
[05:27] <ajmitch> I like having a working system
[05:27] <RAOF> Gallium exists.  It doesn't work nearly well enough for anyone who cares about 3d.
[05:27]  * wgrant might upgrade to Intrepid after the calculus exam tomorrow.
[05:28] <RAOF> Although there's now a XvMC state tracker in git.  That'll be cool.
[05:28] <wgrant> What does that do?
[05:28] <persia> RAOF: How likely is an upstream release in the next couple months?  If we're likely to switch for intrepid anyway, maybe better to start wider testing sooner (although this ought be discussed in #ubuntu-devel, as libdrm is fairly core)
[05:30] <RAOF> persia: I really have no idea.  Upstream may wait until the great gpu-memory-manager wars are resolved before releaseing, in which case that's an indeterminate period.
[05:30] <persia> RAOF: Ah.  Hrm.
[05:31] <wgrant> Who are the contenders in that battle?
[05:33] <RAOF> TTM and GEM.
[05:34] <wgrant> Never heard of the latter.
[05:34] <RAOF> Keith P did GEM for the intel driver.
[05:35] <wgrant> Why must one conquer the other?
[05:35] <RAOF> Because people don't want to support two gpu memory manager interfaces in the kernel indefinately.
[05:36] <wgrant> Ah.
[05:36]  * ajmitch thought that TTM originated with intel
[05:37] <RAOF> It did.  A different group, I think.
[05:37] <ajmitch> Ah, that makes it fun :)
[05:38]  * persia despairs over the inconvenience of attempting to handshake with one left hand and one right hand
[05:38] <RAOF> For bonus points, neither has really been used for !intel hardware yet.
[05:38] <wgrant> persia: Why would one attempt that?
[05:39] <persia> wgrant: When the left hand and the right hand have been properly introduced, it is easier for them to thereafter collaborate...
[05:39] <ajmitch> RAOF: right, and I understand that memory management can be done quite differentlly on other cards
[05:39] <RAOF> ajmitch: Very much so.  I think that new ATI and nVidia have fully virtualised gpu-memory, for example.
[06:59] <dholbach> good morning
[07:00] <TiMiDo> hey anyone in here can help me?
[07:01] <persia> TiMiDo: Depends on the task with which you need help
[07:02] <TiMiDo> persia: im making  a packaged but im getting this error
[07:02] <TiMiDo> Source archive you specified ( ../mdk-1.2.4 ) was not found!
[07:02] <TiMiDo> i'm in the dir.. and i'm doing it.. but i'm getting that error
[07:02] <persia> TiMiDo: You'll need to supply a little more context.  Would you pastebin the relevant log?
[07:02] <TiMiDo> okey
[07:03] <TiMiDo> http://pastebin.ca/1045760
[07:03] <TiMiDo> there it is persia
[07:03] <devfil> doko: ping
[07:04] <persia> TiMiDo: And does ../mdk-1.2.4 exist?
[07:04] <TiMiDo> yes it does
[07:04] <TiMiDo> i'm in that dir
[07:05] <TiMiDo> but im getting that error any ideas persia ?
[07:05] <persia> Right.  I dislike dh_make enough to have never used it.  Anyone else familiar?
[07:07] <devfil> TiMiDo: use dh_make -e farias.aaron@gmail.com with no ../mdk-1.2.4
[07:07] <devfil> if you are in the dir of sources ../mdk-1.2.4 is not needed
[07:07] <TiMiDo> Could not find mdk_1.2.4.orig.tar.gz
[07:07] <TiMiDo> Either specify an alternate file to use with -f,
[07:07] <TiMiDo> or add --createorig to create one.
[07:08] <devfil> TiMiDo: il .. of sources paste the orig of the sources, it is needed to use dh_make
[07:08] <TiMiDo> ?
[07:08] <devfil> s/il/in/
[07:09] <TiMiDo> sorry i'm confused
[07:09] <devfil> TiMiDo: compress orginal sources to tar.gz and rename it to mdk_1.2.4.orig.tar.gz
[07:10] <devfil> move this file in the .. of the sources, your ~/debian/
[07:10] <devfil> and then use dh_make
[07:10] <TiMiDo> okey dne
[07:11] <devfil> persia: why you dislike dh_make?
[07:11] <TiMiDo> Skipping creating ../mdk_1.2.4.orig.tar.gz because it already exists
[07:11] <TiMiDo> Done. Please edit the files in the debian/ subdirectory now. mdk
[07:11] <TiMiDo> uses a configure script, so you probably don't have to edit the Makefil
[07:12] <devfil> TiMiDo: now edit the debian dir as you want to make a working package
[07:12] <TiMiDo> devfil: can you help me a little I'm totally a newbie on this =)
[07:13] <persia> devfil: Because I don't like some of the defaults, and I find it annoying to delete all the examples.  Generally, I find I want to create debian/rules and debian/copyright from scratch.  debian/changelog is dch --create.  debian/control is the only benefit I see to dh_make, and it's not really that hard to type.
[07:14] <devfil> TiMiDo: you should start reading this http://www.debian.org/doc/maint-guide/
[07:14] <TiMiDo> devfil: i've read it =)
[07:14] <TiMiDo> i just need some help
[07:15] <devfil> TiMiDo: what exactly?
[07:15] <TiMiDo> on what dirs do i ut?
[07:15] <TiMiDo> *put
[07:16] <devfil> TiMiDo: in dir you should put dirs that will be created in the package
[07:17] <TiMiDo> okey but what locations do i put it?
[07:17] <TiMiDo> there's two .... dirs names on it
[07:17] <RAOF> You almost certainly don't need anything in debian/dirs
[07:18] <TiMiDo> okey so after that what do  i do?
[07:20] <RAOF> TiMiDo: Come back in here.
[07:21] <TiMiDo> okey
[07:21] <RAOF> What is it that you actually want to do?
[07:21] <TiMiDo> RAOF: create a packaged =) for my first time
[07:21] <RAOF> You're trying to package mdk 1.2.4, I guess?
[07:21] <TiMiDo> yes RAOF
[07:22] <RAOF> And you've read https://wiki.ubuntu.com/PackagingGuide ?
[07:23] <RAOF> The files in debain/ are basically divided into metadata and the debian/rules file which is a makefile that actually does the building.
[07:23] <TiMiDo> yeah i did
[07:24] <TiMiDo> RAOF: i'm lost in the debian/rules part =)
[07:24] <RAOF> Right.  So, debian/rules is a makefile with a couple of mandatory targets and a couple of optional targets.
[07:24] <RAOF> How familiar are you with makefiles?
[07:25] <TiMiDo> Well.. i'm new on that also =)
[07:25] <TiMiDo> never had make a Makefile myself =)
[07:26] <persia> siretart: congratulations
[07:27] <\sh> Without knowing how to write makefiles, you life is miserable and you can't enjoy your evening times...
[07:27] <\sh> Makefiles make the world go round...do a makefile a day ;)
[07:27] <RAOF> Right.  You might want to read a make manual, but it's not totally necessary to do the basics.  The unindented lines with colons, like "build: " are targets.  That's what gets called when you do "debian/rules build"
[07:27] <RAOF> The things after the target name are dependencies, so "build: configure" will run the configure: target before running build:
[07:28] <RAOF> The tab-indented lines are then what gets actually _run_.  Each line gets passed to a (different) shell, and executed.
[07:29] <TiMiDo> damn I'm so freaking lost =*(
[07:30] <RAOF> Right.
[07:30] <RAOF> So, probably playing around with some makefiles is a good idea.
[07:31] <devfil> persia: do you know what an universe contributor do?
[07:31] <TiMiDo> RAOF: is there any tutorials on makefiles?
[07:31] <persia> devfil: How do you mean?
[07:32] <RAOF> TiMiDo: Google gives me http://www.gnu.org/software/make/manual/make.html , which is a not unreasonable introduction.
[07:32] <persia> In general, the universe contributors (including MOTU) do the majority of the work in maintaining the packages in universe.
[07:32] <TiMiDo> hmm okey?
[07:33] <RAOF> TiMiDo: It's also somewhat tailored towards building C programs, but that's GNU for you :)
[07:33] <TiMiDo> oh ic
[07:33] <devfil> persia: not MOTU, only universe contributors. What are the differences between a normal user that help (as me) and an universe contributor?
[07:33] <RAOF> TiMiDo: Just section 2 should give a reasonable overview.
[07:33] <lifeless> RAOF: actually, thats posix
[07:33] <lifeless> RAOF: but YMMV
[07:34] <persia> devfil: Mostly just a history of contributions.  Being an official Universe Contributor includes Ubuntu Membership, so one can use an @ubuntu.com email address and be on planet, etc.
[07:34] <RAOF> lifeless: I was thinking about autotools particularly in this case.  Which is great if you're using something sufficiently C like.
[07:35] <devfil> persia: so a user choices to be universe contributor or ubuntu member
[07:36] <lifeless> RAOF: ah fair enough.
[07:38] <persia> devfil: It's not a choice, really.  Being a universe contributor is one of the ways that one can become an Ubuntu Member.
[07:39] <devfil> persia: ok, so become universe contributor is not needed to become in future MOTU
[07:40] <persia> devfil: They are different things.
[07:41] <persia> Universe Contributors are recognised for their contributions within the Ubuntu development community, and gain membership through this recognition.  MOTU are responsible for overseeing all contributors (recognised or not) to the Ubuntu universe component, and have geen granted the right to upload without review.
[07:41] <persia> Every MOTU is a Universe Contributor, but not every Universe Contributor is MOTU.
[07:42] <lifeless> devfil: universe contributor is just 'those who contribute'
[07:42] <devfil> ok, thanks for the reply :)
[07:42] <lifeless> devfil: 'motu' is those responsible for reviewing contributions and ensuring quality etc
[07:43] <persia> lifeless: Well, a little more than that; there's an application process for Ubuntu Contributing Developers to get recognised and gain the benefits of membership now.
[07:43] <lifeless> persia: still
[07:43] <lifeless> persia: if you strip away the beaucracy ...
[07:43] <persia> lifeless: Well, yes :)
[07:43] <devfil> lifeless: yes, I know. I did understand reading the wiki that become universe contributor is a step needed to become MOTU, but I was wrong :)
[07:44] <lifeless> d
[07:45] <persia> devfil: It's very definitely not a step required on the way to MOTU.  Many people qualify for Universe Contributor before they qualify for MOTU, but lots of people became MOTU directly.
[07:46] <lifeless> I would say, its impossible to _qualify_ for MOTU without also _qualifying_ for UC
[07:47] <persia> lifeless: That's certainly true.
[07:48] <lifeless> devfil: so when you are ready to be a MOTU, apply for that
[07:48] <lifeless> devfil: and if you aren't yet, you might be ready to be a UC
[07:49] <devfil> lifeless: I'm ubuntu member, so I think is not necessary for me to become UC
[07:49] <lifeless> devfil: no, not at all
[07:58] <emgent> morning
[07:58] <devfil> hi emgent :)
[07:58] <emgent> devfil: :)
[08:09] <TiMiDo> devfil: after i created it the rules what do i do now/
[08:10] <RAOF> TiMiDo: You've got some idea of what a makefile looks like now?  Good.
[08:10] <devfil> TiMiDo: did you put build depends on debian/control?
[08:10] <TiMiDo> devfil: nope
[08:11] <devfil> TiMiDo: in debian/control, in the build-depends field you must put the dependencies needed to build the source
[08:11] <devfil> Ti
[08:12] <TiMiDo> devfil: yeah done
[08:12] <TiMiDo> now what?
[08:12] <devfil> TiMiDo: in depends of the package you must put dependencies needed to run the package
[08:12] <devfil> depends field
[08:12] <RAOF> devfil: Except, in most cases, these should be automatically generated.
[08:13] <devfil> RAOF: in most cases
[08:14] <devfil> TiMiDo: now you should try to build the package, to see if it works
[08:14] <RAOF> TiMiDo: So, here's one of those places where you need to know something about the thing you're packaging :)
[08:17] <TiMiDo> devfil: how do i build the package?
[08:17] <RAOF> Running "debian/rules binary" should work, but most people will use dpkg-buildpackage or debuild.
[08:18] <TiMiDo> dpkg-buildpackage: set CFLAGS to default value: -g -O2
[08:18] <TiMiDo> dpkg-buildpackage: set CPPFLAGS to default value:
[08:18] <TiMiDo> dpkg-buildpackage: set LDFLAGS to default value:
[08:18] <TiMiDo> dpkg-buildpackage: set FFLAGS to default value: -g -O2
[08:18] <TiMiDo> dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
[08:18] <TiMiDo> tail: cannot open `debian/changelog' for reading: No such file or directory
[08:18] <TiMiDo> dpkg-buildpackage: failure: tail of debian/changelog gave error exit status 1
[08:18]  * persia strongly recommends running `debuild -S` before building any binaries, to avoid confusion.
[08:18] <TiMiDo> oh ic =)
[08:19] <devfil> TiMiDo: you can use pbuilder, but I think is better if you use debuild binary, debuild binary shows you during build in the sources dir all the file generated ecc...
[08:19] <devfil> you can see if you did a good rules or not
[08:20] <TiMiDo> i got an error
[08:20] <TiMiDo> let http://pastebin.ca/1045802
[08:21] <TiMiDo> that's the error
[08:21] <devfil> TiMiDo: you should install build depends on your pc before use debuild binary
[08:21] <devfil> s/should/must/
[08:21] <TiMiDo> devfil: look read the error that what i've got
[08:22] <TiMiDo> did i do something wrong
[08:22] <TiMiDo> ?
[08:22] <RAOF> TiMiDo: That error's OK; it's only about signing your packages.  You can ignore it for now.
[08:22] <TiMiDo> okey RAOF now the package is ready?
[08:23] <RAOF> Now you have a source package.
[08:23] <RAOF> Readiness is a different metric :)
[08:23] <TiMiDo> oh okey cool =)
[08:23] <TiMiDo> now what? do i do with it?
[08:24] <RAOF> Well, build it, generally.  Does it build?
[08:24] <RAOF> debuild -us -uc will try to build it, without signing.
[08:24] <TiMiDo> as root?
[08:25] <RAOF> No.
[08:26] <TiMiDo> http://pastebin.ca/1045805
[08:26] <TiMiDo> now i got thatt error =)
[08:27] <RAOF> So, you need to install cdbs
[08:27] <RAOF> "Unmet build dependencies: cdbs" is the important line.
[08:28] <TiMiDo> how do i installed cdbs?
[08:28] <devfil> TiMiDo: try again to build
[08:28] <RAOF> Same way you'd install any other package?
[08:28] <RAOF> Generally, I'd 'sudo aptitude install cdbs', but synaptic, apt-get, packagekit... all these and more are your options ;)
[08:29] <devfil> TiMiDo: sudo apt-get install cdbs
[08:29] <TiMiDo> okey
[08:29] <TiMiDo> is building
[08:31] <TiMiDo> nice done =)
[08:31] <TiMiDo> and now how do i put it up?
[08:32] <RAOF> Put it up where?
[08:32] <TiMiDo> on launchpadn
[08:32] <RAOF> You mean, in a PPA?
[08:33] <TiMiDo> yeah
[08:33] <TiMiDo> so people can download my package
[08:33] <RAOF> Well, for that I'd suggest looking at the PPA-quickstart guide, linked to from your PPA page.
[08:34] <TiMiDo> oh ic
[08:35] <TiMiDo> RAOF: if i want to put it on ubuntu
[08:35] <TiMiDo> ?
[08:36] <RAOF> Then you want to upload the source package to revu.  You'll want to make sure that running 'lintian -iI' on the .changes file doesn't list any problems.
[08:37] <RAOF> You'll also want to check out https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#NewPackage
[08:40] <RAOF> https://wiki.ubuntu.com/MOTU/Packages/REVU is the link to revu howto.
[09:41] <siretart> persia: thanks. let's see how good things will work out with me
[09:48] <\sh> go siretart go :)
[09:48] <mbudde> I'm having problems building a package with pbuilder, is this the right place to ask for help?
[09:49] <huats> mbudde: I thinnk so..
[09:49] <huats> fire away
[09:49] <huats> siretart: congrats !
[09:50] <mbudde> ok, I'm trying to build enblend from hardy repos but pbuilder fails: http://paste2.org/p/38383  I have successfully build the hello package so i guess it has something to do with the dependencies?
[10:05] <theseinfeld> !search *
[10:09] <sistpoty|work> hi folks
[10:09] <theseinfeld> howdy ho
[10:41] <mbudde> I solved my problem, "sudo pbuilder update --other-mirror ... --override-config" did the job
[12:40] <\sh> http://www.sourcecode.de/content/launchpad-desktop-integration
[12:40] <\sh> get hot new stuff now :)
[12:42] <emgent> woow
[12:42] <emgent> nice :)
[12:43] <emgent> \sh: alpha is avaiable ?
[12:43] <\sh> emgent: not now...I'll push the stuff on LP the next few days...when some functionality is there :)
[12:44] <emgent> cool :)
[12:44] <devfil> \sh: very nice
[12:44] <emgent> \sh: gnome version too (GTK and not QT) will be avaiable? :)
[12:45] <\sh> emgent: the plan is to provide several frontends :)
[12:46] <\sh> emgent: lp-desk -kde / lp-desk -gnome or something like this
[12:46] <emgent> cool, very good idea :)
[12:46] <\sh> like ubiquity...one backend, several frontends
[12:49] <\sh> emgent: right now, it was just a practive with new pyqt4/pykde4 love...:)
[12:49] <emgent> hehehe ok :)
[12:49] <\sh> practice even :)
[13:08] <ScottK> Does it seem priority inversion to anyone else that "He was also recommended by Launchpad developers" is a significant qualification for our LP liaison?
[13:09] <ScottK> Usually customers are by definition credible with their service providers.
[13:09] <ScottK> siretart: Congratulations.
[13:46] <\sh> ScottK: *g*
[13:57] <lukehasnoname> Hey, simple bug fix for you guys, 238427
[13:57] <lukehasnoname> Hey, simple bug fix for you guys, #238427
[13:57] <ScottK> Where is the Universe SRU verification process documented?
[13:58] <ScottK> Bug #238427
[13:58] <lukehasnoname> <_<
[14:01] <DktrKranz2> ScottK: https://wiki.ubuntu.com/StableReleaseUpdates?action=show&redirect=SRU#head-4f8a5c972c2b7f429e32535b806e78d34275d84d or https://wiki.ubuntu.com/QATeam/PerformingSRUVerification
[14:02] <ScottK> DktrKranz2: Those don't actually say HOW to do verification for Universe.
[14:03] <ScottK> How many people need to test?
[14:03] <ScottK> What's the aging requirement?
[14:03] <ScottK> Etc.
[14:03] <ScottK> Unless I miss it....
[14:03] <DktrKranz2> ScottK: there's no difference, AFAIK. And aging requirement is just an archive admin task
[14:03] <DktrKranz2> aging period is described here: https://wiki.ubuntu.com/ArchiveAdministration#head-1f27dc12ab1558ec21b31ac44e4c86a87a4cd053
[14:04] <ScottK> It used to be that it took any 2 positive reports for Universe SRUs, but Main SRUs had to be verified from the SRU verification team.
[14:06] <ScottK> DktrKranz2: Is there any point in community feedback with the current process?
[14:06] <sistpoty|work> DktrKranz2, ScottK: how about bug 220910... should I tag this as verification-done, as it was tested by the original reporter?
[14:06] <ScottK> sistpoty|work: Apparently we aren't on the right team for that.  We can say it's OK to upload, but aren't allowed to have an opinion on if it works.
[14:07] <DktrKranz2> ScottK: it used to, but some times ago we merged two policy, leaving to sru verification to check for open sru candidates (bdmurray clarified everyone can join in, not only canonical employees)
[14:07] <DktrKranz2> I asked to join to look at uni/multiverse SRUs
[14:07] <ScottK> DktrKranz2: Currently, as written, there is no requirement or even request for user testing of proposed packages.
[14:08] <ScottK> Current process says, "he SRU verification team may also discover that your fix is good."
[14:08] <ScottK> Dear DktrKranz2, please discover that the fix for Bug #226845 is good.
[14:09] <DktrKranz2> do you want to bring back "2 works for me" rule?
[14:11] <DktrKranz2> or do we want more sru-verification guys?
[14:12] <ScottK> I think at the very least we ought to actually ask, in the process, for input from users of the packages.
[14:13] <ScottK> I think 2 works for me is good for Universe as it's not reasonable to expect SRU verification team members to be intimately familiar with all the packages in Universe
[14:13] <ScottK> I'd suggest 2 worksforme and motu-sru to do verification of Universe/Multiverse SRUs.
[14:14] <DktrKranz2> Well, sometimes archive-admins copy packages to -updates even if bugs lack sru-verification input if there are people who declare fix is good, so this could be a good point
[14:14] <ScottK> So we aren't even following the process as written now.
[14:14] <DktrKranz2> exactly
[14:14] <sistpoty|work> I wouldn't make it too strict for small fixes, to be more aligned with main (e.g. for my main sru, I was the only person who tested the .deb from proposed, and pitti still marked it as verification-done :))
[14:15]  * ScottK nods.
[14:15] <ScottK> DktrKranz2: Following the current process, would you please mark Bug #226845 verified.  I just tested it and it works.
[14:16] <ScottK> I also marked in the bug.
[14:16] <DktrKranz2> ScottK: I can't find it in the mirrors, I'll wget it from LP, just a sec...
[14:17] <ScottK> Odd.  It was on mine.
[14:17] <ScottK> Ah well.
[14:19] <DktrKranz2> mh, italy is lazy sometimes :)
[14:20] <leleobhz> ive fixed this bitebug https://bugs.launchpad.net/ubuntu/+source/kphone/+bug/238192
[14:20] <leleobhz> have something to do now?
[14:21] <DktrKranz2> ScottK: during motu-sru meeting, we should talk about SRU process as well, maybe we can have some exceptions for Universe (e.g. bugfix releases)
[14:22] <ScottK> DktrKranz2: OK.
[14:22] <ScottK> We could make the formal process change as simple as "For Universe/Multiverse packages, motu-sru is the SRU verification team."
[14:23] <DktrKranz2> or restore community feedbacks as verification
[14:27] <DktrKranz2> ScottK: I'll need to redo my VM, It will take me a bit, I'll check in a hour.
[14:27] <ScottK> DktrKranz2: No rush.
[14:28] <ScottK> DktrKranz2: I think using community feedback would be a detail of how motu-sru would do it.  I don't think we'd need to disturb the formal process definition for that.
[14:29] <DktrKranz2> so, if motu-sru is fine, we tag bug as verification-done
[14:31] <ScottK> Yes.
[14:31] <DktrKranz2> Sounds good
[14:32] <DktrKranz2> ScottK: have you time to review a merge for main?
[14:35] <ScottK> DktrKranz2: Not just now.  Give me the bug and I'll get to it later today if I can.
[14:37] <DktrKranz2> ScottK: bug 226783.
[14:37] <DktrKranz2> d'oh!
[14:37] <ScottK> DktrKranz2: Not scons.  I don't think I want ot touch that.
[14:38] <ScottK> ot/to
[14:38] <DktrKranz2> ok, thanks anyway
[14:49] <DktrKranz2> ScottK: FTY, amavisd-new-milter verification done :)
[14:50] <ScottK> DktrKranz2: Thanks.
[14:50] <DktrKranz2> *FYI
[14:50] <leleobhz> someone can tellme what i need to do with this? https://bugs.launchpad.net/ubuntu/+source/kphone/+bug/238192
[14:52] <sistpoty|work> leleobhz: subscribe ubuntu-universe-sponsors, and please set the state back to confirmed (or triaged), as fix released means that a fixed package is available in the archive.
[14:52] <siretart> \sh: huats_: ScottK: thanks. Still thinking about my opening email.
[14:53] <leleobhz> sistpoty|work: oh, ok.
[14:53] <leleobhz> sistpoty|work: and send the bug link into maillist?
[14:53] <sistpoty|work> leleobhz: no, subscribing ubuntu-universe-sponsors is enough so that it appears in the teams worklist
[14:54] <leleobhz> sistpoty|work: so, only revert to confirmed and wait?
[14:55] <sistpoty|work> leleobhz: yes
[14:56] <sistpoty|work> leleobhz: and subscribe ubuntu-universe-sponsors of course (left hand side, "subscribe someone else" link on the bug page)
[14:57] <leleobhz> sistpoty|work: done ;]
[14:58] <leleobhz> sistpoty|work: thanks!
[14:58] <sistpoty|work> np ;)
[14:59] <leleobhz> sistpoty|work: ive corrected some problems in uniconvertor, its now wait-and-see?
[15:00] <sistpoty|work> leleobhz: yes
[15:11] <sistpoty|work> persia: btw.: where did you find the sistpoty@stud.uni-erlangen.de address? did I miss to update s.th. (don't have that address any longer, as I'm no student any longer *g*)
[15:28] <Koon> When two packages conflict with each other, should the "Conflicts:" line be added to just one of the packages ? Or both ?
[15:29] <ScottK> It depends.
[15:31] <Koon> ScottK: in which cases would you need to have Conflicts: in both control files ?
[15:32] <Koon> ScottK: or is it just good practice ?
[15:32] <ScottK> It depends.
[15:32] <ScottK> One common use of conflicts is to force removal of an obsolete package when a new package replaces it.
[15:32] <ScottK> In that case adding it to the old package is not needed.
[15:33] <Koon> ScottK: in this case it's two library-dev packages providing the same .a file
[15:33] <ScottK> Koon: What exact problem are you trying to solve?
[15:33] <ScottK> Ah
[15:33] <ScottK> Does the file provide the same functionality?
[15:34] <Koon> ScottK: I would say, not exactly.
[15:35] <Koon> cgilib and libcgi-dev both provide /usr/lib/libcgi.a
[15:35] <Koon> this was fixed in Debian by adding a Conflicts: line to cgilib
[15:35] <Koon> and fixed in Ubuntu by adding a Conflicts: line to libcgi
[15:35] <ScottK> sistpoty|work: ^^^ What do you think?
[15:36] <ScottK> I take it they are separate source packages?
[15:36] <theseinfeld> siretart, you there?
[15:36] <Koon> Yes. When I merged libcgi, I carried on the delta since it wasn't fixed in the deb one. But now I am not sure it's really needed
[15:36] <sistpoty|work> ScottK, Koon: if there is a duplicate file in both, add a conflicts to both source packages
[15:36] <sistpoty|work> erm... binary packages that conflict
[15:37] <siretart> theseinfeld: no, I'm gone. please leave a message after the beep. *BEEP*
[15:37] <ScottK> If they could be considered alternatives, then update-alternatives might be appropriate.
[15:37] <Koon> sistpoty|work: ok, it's in both binary packages that conflict (in Ubuntu).
[15:38] <theseinfeld> siretart, ok, I was just wondering if we can talk live about that libdc1394 packaging thing...out...
[15:38] <sistpoty|work> ScottK: no, you don't really want alternatives for static libraries... that would just feel somewhat wrong to me
[15:38] <sistpoty|work> Koon: that's good :)
[15:38] <ScottK> OK.
[15:38] <Koon> siretart: about bug 239275, you asked me to report the issue in Debian...
[15:38] <sistpoty|work> ScottK: at least I very much doubt there is a use case to have both static libraries installed at the same time
[15:39] <ScottK> It sounds like we are in good shape then.
[15:39] <Koon> siretart: in fact the issue has already been fixed in Debian (bugs #303326 and #462944) by adding a "Conflicts:" line in cgilib
[15:39] <Koon> siretart: but not in libcgi (for libcgi-dev)
[15:40] <siretart> Koon: well, then lets fix that! :) - is there already a bug for that?
[15:41] <siretart> theseinfeld: sure, what's up?
[15:41] <Koon> siretart: posting it right now
[15:41] <sistpoty|work> congrats siretart btw for the launchpad-liason job ;)
[15:44] <theseinfeld> siretart just emailed you also
[15:44] <theseinfeld> siretart, well, like said in the email, I would like to see that work in ubuntu
[15:44] <theseinfeld> siretart, and I will work it out also with debian
[15:45] <theseinfeld> siretart: with guus, for getting him on board :)
[15:47] <siretart> theseinfeld: I'm currently focused on something else, but anyways. I'm happy to hear that you want to work with guus. from my own experience I know that bugs are the easiest way to keep track of issues that need to be fixed
[15:48] <siretart> theseinfeld: therefore I'd like to kindly ask you (again) to file whishlist bugs in debian so that guus can comment on them
[15:48] <theseinfeld> siretart, well, guus knows about the issues. That is why I forked out from debian
[15:49] <ScottK> theseinfeld: If you want progress, file the bugs.
[15:50] <siretart> theseinfeld: forking a package here means duplicating work. I'd like to avoid that if there are no compelling reasons to do so.
[15:50] <siretart> and I still don't see these reasons here
[15:50] <Hobbsee> neither does he want the reasons here, he wants them in a bug report.
[15:50] <siretart> theseinfeld: see, the worst what can happen is that guus decides to close the bug with the tag 'wontfix'. even if that happens, you still ahve a bugnumber to point to
[15:51] <siretart> and the patch and its context will be available for ANY contributor (debian and ubuntu developer) to look at and comment.
[15:51] <theseinfeld> siretart I'll do that
[15:51] <siretart> thanks
[15:51] <theseinfeld> siretart when you say to fill the bug, you mean in Debian, right?
[15:53] <lukehasnoname> I'd venture a yes on that, theseinfeld
[15:54] <siretart> theseinfeld: exactly. the tool 'reportbug' makes this pretty straightforward! (but please make sure to read its documentation first)
[15:57] <theseinfeld> siretart, i have been using that before... don't worry, I will do that... thanks
[16:01] <Koon> siretart: that would be Debian bug #485951 -- let me know if you need anything more from me.
[16:15] <leleobhz> https://bugs.launchpad.net/ubuntu/+source/kaffeine/+bug/209534
[16:16] <leleobhz> what is "
[16:16] <leleobhz> what is "
[16:16] <leleobhz> Accepted into hardy-proposed, please test.
[16:16] <leleobhz> (sorry)
[16:16] <brandon|work> I think the topic needs some updating
[16:16] <brandon|work> today != wednesday
[16:17] <leleobhz> tells the bug already fixed?
[16:18] <geser> leleobhz: hardy-proposed has a fixed package which will be copied to hardy-updates if it fixes the problem and doesn't introduce new one (that the testing which is asked for).
[16:19] <geser> usually such bugs should have a TEST CASE with steps to reproduce the problem but it seems to be missing here
[16:20] <leleobhz> geser: ummmm...
[16:20] <leleobhz> geser: thanks my explanation
[16:21] <leleobhz> RainCT: why the CTCP version?
[16:21]  * leleobhz a little paranoic these days because a ctcp flood
[16:22] <RainCT> leleobhz: heh dunno.. I like CTCP :P. Nice message, by the way :)
[16:23] <leleobhz> RainCT: yesterday a guy was banned from ubuntu-br because this... he sent ctcp version to all channel members more than once
[16:24]  * RainCT only send one to you :P
[16:24] <RainCT> (because of the double «what is "», I was curious if that might be evil irssi messing up with copy-pastes -that happened to me more than once-)
[16:26] <leleobhz> a bug into hardware between chair and monitor :]
[16:27] <lukehasnoname> PEBKAC FTL
[16:27] <RainCT> LOL
[16:28] <leleobhz> :p
[16:28] <RainCT> and it even exists (wtf pebkac) o_O
[16:28] <leleobhz> lukehasnoname: PEBMAC ;]
[16:28] <leleobhz> http://en.wikipedia.org/wiki/PEBKAC
[16:29] <RainCT> nice :)
[16:32] <lukehasnoname> While things are quiet... http://xkcd.com/225/
[16:32] <lukehasnoname> haha
[16:33] <leleobhz> :p
[16:33] <leleobhz> lukehasnoname: nice
[16:45] <SpookyET> hi
[16:45] <SpookyET> I have just started to use PPA, and it only allows me to make packages for intrepid. What do I have to do to enable hardy?
[16:46] <leleobhz> SpookyET: set hardy on debian/changelog?
[16:46] <SpookyET> leleobhz: it's set. but it changed it to intrepid
[16:46] <leleobhz> (!)
[16:47] <SpookyET> ppa changed it automagically
[16:48] <cprov-out> SpookyET: how your dput.cf target looks like ? Are you using incoming = ~name/ubuntu/intrepid ?
[16:51] <SpookyET> just  ~name/ubuntu/
[16:52] <Derevko> I opened a new Bug #239484 , but at this moment I don't understand if the correct status is "In progress" or "Fix Committed"
[16:52] <cprov-out> SpookyET: uhm, what's your ppa url ?
[16:53] <SpookyET> cprov-out: my nickname
[16:53] <SpookyET> ~spookyet
[16:54] <SpookyET> I proably did something stupid. I'm coming from Arch Linux. Making debs is a million times more complicated than pacman packages. I'm trying it again.
[16:55] <cprov-out> SpookyET: nano-syntax (1:20080502-0ubuntu1~ppa2) intrepid; urgency=low
[16:55] <SpookyET> dch -i put intrepid
[16:56] <SpookyET> cprov-out: it's a cool package. gives nano syntax highlighting
[16:56] <Pici> Nano already has syntax hilighting though...
[16:56] <huats_> does anyone has seen nxvl lately ?
[16:57] <mathiaz> huats_: he was around yesterday
[16:57] <huats_> mathiaz: ok thanks.. I haven't seen him :)
[16:57] <huats_> thanks :)
[16:58] <mathiaz> huats_: he's busy these days - he tends to be around during his evenings
[16:58] <huats_> mathiaz: thanks
[16:59] <SpookyET> Pici: custom package with better and more syntaxes
[16:59] <Pici> SpookyET: Ah, I see.
[16:59] <SpookyET> maybe I should change the actual nano
[17:02] <SpookyET> There is a huge thread in the gentoo forums. People chipped in their syntaxes
[17:03] <ScottK> Derevko: If you are working on the package, including uploading to REVU, then In Progress.  Fix committed is for after a MOTU uploads it for archive admin final review.
[17:04] <Derevko> ScottK: ok, thanks
[17:09] <SpookyET> What's the proper way to version date based packages?
[17:09] <SpookyET> i've seen 1:20080506-0ubuntu1   also 2008-05-06-0ubuntu1 a bunch of ways
[17:14] <geser> SpookyET: something like 0.0.20080506-0ubuntu1 has the advantage that you don't get troubles if upstream changes the versioning to the usual scheme
[17:16] <SpookyET> emacs-snapshot has 1:date-1ubuntu1
[17:21] <geser> SpookyET: the 1: is the epoch and shouldn't be used unless necessary (e.g. upstream changed the versioning scheme and the new versions have a lower version than the old ones)
[17:21] <geser> Hi bddebian!!!
[17:22] <bddebian> Heya gang
[17:22] <bddebian> Hi geser
[17:25] <sistpoty|work> hi bddebian
[17:25] <bddebian> Heya sistpoty|work
[18:20]  * sistpoty|work heads home... cya
[18:23] <rulus> If someone has time, bug 239501 is looking for a sponsor. :)
[18:36] <persia> ScottK: DktrKranz2: As a reminder, universe SRU policy is set by MOTU SRU, subject to confirmation at a MOTU Meeting.  If you don't like the current docs, please discuss within the team, and propose new ones.
[18:37] <ScottK> persia: I must have missed that meeting.
[18:37] <ScottK> persia: Will do.
[18:37] <persia> That said, it's best to coordinate with the testing folks (#ubuntu-testing) to align processes and avoid confusion.
[18:37] <persia> ScottK: I'll dig up the minutes...
[18:39] <persia> https://wiki.ubuntu.com/MOTU/Meetings/2007-11-23 is the closest I find.  I was expecting to find minutes for a 7th December meeting with the confirmation, but they appear to be missing.
[18:40] <persia> No, the meeting on the 7th was me whining inconclusively about interdiff
[18:44] <persia> DktrKranz2: I found https://lists.ubuntu.com/archives/ubuntu-motu/2007-December/002965.html, but I can't find the minutes of the relevant MOTU SRU meeting.  Do you have a pointer?
[18:45] <persia> DktrKranz2: Nevermind.  ScottK already asked :)  http://irclogs.ubuntu.com/2007/12/15/%23ubuntu-meeting.txt
[18:46] <persia> ScottK: On review, I find that the policy set by MOTU SRU isn't subject to approval by MOTU Meeting, except insofar as MOTU Meeting has delegated the policy to MOTU SRU, and would be able to revoke such delegation (although I don't imagine this idea would get much traction)
[18:48] <ScottK> persia: I suspect that if we reviewed it, we'd find that MOTU SRU was delegated the responsibilty to execute policy, not to create it.
[18:48] <persia> ScottK: Do you mean by TB or by MOTU Meeting?
[18:49] <ScottK> MOTU meeting.
[18:49] <ScottK> The minutes say they'll document rationale for variance from Main, but that's it.
[18:49] <persia> My memory (and those minutes) indicate that MOTU SRU was to review and establish policy, documenting where it differed from policy for main.
[18:50] <ScottK> I see review in the minutes.  I don't see establish.
[18:50] <persia> The log of the following MOTU SRU meeting covering those topics seemed to cover the policy in some detail.
[18:50] <ScottK> Yes, but without authority to actually set policy, that's out of scope.
[18:50] <persia> ScottK: That may be a secretarial error on my part.  I'll dig a bit deeper.
[18:51] <ScottK> OK.
[18:52] <persia> ScottK: No, the minutes are correct.  I asked that motu sru review the then existing policy, and explain differences from main.
[18:53] <persia> It appears TB delegated MOTU SRU to MOTU generally.
[18:53] <persia> MOTU delegated membership appointment to MOTU Council, and asked for MOTU SRU to explain policy.
[18:53] <persia> TO change policy, we ought to have had a MOTU Meeting (which didn't happen).
[18:53] <ScottK> I hate to be a stickler, but I think policy/process changes are important.
[18:53] <ScottK> Agreed.
[18:54] <persia> I'd like to encourage someone from MOTU SRU to propose a sane policy (and provide the requested documentation) at an upcoming MOTU Meeting after the MOTU SRU organisational meeting.
[18:54] <persia> ScottK: No, thank you for the correction.  Policy is essential if we are to be a happy polity.  It's better to get it right than to ignore it.
[18:55] <ScottK> Sounds reasonable.
[18:55] <ScottK> DktrKranz2, jdong, TheMuso ^^^
[18:56] <persia> \sh: ^^
[18:57] <ScottK> Right.
[18:57] <ScottK> I knew I forgot one.
[18:57] <persia> Cody too, but he's not actively idling
[18:57] <ScottK> Thanks.
[18:58] <ScottK> Yes.  I did check for him.
[19:18] <sebner> ScottK: your beloved LP will have downtimes on 3 days xD
[19:33] <bobbo> gjkfjngkjjgj
[19:34] <Pici> I object.
[19:38] <norsetto> howdy dowdy
[19:38] <devfil> hi norsetto :)
[19:39] <norsetto> heya devfil
[19:41] <slytherin> geser: ping
[19:42] <norsetto> is it me, or LP is even slower than its usual snailpace?
[19:42] <ScottK> It's slower.
[19:42] <slytherin> norsetto: bug pages are slower, if you are using edge
[19:43] <geser> slytherin: pong
[19:43] <slytherin> geser: you keep forgetting about advocating xml-commons-external. :-(
[19:44] <norsetto> oh well, at least I'm still not getting timeouts ...
[19:45] <geser> slytherin: argh :(
[19:47] <norsetto> ah! Why did I say that: Sorry, there was a problem connecting to the Launchpad server.
[19:53] <SpookyET> Can one link me to a tutorial on how to use PPA's bzr? I'd like to store packages in bzr. Idealy, only "debian" folders. Do you use +junk?
[19:53] <ScottK> SpookyET: For PPA questions, #launchpad is a better channel.
[20:06] <jussi01> could someone point me to the page that has the info on how to backport a package?
[20:10] <ScottK> !Backports | jussi01
[20:12] <jussi01> ScottK: thanks - is it worth my while doing the quassel one?? or has someone else done it already?
[20:12] <ScottK> jussi01: You'd have to look.  I don't recall seeing it.
[20:12] <jussi01> ScottK: you have a bad memory :D you did comment on it to give ack ;)
[20:13] <ScottK> OK.
[20:13] <ScottK> Then it's just waiting for an archive admin to process it.
[20:13] <jussi01> ok, so theres nothing I can do to speed it along?
[20:14] <ScottK> If you want to harrass Riddell about it, up to you.  pitti generally does them on Fridays, so I'd suggest just leave it be.
[20:14] <jussi01> ScottK: fyi bug 239165
[20:15] <gpolo> is there something I could do try to gain some attention regarding a bug report (more like a wish) ?
[20:19] <gpolo> this one specifically: https://bugs.launchpad.net/ubuntu/+source/python-stdlib-extensions/+bug/231239
[20:19] <ScottK> jussi01: One useful addition to that bug would be the exact version and revision that you want backported.
[20:20] <jussi01> ScottK: ahh, thank you - I had forgotten about that
[20:22] <ScottK> gpolo: I think you are correct that 8.5 needs to get promoted first.
[20:23] <ScottK> gpolo: You could start that process.  That should help move it along.  See https://wiki.ubuntu.com/MainInclusionProcess for details.
[20:24] <gpolo> ah, good to know
[20:24] <gpolo> too bad I can't look at it right now then, will do it later tomorrow. Thanks ;)
[20:25] <gpolo> but it really looks like there would be no problem on moving tcl/tk 8.5 to main
[20:30] <ScottK> I would guess it almost certainly just needs the paperwork done.
[20:31] <jussi01> ScottK: Riddell just did it :D
[20:32] <ScottK> jussi01: Great.
[20:40] <slytherin> geser: leaving now. see you on saturday. :-)
[20:46] <DRebellion> Could someone spare a moment to take a look at my package in REVU? http://revu.tauware.de/details.py?package=monkeystudio . Thanks :)
[20:51] <leleobhz> DRebellion: fixed all stuff rainct said?
[20:53] <DRebellion> leleobhz, yep
[20:53] <leleobhz> DRebellion: lintian is ok too?
[20:54] <DRebellion> leleobhz, yep
[20:54] <DRebellion> leleobhz, apart from the fact that it complains about "intrepid" not being recognized in the changelog file
[20:54] <DRebellion> leleobhz, but i guess that's expected
[20:54] <DRebellion> (running hardy)
[20:54] <RainCT> yep, Hardy's lintian doesn't know intrepid
[20:55] <leleobhz> if you really cares about this, use a chrooted system
[20:55] <leleobhz> DRebellion: its a kde app?
[20:55] <DRebellion> leleobhz, i used pbuilder for the build test
[20:55] <leleobhz> DRebellion: nice
[20:56] <ScottK> DRebellion: Use the devscripts in hardy-backports and it won't complain any more.
[20:56] <DRebellion> ScottK, ok
[20:57] <DRebellion> leleobhz, it's a qt4 ide
[20:57] <leleobhz> DRebellion: thinked about use CDBS?
[20:58] <DRebellion> leleobhz, not really. This is my first package (you can probably tell from the numerous revisions)
[20:59] <leleobhz> i dont see errors... but i if i be you, start to think use cdbs
[20:59] <leleobhz> a example
[20:59] <DRebellion> leleobhz, I will check it out for my next package then.
[20:59] <leleobhz> http://cdbs.ueberalles.net/kolabadmin.html
[21:02] <leleobhz> DRebellion: see how much its cleaner than make it by hands (and avoid mistakes)
[21:02] <geser> ScottK: how will devscripts from hardy-backports stop complaining lintian about intrepid?
[21:03] <ScottK> geser: Maybe that was the wrong package.
[21:03] <ScottK> Lintian I guess.
[21:04] <norsetto> I always thought that packages in -proposed should have a number < than that in the development distro !?
[21:04] <geser> but using devscripts from hardy-backports should hurt either
[21:04] <ScottK> DRebellion: I think I meant to say lintian, not devscripts.  But getting devscripts from backports is good too.  That one has dch -i will default to Intrepid.
[21:04] <ScottK> norsetto: That's generally true.
[21:05] <norsetto> ScottK: when would that be not true?
[21:05] <geser> gnome updates perhaps
[21:06] <ScottK> When the new repo wasn't open yet and we did SRU work that would be forward ported later or for a package that's been removed in the development version.
[21:06] <ScottK> That might be another where they pushed it to -proposed/updates first.
[21:07] <norsetto> scottk, geser: well, the package I'm looking at right now doesn't fit the bill, even though being a restricted-driver could explain it?
[21:07] <ScottK> Is it the envng one?
[21:07] <norsetto> ScottK: yes
[21:07] <ScottK> envy-ng
[21:08] <ScottK> Since the whole point of that package is to provide new NV driver crack to released versions, I think it's fine.
[21:14] <mario_limonciell> norsetto, amd and nv crack are changing for intrepid anyhow fairly drastically
[21:14] <devfil> someone have an amd64 with a virtual machine to test a "particolar" package?
[21:14] <norsetto> mario_limonciell: and we get already requests for 8.6 :-)
[21:14] <mario_limonciell> geez
[21:15] <mario_limonciell> well at least starting with intrepid they'll be more feasible to fullfill
[21:15] <RainCT> leleobhz: by the way, it looks like debhelper 8 will bring a lot of improvement for debian/rules
[21:16] <leleobhz> RainCT: really nice!
[21:16] <RainCT> leleobhz: I've seen dh8 rules files in Debian that look nearly as nice as CDBS ones :)
[21:16] <leleobhz> i only think may it come with more cdbs documentation
[21:16] <leleobhz> RainCT: :]
[21:17] <leleobhz> RainCT: cleaner packages, less work, easiest bugfixes
[21:17] <leleobhz> very nice
[21:17] <mario_limonciell> RainCT, got a good example of a dh8 package?
[21:17]  * leleobhz smashing our head with handbrake package
[21:17] <mario_limonciell> oh noes, that crack again :)
[21:19] <RainCT> *dh8 -> dh7
[21:23] <RainCT> mario_limonciell: http://svn.debian.org/wsvn/python-modules/packages/python-dsv/trunk/debian/rules?op=file&rev=0&sc=0
[21:23] <mario_limonciell> wow
[21:23] <mario_limonciell> that is very nice
[21:23] <mario_limonciell> that feels quite like cdbs
[21:24] <devfil> someone have an amd64 with a virtual machine to test a package?
[21:25] <ScottK> mario_limonciell: That's by design.  I think the title of the feature was "CDBS Killer".
[21:29] <mario_limonciell> well why is there the negative PR that surrounds CDBS in the first place?
[21:31] <norsetto> mario_limonciell: we should go back to use ar ...
[21:32] <nxvl> asac: ping
[21:33] <mario_limonciell> norsetto, haha.
[21:35] <RainCT> by the way, what happened with the proposal to compress package info (not sure how it's called, the stuff that 'apt-get/aptitude update' downloads)?
[21:40] <rulus> I think bug 239501 is a candidate for a SRU for Hardy. There are no bugs filed in LP except the merge bug, should I apply the SRU procedure (nominating, updating bug description) on that bug?
[21:40] <cyberix> What can a packager expect from the default system?
[21:41] <rulus> oops, sorry for the flood cyberix ;)
[21:41] <cyberix> Should each package have a dependency chain down to a linux-package?
[21:41] <ScottK> rulus: Why do you think it should go into Hardy?
[21:42] <ScottK> cyberix: No.  You can assume essential packages are installed and build-essential is available when you build the package.
[21:42] <rulus> ScottK: it's a tiny bugfix that makes the output of the program readable again; the current version in Hardy displays wrong thinks like javascript excerpts etc.
[21:42]  * ScottK looks
[21:42] <cyberix> I was just told that perl is not among such packages
[21:43] <cyberix> Iirc each Ubuntu system has perl
[21:43] <cyberix> That is why I'm confused
[21:43] <rulus> ScottK: because of the same reason, the graphical interface is currently broken
[21:43] <ScottK> rulus: Do you use this pacakge?
[21:43] <ScottK> cyberix: You have to depend on perl if you need it.
[21:44] <rulus> ScottK: personally, no, I'm developing a better program to do this (with a decent front-end)
[21:44] <rulus> (which is not in the archive yet)
[21:44] <ScottK> Since it's multiverse and no user has complained, I'd suggest leave it for now.
[21:45] <rulus> ScottK: ok, sure
[21:45] <ScottK> rulus: You will find Perl in all the standard Ubuntu installs, but since it's not an essential package, you can't assume it's there.
[21:45] <cyberix> ScottK: Yes, but how should I know that?
[21:45] <ScottK> Oops.  That was meant for you.
[21:45] <rulus> np :)
[21:48] <cyberix> ScottK: perl-base is a dependency of ubuntu-minimal. Doesn't that make it "essential"?
[21:50] <ScottK> I'm looking at the definitions now and find myself a bit confused.
[21:50] <ScottK> ubuntu-minimal is a meta-package.  It does not define the priority of the package.
[21:52] <ScottK> So here's the definition of essential: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Essential
[21:54] <ScottK> cyberix: Look at the output of apt-cache show dpkg for an example of an essential package.
[21:55] <cyberix> coreutils also
[21:55] <cyberix> probably some linux package
[21:56] <cyberix> Can't find it, but I got the idea
[21:56] <cyberix> Now for another matter
[21:57] <cyberix> Should new Ubuntu packages be backwards compatible with previous Ubuntu-releases?
[21:57] <ScottK> cyberix: If it's feasible to do so, yes. What specifically are you concerned about?
[21:58] <ScottK> You must care that someone upgrading from the previous release (and the previous LTS release - but that's the same for Intrepid) can upgrade without failures.
[21:59] <cyberix> http://revu.tauware.de/details.py?package=mi2svg
[21:59] <cyberix> See 1) of June 12 19:47
[22:00]  * ScottK looks
[22:01] <ScottK> cyberix: Do you have the same version of lintian?
[22:02] <sybille_> Hi. Does anyone here know about licensing issues for packaging Firefox extensions? I'm thinking about trying to package Zotero, which is a bibliography management extension that also integrates with OpenOffice.org, but it's licensed under the Educational Community License version 1 and that's not on the list of acceptable licenses in the wiki. Thanks! :)
[22:02] <sybille_> Just ask if you'd like some links. :)
[22:02] <ScottK> sybille_: Please provide a link to the text of the license.
[22:03] <sybille_> ScottK: http://www.opensource.org/licenses/ecl1.php
[22:03] <cyberix> ScottK: You must have read wrong comment.
[22:04] <ScottK> cyberix: I was.
[22:04] <cyberix> ScottK: I could have a dependency on man-db (>= 2.5) to support old versions of Ubuntu.
[22:04] <ScottK> cyberix: Add the dependency on man-db as he says.
[22:04] <cyberix> Ok
[22:04] <cyberix> I don't think it is a bad idea
[22:05] <cyberix> I just felt that I have no idea how much work it would take to support all previous versions of Ubuntu.
[22:05] <cyberix> And I was wondering why he is testing out the package on old systems in first place
[22:06] <ScottK> That's not quite the point.  The point is that your program won't work right with the earlier versions of man-db, so you should version the dependency.
[22:06] <ScottK> If you don't, then if people try to backport it, it'll just break and that's not right.
[22:06] <ScottK> If the version needed is in Dapper, then no versioned depends is needed, but otherwise it is.
[22:06] <emgent> sebner: ping
[22:07] <cyberix> ScottK: It is ok to over estimate the required version?
[22:07] <ScottK> No.
[22:07] <cyberix> ScottK: I'd usually want to set a package to depend on the version that I used while packaging
[22:07] <ScottK> Actually what you want is man-db (>= 2.5~) so the if someone backports man-db it'll work.
[22:08] <ScottK> cyberix: No.  You want to set it on the needed version.
[22:08] <cyberix> e.g. While I packaged Progress Quest I had no idea how well it would work on some old versions of WINE, so I just set it to depend on the current one.
[22:08] <cyberix> It might work well with some old version
[22:08] <sebner> emgent: pong
[22:09] <ScottK> cyberix: That's not the correct way to do it.
[22:09] <cyberix> Then again there are atleast minor problems even with the current on.
[22:09] <cyberix> These are considered bugs
[22:09] <cyberix> But it is still usable
[22:09] <geser> sybille_: after a quick look the ECL looks dfsg-free
[22:10] <geser> but I'm not a licensing expert
[22:11] <directhex> debian-legal@lists
[22:12] <cyberix> Finding out the oldest version of some library that the software can run on may be a Herculean task.
[22:12] <emgent> warp10: ping
[22:12] <cyberix> And it is not that hard to check it against some specific version, if you are back porting it.
[22:13] <ScottK> cyberix: That's true.  Just version them where you know.
[22:13] <ScottK> Don't set versions you don't know to be needed.
[22:13] <sybille_> geser: Thanks, I think it ought to be OK, too, but... So, over in #ubuntu-mozillateam, I was just told to put the extension up on the wiki page and someone will take a closer look (They also sent me over here to ask). So that's what I'll do.
[22:13] <ScottK> sybille_: Free, but extraordinarily painful to deal with.
[22:14] <cyberix> ScottK: Oh. That makes sense.
[22:14] <emgent> norsetto: heya
[22:14] <norsetto> emgent: o/
[22:14] <warp10> emgent: pong
[22:14] <ScottK> sybille_: Make sure you comply with the " Notice of any changes or modifications to the Original Work, including the date the changes were made." part of the license.
[22:15] <sebner> norsetto: he stole my merge but did it the old way :P (eggdrop)
[22:16] <sebner> norsetto: go and tell him \o/ --> emgent
[22:16] <cyberix> ScottK: Thanks a lot. You have been very helpful.
[22:16] <emgent> lol
[22:16] <RainCT> good night
[22:16] <norsetto> sebner, emgent: I hope at least he used the right patch?
[22:17] <ScottK> cyberix: You're welcome.
[22:17] <sebner> norsetto: I think so but not eggdrop-ssl in debian/control
[22:17] <sybille_> ScottK: That would mean adding something like a changelog for the package itself, I guess?
[22:17] <norsetto> sebner: thats ok, it was just an exercise for you anway
[22:18] <ScottK> sybille_: Read the license and make your best judgement.  IANAL.
[22:18] <cyberix> norsetto: Please don't feel bad about me arguing with you. It is nothing personal. I'm just trying to understand how stuff works and trying to get out a good package.
[22:18] <ScottK> sybille_: You might see if you can get upstream to change to some other license.  AFAICT the standart MIT license does most of the same things without all the pain.
[22:18] <emgent> sebner: do you like work in eggdrop-ssl or i can?
[22:19] <norsetto> cyberix: why should I feel bad? I quite like that you try to understand
[22:20] <cyberix> norsetto: Ok. Good. Just wanted to make sure.
[22:20] <sybille_> ScottK: Yeah, I'll talk to the Zotero people about it. Thanks!
[22:20] <norsetto> cyberix: np at all, feel free to ask any question you want
[22:22] <norsetto> emgent, sebner: you are using the wrong patch for eggdrop
[22:24] <emgent> 20 April 2008 - Eggdrop 1.6.19 released, SSL patch updated
[22:25] <emgent> true norsetto
[22:25] <emgent> sebner: I can fix or you like work in this package ?
[22:26] <emgent> so, we can think to eggdrop-ssl too..
[22:33] <Saj0577> Hey guys.
[22:33] <sebner> norsetto: emgent : ah the old patch was used ;)
[22:33] <sebner> norsetto: we used the old patch and did the merge like I wanted to do it. but it isn't uploaded yet
[22:33] <sebner> norsetto: we = he
[22:35] <Saj0577> Hey, I Want to help out with MOTU I know next to nothing about it but I am intrested. Can anyone help me?
[22:35] <norsetto> Saj0577: sure
[22:36] <Saj0577> norsetto: How I start? How I Show willing? How I get someone to help me along the way? Sorry for all questions in advance ;)
[22:36] <norsetto> !packaging | Saj0577
[22:37] <emgent> sebner: i know
[22:37] <norsetto> Saj0577: you may also want to check this link: https://wiki.ubuntu.com/MOTU/GettingStarted
[22:38] <norsetto> Saj0577: this is the right place to ask questions and advice
[22:38] <Saj0577> Checked that one briefly going to read it in full in a minute :)
[22:39]  * Saj0577 is reading https://wiki.ubuntu.com/PackagingGuide/Complete
[22:43] <bobbo> norsetto: if you've got time could you check out my new fix for bug #195196?
[22:43] <norsetto> jussi01: do we have any factoid that points to https://wiki.ubuntu.com/MOTU/GettingStarted ?
[22:43] <norsetto> bobbo: warp10 will check it out tomorrow
[22:43] <bobbo> norsetto: ah ok, thanks :)
[22:44] <norsetto> bobbo: just one question
[22:44] <bobbo> norsetto: sure
[22:44] <warp10> bobbo: yeah, for just 10 euros (special prices today!)
[22:44] <norsetto> bobbo: did you make a get-orig-source rule?
[22:45] <bobbo> norsetto: i created a Watch file, from your comment i though you made either a watch or a get-orig-source?
[22:45] <norsetto> bobbo: I'm asking since the upstream tarball is funnily name (GraphMonkey-1.7-src.tar.gz or something similar)
[22:45] <norsetto> bobbo: yes, a rule to make a proper orig.tar.gz using the watch file could be very cool
[22:47] <bobbo> norsetto: i'll have a look :)
[22:47] <norsetto> bobbo: thanks. Let me know if you need help
[22:49] <norsetto> Saj0577: before immerging yourself into the packaging guide, I would also suggest you have a look at https://wiki.ubuntu.com/UbuntuDevelopment, it really answers a lot of questions about how we develop ubuntu, really helpful for people who doesn't know our processes
[22:50] <Saj0577> norsetto: thank you
[22:50] <leleobhz> well, my package about dependencies
[22:50] <leleobhz> [12/06-18:49:44] <@jbrjake> and no, it cannot use your system's libraries, because your system cannot guarantee it has the specific revisions handbrake needs nor will they have the custom patches handbrake applies.
[22:50] <leleobhz> so, i leave the compilation system intact?
[22:54] <ryanakca> How can I make knmap not run configure twice (once at start of build, and one at the end)?
[22:54] <bobbo> norsetto: Using the second example from https://wiki.ubuntu.com/PackagingGuide/Examples/ChangingTheOrigTarball, the version number should be hard coded right?
[23:00] <norsetto> bobbo: the version number you should get from uscan filtered by the sed, even though that regexp looks funny
[23:00] <bobbo> norsetto: im downloading some packages with examples in them, ill see what they di
[23:01] <bobbo> s/di/do/
[23:01] <norsetto> bobbo: yes, it works fine
[23:01] <leleobhz> noone?
[23:02] <norsetto> bobbo: in the dehs output you will see a line with something like <upstream-version>1.2.0</upstream-version>
[23:02] <norsetto> bobbo: and the sed will just return what is in between <upstream-version> and </upstream-version>
[23:02] <bobbo> ah, ok
[23:03] <norsetto> bobbo: so, you don't need to use the bzcat, just use an mv (or a cp)
[23:21] <bobbo> norsetto: what command do i test the get-orig-source with?
[23:21] <norsetto> bobbo: btw, there is no need to do something so complex, a simple usca --force-downloads will do
[23:22] <norsetto> bobbo: sorry, uscan --force-downloads
[23:22] <norsetto> bobbo: argh: uscan --force-download
[23:22] <bobbo> norsetto: hehe, tired?
[23:22] <norsetto> bobbo: test it with "make -f debian/rules get-orig-source"
[23:23] <norsetto> bobbo: dislexic :-/
[23:23] <bobbo> norsetto: ah, ok :)
[23:26] <bobbo> norsetto: "make: Nothing to be done for `get-orig-source'."
[23:26] <norsetto> bobbo: make sure to use tabs!
[23:29] <TheMuso> ScottK: What was the ping about earlier?
[23:31] <Saj0577> Fixing a bug on a program and I dont have an email account that works so would it be alright if I just put my wiki link where the email goes as i dont have an email account?
[23:32] <norsetto> bobbo: there is nothing being mentioned in the debian package, but I think the upstream tarball was changed so that it unrolls in graphmonkey-1.7 not GraphMonkey-1.7-src
[23:33] <bobbo> norsetto: yeah, it extracts to ./graphmonkey-1.7
[23:33] <norsetto> bobbo: ok
[23:35] <Saj0577> Yeah?No?
[23:36] <slangasek> Saj0577: "where the email goes" - do you mean in the debian/changelog?
[23:36] <Saj0577> yeah.
[23:36] <slangasek> no, that won't work
[23:37] <Saj0577> I have no email acc that works at present so what should I do?
[23:38] <slangasek> the changelog format requires that it be formatted as an email address; it doesn't have to be valid (though we certainly /want/ it to be), but it does have to be well-formatted
[23:38] <slangasek> what about getting an email account with a free provider?
[23:39] <Saj0577> okay. Then would it be okay to change it later for a pernament email address or what?
[23:40] <slangasek> sure
[23:40] <Saj0577> okay. Will do that for now then and change it on a later date. :)
[23:40] <slangasek> we wouldn't go back and update old changelogs of already-uploaded packages, but maybe you'll have a permanent email address before the upload happens. :)
[23:41] <norsetto> Saj0577: just use slangasek@ubuntu.com, he won't mind
[23:41]  * norsetto runs away
[23:41] <Saj0577> When the upload happen?
[23:42] <bobbo> Saj0577: once a sponsor has reviewed it and deemed it good enough to go into the archives
[23:42] <Saj0577> o right il just keep this email for MOTU work then ;)
[23:43] <ajmitch> norsetto: bad person
[23:43] <norsetto> ajmitch: person?
[23:43] <ajmitch> norsetto: you
[23:43] <zul> hey ajmitch
[23:43] <slangasek> ajmitch: what would be interesting is to see whether anyone would sponsor it that way
[23:43] <ajmitch> unless you're just another irc bot? :)
[23:43] <norsetto> ajmitch: yes, who told I'm  a person!?
[23:45] <ajmitch> slangasek: it'd be interesting to see
[23:46] <norsetto> ajmitch: actually, it happened to me once
[23:47] <norsetto> ajmitch: by mistake somebody used by email as the maintainer, I discovered it only because it popped up in my list of assigned packages
[23:47] <ajmitch> probably more likely for that to happen than for your name to end up in the changelog
[23:49] <norsetto> ajmitch: it could happen, somebody copy&pasting an old changelog and forgetting to change the email, perhaps
[23:58] <Saj0577> hey guys when i run debuild -S i get the error: gpg: [stdin]: clearsign failed: secret key not available.   Any advice?
[23:58] <Jazzva> Saj0577: You need to generate a pair of public-secret GPG keys, using your name and e-mail address with it
[23:59] <Saj0577> yeah i have the key created on my machine with that email account and name
[23:59] <Jazzva> !GPG | Saj0577