[00:41] <stochastic> does anyone have time to do a REVU: http://revu.ubuntuwire.com/p/swh-lv2
[00:56] <kamalmostafa> The 'debchange' script (dch) in Karmic's devscripts package does not think "lucid" is a valid distribution, so it whines at me accordingly.  Is there any reason why Karmic's debchange couldn't include "lucid"?   Should I force Lucid's whole devscripts package onto my Karmic development system?
[00:58] <persia> kamalmostafa: Ignore the error or work in a chroot :)
[00:59] <persia> kamalmostafa: Extra points for submitting the patch to make sure that doesn't happen for lucid as soon as the name for lucid+1 is announced.
[00:59] <JontheEchidna> shouldn't enabling karmic-backports fix the issue? I believe that's what has happened in all previous releases
[00:59]  * JontheEchidna comments and runs, off to watch Lost
[01:00] <persia> Well, that usually fixes it, but fixing it pre-release is better :)
[01:00] <kamalmostafa> JontheEchidna: wait... Lost!?  Oh, not my timezone yet (whew!)
[01:00]  * micahg has backports enabled and doesn't see the fix
[01:02] <kamalmostafa> persia: its certainly easy enough to work around -- I guess I was really wondering if everyone else bumps into this annoyance or if there's a more "proper" way to set up my environment.
[01:03] <JontheEchidna> kamalmostafa: just the recap show, the premiere is in an hour
[01:04] <kamalmostafa> JontheEchidna: Okay, as long as I've got at least 108 minutes.
[01:04] <JontheEchidna> ;-)
[01:20] <kklimonda> what are the options of creating daily builds for ppa?
[01:20] <kklimonda> bzr builder is one
[01:25] <micahg> kklimonda: https://edge.launchpad.net/drobotik
[01:30] <kklimonda> micahg: right - the evil script I couldn't get to work in the past ;)
[01:30] <kklimonda> but I guess it's time to try it again
[01:43] <kklimonda> are backports enabled for ppa builds?
[01:44] <RAOF> kklimonda: They are if you enable in the “PPA Details” section of your ppa.
[01:44] <kklimonda> right, I've just thought of that
[02:11] <kklimonda> fta: what is the workflow with your scripts for daily builds? I have no idea how it works..
[02:53] <solarkennedy> I need some help, I'm building my own version of a package (bind9) using the standard apt-get source bind9; etc
[02:53] <solarkennedy> But the package from security is trying to upgrade over my version
[02:54] <solarkennedy> even though (I think) apt-get source got the patched version
[02:54] <solarkennedy> What can I do to make my version take priority over the one from security?
[05:21] <jacob> ffffffuuuuuuu-
[05:21] <jacob> sorry, wrong channel. carry on.
[07:19] <suji11> Hi, anyone advocate/review my package http://revu.ubuntuwire.com/p/iok
[07:42] <angelabad> Hi, can anyone review pidgin-embeddedvideo? Embedded video is a GTK+ plugin for pidgin. http://revu.ubuntuwire.com/p/pidgin-embeddedvideo
[10:39] <randomaction> suji11: I found a number of lintian errors/warnings in iok, see REVU page
[10:51] <Laney> randomaction: are you somehow interested in Agda?! :)
[10:52] <randomaction> not really, I'm working on uninstallable packages
[10:52] <Laney> blast
[10:52] <Laney> do you have an easy to read list?
[10:52] <Laney> i'll look at the haskell stuff
[10:52] <randomaction> http://qa.ubuntuwire.com/debcheck/debcheck.py?dist=lucid&list=universe-only-relationship-Depends&arch=i386
[10:53] <Laney> oh that's not bad at all
[10:54] <randomaction> there are many haskell packages that FTBFS because dh_haskell doesn't exist anymore
[10:55] <Laney> sure
[10:55] <Laney> there will be a haskell transition before long
[10:55] <randomaction> from what I researched, it was a simple wrapper around dh_haskell_*, so it's going to be easy to fix
[10:56] <randomaction> if it's not done in Debian
[10:56] <Laney> it is
[10:56] <|xaka|> anybody can tell me know to build cross-dependens packages? A -> B, B -> C, C -> A?
[10:56] <Laney> |xaka|: don't
[10:56] <|xaka|> but how ubuntu guys did it?
[11:02] <randomaction> Laney: I hope I didn't break much by syncing agda
[11:05] <Laney> randomaction: no, not at all. I was looking at doing it
[11:05] <Laney> I just uploaded the Agda standard library to Debian and am laying the groundwork for that
[11:08]  * Laney . o O ( Dear Santa, please bring Soyuz binNMU support for Christmas, he's been a really very good boy )
[11:09] <randomaction> ah, so we do -build1 uploads just because it doesn't support binNMUs?
[11:11] <Laney> well binNMUs a la Debian aren't really what I mean, but yeah
[11:11] <jetienne> debchange warning: new version (0.05) is less than the current version number (0.05). <- from a debchange :)
[11:11] <Laney> I want to avoid having to do a manual sourceful upload
[11:14] <Laney> although tbh, most of this Haskell transition could be done with syncs as packages are getting new uploads to Debian
[11:14] <Laney> . o O ( Dear Soyuz, please let me schedule actions with a wanna-build like syntax )
[11:32] <jetienne> q. in a dh_make, it propose a init.d.ex and a init.d.lsb.ex, which one is the prefered one .?
[11:36] <jetienne> ok init.d.ex it will be ;)
[12:22] <mok0> Anyone know of a way to determine geolocation by IP?
[12:28] <Rhonda> I forgot what option I could use for the translations.launchpad.net page to have more than 10 items per page?
[12:29] <randomaction> mok0: whois?
[12:30] <mok0> randomaction: doesn't that just give you who registered the ip numbeR?
[12:30] <randomaction> Rhonda: batch
[12:31] <randomaction> mok0: that's right; do you need finer results?
[12:31] <Rhonda> randomaction: Thanks!
[12:34] <mok0> randomaction: yes
[12:35] <mok0> randomaction: For example http://www.melissadata.com/Lookups/iplocation.asp lets you look up where you are
[12:36] <mok0> ... well any IP
[12:36] <mok0> I was just wondering if that could be done by any of the standard tools we have in Linux
[12:37] <mok0> randomaction: It's different from whois, that only finds the organization that has registered the ip address
[12:37] <randomaction> mok0: well, for my IP it gives results correct to 700 km, while whois lets you track me down within 2 km :)
[12:40] <mok0> randomaction: heh
[12:41] <mok0> randomaction: perhaps you have registered your own IP?
[12:41] <randomaction> nope, it's an ISP local to this part of the city
[12:42] <mok0> randomaction: well, I can't say how that geolocator works, that's what I'm trying to find out :-)
[12:43] <mok0> randomaction: I presume the ISP has to submit information somewhere
[12:43] <randomaction> http://www.outflux.net/blog/archives/2010/01/24/google-is-wardriving/
[12:44] <randomaction> ^^ was on Planet Ubuntu recenlty
[12:45] <mok0> randomaction: interesting. Well the data is out there somewhere
[12:45] <mok0> randomaction: you'd think there is some service like whois or dns that could be queried
[12:46] <randomaction> I'd think that's all there is
[12:48] <mok0> randomaction: hm, kees has a script on his site that might be *exactly* what I'm looking for
[12:50] <mok0> randomaction: woot, it works
[12:51] <randomaction> is this a Google service?
[12:52] <mok0> randomaction: yes
[12:52] <mok0> randomaction: actually, it works by MAC address not IP
[12:52] <mok0> randomaction: I have to figure out how to change the script
[12:53] <jetienne> http://www.outflux.net/blog/archives/2010/01/24/google-is-wardriving/ <- tell this guys about geoip-like services
[13:00] <paissad> hi all, is this channel for helping about creating .deb packages for a possible later upload in ubuntu repositories ?
[13:06] <dooooomi> mok0: i made the changes to the klick package as you suggested. i've also uploaded the frontend gtklick (http://revu.ubuntuwire.com/p/gtklick)
[13:07] <mok0> dooooomi: OK, I'll take a look
[13:08] <dooooomi> mok0: thanks!
[13:09] <iulian> paissad: Yes.
[13:09] <randomaction> paissad: yes, among other things
[13:10] <paissad> iulian, randomaction ok thanks
[13:24] <mok0> dooooomi: I submitted my review. Ping me later I have to be afk for a while
[13:25] <mok0> dooooomi: will take a look at gtkklikc later
[14:13] <alkisg> Urm... I issued this command: `bzr mv menus/ src`
[14:13] <alkisg> ...hoping to move the menus directory into the src directory. It did, but all the files in the menus directory were gone. Could someone explain me if that's normal?
[14:46] <_stink_> new-ish to packaging, and here's something i don't get: i hear that a benefit of pbuilder is that you don't have to install all those -dev packages on your machine.  but if i have to debuild first to get the .dsc file to send to pbuilder, and debuild needs all those -dev packages, how am i avoiding installing them on my machine?  am i misunderstanding something?
[14:46] <Laney> you run debuild -S
[14:47] <_stink_> ah! hah, thanks
[14:47] <_stink_> duh me
[14:47] <_stink_> :)
[14:48] <geser> _stink_: but you still might need some build-depends installed, like debhelper
[14:48] <Laney> yes, those needed for the clean: target
[14:50] <feuloren> hi, I have a long question about packages names and dependencies :
[14:50] <feuloren>  current version of babl is lucid is 0.0.22 and package's name is libbabl-0.0-0; many packages have dependencies against it,   but the new upstream release is 0.1.2 so package's name should be changed to libbabl-0.1-0; if one change the name of this package, is there a need to repackage all the packages that depends on it ?
[14:51] <_stink_> Laney: geser: thanks!
[14:51] <geser> feuloren: probably only to rebuild (if the API didn't change)
[14:52] <Rhonda> feuloren: Why do you think that package's name should be changed to libbabl-0.1-0? The upstream release version has nothing to do with it, that's API/ABI versions in the package name, not upstream versions.
[14:52] <geser> feuloren: how does upstream call the library (the .so file) itself?
[14:52] <Rhonda> feuloren: As long as the upstream release 0.1.2 hasn't changed the backwards compatibility it should be fine.
[14:57] <feuloren> geser, Rhonda : ok, i thought package's name should match the upstream version of the package
[14:58] <Rhonda> Not really, no. :)
[14:58] <Rhonda> package versions should match upstream versions. :)
[14:58] <geser> library package names match the upstream library naming and so-version
[15:22] <hakaishi> Hi everyone! Anyone up to advocate for qt-shutdown-p? (I just need one more advocate) http://revu.ubuntuwire.com/p/qt-shutdown-p
[16:06] <bddebian> Heya gang
[16:08] <zooko> kirkland: I enjoyed reading your interview. I hadn't noticed that the interviewer talked about Tahoe-LAFS last time I spoke to you.
[16:18] <sebner> huhu bddebian :)
[16:18] <bddebian> Heya sebner
[16:25] <hyperair> persia: how does one apply for MOTUship these days?
[16:27] <Rhonda> hyperair:   * common/usr/bin/sw-repair-set.sh:
[16:27] <Rhonda>      - loose repair case for exim4.
[16:27] <Rhonda>      - add Enta and Sysa in another case.
[16:27] <Rhonda> eeks, wrong paste. :)
[16:27] <Rhonda> hyperair: http://wiki.ubuntu.com/MOTU should have the relevant informations. :)
[16:27] <hyperair> Rhonda: thanks.
[16:27] <hyperair> Rhonda: is it up to date?
[16:28] <hyperair> Rhonda: afaik it used to be through the MC, but i have no idea about the state of the MC currently
[16:28] <Rhonda> I would hope so. If you find something outdated feel free to fix it. :)
[16:28] <hyperair> Rhonda: it's outdated.
[16:28] <hyperair> Rhonda: but i have no idea what's the up to date information, which is why i'm asking.
[16:29] <randomaction> hyperair: apply to DMB
[16:29] <hyperair> randomaction: how?
[16:29] <hyperair> randomaction: what are the procedures?
[16:29] <randomaction> let me find a link; they voted on the procedure just yesterday
[16:30] <Rhonda> hyperair: http://wiki.ubuntu.com/DeveloperMembershipBoard is outdated then, too?
[16:30] <randomaction> https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
[16:30]  * Laney hopes this build isn't stuck
[16:30] <Rhonda> Ah, doesn't seem to be. :)
[16:30] <Laney> that doesn't mention MOTU
[16:30] <randomaction> hmm, it doesn't mention MOTU
[16:31] <kreuter> howdy, #ubuntu-motu.  where do I put upstart init files in a debian/ directory so that dh_installinit will find them?  (or, alternatively, how do I tell dh_installinit what files to use?)
[16:31] <Laney> and https://wiki.ubuntu.com/UbuntuDevelopers says that MOTU is still a delegated team
[16:31] <Laney> persia (or other MC member): can you shed any light on how to apply for MOTU currently?
[16:31]  * hyperair sighs. whatever happened to succession plans prior to dissolving?
[16:32] <Laney> jpds, nhandler: ^^^ ?
[16:32] <Laney> kreuter: look at the manpage
[16:32] <Laney> it's really very clear
[16:33] <kreuter> oh.  oops.  I was looking at the manpage on the wrong host.  sorry for the noise.
[16:34] <sebner> hyperair for MOTU \o/
[16:36] <hyperair> sebner: thanks =)
[16:42] <geser> Laney: the wiki page with the ApplicationProcess should also apply to MOTU for now (it's based on the MC process)
[16:43] <Laney> geser: The UbuntuDevelopers page still lists MOTU as a delegated team. Is that no longer true?
[16:44] <Laney> (because it then says "# Review the requirements for the specific team of interest, and apply to that team for membership")
[16:45] <geser> MOTU still exists, https://wiki.ubuntu.com/Specs/LucidMOTU got approved on the last DMB meeting (without the MC part), the future of the MC is to be discussed/decided within MOTU
[16:45] <Laney> delegated for the purpose of developer applications, that is
[16:46] <Laney> and wiki/MOTU still talks abot the MC
[16:46] <geser> it's not yet decided what powers the MC will have (at least it's not very clear to me)
[16:46] <Laney> so I don't see how MOTUs are supposed to apply currently
[16:46] <geser> I guess nobody will remove the parts about MC without knowing if MC comes back or not
[16:47] <geser> s/will/want/
[16:47] <Laney> I'll just mail the list(s)
[16:47] <geser> some parts about MOTU/ MC is still in motion and not finally settled yet
[16:48] <geser> mok0 proposed to expand "MOTU" to "Masters of the Unknown" :)
[16:48] <sebner> geser: I'm wondering if there is finally a schedule about making this decisions as this is going on since months already
[16:49] <sebner> lol
[16:49] <geser> sebner: what kind of decision? MOTU will stay, this got decided (the spec approved)
[16:49] <geser> what happens to MC is to be decided by MOTU
[16:50] <sebner> geser: also after archive-reorg?
[16:50] <geser> yes
[16:50] <sebner> geser: what happened to per package upload rights?
[16:50] <Laney> PPU = DMB
[16:50] <Laney> this is clear
[16:50] <Laney> I just don't see who decides MOTU applications
[16:50] <Laney> in the middle of composing the mail now
[16:51] <randomaction> FWIW, DMB did review one MOTU nomination yesterday
[16:52] <geser> for now the DMB does it (there are two applications carried over from the MC to the DMB)
[16:52] <Laney> (at the very least the wiki needs to clarify this)
[16:52] <ripps> Does anybody know how to stop pbuilder after it's done building so I can inspect the environment?
[16:52] <geser> ripps: setup a hook
[16:52] <ripps> geser: like what?
[16:53] <hyperair> geser: so is the procedure the same? just add yourself to the meeting agenda and mail the list?
[16:53] <Laney> there is an example on the wiki
[16:53] <Laney> but you should name it BXXX instead of CXXX, I think
[16:53] <geser> hyperair: yes
[16:53] <hyperair> geser: okay, thanks =)
[16:53] <randomaction> ripps: manpage describes --hookdir option
[16:54] <hyperair> now i need to continue looking for endorsements..
[16:54] <Laney> or use the FTBFS hook and hax debian/rules to make the build always fail
[16:55] <geser> ripps: /usr/share/doc/pbuilder/examples/C10shell but save it as B10shell (or any other number)
[16:55] <ripps> geser: ah thanks, I had C10shell, I just didn't know how to execute it at the right time.
[16:56] <Laney> C hooks are executed on failures
[16:56] <geser> ripps: man pbuilder; it describes the different kind of hooks (A till G)
[16:56]  * jdong wonders what these flame icons are on launchpad bugs
[16:56] <jdong> is it... a popularity metric?
[16:56] <geser> bug heat
[16:56] <jdong> grrreat :)
[16:56] <geser> but it's bugged
[16:56] <hyperair> i haven't seen any of them heat up though
[16:56] <jdong> now all we need are avatars and thumbs-up/down logos!
[16:56] <hyperair> yeah, it's bugged. =p
[16:56] <jdong> https://bugs.edge.launchpad.net/gedit/+bug/276094
[16:57] <jdong> obviously more than jus the CPU is getting hot
[16:57] <geser> hyperair: look at nspluginwrapper, https://edge.launchpad.net/ubuntu/+source/nspluginwrapper/+bugs
[16:57] <hyperair> geser: wow. we've got a 4-flame one!
[16:57] <hyperair> =O
[16:58] <randomaction> jdong: http://blog.launchpad.net/bug-tracking/bug-heat
[16:59] <jdong> randomaction: ah, good to know :)
[16:59] <geser> hyperair: another one: https://bugs.edge.launchpad.net/ubuntu/+source/seahorse-plugins/+bug/429322, there the duplicate list is longer then the comments
[17:00] <hyperair> lol
[17:00] <hyperair> that's pretty hilarious =p
[17:01] <Laney> that bug times out
[17:01]  * Laney strokes Launchpad
[17:01] <jpds> How I learnt to stop worrying and LOVE the Launchpad.
[17:03] <Rhonda> Has someone the link handy for where the difference in versioning between Debian and Ubuntu packages are listed?
[17:03] <Rhonda> Like, which packages are in sync, which need sync, which contain patches and so on?
[17:04] <Laney> do you mean multidistrotools?
[17:04] <Rhonda> No clue if I mean that before I've seen it. :)
[17:04] <Laney> Rhonda: If so, http://qa.ubuntuwire.com/multidistrotools/
[17:04]  * Laney was getting the link
[17:05] <Rhonda> I think that might be something, thanks.
[17:05] <Laney> UDD carries all this as well
[17:05] <Laney> if you want to create your own reports
[17:05] <Rhonda> Ah, cool!
[17:05] <Rhonda> Thanks for _that_ information, that will be extremely helpful, hopfully. :)
[17:06] <Laney> I believe part of the vision was to obsolete MDT with UDD :)
[17:06] <Rhonda> thus the U ;)
[17:07] <Rhonda> Ah, that compares squeeze and not sid …
[17:08] <StevenK> Because that's where we are pulling from by default this cycle
[17:08] <Rhonda> Yes, figured that. Unfortunately ejabberd won't be able to transition to squeeze and I was searching for it on that page and didn't find it. ;)
[17:09] <StevenK> We are happy to sync from unstable, but that needs to be requested
[17:09] <StevenK> (And ACKed, if you're no core-dev/motu)
[17:09] <Rhonda> Got already. ;)
[17:10] <Rhonda> But I was just searching for a known pattern in the page that I know of.
[17:10] <Laney> Rhonda: I made a (really bad) script that uses UDD to compare sid and lucid
[17:10] <Laney> alioth: ~laney-guest/udd.pl
[17:11] <Laney> it just does it for reverse build deps of ghc6, but you get the idea
[17:11] <Rhonda> Laney: I am thinking of doing something like this, at least for the pkg-games team maintained packages: http://backports.deb.at/lenny-backports/ :)
[17:11] <Laney> yes, that would be very easy
[17:11] <Rhonda> Wait. .pl?
[17:11] <Rhonda> How did you manage to get CGI working on alioth?
[17:11] <Laney> it's not CGI
[17:12] <StevenK> It's a script to snarf, chmod +x, and run
[17:12] <Laney> correct
[17:12] <Rhonda> And it gives me 404
[17:12] <Rhonda> Oh
[17:12] <Laney> I mean in my home directory, sorry
[17:12] <Rhonda> Right. :)
[17:12] <Rhonda> I thought you meant http://alioth/~laney-guest/ :)
[17:13] <Laney> yeah, ambiguous statements
[17:13] <Rhonda> Like I have my http://alioth.debian.org/~rhonda-guest/stable-RC.php page. :)
[17:13] <sebner> Laney: I'm wondering about perl being so popular for such things
[17:14] <Rhonda> sebner: Because it's less prone to errors than php?
[17:14] <sebner> Rhonda: what about python, ruby, bash?
[17:14] <StevenK> I daresay bash is unsuitable
[17:14] <sebner> yeah right ^^
[17:15] <StevenK> And what about them, it was written by Laney by the language that was most suitable for them to use ...
[17:15] <Rhonda> sebner: perl offers through the AptPkg module some sweet comparison functions.
[17:15] <StevenK> Except that AptPkg is a pile of segfaulting crap. Sometimes.
[17:15] <sebner> StevenK: sure, I don't have a problem with that. I just noticed that a lot stuff in this area is written in perl
[17:16] <Rhonda> sebner: And I don't speak python or ruby, neither know wether they would offer similar functionality. And bash … well. bash. It's tough to do proper processing in bash, at least IMHO.
[17:16] <Laney> sebner: because I considered it to be the best for a quick hacky script to get the list I needed
[17:16] <Rhonda> StevenK: Never had a single one, to be honest.
[17:16] <Laney> Rhonda: and UDD offers some SQL functions to do version comparisons
[17:16] <Laney> debversion_*
[17:16] <StevenK> Rhonda: Use it on an arch that isn't i386 or amd64
[17:16] <Laney> I use it in the script :)
[17:16] <Rhonda> Laney: Oh, right. Thanks for the rminder!
[17:16] <Rhonda> StevenK: Like, powerpc? Am there. :)
[17:17] <StevenK> Rhonda: Hmph. I've had it segfault on alpha and sparc
[17:18] <Laney> I should have modelled SQL in Type Theory and written an Agda program to do it
[17:18] <Rhonda> Heading home - thanks for the nice ideas and hints!
[17:26] <kreuter> hello again, #ubuntu-motu.  I'm trying to get a package's upstart file installed.  I'm able to construct a .deb whose data.tar.gz contains the upstart file, but the file doesn't get into /etc/init when I install the .deb with "dpkg -i".  what am I doing wrong?
[17:29] <kreuter> hm.  "dpkg -L" reports that the package contains the upstart file, too.
[17:32] <abogani> Laney: upstream authors refused to fix it.
[17:33] <Laney> find out what license the binaries are under
[17:33] <Laney> if they have permission to redistribute in that form
[17:38] <soren> kreuter: If it has existed before and you deleted it back then, installing the package again will not regenerate it.
[17:38] <soren> kreuter: This is by design.
[17:38] <soren> kreuter: dpkg will respect the admin's deletion of conffiles and not regenerate them on upgrades.
[17:39] <kreuter> oh, of course.
[17:39] <kreuter> it's been a while since I've used debianoids.
[17:40] <geser> kreuter: there is an option to force dpkg to reinstall the file
[17:40] <kreuter> right.
[17:41] <abogani> Laney: I promise the last question: Where I can found instructions for create a .dfsg package (that is a oackage that recreate .orig and remove not DFSG compatible files) ?
[17:41] <soren> --force-confnew
[17:41] <soren> kreuter: dpkg -i --force-confnew file.deb
[17:41] <soren> kreuter: ...ought to do it.
[17:42] <geser> --force-confmiss should be better
[17:42] <kreuter> thanks
[17:42] <soren> geser: Right you are.
[17:47] <geser> soren: btw have you some time to sponsor bug #511356?
[17:53]  * randomaction hopes to have bug 515092 sponsored some time
[17:54] <abogani> Anyone know where I can found instructions for create a .dfsg package (that is a package that recreate .orig and remove not DFSG compatible files - sorry I don't know if this a specific name) ?
[17:56] <randomaction> abogani: try http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-origtargz
[17:57] <soren> geser: Sure, I'll take a look.
[17:57] <abogani> randomaction: Yeah! Exactly what I'm looking for! Thanks a lot!
[17:59] <soren> geser: Oh, dear, it's one of those format 3.0 things.
[18:00] <geser> soren: is that a problem?
[18:00] <soren> geser: Only that I've never dealt with them before.
[18:01]  * soren just does what he always did
[18:02] <soren> geser: Looks good. /me uploads
[18:03] <geser> soren: thanks
[18:03] <soren> Err...
[18:03] <soren> Whoops :)
[18:03] <soren> There we go.
[18:10] <MaximLevitsky> I have seen that ubuntu provides packages of latest kernels
[18:11] <MaximLevitsky> It seems that they are at http://kernel.ubuntu.com/~kernel-ppa/mainline/
[18:11] <MaximLevitsky> But I need the source of these packages
[18:11] <MaximLevitsky> Where I can download it
[18:11] <MaximLevitsky> Basicly I need ubuntu kernel package of 2.6.33-rc6
[18:12] <MaximLevitsky> As a kernel developer I never use kernel package
[18:12] <MaximLevitsky> But I published my driver, and was asked to provide an ppa to users
[18:12] <MaximLevitsky> I want to patch the 'ubuntu' kernel variant
[18:13] <MaximLevitsky> but 10.4 seems to have only 2.6.32, right?
[18:13] <geser> try asking in #ubuntu-kernel where the kernel guys are
[18:15] <MaximLevitsky> geser: will try, thanks
[18:42] <fta> kklimonda, which part of the README do you need me to clarify?
[18:44] <kklimonda> fta: the workflow is to prepare two conf files, a debian/rules file with get-orig-source that fetches source from repository and then what? just running daily.sh [pocket]?
[18:44] <fta> kklimonda, correct
[18:45] <kklimonda> fta: then everything is clear - i've spent some time after sending you a message on that
[18:45] <fta> could be manual, or in a crontab (then i advise -e to get a proper email rather than the default stdout in an ugly email from cron)
[18:48] <fta> kklimonda, use lp:drobotik for the code, and lp:~fta/+junk/ppa-confs / https://code.edge.launchpad.net/~fta/+junk/ppa-confs for some real life examples
[19:46] <alex_mayorga> Hello! Are sun JRE,JDK 1.6.0_18 in the horizon?
[19:47] <geser> would that be the sun-java6 package? if yes, then it's gone for lucid
[19:48] <alex_mayorga> geser, what would replace it?
[19:48] <persia> openJDK6
[19:48] <alex_mayorga> I'm on lucid and I still have it BTW
[19:49] <alex_mayorga> and there's https://edge.launchpad.net/ubuntu/lucid/+source/sun-java6
[19:49] <geser> alex_mayorga: if you have it installed, then apt (or other tools) don't force a removal from your system when it gets removed from the archive, but you can install it (or update) it anymore
[19:50] <geser> doesn't the app you need sun-java6 for run with openjdk?
[20:14] <alex_mayorga> geser, bug 477812
[20:18] <geser> alex_mayorga: the same applies for a (possible) update to _18. Someone from the community has to prepare updated packages.
[20:20] <alex_mayorga> geser,  I might as well package it over the weekend if somebody holds my hand ;-)
[20:20] <alex_mayorga> is this the right place?
[20:20] <geser> yes, we can try to help you
[20:21] <alex_mayorga> OK, thanks!
[20:23] <randomaction> alex_mayorga: since this is a security update, https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation is probably something you need to bookmark :)
[20:46] <kamalmostafa> I have always just ignored "W: out-of-date-standards-version 3.8.1 (current is 3.8.3)" while making bug fixes.  Now I'm packaging a new version of an upstream source tarball (by stuffing in the debian/ dir snarfed from the old Ubuntu version), and I get that warning as usual.   What's the process to resolve it?
[20:47] <sebner> kamalmostafa: check what changes need to be done and bump it
[20:47] <sebner> kamalmostafa: debian/control
[20:47] <persia> Um, maybe?
[20:47] <persia> Only bump Standards-Version for packages that are not maintained in Debian.  If Ubuntu has a different version, it's still not worth it.
[20:49] <sebner> right
[20:49] <kamalmostafa> sebner: I've merged the few documented code changes from ubuntu's and debian's previous versions -- but I don't know what the "standards-version" even implies really.
[20:50] <sebner> kamalmostafa: it's debian packaging policy, but if the package is in Debian, really try to update/get it updated there
[20:50] <geser> it's sort of a hint when the package was last checked to comply with current Debian policy
[20:51] <randomaction> Debian policy evolves over time
[20:52] <kamalmostafa> persia: This package (hamlib) is maintained in Debian.  Possibly relevant here is that the package has been orphaned.   My intent here is to package it for Debian actually.   So maybe there is value in "updating it to more recent standards compliance" -- but I don't know what that entails.
[20:52] <Laney> read upgrading-checklist.txt.gz and do what you have to
[20:53] <kamalmostafa> Laney: where's that file?
[20:53] <persia> kamalmostafa: If you want to fix that stuff and update the standards version, organise a QA upload in Debian.  Otherwise, minimise the divergence.
[20:53] <Laney> in the debian-policy package
[20:53]  * randomaction just bumps it and reads lintian output after that
[20:53] <sebner> heh
[20:54]  * sebner reads the changelog of debian-policy package on p.d.o
[20:54] <randomaction> persia: do Debian make QA uploads of new versions?
[20:54] <kamalmostafa> well... is randomaction's method really viable?  Sounds like the path of least resistance.
[20:55] <persia> randomaction: Not usually, because usually if anyone cares enough, that person adopts the package, but it can happen (usually only if required for some interesting transition when the package change is interesting, but the package remains uninteresting)
[20:56] <kamalmostafa> persia: I'd be interested in at least *looking* at the divergence... if its a one line change to bring it up to standards, then worth doing, but if its a huge ugly thing then minimizing the divergence sounds more attractive.
[20:56] <randomaction> persia: ok, that's how I imagined it - they must prefer to get a real maintainer
[20:57] <kamalmostafa> actually, it looks like the future "real maintainer" might end up being me.
[20:57] <persia> randomaction: It's always preferable to have a maintainer :)
[20:57] <persia> kamalmostafa: If you're interested, go for it :)
[20:58] <kamalmostafa> well, okay then my question really boils down to:  Am I *required* to update the standards version from 3.8.1 to 3.8.3, or is it my option here?
[20:58] <kamalmostafa> or maybe... Will debian require it?
[21:00] <persia> Debian will strongly encourage it.  Ubuntu will strongly discourage it, except for packages only in Ubuntu.
[21:01] <kamalmostafa> persia: *sigh* :-)
[21:01] <Laney> that's a clear answer
[21:01] <Laney> "It depends on what you are doing"
[21:02] <Laney> (it's really not that hard to do anyway)
[21:02] <kamalmostafa> Okay, thanks everyone.  I will go examine the policy, and will try randomaction
[21:02] <kamalmostafa> 's "just try it trick".
[21:02] <kamalmostafa> Laney: Yes, I'm certainly not against trying it -- just wasn't sure even how to begin.  Thanks again for the pointers folks.
[21:04] <randomaction> kamalmostafa: actually, the policy changes between 3.8.* version are not large
[21:05] <jcfp> Laney: tx for sponsoring sab
[21:05] <kamalmostafa> randomaction: that's what I imagined anyway -- just 0.0.2 difference can't be much, right? ;-)
[21:08] <Laney> jcfp: you are welcome
[21:15] <kamalmostafa> Re: hamlib debian standards version... That was easy!  I examined the checklist and found nothing applicable to hamlib between 3.8.1 and 3.8.3, so bumped it to 3.8.3 and lintian is happily silent.  Thanks again Laney, randomaction, persia, sebner, and geser.
[21:16] <sebner> kamalmostafa: another hint. If you want to get it into Debian you already want to bump it to 3.8.4
[21:17] <kamalmostafa> sebner: oh *now* you tell me!  ;-)   The checklist only lists up to 3.8.3.  Where do I find the 3.8.4 doc?
[21:18] <Laney> yes, you should install debian-policy from *debian*
[21:18] <sebner> kamalmostafa: that's why I said Debian. 3.8.4 is still in Debian Unstable and not yet synced to Ubuntu
[21:18] <sebner> kamalmostafa: lintian might complain that 3.8.4 is too new (wanting 3.8.3) but you can safely ignore that
[21:19] <kamalmostafa> Laney, sebner: Ah, got it.  Okay, I'll go fetch it from there.
[21:22] <kamalmostafa> Laney, sebner: hmmm... but if my lintian isn't itself 3.8.4 compliant, it won't be able to actually warn about any 3.8.4 violations, right?
[21:23] <Laney> right
[21:23] <kamalmostafa> I would think it invalid to declare the package 3.8.4 compliant based on my lintian 3.8.3 results (even if I've visually examine the 3.8.4 rules)
[21:27] <rhpot1991> if I open up a sponsorship request bug, should my bzr branch be ready to close it?
[21:30] <ScottK> kamalmostafa: Lintian doesn't define 3.8.4 compliance.  Following the rules in 3.8.4 does.
[21:32] <kamalmostafa> ScottK: Understood.  And now that I actually *look* at 3.8.4, the checklist changes from 3.8.3 are trivial and non-applicable to my package anyway.
[21:35] <rhpot1991> if someone wants to take a look: https://bugs.launchpad.net/ubuntu/+source/libhdhomerun/+bug/516762
[21:35] <rhpot1991> persia: since you have helped me in the past with this maybe you want to have a look ^
[21:48] <sebner> kamalmostafa: that applies to 95% of the packages anyways
[21:54] <persia> Any pbuilder users about?
[21:54] <persia> Err, rather pbuilder-dist users, to be specific
[21:54] <RAOF> Yes?
[21:54] <persia> Cool.
[21:54]  * RAOF needs to blog his pbuilder-on-tmpfs benchmarks still.
[21:54] <persia> So, using pbuilder-dist, how to I create an i386 builder on an amd64 system?
[21:55] <randomaction> persia: I won't claim expertise, but yes.
[21:55] <randomaction> persia: whoops, I'm on i386
[21:55] <persia> I'm mostly looking for usage information :)  I'm planning to try to port the stuff I just did to make mk-sbuild-lv create armel schroots to pbuilder.
[21:55] <RAOF> I don't have an i386 chroot on hand, but from memory it's “pbuilder-dist lucid i386 create”
[21:55] <cody-somerville> With my pbuilder setup, I would run: sudo ARCH=i386 pbuilder create
[21:56] <persia> RAOF: OK.  Makes sense.  Thanks.
[21:57] <RAOF> Or, rather, I'd have a pbuilder-lucid-i386 symlink to pbuilder-dist
[21:57] <persia> So pbuilder-dist doesn't get called directly, but is symlinked?
[21:58] <RAOF> You can call it directly, but it's more convenient to symlink it.  Then tab-autocomplete works better.
[21:59] <persia> Makes sense.  That's why I asked for users :)
[21:59] <persia> Now I just have to try to untangle the python so I can determine the conditions when I want to replace the call to debootstrap.
[22:03] <Rhonda> What's ubuntu's stand with respect to regular menu files below /usr/share/menu and freedesktop files below /usr/share/applications?
[22:03] <Rhonda> Are regular menu files hidden for Ubuntu?
[22:03] <persia> Rhonda: There's lots of debate on the matter.
[22:03] <persia> The menu files aren't shown by default, although available in a "Debian" menu if menu-xdg is installed.
[22:04] <Rhonda> persia: see LP #511912, irssi is a textbased IRC client and I'm somewhat indifferent on adding a freedesktop file when the regular menu file is there …
[22:04] <Takyoji> So I'm relatively new to packaging software; but am familiar with using Linux and bash, along with some general software development. Any recommendations as a starting point? (such as the PackagingGuide on the wiki, or the New Maintainer's Guide on Debian.org)
[22:04] <persia> Many, but not all, application have XDG desktop entries.  Some people believe this should be done upstream, and not in packaging, because of translations issues.  Others tend to just add them.
[22:05] <persia> Rhonda: I'd suggest that 511912 is "wontfix" because it's a CLI client.  If you concur, I'm happy to so mark it.
[22:07] <Rhonda> persia: I don't want to play stubborn wontfix games if it is against some guideline I am not aware of yet. :)
[22:08] <persia> Not that I know about.  I'm one of the proponents of .desktop files for everything, but I don't really see the point of doing them for CLI apps.
[22:10]  * Rhonda thanks persia :)
[22:11] <Rhonda> I'll add at least the informations that installing menu-xdg will enable that part of the menu tree.
[22:11] <persia> Sounds like a good plan :)
[22:13] <randomaction> Takyoji: besides the two you mentioned, I'd recommend https://wiki.ubuntu.com/MeetingLogs/devweek0909/PkgFromScratch which was awesome at the time (maybe some links have died since then)
[22:14] <Takyoji> alrighty
[22:18] <Takyoji> Another question I have is: is there any listing for projects that need a package maintainer?
[22:18] <persia> We don't have maintainers in Ubuntu.
[22:18] <persia> There's a heap of packages that need a maintainer in Debian, and there's another heap of stuff that only exists in Ubuntu that we'd appreciate help maintaining.
[22:19] <Takyoji> ahh
[22:22] <persia> OK.  So I've patched pbuilder-dist to permit the architecture-switching I wanted, but I'm getting a bit confused looking at pbuilder itself.  Right now, DEBOOTSTRAP="debootstrap" appears to be defined in pbuilderrc, rather than in code.  Anyone have any suggestions as to how to dynamically select an alternate debootstrap implementation depending on HOST/TARGET architecture combinations?
[22:25] <geser> have you tried setting it in the environment (export DEBOOTSTRAP)?
[22:26] <persia> geser: I haven't.  Does that work?
[22:26] <persia> As in, does a call like `DEBOOTSTRAP="echo" pbuilder-lucid-i386` print the right debootstrap command?
[22:27] <persia> Err, `DEBOOTSTRAP="echo" pbuilder-lucid-i386 create`
[22:27] <geser> hmm, probably not as pbuilderrc is sourced and overwrites those settings
[22:29] <geser> an other idea might be to write the setting into a temp file and pass it through --configfile (I need to check the code if it's source after the global one)
[22:29] <geser> or even easier: --debootstrap
[22:31] <kirkland> zooko: cheers
[22:33] <persia> geser: Ooh.  Excellent.  Thanks.
[22:39] <persia> OK.  Now I'm ready for a tester.  Anyone have an i386 or amd64, use pbuilder-dist from ubuntu-dev-tools, and have time to test something?
[22:40] <geser> sure, /me has amd64
[22:40] <mok0> persia: Will an sbuilder do?
[22:40] <persia> mok0: No.  I already make that case work.  Grab mk-sbuild-lv from bzr, and try --arch=armel
[22:41] <persia> geser: Thanks.  Please install qemu-arm-static, and then try the bzr pbuilder-dist with armel as your target architecture.
[22:42] <mok0> persia: what LP project?
[22:42] <persia> mok0: lp:ubuntu-dev-tools
[22:43]  * persia will upload the bundle if both pbuilder and sbuild support works, but otherwise wants to fix before uploading
[22:50] <mok0> persia: ... and build any old package?
[22:50] <persia> mok0: Sure, or run any old program (with schroot -p)
[22:50] <persia> For best results, pick something not currently on the FTBFS list :)
[22:51] <mok0> persia: mk-sbuild-lv failed :-(
[22:51] <mok0> W: Failure trying to run: chroot /tmp/schroot-2KvyJk mount -t proc proc /proc
[22:51] <persia> Why, and how?  It worked for me, but I didn't do lots of testing.
[22:51] <mok0> A warning really
[22:51] <persia> Are you running lucid?
[22:52] <mok0> persia: karmic
[22:52]  * persia hunts source
[22:53] <mok0> persia: I only have one workstation for my work. I haven't dared to install lucid on it
[22:53] <persia> heh.  Understood.
[22:56] <persia> mok0: I don't see any differences in build-arm-chroot between karmic and lucid.  Does mk-sbuild-lv work with your native architecture?
[22:56] <geser> persia: syntax error in line 317 (else if -> elif)
[22:57] <mok0> persia: yes I had no problems making an amd64 sbuildier
[22:58] <persia> geser: Thanks.  Fixing.
[22:58] <persia> Oddly, both show correct with my syntax highlighting.
[22:58] <mok0> Hm, you don't need to be root to run mk-lv-sbuild, right? I forget
[22:58] <geser> I guess "else: if" would also work
[22:59] <persia> mok0: You shouldn't be ruut.  It runs with sudo
[22:59] <persia> geser: Committed the change to elif anyway.
[22:59] <mok0> It actually refuses to run with sudo
[22:59] <geser> persia: E: Unknown option [--debootstrap=build-arm-chroot] was specified
[22:59] <persia> mok0: It uses sudo internally.
[23:00] <persia> geser: Hrm.  I think I have to investigate pbuilder code more.  The manpage seems to document --debootstrap, but it may trap "incorrect" values.
[23:00] <geser> persia: s/=/ /
[23:01] <persia> Just found that :)
[23:03] <geser> persia: next one: E: unsupported architecture: --arch
[23:03]  * persia was sure that was fixed, and looks again
[23:04] <mok0> Oh, hang on
[23:04] <mok0> ah
[23:04]  * geser has r572
[23:05] <persia> geser: I found the issue.  It will be in 575
[23:05] <mok0> the lvm partition was made, but schroot -l doesn't list it
[23:06] <persia> geser: pushed
[23:06] <persia> mok0: Did debootstrap complete?  It really worked for me.
[23:07] <persia> http://paste.ubuntu.com/368455/
[23:10] <geser> persia: E: Couldn't download dists/lucid/main/binary-armel/Packages
[23:10] <geser> E: build-arm-chroot failed
[23:10] <persia> Grr, mirror failure.
[23:11]  * persia tries to figure out how that is set
[23:11] <crimsun> 10
[23:11] <crimsun> gah
[23:11] <persia> 9
[23:11] <geser> 221
[23:11] <geser> that's the line for the mirror setting
[23:12] <persia> It doesn't seem to be very rich.  Compare to lines 233-281 in mk-sbuild-lv
[23:16] <persia> How does one do logical AND in python?
[23:16] <geser> True and False
[23:18] <persia> So http://paste.ubuntu.com/368530/ should (roughly) do the right thing?
[23:22] <dooooomi> mok0: about your comment on klick's copyright file: it says that all samples are gpl, so i'm not sure what exactly is missing. maybe it's just the wording that's not clear enough?
[23:23] <mok0> dooooomi: hm? Let me check again
[23:25] <mok0> dooooomi: Indeed
[23:26] <mok0> dooooomi: however I still think the new format is better, and clearer
[23:27] <mok0> dooooomi: especially because there are several copyright holders
[23:30] <dooooomi> mok0: yup, i'll just change it to the new format. seems like a good idea anyway
[23:31] <jsplice> hello
[23:32] <mok0> dooooomi: great
[23:32] <jsplice> i'm interested in contributing, but am a bit overwhelmed by all the stuff on the ubuntu site...was hoping someone could give me a push in the right direction
[23:32] <jsplice> i'm a java developer but would like to do some C++ stuff
[23:32] <mok0> jsplice: like what? Bugfixing?
[23:33] <jsplice> yea i think that would be a good place to start
[23:33] <dooooomi> mok0: if i changed just the file format of a sample (in this case, C code to .wav), does that make me a copyright holder? or should i only mention the original copyright holder?
[23:33] <persia> jsplice: Have you already encountered some bugs in c++ programs, or would you like help finding them?
[23:34] <mok0> dooooomi: Copyright applies to the content, so no I wouldn't say so
[23:34] <jsplice> i would like to help find them, and hopefully expose my self to the source, to become more familiar with linux C++ development
[23:35] <mok0> dooooomi: otherwise, I could reformat an ebook and gain copyright :-)
[23:35] <mok0> dooooomi: 3. profit
[23:35] <persia> jsplice: Well, I'd suggest asking in #kubuntu-devel, as most of their stuff is in c++.  If you've no luck there, try here again, and we can maybe find something.
[23:35] <dooooomi> mok0: hehe, makes sense
[23:35] <mok0> jsplice: do you have an LP account?
[23:35] <jsplice> persia: what is all the gnome stuff written in?
[23:36] <mok0> C
[23:36] <jsplice> mok0: yes
[23:36] <persia> Erm, one *does* gain copyright on a format shift, over the specific new media.  This doesn't grant copyright over either the original source, nor does it prevent others from converting themselves.
[23:36] <mok0> jsplice: you also need to become familiar with the general workflow on LP
[23:36] <persia> Erm, not quite.  GNOME is written in a special dialect of C :)
[23:37] <persia> (gobjects just don't belong in K&R)
[23:37] <mok0> persia: still C thought
[23:37] <persia> Well, maybe :)
[23:37] <RAOF> But object-oriented C, with closures & signals & a main loop.
[23:37] <mok0> AFAIK some of gnome developement is moving to C#
[23:38] <mok0> aka mono
[23:38] <persia> I've also seen a fair bit of Vala
[23:38] <jsplice> C#...that's interesting
[23:38] <Laney> c# is not (or should not be) aka mono
[23:38] <RAOF> As long as you're not forced to directly interact with unmanaged code, GC is the bees knees & the ant's pyjamas.
[23:39] <jsplice> mok0: will becoming more familiar with LP make contributing an easier thing to approach?
[23:39] <mok0> jsplice: I would say definitely
[23:40] <mok0> jsplice: process a dozen bugs and you know much more
[23:40] <jsplice> mok0, by process, do you mean fix them?
[23:40] <mok0> jsplice: no
[23:41] <mok0> jsplice: look at it, see if you can reproduce it, find out if there is enough info for the -devs, ask contributor to provide more,
[23:41] <mok0> jsplice: etc
[23:42] <mok0> Lets see what ubotty says
[23:42] <mok0> !bugs
[23:42] <jsplice> mok0, ok I understand what you mean now...what is the preferred IDE for this type of development?
[23:43] <mok0> jsplice: webbrowser?
[23:43] <persia> The best IDE is the one which makes you happy
[23:43] <jsplice> no i mean IDE for when i want to compile, debug, etc.
[23:43] <jsplice> if i want to reproduce the error and step through the source code
[23:44] <mok0> jsplice: You are asking because you are not familiar with Linux?
[23:44] <jsplice> mok0, for the most part yes...i use Eclipse at work for all my development
[23:44] <mok0> jsplice: ... doesn't that work for non-java projects?
[23:45] <jsplice> mok0, yes i believe it has a C/C++ plugin...i'm only asking because i didn't know if most ubuntu developers preferred a particular IDE for any reason
[23:45] <mok0> jsplice: I'm a CLI guy... I just use make, emacs, etc
[23:45] <jsplice> ah ok
[23:46] <mok0> jsplice: so, I don't know much about IDEs. Theres Kdevelop for the Kubuntu stuff, codelite,... many others
[23:48] <mok0> jsplice: generally, I feel IDEs are getting in my way :-)
[23:48] <mok0> perhaps because I don't want to bother learning a program the does something I already know how to do :-)
[23:48] <jsplice> mok0, yea, that can be true sometimes...i use spring and Java at work, so i'm not used to all the low-level configuring of make and stuff like that
[23:49] <jsplice> maven makes that easier for me with java development
[23:49] <mok0> jsplice: well, you probably will need to look at makefiles sometimes
[23:49] <jsplice> mok0, yea i figured it would be part of the learning process
[23:50] <mok0> jsplice: of course you can always come here to ask
[23:50] <jsplice> mok0, thanks, i appreciate it...i'm sure i will need help
[23:50] <mok0> jsplice: great! We really need it
[23:51] <mok0> jsplice: but first, see what you can learn about bug triaging
[23:51] <geser> persia: looks like it works now, it's downloading the base system
[23:52] <jsplice> mok0, will that information by on the LP site?
[23:52] <persia> geser: Cool.  Thanks.  I'll double-check state,and upload.
[23:52] <jsplice> *be
[23:52] <mok0> jsplice: most tutorial stuff is on the wiki... here is one link to get you started : https://wiki.ubuntu.com/Bugs/Triaging
[23:52] <jsplice> mok0, ok great...thanks
[23:53] <mok0> jsplice: there are some LP teams you can join, some of them will get you further privileges
[23:54] <jsplice> mok0, ah ok
[23:54] <mok0> jsplice: for triaging, consider yourself as sitting in "the reception"... you will be the first one to look at a bug report
[23:55] <mok0> jsplice: and you have to get the bug report in shape, to spare the -devs from having to get additional info etc.
[23:55] <jsplice> mok0, ok i get it...so like you said, that person must try to reproduce the errors and get more info if needed
[23:55] <mok0> jsplice: if you can fix the bug yourself, so much better!
[23:55] <mok0> jsplice: right
[23:56] <jsplice> mok0, what repository management software is used for all of this? subversion?
[23:57] <mok0> jsplice: Ubuntu uses bazaar
[23:58] <mok0> jsplice: you don't need to use that if you don't want to
[23:58] <mok0> jsplice: if you fix a bug, the standard way is to attach a patch to the bug report
[23:59] <jsplice> ok i see
[23:59] <jsplice> i've never heard of bazaar
[23:59] <mok0> jsplice: In the future, we may move towards a more bzr centric approach
[23:59] <mok0> jsplice: it is a DVCS mainly developed by Canonical