[00:04]  * sistpoty keeps on stepping people on the foot
[00:29] <pochu> we could switch MC applications to answers.launchpad.net which expires unanswered tickets after 15 days :P
[00:32] <daskreech> Hello
[00:32] <daskreech> Will Virtualbox 1.6 have a package for hardy?
[00:34] <pochu> bug 240856
[00:34] <pochu> daskreech: ^ if that is approved, then yes (in the backports). So if you test it and give some feedback there, that would be appreciated
[00:35] <daskreech> pochu: Oh you ^_^
[00:35] <daskreech> gracias
[00:35] <pochu> de nada :)
[00:41]  * sistpoty is off to bed... gn8 everyone
[00:41] <daskreech> NIght
[00:59] <emgent> night.
[01:06] <nxvl> emgent: have a beer in my name!
[01:30] <cyberix> How does python library naming work?
[01:30] <cyberix> there are lots of packages that are called python-pysomething
[01:30] <cyberix> but then pycrypto is just called python-crypto
[01:30] <cyberix> instead of python-pycrypto
[01:33] <cyberix> "Public modules should be packaged with a name of python-foo, where foo is the name of the module."
[01:33] <cyberix> So the module name of pycrypto is mere crypto
[01:34] <cyberix> Did I get it right?
[01:36] <pochu> cyberix: right
[01:36] <pochu> if you do 'import crypto', then it should be python-crypto
[02:29] <jscinoz> Does anyone else here use cowbuilder and run into problems building multiple packages concurrently, it would appear that /var/lib/dpkg is shared amoung all running chroots, any ideas what I'm doing wrong?
[03:01] <DaskreecH> hi stdin
[03:01] <DaskreecH> Have you ever used quote ?
[03:01] <stdin> hey
[03:01] <stdin> don't think so, what is it?
[03:01] <DaskreecH> Dunno just noticed it gets installed by default
[03:02] <stdin> on intrepid? (I have Hardy here)
[03:02] <DaskreecH> On hardy
[03:02] <nxvl> i think i have use it
[03:03] <nxvl> it's just eastern egg
[03:03] <nxvl> or something
[03:03] <DaskreecH> nxvl: What is it for?
[03:03] <stdin> "which quote" shows nothing, probably a bash built-in
[03:03] <nxvl> it's kind of fun
[03:03] <nxvl> DaskreecH: tipe quote on the terminal
[03:03] <DaskreecH> I know :)
[03:03] <nxvl> type*
[03:03] <DaskreecH> stdin: it's a function
[03:04] <stdin> ahh, I know what that is
[03:04] <nxvl> is just to put quotes to a string
[03:04] <stdin> it's from bash_completion
[03:04] <DaskreecH> ah ok makes sense now
[03:05] <nxvl> (i was confusing it with other tool which just prints famus quotes on the terminal)
[03:05] <DaskreecH> ok well what I was really here to ask about was a bug :)
[03:05] <DaskreecH> https://bugs.launchpad.net/hardy-backports/+bug/240856
[03:06] <DaskreecH> What's the likelihood of that happening?
[03:49] <DaskreecH> is there license issues with backporting 1.6.2 to hardy?
[05:04] <YokoZar> ScottK: I hope I did this right: I reset https://bugs.edge.launchpad.net/hardy-backports/+bug/240755 to confirmed to request a slightly newer version of the Intrepid package to replace the Wine backport
[05:49] <kostmo> I'm getting a "native-package-with-dash-version" error from Lintian
[05:50] <kostmo> it was suggested that my package be named pyrocket-0.5-0ubuntu1
[05:50] <eboyjr> Will this help?: http://lintian.debian.org/tags/native-package-with-dash-version.html
[05:51] <kostmo> I've seen the error explanation, but I don't understand how to fix it
[05:51] <persia> kostmo: You need an orig.tar.gz in the parent directory when you build the package.
[05:52] <persia> e.g. pyrocket_0.5.orig.tar.gz
[05:52] <persia> s/e.g./i.e./ (Oops)
[05:52] <kostmo> so starting from a clean package build, should I actually run debuild twice?
[05:52] <persia> Not usually, although it can help detect certain classes of bugs.
[05:53] <persia> Typically, one just renames the upstream tarball.
[05:53] <kostmo> I'm not sure how to generate the orig.tar.gz file, actually
[05:53] <kostmo> I'm packaging up my own program, btw
[05:53] <persia> kostmo: Download the tar.gz file from upstream.  Rename it.
[05:53] <persia> Ah.  Therein lies the confusion :)
[05:53] <persia> You'll want to wear two different hats, and think about the program two different ways.
[05:54] <persia> Firstly, make a perfect version with no debian/
[05:54] <persia> Bundle that up into a tar.gz file and put it on the internet.
[05:54] <persia> Next, rename the tarfile to orig.tar.gz, and add all the packaging information.
[05:55] <kostmo> does it matter where (or at all) I put it on the internet?
[05:55] <persia> Then, when you run debuild -S, you'll get a diff.gz with the packaging, and a .dsc.
[05:55] <persia> It doesn't matter where you put it.  People tend to put them on the project homepage, and host them on the same service that hosts the code.
[05:56] <persia> You want to have an internet-accesible archive of releases so you can construct a working watch file, to provide notification when the version in the distribution differs from the version upstream.
[05:56] <kostmo> ok, so the orig.tar.gz doesn't have to have any kind of installer (i.e. more like a fend-for-yourself piece of code)?
[05:56] <persia> As your project grows, you probably won't have time to focus on both packaging for each distribution and doing all the upstream work: creating this separation of concerns early makes that transition easy later.
[05:57] <persia> Well, your life will be easier if your setup.py takes an install argument for a raw install.
[05:57] <kostmo> ok
[05:57] <persia> But no, no nice packaged installer to integrate with the distribution.
[05:58] <persia> You'll likely want a slightly different set of packaging information to be able to integrate into each of Debian, Ubuntu, Fedora, SuSE, slackware, etc.
[05:59] <kostmo> under what circumstances would the distribution's version differ from my upstream version?
[05:59] <kostmo> i.e. why do I need a 'watch' file?
[06:00] <persia> kostmo: Well, firstly getting new upstream versions into released stable distributions is hard, so most distributors aren't likely to do that.
[06:00] <persia> Secondly, as the number of distributions that packages pyrocket grows, you may not be watching them all, so it helps to have automated notification when there is a new upstream, for those packaging the updates for the given distribution.
[06:01] <ScottK> YokoZar: Generally one files a new bug, but I think that will work.  Is it really worth another backport?
[06:03] <kostmo> so the effectiveness of this watch file depends on having a stable URL for the upstream code?
[06:03] <YokoZar> ScottK: Well if the backported one is going to be SRUed, then I think so.  The changes to the .desktop file to make it say "Wine Windows Program Loader" instead of "Wine Windows Emulator", but more importantly it also adds an association for .msi files.  If we also update shared-mime-info, then users will be able to double click msi files.
[06:03] <ScottK> OK.  Sounds reasonable.
[06:04] <kostmo> I hadn't considered starting a sourceforge project, but I guess I could
[06:04]  * cody-somerville disturbingly just realizes he missed the MOTU-SRU meeting.
[06:08] <persia> cody-somerville: It's important to stay on top of these things :)
[06:09] <cody-somerville> ScottK, how did it go?
[06:10] <ScottK> IIRC it went fine.
[06:10] <ScottK> It's very late here and I'm not entirely awake.
[06:10] <ScottK> Ask me again tomorrow.
[09:50] <tooba1> hey, how is it possible that in REVU several packages have an empty Lintian file, while running Lintian gives lots of errors/warnings? I uploaded a package, and its Lintian file was correctly generated, but in other cases (e.g: http://revu.ubuntuwire.com/details.py?package=playonlinux, http://revu.ubuntuwire.com/details.py?package=gedit-regex-plugin), it didn't happen
[09:53] <geser> tooba1: my guess would be different versions of lintian
[09:54] <tooba1> there are HUGE differences!
[09:54] <tooba1> but, principally, the point is:
[09:54] <tooba1> isn't the file automatically generated on server? So where would be the different Lintian versions?
[09:56] <geser> the file is generated on the server, but I don't know which lintian version is there installed
[09:56] <geser> if you run lintian on your system you might use a different version
[09:57] <geser> and it also depends if you run lintian on the source package or on the binaries (debs)
[09:57] <geser> revu checks only the source package
[09:57] <tooba1> ok, I get it. Anyway, this is very strange, since there are a lot of things missing, so I think it's more probable that it's run with lots of "exclude" arguments (on the server)
[09:58] <tooba1> the server doesn't have the binaries, as I see
[09:58] <tooba1> I think it checks the ".changes", as I do
[09:59] <wgrant> geser: I installed the latest backported lintian about a week ago - it definitely supports 3.8.0.
[09:59] <geser> tooba1: then playonlinux and gedit-regex-plugin are lintian clean (at least the source packages)
[09:59] <wgrant> tooba1: We can't risk building the packages, so we don't run it on binaries. Just sources.
[10:00] <tooba1> wgrant: right. But running "lintian xyz.changes" means checking sources, right?
[10:00] <wgrant> If it's a source-only changes, yes.
[10:01] <emgent> morning
[10:01] <tooba1> well... I thing that looking at http://revu.ubuntuwire.com/details.py?package=gedit-regex-plugin, you'll get the point. The "lintian" is empty, I attached a lintian report
[10:01] <geser> Hi emgent
[10:01] <tooba1> they're all source changes, obviously
[10:01] <emgent> geser :)
[10:01] <tooba1> (right?)
[10:01] <wgrant> And it indeed runs on the .changes.
[10:02] <tooba1> wait
[10:02] <wgrant> All of those are binary issues.
[10:02] <tooba1> here's a more interesting example
[10:02] <wgrant> Except for the lack of intrepid.
[10:02] <tooba1> exactly that
[10:03] <wgrant> Your lintian is broken and/or out of date.
[10:03] <geser> tooba1: you can also run lintian just on the .deb or the .dsc
[10:04] <tooba1> I get it
[10:06] <wgrant> It would be optimal to automatically build each upload, but that would imply development of a virtualised building infrastructure.
[10:06] <tooba1>   ok
[10:07] <geser> wgrant: doesn't revu run on a sparc machine? so it isn't the fastest either for building packages
[10:08] <tooba1> but it's awful that lintian is not able to spot changes that ARE in the source files...
[10:08] <wgrant> It's a 5 year old UltraSparc III, right.
[10:08] <tooba1> anyway, [OT]
[10:08] <wgrant> tooba1: It is...
[10:08] <tooba1> thanks for the clarifications
[10:08] <wgrant> tooba1: What didn't it pick up?
[10:11] <tooba1> package-contains-empty-directory, readme-debian-contains-debmake-template, copyright-lists-upstream-authors-with-dh_make-boilerplate, copyright-without-copyright-notice, extended-description-is-empty, section-is-dh_make-template, script-not-executable, binary-without-manpage, extra-license-file, extended-description-line-too-long, unknown-section, python-script-but-no-python-dep
[10:11] <tooba1> (in just 2 packages :-)
[10:11] <wgrant> The second, third and fourth could be picked up, but the rest are binary issues.
[10:12] <tooba1> yep
[10:13] <tooba1> no wait, why not ﻿"extended-description-is-empty"?
[10:13] <wgrant> Because that's a binary attribute.
[10:13] <wgrant> Though you should in general be able to check that in debian/control.
[10:14] <wgrant> I don't believe it's required by policy, though.
[10:14] <tooba1> aha
[10:29] <k0p> hi all.
[10:30] <k0p> I'm trying fix some issues in my package. What's binary-arch-rules-but-pkg-is-arch-indep ? can I make a package for 'all' arch?
[10:32] <persia> k0p: That is a report that it appears debian/rules is calling the binary-arch target even when the package is architecture-independent.  You likely want to check the rules structure carefully.  `make -p -f debian/rules` may help, although it may confuse.
[10:34] <k0p> persia, really nice. thanks for the help.
[10:34] <k0p> :)
[10:35] <persia> k0p: You may find that running lintian -iIv is more informative than lintian alone, for these expansions to be automated.
[10:36] <k0p> persia, gh. I don't know the lintian command
[10:36] <k0p> thanks :D
[10:37] <k0p> persia, one more question
[10:37] <k0p> the package on revu only have comment when does it have errors?
[10:39] <cyberix> I considered packaging Astro Chicken, but then I changed my mind -> http://cs.helsinki.fi/u/twruottu/ss/astro_chicken.png
[10:40] <cyberix> And no, I don't have a written permission to publish this screen shot
[10:44] <tooba1> k0p; the package has comments when someone commented it :-)
[10:44] <tooba1> it may have errors nobody noticed
[10:44] <tooba1> it may have comments not regarding errors
[10:45] <tooba1> tipically, the only systematic method of finding (many) errors if lintian
[10:45] <tooba1> you build your package, then run "lintian nameofthepackage.changes"
[10:45] <k0p> hmm yeap.. now I understand. I don't need upload to see the lintian file
[10:45] <k0p> lol
[10:48] <tooba1> right...
[10:48] <tooba1> moreover, the lintian file you see when you upload shows a very small part of the potential errors, because it runs on the package not compiled
[10:48] <tooba1> bye
[10:49] <cyberix> k0p: Congrats. You are one step closer to being a perfect packager.
[10:49] <k0p> lol
[10:49] <k0p> cyberix, so far...
[10:50] <cyberix> k0p: Not that far. It seems you found revu. Now you are getting one step closer every day.
[10:52] <k0p> I would like that my package should be able in 8.10
[10:52] <k0p> may be it not possible, right?
[10:52] <k0p> is it late?
[10:53] <cyberix> k0p: It is still possible
[10:53] <cyberix> https://wiki.ubuntu.com/IntrepidReleaseSchedule
[10:53] <cyberix> k0p: k0p You should get it in before FeatureFreeze
[10:54] <cyberix> (sorry for two nicks)
[10:54] <cyberix> :-P
[10:54] <k0p> hehe
[10:54] <k0p> :)
[10:54] <k0p> 28 th august right?
[10:54] <cyberix> getting it in means that you must get two sponsors in revu and get someone to upload it before the FeatureFreeze
[10:54] <cyberix> yes
[10:55] <k0p> yeah ... but I don't have sponsors .. not yet :)
[10:55] <k0p> i'm fixing issues on my package
[10:55] <cyberix> Of course the package may be sent back to revu, if there is some big problem with it
[10:55] <cyberix> But revu is trying to make sure there is nothing wrong with it before it gets uploaded
[10:55] <k0p> hmm of course
[10:56] <cyberix> There is one revuday each week
[10:56] <k0p> cyberix, but in revu nobody make package.. only make sources
[10:56] <k0p> really?
[10:56] <cyberix> That is the day when you are supposed to ask sponsors
[10:56] <k0p> I don't understand so much . .revu is compiling ?
[10:56] <k0p> build packages? or what's that?
[10:56] <cyberix> no
[10:56] <cyberix> reviewing
[10:57] <cyberix> so, if you want to be efficient you should fix all reported issuesduring the week between revu days, so you can ask for sponsors on each revu day
[10:57] <cyberix> you can only ask for sponsors, if you have fixede all reported problems
[10:58] <k0p> hmm
[10:58] <k0p> yeah
[10:58] <cyberix> then it is likely that someone looks at your package and reports more problems
[10:58] <k0p> what the day of revu?
[10:59] <k0p> so may be in next week my package found a sponsor?
[11:00] <cyberix> In theory yes, but if you are very new at packaging you'll probably get error reports instead
[11:00] <cyberix> :-)
[11:00] <cyberix> revu day is announced in the topic of this channel
[11:01] <cyberix> I'm not sure which weekday it currently is
[11:02] <k0p> cyberix, well .. I have 4 Errors and 2 Warnings...
[11:03] <cyberix> humans can usually find more errors than lintian :-)
[11:03] <wgrant> cyberix: There isn't one at this time.
[11:03] <cyberix> but ofcourse it makes no sense to ask humans before you have fixed the easy ones
[11:04] <cyberix> wgrant: How is that?
[11:04] <k0p> cyberix, of course.
[11:04] <wgrant> cyberix: Nobody is running REVU days.
[11:04] <cyberix> wgrant: Each day is a "revu day" then?
[11:05] <wgrant> I guess that each day is equally REVU-friendly, perhaps.
[11:05] <k0p> cyberix, in changelog.. intrepid is a versiong right?
[11:05] <cyberix> I suppose revu days appear closer to release when people are busy
[11:05] <cyberix> k0p: interpid is the codename for Ubuntu 8.10
[11:06] <cyberix> k0p: So, you are working with the Umit package?
[11:06] <k0p> yeap
[11:06] <k0p> how you guess?
[11:06] <cyberix> packager email address sounded similar to your (nick)name
[11:07] <k0p> is intrepid or interpid?
[11:07] <k0p> yeah
[11:07] <k0p> :)
[11:07] <cyberix> intrepid
[11:07] <k0p> hmm
[11:07] <cyberix> http://en.wiktionary.org/wiki/intrepid
[11:08] <cyberix> Does Umit depend on nmap or is it standalone?
[11:08] <k0p> depend of nmap
[11:09] <k0p> may be the error about bad-distro-name is because I don't have 8.10 installed.. I have 8.04
[11:10] <cyberix> I think my 8.04 didn't complain about intrepid
[11:11] <k0p> hmm
[11:12] <k0p> cyberix, umit (0.9.5-ubuntu1) intrepid; urgency=low
[11:12] <k0p> looks like fine?
[11:15] <cyberix> I think the version number should be 0.9.5-0ubuntu1
[11:16] <cyberix> but ofcourse you have to make that change to each place where you specify the version number
[11:17] <k0p> right
[11:18] <cyberix> k0p: Ok. I get the bad distro name error too
[11:18] <cyberix> so it should be ok
[11:18] <k0p> is n't 0.9.5-0ubuntu1?
[11:19] <wgrant> cyberix: One only specifies the version number in a single place unless one is doing strange things that shouldn't be done.
[11:20] <k0p> wgrant, but the trouble is in intrepid :/
[11:20] <cyberix> Oh I forgot
[11:20] <wgrant> k0p: Install lintian from hardy-backports.
[11:20] <k0p> wow
[11:20] <k0p> Online it don't appear
[11:20] <wgrant> Hm?
[11:20] <k0p> I don't have one error and one warning
[11:21] <cyberix> Because they have a newer version of lintian there
[11:21] <wgrant> Online where?
[11:21] <k0p> wgrant, revu
[11:21] <cyberix> revu of course
[11:21] <wgrant> On REVU? I upgraded lintian there last week.
[11:21] <k0p> wgrant, yeah.. I'll update lintian from backport
[11:21] <k0p> thanks for the help
[11:21] <k0p> :)
[11:21] <wgrant> np
[11:21] <cyberix> k0p: You should till change the version number to 0.9.5-0ubuntu1
[11:22] <cyberix> That is something lintian won't warn about
[11:22] <wgrant> It should, though.
[11:22] <cyberix> Well, lintian doesn't report Ubuntu specific stuff, right?
[11:23] <wgrant> cyberix: It doesn't, but it might be nice if it did.
[11:27] <cyberix> k0p: I'm happy to see that someone is trying to package umit for Ubuntu.
[11:28] <cyberix> k0p: I recall I wanted to try it out sometime, but didn't because there was no package.
[11:28] <k0p> cyberix, I already make one package
[11:28] <k0p> well.. We're working hard to release stable version
[11:28] <k0p> before august
[11:29] <k0p> after that we need to merge lot of features that was develpmenting in other branches.
[11:29] <cyberix> You just have to figure out which version of nmap will ship with intrepid
[11:29] <k0p> cyberix, it isn't a problem
[11:29] <k0p> >=4.50
[11:29] <k0p> right?
[11:30] <cyberix> sure
[11:30] <k0p> :)
[11:30] <cyberix> btw specify the version requirement only, if umit really doesn't work well with older versions of nmap
[11:31] <k0p> I have a working about native-package-with-dash-version
[11:31] <k0p> hmm ok
[11:31] <k0p> give me a second
[11:32] <k0p> umit working nice with older version. . 4.20 it's nice. but I don't have totally sure about that
[11:32] <k0p> i'll verify it
[11:32] <cyberix> You can just say nmap in dependencies, without a version requirement
[11:32] <cyberix> If upstream tells you not to use versions older than x, then that is valid reason for setting the requirement.
[11:32] <k0p> cyberix, I do it
[11:33] <k0p> ok
[11:33] <cyberix> Now I have to do some household hacking
[11:33] <cyberix> :-D
[11:33] <k0p> hehe :)
[11:33] <cyberix> See you later, and good luck with the project
[11:33] <k0p> good luck
[11:33] <k0p> thanks a lot for your help
[11:34] <cyberix> no problem
[13:52] <AnAnt> Hello. could some review those: http://revu.tauware.de/details.py?package=ubuntume-gdm-themes  ,                                                                           |
[13:52] <AnAnt> http://revu.tauware.de/details.py?package=usplash-theme-ubuntume
[13:54] <persia> AnAnt: I'm going to discourage the use of REVU for package updates (like those), as they have an even greater chance of being ignored than other things on REVU.
[13:54] <persia> That said, looking now.
[13:54] <AnAnt> persia: errm, I don't understand
[13:54] <AnAnt> persia: I mean, how would package updates be reviewed then ?
[13:55] <persia> AnAnt: REVU is for new packages, not already in the archives.  For updates to packages already present, submitting a diff as a bug is preferred.
[13:56] <AnAnt> ok
[13:56] <persia> Mind you, for native packages, this doesn't always work, and you'll have to submit the entire tar.gz (which is part of why I don't like native packages).
[13:57] <persia> AnAnt: Anyway, I know you, and know you maintain these packages, and know that they likely ought get updated, so unless I can find something extra wrong, I'll upload them this time: just please use a bug to update them in the future.
[13:57] <AnAnt> sure thing
[13:57] <AnAnt> thanks
[13:58] <AnAnt> persia: btw, regarding webstrict, the maintainer is trying to get it in Debian
[13:59] <AnAnt> persia: anyways, he'll need to make changes, seems that debian don't have openjdk yet
[14:00] <AnAnt> persia: oh, for java based software, should the package build-depend on openjdk or on default-jdk
[14:00] <persia> AnAnt: Ah.  Right.  I think there was an effort to do that.  You might ask on #debian-java on OFTC to check the current status.
[14:00] <persia> That said, if it can build on gcj, that would be far preferable.
[14:02] <AnAnt> persia: how about default-jdk ?
[14:03] <AnAnt> persia: btw, thanks for the link !
[14:38] <k0p> cyberix, are you there?
[14:42] <persia> k0p: It's generally best to ask your questions and look for whoever is about to answer: you may need a specific person, but even then, telling them what you seek can help them form an answer when they return, in case you are not watching at that moment.
[14:43] <cyberix> k0p: I'm here
[14:44] <cyberix> k0p: I'm having a coffee break from household hacking
[14:46] <bliZZardz> is DBus part of Gnome?
[14:48] <jpds> bliZZardz: I think it's idenpentant of the DE: http://www.freedesktop.org/wiki/Software/dbus
[14:48] <persia> bliZZardz: GNOME relies on DBUS, but other things do as well.  Why?
[14:50] <bliZZardz> persia : bon jour! well, i was just exploring DBUS, hence curious to understand it - was not sure whether it is 'still' being used
[14:50] <persia> bliZZardz: It is very much in use.
[14:50] <bliZZardz> persia : any good place/link to understand GNOME better(except for the code:P )
[14:51] <persia> bliZZardz: gnome.org?
[14:51] <persia> That said, I think the code is better: I'd recommend looking at session, panel, and menus primarily.
[14:53] <bliZZardz> persia : any specific reasons for that rationale?
[14:57] <persia> bliZZardz: I found it more useful?
[14:59] <bliZZardz> persia : useful as in??? gtk code that can be used in other ways?
[14:59] <k0p> persia, ok.
[14:59] <k0p> sorry
[15:01] <k0p> i'm trying to solve native-package-with-dash-version warning. it's cause is set as debian native package? I would like know how solve this
[15:01] <persia> bliZZardz: Useful in understanding how GNOME works.  For GTK code, look at your favorite GTK application.
[15:01] <persia> k0p: You need an orig.tar.gz file.  Then rebuild.  That's it.
[15:02] <k0p> persia, just make a rename?
[15:03] <persia> Right.  rename the upstream tar.gz file to match the naming convention for orig.tar.gz, and you should be good.
[15:06] <k0p> persia, thanks. silented this warning
[15:07] <bliZZardz> persia : you know of any channels/forums wherein i can application deisgn questions/queries?
[15:10] <persia> bliZZardz: I don't.  Sorry.
[16:12] <DRebellion> Could someone review my package? http://revu.tauware.de/details.py?package=monkeystudio Thanks ;)
[16:16] <sistpoty> hi folks
[16:16] <sebner> huhu sistpoty
[16:16] <sistpoty> hi sebner
[16:19]  * sistpoty reboots again, and hopes to be right back *g*
[16:20] <DktrKranz> reboot? what does this word mean?
[16:28]  * sistpoty grumbles a little bit about being forced to use the nv driver instead of the blob
[16:29] <sebner> sistpoty: you too? ^^
[16:29] <sistpoty> yep
[16:29] <sebner> sistpoty: kernöl?
[16:30] <sistpoty> sebner: 2.6.26-2-generic
[16:30] <sistpoty> (lrm doesn't seem to contain nvidia blob any longer... /me wonders where it went)
[16:30] <sebner> sistpoty: kay. though also compiling and using that thing on the old 2.6.24 kernel isn't working :(
[16:30] <persia> sistpoty: Which version of libdrm do you have?
[16:30]  * DRebellion gumbles a little bit about never getting a review :P
[16:31] <sistpoty> persia: 2.3.0-4ubuntu1
[16:31] <persia> Oh well.  No nouveau either then
[16:31] <persia> DRebellion: Yeah.  This cycle has been weak on reviews.  Sorry about that.
[16:32] <DRebellion> persia, by cycle, do you mean up to alpha1?
[16:34] <persia> DRebellion: I mean intrepid
[16:34] <DRebellion> oh, right
[16:34] <DRebellion> =
[16:34] <DRebellion> =(
[17:04] <\sh> sebner: do you want to work on an SRU?
[17:05] <kostmo> hey all, I have uploaded my package to REVU, am I supposed to get an e-mail with login information? Package is here: http://revu.ubuntuwire.com/details.py?upid=2611
[17:10] <sebner> \sh: depending on how urgent it is since today I haven't got really time to work on it but tomorrow
[17:10] <sistpoty> kostmo: just try to log in with your email address and give no password, then there'll be a "recover password" link
[17:11] <\sh> sebner: bug #241587 check the debdiff
[17:11] <\sh> sebner: check if it works on hardy etc :)
[17:14] <sebner> \sh: so many patches to test O_o . I never used claws mail so I have to waste time for setting it up correctly and test then every patch?
[17:15] <\sh> sebner: no..the patches are coming from upstream....
[17:16] <\sh> sebner: just make a "run test" the more in-deep testing we are doing via -proposed
[17:16] <sebner> \sh: ah ^^ kk. ok if tomorrow?
[17:16] <\sh> sebner: I trust upstream in this..colin was very helpful...
[17:16] <\sh> sebner: sure :)
[17:17] <sebner> \sh: np, Will do and ping you tomorrow about it then
[17:17] <\sh> sebner: I'm busy with leonov release tomorrow and in the evening I'm watching EM finals ;)
[17:18] <sebner> \sh: bah! but me too. except the leonov thing xD
[18:48] <sistpoty> doko: ok if I grab crystalspace merge from you?
[18:51] <Lutin> johanbr: looking at the empathy buildlog would have shown you that it failed because some packages it relies on were broken at the time it was built
[18:57] <johanbr> Lutin: Right. Do you know if those packages have been fixed?
[18:57] <DktrKranz> sistpoty, devfil was looking at it, he should have a debdiff ready
[18:58] <sistpoty> DktrKranz: ah, thanks... didn't find a bug on lp, so I assumed it wasn't taken yet
[18:58] <Lutin> johanbr: I gave it back on i386, built fine, waiting for it to go through NEW
[18:59] <sistpoty> DktrKranz: and just in time... as at this moment dl of the source packages finished *g*
[18:59] <DktrKranz> heh
[18:59] <johanbr> Lutin: Alright. Thanks.
[18:59] <DktrKranz> sistpoty, FYI bug 242961
[19:00] <sistpoty> DktrKranz: ah... I guess I was confused that the title didn't contain "merge" *g*
[19:01] <guest22> Can someone please help with an (apparently) difficult question on the appropriate version number to assign to a package to be uploaded as a stable release update?
[19:01] <DktrKranz> sistpoty, probably because he was trying to get package in shape again, since it requires much love
[19:01] <DktrKranz> and I guess merge is not enough :P
[19:01] <devfil> sistpoty: in Debian package fails to build, I've merged it and updated it to the latest version
[19:06] <guest22> There's a significant bug in the package which is currently in hardy (version 0.25-0ubuntu1) which has been fixed by a new upstream release which is now in intrepid as 0.26-0ubuntu1. What should the version number be for the hardy release of 0.26, since 0.26-0ubuntu1 is already taken by the intrepid release, and 0.26-0ubuntu2 incorrectly implies that it follows the intrepid release?
[19:07] <DktrKranz> guest22, 0.26-0ubuntu1.1
[19:07] <DktrKranz> mh... no, I misread
[19:08] <DktrKranz> 0.25-0ubuntu1.1 should fit
[19:09] <guest22> DktrKranz: But the new release for hardy would be based on 0.26 upstream, so surely 0.25-xxx is incorrect?
[19:10] <devfil> guest22: 0.26-0ubuntu0.1
[19:10] <DktrKranz> guest22, if new upstream release is a bugfix release, you can use 0.26-0ubuntu1~hardy1
[19:11] <guest22> devfil and DktrKranz: any suggestions on which is preferred, 0.26-0ubuntu0.1 or  0.26-0ubuntu1~hardy1 (yes, it is a bugfix release)?
[19:12] <devfil> guest22: ~hardy1
[19:13] <guest22> devfil and DktrKranz: OK, thanks to both of you for the advice. One additional question:  the wiki at https://wiki.ubuntu.com/StableReleaseUpdates mentions uploading to release-proposed, but doesn't give any more details. Do I just do dput to hardy-proposed? If so, where do I find the dput config for this upload target?
[19:13] <devfil> guest22: in changelog use hardy-proposed
[19:14] <DktrKranz> guest22, just attach a debdiff for hardy-proposed to a bug report, subscribe motu-sru for approval and wait for sponsors to upload package for you.
[19:15] <guest22> DktrKranz: Ah, so I just ignore the additional instructions at the StableReleaseUpdates wiki, eg. "4. Upload the fixed package to release-proposed with the patch in the bug report ..."?
[19:15] <DktrKranz> guest22, yes. This is managed by developers who have upload rights.
[19:16] <DktrKranz> as much as following steps
[19:17] <guest22> DktrKranz: OK, thanks. It really would be useful to have better documentation for package maintainers so that one doesn't have to clarify everything on IRC.
[19:19] <guest22> Apologies for the heresy, but the Fedora people really are ahead in this respect.
[19:19] <DktrKranz> guest22, it's a work in progress, We hope to have something better soon.
[19:20] <guest22> DktrKranz: Sure, I understand.
[19:20] <DktrKranz> thanks for bringing us bugfix releases :)
[19:26] <guest22> DktrKranz: No point in going to the effort of getting a package accepted, and then ignoring bugs, eh?
[19:28] <DktrKranz> we usually don't ignore bugs, there have been cases where updates were problematic (e.g. new version had new features, which do not fit well with our policy), but the great majority of bugs are processed successfully.
[19:29] <DktrKranz> if new release is just bugfix, it's just the matter to find some test cases to check if bugs are addressed correctly
[19:30] <highvoltage> does canonical use livecd.sh to build the squashfs images in ubuntu?
[19:59] <geser> DktrKranz: re the apache2-mpm-itk SRU: does intrepid need to be fixed now? as I assume that apache2 will see some more uploads till release, apache2-mpm-itk will need some more rebuilds till then
[20:00] <krzysz01> i just fogured out that sometimes when making .debs have to copy binaries makeally to (your package)-(version/debian/(your package)/(whatever directory on the filesystem the binary should be added to)
[20:00] <ScottK> geser: It's good to keep it in sync as you go.
[20:00] <DktrKranz> geser, let's have it in our radars. Maybe we can  milestone it for 8.10 or RC
[20:01] <krzysz01> I have built a package of my project. what do i do now?
[20:03] <geser> ScottK: ok, will do a rebuild
[20:03] <ScottK> I may be a little paranoid about it because I ended up forgetting one on another package for Hardy and had to do an SRU.
[20:04] <DktrKranz> that's would be a shame
[20:07] <geser> ScottK: I have made several rebuild of apache2-mpm-itk already so I hopefully don't forget it till release (and it should pop up when I check unmet deps before release if it needs a rebuild). That's also the reason why I catched it that apache2-mpm-itk needs a rebuild when I saw the apache2 SRUs on hardy-changes.
[20:08] <ScottK> geser: If you want to wait to upload it, I'm OK.  If it was me, I'd upload it.
[20:12]  * DktrKranz will process more SRUs when able to boot new 2.6.26, VMware is not working properly with 2.6.24 and intrepid :S
[20:13] <tacone> DktrKranz: virtual box 1.6.2 should be able to support the new kernel. http://virtualbox.org/wiki/Changelog
[20:14] <DktrKranz> tacone, yes, but VM images provided by canonical are for VMware only, I need to port them to virtualbox
[20:14] <geser> ScottK: I've no problem doing a upload right now (at least I don't forget to close the bug later), but it isn't a top priority right now knowing that it will break again (hardy had 5 rebuilds (and 1 new version))
[20:15] <tacone> DktrKranz: didn't know canonical provids vm images. virtualbox should be able to import them, although last time I tried (many months ago) it didn't worked.
[20:15] <DktrKranz> oh, and why my clock says it's 20:47 when it's 21:17? is NTP broken?
[20:16] <johanbr> NTP will not set the clock if the difference is too big.
[20:16] <DktrKranz> tacone, I'll have a try with new kernel benC uploaded last night
[20:17] <tacone> DktrKranz: nice.
[20:17] <DktrKranz> johanbr, sometimes it just goes out of sync, it does it automatically. I'll move to manual
[20:18] <johanbr> If ntpd can't keep your clock synced, something is wrong.
[20:18] <DktrKranz> it does on a random basis, sometimes it's synced
[20:19] <DktrKranz> and sometimes not (as of now)
[20:19] <johanbr> Probably either you're syncing with a bad server, you have a very jittery network connection or your internal timesource is unreliable.
[20:27] <sistpoty> hm... as promised, mail about DIF: http://paste.ubuntu.com/23581/ anything I missed, should be clearer or other comments?
[20:29] <ScottK> sistpoty: I'd take the bit about new versions being good out.
[20:29] <ScottK> Other than that, I'm good.
[20:29] <sistpoty> ScottK: you mean like that: http://paste.ubuntu.com/23582/
[20:30] <sistpoty> ScottK: do you think it's clear enough, that ppl. won't start to ask if a merge should still be done?
[20:31] <ScottK> I think it's good.
[20:31] <sistpoty> ScottK: ok, thanks for reviewing :).
[20:36] <sistpoty> hm... apt and it's recommends are really annoying... it somehow decided to install (upgrade?) frozen-bubble after an apt-get -f install in order to test the wordpress merge
[20:36] <highvoltage> heh, that's actually more funny than annoying.
[20:37]  * highvoltage is a bit scared of the apt-recommends thing
[20:37] <sistpoty> well, f-b is one of the ~30 packages it draws in
[20:37]  * sistpoty still blames the perl transition *g*
[20:41] <highvoltage> does it pull in the reccommends from the recommended packages too?
[20:42] <sistpoty> highvoltage: I assume it does. not too sure though (and imo most packages it draws in for me are ones that are just upgraded... though a apt-get upgrade holds these back)
[20:42] <highvoltage> I guess it will just take some time for everyone to get used to it.
[20:43] <sistpoty> oh, nice... the first apt-get -f install failed. now it draws in even more packages. apt's behaviour appears somehow random to me *g*
[20:58] <sistpoty> hm... I'm just trying a very interesting upgrade, which might remove parts of kde for me. so in case I won't be on irc tomorrow, figure out what went wrong *g*
[20:59] <highvoltage> screen and irssi dude ;)
[20:59]  * highvoltage ducks
[20:59] <sistpoty> nah, I want some clicky stuff at least (kvirc) *g*
[21:01] <sistpoty> highvoltage: I mean can irssi inform me if I'm highlighted via try bubble opening? (imo a killer feature of kvirc)
[21:01] <sistpoty> s/try/tray/
[21:01] <highvoltage> yep
[21:01] <sistpoty> damn *g*
[21:01] <highvoltage> I think nixternal blogged about how to do that at some point
[21:01] <highvoltage> it doesn't do it out of the box, but iirc it's quite easy to implement
[21:02] <sistpoty> heh, so it involves fiddling with stuff... /me rather fiddles with source packages *g*
[21:03] <highvoltage> http://blog.nixternal.com/2007.03.22/notify-works-in-kubuntu/ and http://pthree.org/2007/03/21/irssi-gui-notify/ explains
[21:03] <sistpoty> I mean I'm even to lazy to recompile the nvidia blob (which I used to do on unstable) and instead use nv *g*
[21:03]  * highvoltage is too lazy to even buy nvidia
[21:04] <sistpoty> well, back then ati didn't offer docs yet *g*
[21:04] <sistpoty> oh nice link!
[21:04] <highvoltage> by some sheer luck, all my machines just happen to have intel display chips, which happen to work beautifully in ubuntu
[21:05] <sistpoty> well, as I have very much fun of playing games, nvidia used to have the best opengl driver, so that's what I bought
[21:05] <highvoltage> I must admit, I have an Nvidia card lying around too. I bought it because I needed a DVI port, which my onboard card didn't have
[21:06] <highvoltage> but in the end I got a mac mini which had a dvi port. luckily it has an intel chip onboard.
[21:53] <ppp> Gday all. I posted on the motu list, no feedback, is there any particular reason why its taking 2 years to get tripwire updated?
[21:55] <sistpoty> ppp: #ubuntu-motu please for universe stuff
[21:55] <sistpoty> oh, he, wrong tab *g*
[21:55] <sistpoty> sorry
[22:00] <sistpoty> ppp: we've synced tripwire right from unstable. as we're a small team, we cannot care for every package in ubuntu alone, but rather rely on debian/unstable there
[22:00] <ppp> Ok thank you, so I should take the matter up with Debian?
[22:01] <sistpoty> ppp: hence the best way to get a new upstream version (apart from doing it yourself) is to file a whishlist bug against debian/unstable for tripwire
[22:01] <sistpoty> yes
[22:01] <ppp> Right, I can contribute well on testing but Im not a packager, so I will discuss with Debian
[22:01] <sistpoty> ppp: if a version number of a package doesn't contain "ubuntu" then, it's usually straight synced from unstable
[22:02] <ppp> Good to know thanks
[22:02] <cyberix> What should happen after a new upstream version of a package gets released?
[22:02] <sistpoty> ppp: I guess just filing a wishlist bug against debian bts is the best way to proceed (iirc daniel baumann, the debian maintainer does quite a good job)
[22:02] <cyberix> Who should do what?
[22:02] <cyberix> I suppose some one has to do something, so the package will get updated
[22:03] <sistpoty> cyberix: if it's a local package in ubuntu, it's best that the package updates it (since he/she knows it best)
[22:03] <sistpoty> cyberix: likewise there is the option to file a bug, but we're quite lacking behind in regards to sponsoring
[22:04] <sistpoty> cyberix: finally, if the source is unstable, the best way is to file a bug there... bonus points for attaching s.th. usable in regards to a new upstream version
[22:04] <sistpoty> s/package/packager/ in the first sentence :)
[22:12] <cyberix> sistpoty: "s.th. usable" == new source package?
[22:12] <sistpoty> cyberix: for example
[22:14] <sistpoty> cyberix: however don't focus too much on providing a "patch"... it's imho not too likely, that a new upstream version will just get uploaded from such a patch
[22:14] <sistpoty> (but rather that the corresponding maintainer will do it on his/her own)
[22:16] <krzysz01> i have a pjoject readfile. i built a package and put it into my ppa check it out (krzysdrewniak on launchpad)
[22:25] <cyberix> sistpoty: How about a case where I am that maintainer ;-)
[22:25] <sistpoty> cyberix: you mean in unstable?
[22:25] <cyberix> yes
[22:26] <sistpoty> cyberix: then write a mail to youself requesting a new upstream version :P
[22:26] <cyberix> X-D
[22:31] <cyberix> I wonder, if I'll ever understand how this works
[22:31] <cyberix> Has anyone ever updated an Ubuntu package to new upstream version?
[22:34] <directhex> technically no
[22:34] <directhex> i've prepared a new debian package though
[22:43] <cyberix> How should I provide an icon for files with a certain mime-type?
[22:48] <bluefoxicy> the hell?
[22:48] <bluefoxicy> "Who knows?  Maybe you'll go down in Income Investor history as the one who crafted our motto -- a part of the whole.  Ubuntu, indeed."
[22:49] <bluefoxicy> oh god
[22:49] <bluefoxicy> "Ubuntu describes .... While it may not be well known outside South Africa (except perhaps in South Boston)"  ROFL
[22:51] <neurobuntu> will debs that are compiled in debian work in ubuntu? and visa versa?
[22:53] <cyberix> neurobuntu: They might
[22:53] <cyberix> neurobuntu: There is no guarantee
[22:53] <neurobuntu> ok thanks
[23:03] <sistpoty> hm.. I'm doing s.th. wrong. I tried to process the sponsors queue today, but I only found one thing to upload, out of 10 or so rejects.
[23:12] <kostmo> I was wondering if any Ubuntu Developers would be willing to review/sign off my package: https://bugs.launchpad.net/ubuntu/+bug/242910
[23:13] <sistpoty> kostmo: I'll take a look in a few minutes
[23:13] <kostmo> thanks!
[23:18] <sistpoty> kostmo: any reason for the version 0.5-ubuntu6 in debian/changelog (why not use -0ubuntu1)?
[23:18] <sistpoty> kostmo: also, your upload is targeted at hardy instead of intrepid
[23:19] <kostmo> sistpoty: I was getting lintian warnings on my system, which the PPA and later REVU would treat as errors, and at least the PPA wouldn't let me re-upload the same version
[23:19] <kostmo> so I kept incrementing the version number until I got it right
[23:20] <kostmo> I was wondering whether I should put intrepid in there
[23:20] <kostmo> I know it works on Hardy, because that's the system I have
[23:20] <sistpoty> kostmo: yes, you'll need to put intrepid there, as hardy is released, and hence we cannot add new packages to it
[23:20] <kostmo> ah ic
[23:21] <kostmo> can you put multiple release codenames in the changelog?
[23:21] <sistpoty> no
[23:21] <kostmo> I haven't downloaded the alpha/beta of Intrepid for testing on my machine
[23:22] <kostmo> would I need to do that first?
[23:22] <sistpoty> kostmo: you should do so, at least in a chroot ;)
[23:22] <kostmo> when you say chroot, do you mean for building the package?
[23:23] <kostmo> I'm not sure how you would run intrepid in chroot, or what that means exactly
[23:23] <sistpoty> kostmo: both for building it and for testing it
[23:24] <sistpoty> kostmo: s.th. like "sudo deboostrap /path/to/chroot intrepid"
[23:24] <sistpoty> kostmo: then you can test it inside the chroot with chroot /path/to/chroot
[23:25] <emgent> hello there
[23:26] <sistpoty> hi emgent
[23:26] <kostmo> is there a tutorial/walkthrough you could point me at for this chroot procedure?
[23:26] <emgent> sistpoty: hi man :)
[23:26] <sistpoty> kostmo: man debootstrap should give you a starting point...
[23:26] <sistpoty> kostmo: others than that, I'm not sure if there's a tutorial
[23:26] <kostmo> I'm looking at that now... it says you can use a URL for a mirror?
[23:27] <sistpoty> kostmo: then use your ubuntu mirror of choice ;) (probably its debootstrap /path/to/chroot intrepid <mirrorlocation>(
[23:28] <sistpoty> (straight from my memory though()
[23:28] <kostmo> so does that mean I don't have to download a livecd for intrepid?  I've never tried a distro pre-release before
[23:29] <sistpoty> kostmo: no,  debootstrap will download the necessary packages to well, create a minimal chroot for intrepid
[23:29] <geser> kostmo: pyrocket commented
[23:30] <sistpoty> geser: cheater :P
[23:30] <geser> sistpoty: I saw after I commented that you do an real-time review
[23:31] <sistpoty> geser: well, I was more busy with chroot issues than reviewing :P
[23:33] <sistpoty> kostmo: heh, now you've got two comments for your package ;)
[23:53] <sistpoty> woohoo... another package from ubuntu-universe-sponsors queue uploaded :)