[01:27] <AdamDH> is there an easy way to run a shell script from inside rules?
[01:30] <coppro> it's a makefile; each line is a separate shell
[01:30] <coppro> to run a script, just run it as you would from shell
[02:03] <TheMuso> vorian: Please do not forget to include all changes since the last Ubuntu merge when uploading a merge.
[02:44] <RAOF> crimsun: Hi!  Is nouveau-kernel-source still on your todo list, or is it time to advertise again.
[02:45] <RAOF> Nice coincidence with #ubuntu+1
[02:45] <crimsun> yes, on my TODO
[02:45] <crimsun> overrun with alsa and pulseaudio bugs, surprise surprise
[02:45] <RAOF> Shock!
[02:46] <crimsun> oh, and this alsa-plugins (lib32asound2-plugins) interaction with flashplugin-nonfree on 64-bit is a bit tragic
[02:46] <crimsun> now that flashplugin-nonfree uses nspluginwrapper forcibly with the 32-bit plugin regardless of installation arch, we have a bit of a mess on Ubuntu
[02:47] <crimsun> i think what needs to occur is that ia32-libs needs to be fixed by removing alsa-plugins from it
[02:47] <crimsun> at the same time, it should depend on lib32asound2-plugins
[02:48] <lfaraone> hey crimsun
[02:48] <crimsun> otherwise, we've regressed to the release of hardy, where audio is nondeterministically inaudible, and pulseaudio and all other audio apps need to be restarted
[02:50] <crimsun> hi lfaraone
[02:57] <RAOF> crimsun: The problem with lib32asound2-plugins is that it's built from a main source, so can't b-d on ia32-libs and so can't build the pulseaudio plugin.
[02:59] <RAOF> I don't expect ia32-libs to be promoted to main anytime this geological epoch. :)
[03:02] <StevenK> What does lib32asound2-plugins require from ia32-libs?
[03:02] <StevenK> Perhaps that needs to be split out too?
[03:04] <crimsun> apparently alsa-plugins has build-time magic to provide .so symlinks and to copy .pc for pulseaudio and dbus
[03:08] <RAOF> StevenK: It requires ia32-libs in order to get 32-bit pulseaudio libs to build against.
[03:09] <StevenK> RAOF: Right, so maybe we need to split out lib32pulseaudio or so ?
[03:09] <RAOF> Yeah, that'd work.
[03:10]  * RAOF wasn't thinking of the ogre model when he did the alsa-plugins biarch work.
[03:11] <RAOF> So, who wants to take the review of nouveau-kernel-source off crimsun's overstreached TODO list?
[03:32]  * TheMuso will look into bi-arch pulse libs.
[03:32] <TheMuso> Although I don't look forward to implementing it. :p
[04:32] <milos_> good morning!
[06:16] <milos_> how much it usually takes for one package to get sponsored?
[06:30] <dholbach> good morning and happy new year!
[06:31] <Hobbsee> hey there dholbach!
[06:31] <dholbach> hi Hobbsee
[06:36] <iulian> Hiya dholbach!
[06:37] <dholbach> hiya iulian
[06:47] <fabrice_sp> Hi dholbach1 and happy new year also!
[06:48] <fabrice_sp> oops: dholbach, no dholbach1
[06:48] <dholbach> hiya fabrice_sp
[06:53] <fabrice_sp> Now that I'm back from holidays, I will start again to request review for dvsdstyler package at http://revu.ubuntuwire.com/details.py?package=dvdstyler? Is there someone willing to have a look at it? It has already been reviewed by mok0 and siretart
[07:06] <wikz> I have uploaded a new package for spicebird, would someone like to revu it? spicebird is a collaboration client and it's based on TB3a2. http://revu.ubuntuwire.com/details.py?package=spicebird
[07:15] <fabrice_sp> wikz, will have a look (even if I'm not a MOTU, I saw some errors in your packaging)
[07:21] <wikz> fabrice_sp: thank you so much :)
[07:44]  * Hobbsee does the 'upgrade to jaunty' dance
[07:46]  * TheMuso corsses his fingers for Hobbsee.
[08:06] <pwnguin> ive got a question about patches
[08:06] <pwnguin> i recall seeing that you can put comments in quilt system packages' patches
[08:07] <pwnguin> is that unique to quilt, or does the standard unified diff format allow comments?
[08:07] <didrocks> Hi everybody and happy new year \o/
[08:09] <NCommander> pwnguin, the patch utility ignores anything that isn't proper diffs, so its not quilt specific
[08:10] <pwnguin> "proper diffs"
[08:10] <pwnguin> meaning, anything that isn't the header or a chunk?
[08:17] <pwnguin> ah. the manpage say patch skips leading and trailing garbage, so you can save a message and give it to patch without processing
[08:35] <huats> morning all
[08:37] <Hobbsee> morning
[08:44]  * Hobbsee wonders why a jaunty dist-upgrade installs lilo by default.
[08:45] <Hobbsee> oh.   recommended by the kernel images. yay.
[09:16] <orly_owl> the kernel recommends lilo? why?
[09:18] <Hobbsee> orly_owl: i've no real idea, although i remember hearing something about it being needed for some configurations?
[09:18] <orly_owl> sounds odd
[09:22] <Hobbsee> i've asked in -kernel, but might be too early in the day?
[09:23] <dholbach> Is there anybody who would like to give a session about merging at the Ubuntu Developer Week? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
[09:23] <dholbach> Is there anybody who would like to give a hands-on session about python packaging at the Ubuntu Developer Week? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
[09:30]  * directhex hands Hobbsee a fresh copy of elilo
[09:41] <jpds> thekorn: re: lplib for requestsync: that's great work :)
[09:42] <thekorn> jpds, thanks, hugdaylist and grab-attachments also done but not pushed yet
[09:42] <thekorn> jpds, I think massfile is the only one which still depends on launchpadbugs
[09:43] <jpds> thekorn: It's okay, mark the branch for merging when you think they're ready and I'll copy it across.
[09:44] <thekorn> jpds, before merging this branch we should think about adding a tool for managing access tokens,
[09:44] <jpds> thekorn: You write far better python than me :)
[09:44] <jpds> thekorn: Good point.
[09:45] <thekorn> managing right now would mean "creating access tokens" right now, but in the future it can also show you all your tokens etc
[09:45] <dholbach> thekorn: that'd be awesome! :)
[09:45] <dholbach> thekorn: that should probably be in a separate package - what do you think?
[09:45] <dholbach> I could imagine that a bunch of packages (not just development tools) would make use of it
[09:46] <thekorn> dholbach, yes, maybe launchpadlib itself would be the best place for it
[09:46] <dholbach> james_w: ^ what do you think?
[09:48] <james_w> I think you are probably right
[09:54] <thekorn> ok, I will think about such an token management tool later today and write a patch
[09:56]  * dholbach hugs thekorn
[10:31] <Hobbsee> directhex: elilo?  haven't heard of that
[10:32] <directhex> Hobbsee, it's what us cool doodz with itanium use
[10:32] <directhex> Hobbsee, i.e. for EFI-based bootings
[10:32] <Hobbsee> ahhh
[11:31] <Hobbsee> hrm, another open week
[11:32] <Hobbsee> some of those sessions look interesting
[11:33]  * Hobbsee hopes logs appear in findable places.
[12:12] <directhex> doko__, do you have plans to package the new ironpython 2.0?
[12:13] <doko__> directhex: yes, but python2.6 comes first. go ahead if you want to do the update
[12:16] <directhex> jms@osc-franzibald:/tmp/IronPython-2.0$ mono ipy.exe
[12:16] <directhex> IronPython requires .NET 2.0 SP1 or later to run.
[12:16] <directhex> this is gonna be fun
[12:18] <doko__> directhex: it's available in jaunty
[12:19] <directhex> doko__, 2.0?
[12:24] <directhex> hm, doesn't seem to run
[12:47] <milos_> would somebody be kind and review my debdiff?
[12:49] <nhandler> milos_: What is it for? And is it a simple one? (I only have a few minutes)
[12:50] <milos_> I am not in a hurry so, you can look at it when you have more time
[12:50] <milos_> nhandler, http://launchpadlibrarian.net/20901340/yagiuda_1.19.5%7Eppa1.debdiff
[12:51] <milos_> nhandler, it's about 3 lines of code
[12:51] <nhandler> Is there a bug report?
[12:51] <milos_> yup nhandler https://bugs.launchpad.net/bugs/312842
[12:53] <khashayar> Hi folks. I've been backporting ardour 2.7.1 for hardy and intrepid. It's the first time I attempt to do official backporting. Is there a backporter who could tell me what the next step is?
[12:55] <nhandler> milos_: Well, looking at the patch, it is not perfect. For one thing, the syntax for closing a launchpad bug is (LP: #312842). Closes is for Debian bugs. Second, you need to get the the patch applied in jaunty before it can get into Intrepid. Third, your version is not correct. You want to look at the version currently in jaunty and just bump the ubuntu revision. You also should filter out the changes to config.sub and config.guess from you
[12:56] <Laney> you got cut: "from you..."
[12:56]  * nhandler is starting to hate irssi
[12:56] <stefanlsd> milos_: to add to nhandler - you have lines showing change where you've changed white space... (dont do that)
[12:57] <stefanlsd> milos_: we want to make the diff as minimal as possible
[12:57] <nhandler> http://paste.ubuntu.com/100286/
[12:57] <nhandler> milos_: Actually, it looks like the package is auto synced from Debian. Is the patch relevant to debian? If so, send the patch upstream
[12:58] <nhandler> milos_: If not, you can subscribe ubuntu-universe-sponsors to the bug report after making the changes. That will ensure it gets looked at
[12:58]  * nhandler has to run now
[12:58] <Hobbsee> nhandler: you want http://scripts.irssi.org/html/splitlong.pl
[12:59] <maxb> khashayar: https://help.ubuntu.com/community/UbuntuBackports
[12:59] <milos_> nhandler, I don't know bout Debian. I would search it.
[12:59] <stefanlsd> nhandler: or, not talk so much :P
[13:02] <milos_> nhandler, ok I will try to fix this and will send again to ubuntu-universe-sponsors mailing list
[13:05] <milos_> stefanlsd, about lines with white space, I should just delete those lines from patch?
[13:08] <khashayar> maxb: Thanks. I've built packages using prevu, and they're currently being built in ppa. Where do I find someone to take a look at them?
[13:09] <Laney> nhandler: I have a script which automatically splits lines taht get too long if you're interested
[13:10] <stefanlsd> milos_: yeah, you can do that (or fix your source and redo the debdiff). either way
[13:10] <Laney> nhandler: Oh, you already got linked, nm
[13:19] <vorian> khashayar: are they new packages?
[13:20] <vorian> if so you can upload them to revu http://revu.ubuntuwire.com/
[13:20] <hyperair> nhandler: i've made the changes you've requested in codelite
[13:25] <khashayar> vorian: thanks, I'll check that out.
[13:25] <khashayar> vorian: sorry, they're backports, not new packages.
[13:26] <Laney> khashayar: The backports wiki you got linked to explains it
[13:30] <khashayar> Laney: I've read that page, but there are some things I don't understand. Will investigate some more and get back here later, possibly with questions. Thanks again.
[13:34] <vorian> hi rrittenhouse
[13:48] <rrittenhouse> hi vorian
[13:48] <rrittenhouse> vorian, how are you?
[13:48] <vorian> good good
[13:53] <jpds> thekorn: Do you know what could be wrong here: http://pastebin.ubuntu.com/100312/ - it's not working for me against staging either and I've redone the cookie file, everything..
[13:56] <thekorn> jpds, I will have a look at it in about 10 minutes
[13:56] <jpds> thekorn: I'm not in a hurry.
[14:00]  * hanska waves
[14:02]  * ScottK waves back.
[14:12] <directhex> hanska visiting ubuntuland again?
[14:13] <directhex> come to steal our bugs? :o
[14:13] <hanska> directhex: nah :)
[14:13] <hanska> directhex: have some plans about becoming a MOTU too, some day
[14:13] <soc> hi
[14:13] <soc> i could need some packing help ...
[14:13] <soc> i would like to package the droid font for ubuntu/debian
[14:13] <soc> can someone help me?
[14:14] <soc> i plan to start working on it in 50 minutes ...
[14:15] <thekorn> jpds, which version of py-lp-bugs are you using? is it jaunty, intrepid or earlier?
[14:15] <hanska> soc: what's your problem?
[14:16] <soc> hanska: i never really did it before
[14:17] <soc> so i decided to start with a typeface, because i don't have to compile anything and the dependencies are easier ...
[14:18] <thekorn> jpds, what's the result of
[14:18] <thekorn> python -c 'from launchpadbugs.http_connection import HTTPConnection; h = HTTPConnection("path/to/cookie"); print h.needs_login()'
[14:21] <soc> ok, i'll be back in 45 minutes ...
[14:55] <stefanlsd> anyone have a pointer to why my watch file isnt working... looking for this  ftp://ftp.uk.linux.org/pub/linux/Networking/netkit/netkit-tftp-(.*)\.tar\.gz    and debug returns nothing - uscan debug: requesting URL ftp://ftp.uk.linux.org/pub/linux/Networking/netkit/  -  uscan debug: received content: [End of received content]
[14:55] <bddebian> Heya gang
[14:56] <ScottK-desktop> Heya bddebian.
[14:58] <bddebian> Heya ScottK-desktop
[15:05] <stefanlsd> for info - it needs   opts=passive   before the ftp:// to do pasv ftp
[15:06] <stefanlsd> could just be where i'm sitting
[15:11] <RainCT_> dholbach: hey
[15:11] <dholbach> RainCT_: hiya :)
[15:12] <RainCT_> dholbach: I don't arrive home until around 17:15 UTC on mondays :(
[15:12] <dholbach> RainCT_: ah ok - I guess I'll just pester the others then :)
[15:12] <dholbach> RainCT_: would you like to give another session during the rest of the week? :)
[15:13] <RainCT_> dholbach: I guess the Getting Started is supposed to be an intro for your session?
[15:13] <dholbach> RainCT_: a very general introduction with room for lots of questions about ubuntu development in general
[15:17] <ScottK> dholbach: Where do HoF bugs get put? Do I just tell you?
[15:18] <stefanlsd> can i just start grabbing merges from mom?  i see we're past 25th dec. and still 106 merges left... and alpha 3 coming up
[15:18] <dholbach> ScottK: yeah :)
[15:20] <ScottK> dholbach: Currently it looks like all my non-sponsor uploads are changed-by scott@kitterman.com and signed-by ubuntu@kitterman.com (even though both email addresses are on the key) so ALL my uploads get counted towards sponsored uplods.
[15:20] <ScottK> uplods/uploads.
[15:20] <dholbach> ScottK: I'll check that - are both mail addresses in LP?
[15:20] <ScottK> Dunno if you care about special casing that, but it doesn't seem fair.
[15:20] <RainCT_> dholbach: I was thinking about doing it the week before, but I think I'll be busy finishing my research project that week, so dunno..
[15:20] <ScottK> dholbach: yes.
[15:20] <dholbach> ScottK: alright, I'll let you know
[15:21] <dholbach> RainCT_: oh... I was thinking about some session about a different topic
[15:26] <AdamDH> hey all trying to run a shell script from my make file with  $(shell scripts/patch) but I get scripts/patch: 23: /tmp/buildd/msp430-binutils-msp430-binutils-2.18-msp430/patches/msp430-binutils-2.18-msp430-cvs.0.0.20090105.patch: Permission denied line 23 is when it runs my function, I am running pbuilder build ../*.dsc as root
[15:27] <AdamDH> its chmodded +x as well
[15:29] <maxb> AdamDH: If it's within the diff.gz part of the source package, then you need to remember that diffs don't preserve modes. So, it won't be +x by the time the build actually runs
[15:30] <AdamDH> so I need to somewhere in my rules chmod it +x so it executes
[15:31] <maxb> That, or run $(shell /bin/sh the_script) instead
[15:35] <AdamDH> the script works perfectly when not been called by make! I will give that a go, thanks
[15:36] <AdamDH> still get permission denied, now I get it when it reads in the /tmp/buildd/msp430-binutils-msp430-binutils-2.18-msp430/patches/msp430-binutils-2.18-msp430-cvs.0.0.20090105.patch: Permission denied patch
[15:52] <soc> mhhh, sorry took longer to get rid of that snow :-/
[15:52] <soc> i want to package the droid fontface, can someone guide me?
[15:53] <vorian> soc: have you read any kind of documentation yet?
[15:53]  * vorian will show a couple of links if not
[15:53] <soc> yes
[15:53] <pmjdebruijn> soc: how are they licenseD?
[15:53] <soc> apache
[15:54] <soc> in https://wiki.ubuntu.com/PackagingGuide/Complete#Packaging%20From%20Scratch : The underscore, "_", between the package name (hello) and the version (2.1.1), as opposed to a hyphen, "-", is very important. The packaging tools will look for a file with that exact name. If you get it wrong, the result is that the tools will incorrectly assume that there is no original source at all and the package will be built as a Debian native package.
[15:54] <dholbach> directhex: do you think we could have a session at Ubuntu Developer Week about Mono Packaging? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
[15:54] <vorian> how far have you gotten soc?
[15:54] <soc> so my first question:
[15:54] <vorian> ah :)
[15:54] <soc> i have the font files, should i put them in an archive?
[15:54] <soc> i'm just starting
[15:54] <directhex> hanska, what do you think?
[15:55] <directhex> or sebner or Laney
[15:55] <pmjdebruijn> soc: are the android fonts Apache licensed? seriously?
[15:55] <soc> yes
[15:55] <soc> i opened them with fontforge
[15:55] <hanska> directhex: pong
[15:55] <pmjdebruijn> cool :)
[15:55]  * hanska was going to bed
[15:55] <hanska> :)
[15:55] <soc> license states:
[15:55] <directhex> dholbach, possibly, just gotta bounce ideas off clever people like hanska first
[15:56] <directhex> hanska, bed? it's 4pm!
[15:56] <hanska> directhex: didn't sleep tonight :/
[15:56] <hanska> (5pm here though)
[15:56] <pmjdebruijn> soc: use a current font package, like liberation as an example
[15:56] <pmjdebruijn> soc: ttf-libration (for example)
[15:56] <hanska> dholbach: tell me :)
[15:56] <soc> Licensed under the Apache License, Version 2.0
[15:56] <soc> pmjdebruijn: i alredy did that ...
[15:57] <pmjdebruijn> soc: huh? well it should be simple enough then
[15:57] <soc> but i'm not really sure, what things i can reuse
[15:57]  * hanska just saw the link, second, let me look at it
[15:57] <sebner> directhex for mono packaging \o/
[15:57] <Laney> directhex: recruits to transition the libraries? ;)
[15:57] <hanska> Laney: ahah right :)
[15:57] <directhex> hanska, you'll muck up your circadian rhythms if you go to bed early. anyway... ubuntu developer week is a week of exciting lessons for new devs (and new skills for old devs) on given topics
[15:57] <directhex> Laney, could be, could be :p
[15:57] <dholbach> hanska, directhex: we're going to have Ubuntu Developer Week again with a weel full of one-hour-long tutorial sessions
[15:58] <sebner> directhex for mono packaing \o/
[15:58] <sebner> *packaging
[15:58] <sebner> ^^
[15:58] <soc> so basically i have to write a .dsc file and that diff file, am i right?
[15:58] <dholbach> I just thought it'd be great to demonstrate to people what's special about mono packaging and answer a bunch of questions
[15:58] <hanska> dholbach: on IRC? :)
[15:58] <sebner> hanska: sure
[15:59] <dholbach> hanska: yep
[15:59] <directhex> dholbach, i agree
[15:59] <hanska> uhm
[15:59] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep is the preliminary schedule
[15:59] <hanska> directhex: you know I don't have connection where I study :/
[15:59] <hanska> directhex: and I'll leave again on 12 :/
[15:59] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek the schedule (and logs) of last time
[15:59] <hanska> :(
[15:59] <Laney> leave?!?!?!
[15:59] <directhex> hanska, crap, i forgot about that
[15:59] <hanska> directhex: I would've really joined you guys :/
[16:00] <Laney> it's ok
[16:00] <Laney> you can record a video
[16:00] <Laney> we'll play it at the start
[16:00] <sebner> lol
[16:00] <hanska> Laney: lol
[16:00] <hanska> Laney: I can also call by phone, heh :P
[16:00] <Laney> dholbach has done MOTU videos in the past!
[16:01] <hanska> Laney: well.. if I were to talk about mono packaging with some sort of screencast
[16:01] <directhex> the ideal would be to get meebey involved, but he's been AWOL for a few days
[16:01] <soc> mhh
[16:01] <hanska> Laney: I believe that an open terminal and me typing commands (even if I could also record voice), that wouldn't be too exciting!
[16:01] <Laney> haha
[16:01] <hanska> :)
[16:01] <Laney> It'd excite me
[16:02]  * hanska excites Laney 
[16:02] <hanska> oO
[16:02] <dholbach> hanska, directhex: I think it'd be enough to have a small example or two, talk through it and answer heaps of questions
[16:02] <Laney> for sure
[16:02] <Laney> helloworld-sharp
[16:02] <hanska> dholbach: I would've done that, sure, but I have internet connection only on weekends
[16:02] <sebner> more like debian/control and rules magic
[16:02] <dholbach> hanska, directhex: and explain how to help out on the Mono Packaqing goodness
[16:02] <dholbach> hanska: right :/
[16:02] <soc> so now i'm going to put the font files in an archive and call it ttf-droid_1.00b112.orig.tar.gz?
[16:02] <sebner> hanska: remembers me on me ^^
[16:02] <sebner> *myself
[16:02] <dholbach> anybody else up for giving a hands-on session at UDW?
[16:02] <hanska> sebner: just because I'm at university :/
[16:03] <sebner> hanska: university without internet. wired
[16:03] <Laney> weird*
[16:03] <sebner> Laney: +1
[16:03] <hanska> sebner: Uni has, my home there hasn't
[16:03] <hanska> (it's ~140km from here)
[16:03]  * sebner wouldn't stay in a home without internet :\
[16:03] <directhex> slomo can help too. right slomo?
[16:04] <Laney> directhex: "How to package ikvm", right?
[16:04] <hanska> Laney: \o/
[16:04] <dholbach> hanska: where do you live?
[16:04] <soc> mhh the version is "Version 1.00 build 112"
[16:04] <soc> how should i translate that?
[16:04] <directhex> Laney, i need to perfect face-stabbing-over-IP i think
[16:04] <soc> 1:112?
[16:04] <hanska> dholbach: Palermo (university), Mazara del Vallo (home city, where I am now) --> Italy
[16:04] <soc> or 1.00b112?
[16:04] <dholbach> hanska: ah ok
[16:04] <directhex> soc, 1.00b112 works for me
[16:04] <soc> ah ok
[16:05] <slomo> directhex: ikvm? no, packaging that needs more time than i currently have ;)
[16:05] <hanska> soc: also something like 1.00~b112 wouldn't be too bad
[16:05] <soc> so now i have the fonts in that archive
[16:05] <soc> ah ok
[16:05] <directhex> slomo, nah, ikvm is almost in reasonable shape now (!)
[16:05] <sebner> directhex: anyways, you just need a simple example and show howto deal with the control and rules file (also howto patching the makefiles) and answering questions, that's all
[16:05] <soc> ttf-droid_1.00~b112.orig.tar.gz is the filename now ...
[16:05] <hanska> directhex: openpgp-sharp, it's a project of mine :)
[16:05] <directhex> slomo, an ubuntu developer week session on mono packaging. you've experience with one of the bigger examples
[16:05] <sebner> hanska: with *good* makefiles? ^^
[16:06] <hanska> sebner: I wrote that by hand, so... but it needs monodevelop installed :P
[16:06] <hanska> sebner: however, I could make a preview-release-tarball
[16:06] <sebner> hanska: heh
[16:06] <slomo> directhex: ... like mono itself? or which one do you mean?
[16:06] <hanska> (with a sane Makefile)
[16:06] <soc> directhex, hanska: or shouldn't i create my own archive? should i better download that "snapshot" file from git???
[16:07] <soc> problem is, that there are more things in that archive that i don't need ...
[16:08] <directhex> slomo, no, CLI packaging in general. just education for people, so they can package mono apps/libs more effectively. same as other dev week tutorials, really
[16:08] <directhex> slomo, i'd like to agree to dholbach's request, but i want to have people on-hand who are super smart & can answer real-world questions
[16:09] <soc> directhex, hanska: should i use the generated archive from the git ( http://android.git.kernel.org/?p=platform/frameworks/base.git;a=snapshot;h=6b8721393400f8e98bb6c29d47b38c79be7ade32;sf=tgz ) which has many files i don't need or should i extract the fonts out of that archive, and place them in a new archive?
[16:09] <dholbach> directhex: I'm sure that having a few examples at hand you can talk about, knowledge about general packaging techniques and a few people you can ask on IRC if you don't know the answer yourself off-hand, that's fine :)
[16:09] <hanska> soc: do you intend to package the whole platform as well?
[16:10] <hanska> directhex: I can give you my phone number *hrhr*
[16:10] <soc> no, i just want to have a package for the font
[16:10] <soc> hanska: just a ttf-droid with the fonts
[16:10] <hanska> soc: then yes, make a separate source package, and state what you did in a debian/README.source file
[16:10] <soc> ah ok
[16:11] <directhex> hanska, i should make a README.source for ikvm!
[16:11] <soc> ok, then now i extract the files from my orig.tar.gz again
[16:11] <hanska> soc: also, implement a get-orig-source target in debian/rules, which should grab the snapshot (the same exact revision you got), and mangle it appropriately to have the final tarball
[16:11] <soc> cd into it and do dh_make?
[16:11] <hanska> soc: sure.
[16:11] <hanska> soc: remember, debian/README.source and get-orig-source in debian/rules.
[16:11] <soc> hanska: that's the thing i don't know how to do
[16:12] <hanska> get-orig-source should automatize all the steps you did to get the original tarball
[16:12] <soc> because of that i asked, if i can just create my own source archive instead of cleaning up the original ...
[16:12] <hanska> soc: sure you can, but you should give other users/developers the chance to get the same exact tarball you created
[16:12] <hanska> s/should/must/
[16:12] <hanska> (as far as I'm concerned)
[16:13] <directhex> dholbach, let me try and get ahold of meebey, since he's been doing this stuff a few years longer than me
[16:13] <dholbach> directhex: if meebey can just hang out there or be around to answer the questions that you really can't answer, that's fine
[16:13] <dholbach> directhex: we'll have a bunch of really really new people there
[16:13]  * hanska to bed, later guys!
[16:13] <soc> mhh, i can't see how ttf-liberation did that ...
[16:13] <dholbach> and we're going to get them excited
[16:14] <dholbach> and it's going to be great
[16:14] <soc> hanska: is the debian/rules a bash file?
[16:15] <directhex> soc, it's a Makefile
[16:15] <soc> what should get-orig-source do? just get the archive?
[16:15] <soc> or overwrite the files locally?
[16:15] <directhex> soc, download (or generate) an orig.tar.gz
[16:15] <soc> ah k
[16:15] <soc> where should that orig.tar.gz be placed?
[16:16] <directhex> dholbach, if i can pin down meebey, i can check over things like suggested example packages, or times/days he'll be about, or things like that
[16:16] <soc> in the source folder?
[16:16] <directhex> soc, policy says in ../ i think
[16:16] <soc> ah ok
[16:17] <soc> btw. should i put the font files in my archive in a folder?
[16:17] <dholbach> directhex: awesome - the earlier we fix up the schedule the better :)
[16:17] <soc> and do the font files need some special permissions?
[16:17] <soc> or will fix the installer that for me
[16:17] <soc> because atm the files belong to me, not to root
[16:17] <directhex> dholbach, hence [16:12] /me jumps up & down on meebey
[16:18] <dholbach> hehe
[16:18] <directhex> soc, your rules file should do any general cleaning up of things
[16:18] <dholbach> somebody asked for a session about merging? anybody up for talking about merging?
[16:18] <soc> ah k
[16:18] <soc> i'll guess i try it and then rinse and repeat :-/
[16:19] <directhex> i wonder how long to assign to heckling in a mono session...
[16:20] <soc> ttf-droid_1.00~b112$ dh_make -e soc@krg-nw.deThe directory name must be <package>-<version> for dh_make to work!
[16:20] <soc> I cannot understand the directory name or you have an invalid directory name!
[16:20] <hanska> soc: just what it says
[16:20] <hanska> ttf-droid-1.00~b112
[16:21] <directhex> soc, when you extract foo 1.0's orig, it should go into a folder called foo-1.0
[16:21] <soc> so i have to call the archive ttf-droid_1.00~b112.orig.tar.gz, but the folder inside it ttf-droid-1.00~b112?
[16:22] <soc> type of package?
[16:22] <soc> single binary, multiple binary, library, kernel module or cdbs?
[16:22] <hanska> soc: single binary
[16:22] <soc> even if there are multiple *.ttfs?
[16:22] <hanska> yes.
[16:23] <directhex> it means "single binary package"
[16:23]  * hanska really goes now
[16:23] <soc> ah ok
[16:23] <soc> thanks!
[16:23] <directhex> as opposed to lots of binary packages from one source
[16:23] <soc> atm Licence states: blank
[16:23] <soc> ah ok, i understand
[16:23] <soc> how can i tell dh_make the licence?
[16:24] <directhex> generally your upstream should come with a COPYING or LICENSE file in the tarball
[16:24] <soc> Skipping creating ../ttf-droid_1.00~b112.orig.tar.gz because it already exists
[16:24] <soc> Currently there is no top level Makefile. This may require additional tuning.
[16:24] <soc> Done. Please edit the files in the debian/ subdirectory now. You should also
[16:24] <soc> check that the ttf-droid Makefiles install into $DESTDIR and not in / .
[16:24] <mok0> soc: man dh_make
[16:24] <soc> yes
[16:24] <soc> where do i have to place that file?
[16:28] <soc> mhh, i have both a NOTICE file with Copyright, License, the "No warranties" paragraph and the full apache license text
[16:29] <soc> and i have a README.txt with Copyright, License, the "No warranties" paragraph and a comment "This directory contains the fonts for the platform. They are licensed under the Apache 2 license."
[16:29] <soc> which one is the right ne?
[16:30] <savvas> I think you have to add them all if you include all of those files
[16:31] <soc> savvas: afaik the debian distribution has some shared directory with all common licenses ... does that matter
[16:33] <directhex> soc, common-licenses? are your files under Apache 2.0?
[16:33] <soc> yes?
[16:34] <savvas> Well um.. you can add a note in debian/copyright:
[16:34] <savvas> On Debian systems, the complete text of the GNU General
[16:34] <savvas> Public License can be found in `/usr/share/common-licenses/GPL'.
[16:35] <savvas> at least this is what dh_make command creates :)
[16:35] <directhex> s/GPL/Apache-2.0/
[16:39] <savvas> correct directhex!
[16:39] <savvas> soc: I would just mention one by one which licenses are used for which files - just make sure you are allowed to package/distribute them using those licenses :)
[16:39] <soc> ok
[16:40] <soc> only apache2.0 is used
[16:40] <savvas> ah cool then
[16:42] <soc> what is the debian/watch file?
[16:42] <directhex> it's used by "uscan" to let the archive inform you of new upstream releases
[16:43] <savvas> https://wiki.ubuntu.com/PackagingGuide/Complete#Creating%20And%20Using%20A%20debian/watch%20File
[16:43] <directhex> i.e. DEHS (and whatever ubuntu equivalent exists) periodically uses the watch file to detect a source tarball newer than your packaged version
[16:43] <Laney> UEHS!
[16:44] <soc> mhhh
[16:44] <soc> the font was build by Steve Matteson
[16:44] <soc> but Google has the copyright and the trademark
[16:44] <soc> so who should be "upstream autjor"?
[16:45] <savvas> the best way to clear out copyrights and licenses is to contact the authors directly :)
[16:45] <soc> mhh
[16:46] <savvas> the project is on google code?
[16:46] <soc> on kernel.org
[16:46] <savvas> ah ok
[16:46] <savvas> I thought my watch file could help you :)
[16:46] <savvas> I'm playing around with fspy currently :P
[16:47] <savvas> http://mytty.org/fspy/
[16:49] <soc> do i have to put the whole Apache license text in that file?
[16:49] <soc> or is this enough?
[16:49] <soc> License:
[16:49] <soc>     Apache 2.0 License
[16:49] <soc> The Debian packaging is (C) 2009, Simon Ochsenreither <soc@krg-nw.de> and is licensed under the Apache 2.0 License, see `/usr/share/common-licenses/Apache-2.0'.
[16:50] <superm1> crimsun, what would you think about adding something to set the default Digital Input Source to be a digital device in the init script for alsa?  If it's available, it should work, otherwise it should fall back nicely i'd think..
[16:59] <savvas> soc: looks good to me. Here's an alternative: http://paste.ubuntu.com/100426/plain/
[17:01] <soc> do you think i can cite parts of the press release from ascender for the description?
[17:01] <hanska> soc: "17:49 <soc> The Debian packaging is (C) 2009, Simon Ochsenreither [..]"
[17:01] <hanska> the (C) has non legal value
[17:01] <hanska> soc: the only recognized terms are "copyright", "copr." and "©"
[17:02] <hanska> soc: so fix that to be "Copyright (C)"
[17:02] <soc> hanska: i just took what dh_make generated :-P
[17:02] <soc> that wasn't my idea
[17:02] <savvas> that's true
[17:02] <hanska> soc: or, it would be better if you use "Copyright ©" (that's an utf-8 character, if you can't see it, it's the C in a circle)
[17:03] <savvas> So, the debian version of dh_make uses "The Debian packaging is copyright (C)" ?
[17:03] <soc> i can see it :-)
[17:03] <soc> no problem ...
[17:04] <soc> "The Debian packaging is (C)"
[17:04] <soc> not even copyright :-P
[17:04] <hanska> soc: add Copyright there!
[17:04] <savvas> hanska: did you mention this to the maintainers of the dh-make package?
[17:05] <soc> no
[17:05] <soc> ok, i did
[17:05] <hanska> savvas: not yet, but it's a well-known issue among us Debianists :)
[17:05] <hanska> savvas: there also was some thread on debian-legal
[17:05] <savvas> darn
[17:10] <soc> ok, i have copyright and control
[17:11] <savvas> 2 down, 98 to go
[17:11] <savvas> just kidding :p
[17:11] <soc> :-P
[17:11] <soc> next thing is the defoma file
[17:12] <soc> ttf-droid.defoma-hints i guess ...
[17:19] <soc> wth???
[17:19] <soc> ubuntu doesn't have the package i need ... *argh*
[17:19]  * soc fetches libft-perl from debian ..
[17:20] <soc> no installable --- *grrrrrr*
[17:20] <ScottK> soc: If there's a package in Debian that's not in Ubuntu there's generally a good reason why not.
[17:20] <soc> ah k
[17:20] <soc> i need the file FreeType.pm for defoma-hints
[17:21] <ScottK> So the first step would be to find out why we don't have it.
[17:21] <soc> defoma-hints truetype DroidSans.ttf
[17:21] <soc> Wait for second...
[17:21] <soc> defoma-hints Can't locate FreeType.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at (eval 4) line 2.
[17:21] <soc> yes ...
[17:21] <soc> that would be good
[17:21] <soc> it depends on perlapi-5.8.8 ... weird...
[17:21] <soren> soc: Deleted in intrepid-release on 2008-09-05  (Reason: (From Debian) RoQA; buggy, orphaned )
[17:22] <soren> soc: perlftlib, that is.
[17:22] <soren> soc: ...which is the source package for libft-perl
[17:22] <soc> so i can't use defoma-hints naymore?
[17:23] <soren> I have no idea. I'm just telling you why libft-perl isn't there anymore.
[17:23] <soc> yes, i see
[17:23] <soc> but that doesn't really help me :-/
[17:24] <soren> Well, it tells you that Debian also doesn't have the package anymore, so you're hardly alone with your problems.
[17:26] <jcfp> hi all. For sabnzbdplus I'd like to get ubuntu's libjs-mochikit updated. The current mochikit package (1.3.1) appears to be copied straight from debian. What's the best approach here? Ask the debian javascript maintainers?
[17:27] <hanska> jcfp: yes, please. As a Debian maintainer I'd like to keep the delta between the two distros as narrow as possible
[17:27] <hanska> jcfp: reportbug -B debian libjs-mochikit
[17:28] <hanska> jcfp: file a wishlist bug, asking for the version you need to be pushed in
[17:28] <hanska> (however, other guys' mileage may vary here, that's just my humble opinion.)
[17:29] <Laney> jcfp: You might ask if they have an update in the works, or are planning one soon and offer to help them with it to speed it along
[17:32] <jcfp> hanska: thanks, sounds good
[17:33] <jcfp> Laney: I'll try to ask nicely. The update itself appears simple though I know nothing about that git stuff etc.
[17:34] <jcfp> After that, will it automatically appear in ubuntu or should i ask/file a bug somewhere?
[17:37] <soc> mhhh "Width = Variable" is certainly wrong for a monospaced font, isn't it?
[17:39] <james_w> jcfp: you will need to file a "sync request"
[17:40] <ScottK> jcfp: After it's in Debian you'll need to ask to have it sync'ed into Ubuntu as we are past the point in this release cycle where it's done automatically.
[17:40] <jcfp> thanks
[17:49] <Laney> jcfp: looks like a pretty easy update. As it's team maintained, you could visit their IRC channel and ask if they mind you doing the update
[17:50] <Laney> jcfp: Actually, it's already in their git!
[17:51] <jcfp> Laney: serious? I only checked at packages.debian.org
[17:51] <Laney> http://git.debian.org/?p=pkg-javascript/mochikit.git
[17:51] <jcfp> So all there's to do is file the sync request in launchpad
[17:51] <Laney> jcfp: No, they need to upload it
[17:51] <Laney> (to debian)
[17:51] <Laney> maybe they haven't finished doing it yet, you should pop over and ask how you can help
[17:53] <jcfp> ah. last stupid question: which is their irc channel?
[17:55] <jcfp> Laney: I tried the update locally, just for testing with sabnzbdplus, and it appeared (to me that is ;) no further changes would be needed... but we'll see.
[17:55] <pochu> there's #debian-java on OFTC, not sure if that's the one you're looking for
[17:55] <Laney> javascript
[17:55] <jcfp> ok thanks all
[17:56] <Laney> TheMuso, crimsun: I'm seeing symptoms of that pulse race bug again. Have you heard/experienced similar elsewhere?
[17:56] <Laney> (Intrepid)
[18:00] <soc> can i delete every file in the /debian folder that i don't use?
[18:10] <coolbhavi> hi james_w
[18:10] <directhex> doko__, FYI, ironpython depends: mono >= 2.2
[18:11] <james_w> hello coolbhavi
[18:27] <soc> ok, i have built the package
[18:27] <soc> i got one error
[18:27] <soc> make[1]: *** Keine Regel, um »clean« zu erstellen.
[18:27] <soc> "No rule to create clean" or something like that ...
[18:27] <soc> is that bad?
[18:28] <maxb> A clean target is mandatory: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
[18:28] <maxb> dh_make should have supplied you with an example one
[18:29] <soc> i deleted that ...
[18:32] <soc> #!/usr/bin/make -f
[18:32] <soc> include /usr/share/cdbs/1/rules/debhelper.mk
[18:32] <soc> include /usr/share/cdbs/1/class/makefile.mk
[18:33] <soc> this is my rules file ...
[18:33] <soc> ithought this was enough
[18:35] <maxb> Hm. It is supposed to be enough.
[18:36] <maxb> Perhaps your problem is more complex than a single line of error can explain
[18:37] <jpds> thekorn: I'm using intrepid, but tjaalton tried both.
[18:38] <thekorn> jpds, the output of the command I gave you would be intresting,
[18:39] <soc> mhh
[18:39] <thekorn> jpds, I'm about to leave, can you please file a bugreport against py-lp-bugs with the result
[18:39] <soc> i want to upload my source package to my ppa, to try it, how can i do that?
[18:40] <jpds> thekorn: I get False.
[18:41] <thekorn> jpds, then you should not get this error :)
[18:41] <thekorn> I'll check the logic behind it again tomorrow
[18:42] <khashayar1> Hi, I've been talking to the ubuntustudio guys about becoming their backporter. There's a bugreport on launchpad requesting a backport of ardour. I've successfully built backports of 2.7.1 for hardy & intrepid in my ppa (and locally with prevu), and I've read the wiki page about backporting. Still, I'm a bit confused what the next step should be. There's the bugreport, there's the package, but what's the next n
[18:45] <AdamDH> can any one tell me why http://www.pastebin.ca/1300274 this is running configure make and make install but nothing is there in the package after the .deb has been created
[18:45] <jmarsden|work> soc: Once it builds cleanly on your own machine and in a pbuilder, you can use dput to upload it to your PPA... https://help.launchpad.net/Packaging/PPA
[18:45] <soc> just read it, thanks, yes
[18:47] <_MMA_> ScottK: If ya can help out khashayar here that would rock.
[18:47] <soc> although i don't understand why it doesn't build cleanly
[18:47] <soc> i let cdbs handle that ...
[18:47] <ScottK> _MMA_: Sure thing.
[18:47] <maxb> khashayar1: You need a better/fixed IRC client, or you need to manually avoid saying things longer than ~400 characters
[18:47] <ScottK> khashayar1: What bug do you have?
[18:47] <ScottK> That too.
[18:48] <soc> btw, do i need to set some permissions on files in the debian folder?
[18:48] <soc> or is this done automatically?
[18:48] <khashayar1> Oh, sorry maxb, I'll try to think of that. New to irc.
[18:48] <_MMA_> bug 299287
[18:48] <maxb> khashayar1: You got truncated at "....but what's the next n" - better IRC clients will autosplit long lines into multiple messages
[18:49] <khashayar1> maxb: Thanks, I'll try to find something better (using pidgin now).
[18:49] <khashayar1> _MMA_: thanks
[18:50] <khashayar1> ScottK: I've built packages for hardy and intrepid.
[18:50] <ScottK> khashayar1: OK.  Did you test that the work?
[18:50] <khashayar1> That is, I've backported ardour 2.7.1 successfully. The packages are in my ppa.
[18:50] <khashayar1> Yes, they work well for me.
[18:50] <ScottK> khashayar1: You said you'd filed a bug?  What bug?
[18:50] <khashayar1> (Quick tests though)
[18:51] <_MMA_> ScottK: Above.
[18:51] <ScottK> For backports that's considered sufficient except in special cases.
[18:51] <ScottK> OK.
[18:51] <khashayar1> ScottK: I'm hoping to be able to backport ubuntustudio related packages on a regular basis.
[18:51] <ScottK> khashayar1: Please put the exact version/revision you tested in the bug.
[18:52] <ScottK> khashayar1: Did you have to make any changes to the package?
[18:52] <_MMA_> It's for 2.5 but 2.7.1 is latest and in Jaunty. But scons in Hardy/Intrepid is a pain. So hopefully this can work.
[18:52] <khashayar1> For intrepid, no changes at all.
[18:52] <khashayar1> For hardy, I had to make two small changes.
[18:52] <ScottK> Intrepid already has 2.5.  Did you do 2.7?
[18:53] <ScottK> if the package needs changes then you need to provide a debdiff for that too.
[18:53] <khashayar1> ScottK: Yes, 2.7
[18:54] <ScottK> OK.  Are you trying to get 2.7 in both or 2.7 in Intrepid and 2.5 in Hardy?
[18:54] <khashayar1> Alright, I'll read up on debdiff. Should that debdiff be attached to the bug report?
[18:54] <ScottK> Yes
[18:54] <khashayar1> 2.7 in both
[18:54] <khashayar1> Well, hardy's my priority.
[18:54] <ScottK> OK.  Bug  says 2.5.
[18:54] <ScottK> We need to have both because we don't want Hardy to have a higher version than Intrepid.
[18:55] <khashayar1> Yes, I thought so, that's why made both.
[18:55] <khashayar1> Should I file a new bug concerning 2.7?
[18:55] <ScottK> khashayar1: Just edit the existing one.
[18:55] <khashayar1> Alright, let's see what I can do.
[18:55] <ScottK> You can actually do both Hardy and Intrepid backports in one bug in the future using also affects.
[18:56] <khashayar1> Good to know.
[18:56] <_MMA_> ScottK: Thanx for the help.
[18:56] <ScottK> No problem.
[18:57] <ScottK> _MMA_: NCommander can also help on backports stuff too.
[18:58] <khashayar1> By the way, I didn't file that bug (_MMA_ did). I assume that means I can't edit it?
[18:58] <_MMA_> Ahh... That's right.
[18:59] <_MMA_> khashayar1: Done. (refresh page)
[19:00] <khashayar1> Thanks :-)
[19:02] <khashayar1> I found a debdiff howto. I'll read that first, and then I'll post on the bug report. Thanks a lot for your help, ScottK.
[19:03] <ScottK> khashayar1: No change.
[19:03] <ScottK> change/problem.
[19:03] <ScottK> Sorry.  Doing too many things at once.
[19:03] <khashayar1> Haha, I see that :-)
[19:07] <soc> hmmm, i have uploaded a source package to launchpad, how long will it take until it shows up in the webfrontend?
[19:10] <cody-somerville> soc, did you get an accept e-mail?
[19:10] <soc> mom
[19:11] <soc> no
[19:12] <AdamDH> any one mind taking a look at this and telling me why its not installing anything into the completed deb? I have used the same install line from a previous package I did and cannot see why it will not work in this case, http://www.pastebin.ca/1300274, bugging me as I cannot see anything wrong
[19:13] <AdamDH> everything completes with out an error
[19:13] <khashayar1> ScottK: I've updated commented on the bug report with a debdiff, a link to my ppa, and some other info.
[19:13] <AdamDH> *compiles
[19:13] <ScottK> khashayar1: What's the bug for Intrepid?
[19:20] <_MMA_> ScottK: I though tit could be done for multiple releases? Though my bug was only for Hardy.
[19:20] <ScottK> _MMA_: It can, but I thought he said he'd done a separate bug already.  Just use also affects to add intrepid-backports
[19:21] <_MMA_> I don't think he filed another. I'll let him chime in.
[19:31] <lfaraone> Do sync requests tke a while to process once ack'd by motu?
[19:32] <jpds> lfaraone: archive admins are bake from holiday.
[19:32] <jpds> So it shouldn't take too long now.
[19:33] <lfaraone> jpds: kk, thanks.
[19:34] <jpds> back*
[19:34]  * lfaraone has a tendency to pester, and is trying to ensure I don't.
[19:57] <gerlumpi_> hallo
[20:05] <khashayar> ScottK: Sorry, I was gone for a while there. No, there's no report about intrepid. Just the one mentioned here.
[20:05] <ScottK> khashayar: Then add intrepid-backports using also-affects.
[20:06] <ScottK> khashayar: Does Intrepid need the changes too?  If so, another debdiff.
[20:10] <khashayar> No changes for intrepid, I only changed the changelog for that.
[20:57] <cody-somerville> who maintains mdt?
[20:57] <Adri2000> is it maintained?
[20:58]  * cody-somerville croaks.
[21:04] <Adri2000> cody-somerville: launchpad says wgrant and I'd say maybe lucas as well
[21:04] <cody-somerville> wgrant, lucas: ping
[21:06] <cody-somerville> wgrant, lucas: compare-versions seems to get tricked if there is multiple versions of a package in an archive
[21:20] <oliver_g_> hello
[21:20] <oliver_g_> I'm quite new to Ubuntu packaging and would like to package a Gedit plugin I've made
[21:21] <oliver_g_> and there are some questions about this...
[21:21] <oliver_g_> maybe someone can help me with this?
[21:22] <jpds> oliver_g_: It's best to just ask away, and those who can help will help :)
[21:22] <oliver_g_> for start, there is no version number, so is it ok to just create a version number like "git20080105-1" ?
[21:23] <jpds> oliver_g_: I would go for: 0.0~gitYYYYMMDD-1 .
[21:23] <directhex> and use the date, not a git hash (i've seen that before o_o)
[21:23] <jpds> This way you wouldn't need an epoch for the first release (ie. 1.0).
[21:25] <oliver_g_> doesn't the ~ sign give problems later when extending the version to 0.0~gitYYYYMMDD-1~ppa1 ?
[21:25] <directhex> oliver_g_, no.
[21:25] <jpds> Not at all.
[21:25] <oliver_g_> or is it ok to have as many tildes in the version as needed?
[21:25] <oliver_g_> ah ok
[21:25] <jpds> oliver_g_: And if it is an Ubuntu package not in Debian, it should end in -0ubuntu1.
[21:26] <oliver_g_> right... that's another question: how do I decide for which system the package is?
[21:27] <oliver_g_> should I create different control files for Debian Lenny, Ubuntu Hardy, Intrepid...
[21:28] <oliver_g_> (that was probably a somewhat dumb question because it shows how I didn't grasp the very basics, but anyway :-)
[21:30] <oliver_g_> in essence, after going through the examples in PackagingGuide, there's a source package as result... Is that package Intrepid-specific, or Ubuntu-specific, or would it basically work with every .deb system?
[21:30] <jpds> oliver_g_: Sometimes it can be exactly the same, depends on the package.
[21:32] <jpds> oliver_g_: There are no dumb questions, everyone had to start off at one point.
[21:32] <oliver_g_> So if I create a package from scratch and want to get it into Ubuntu repos, I add -0ubuntu1 (for bookkeeping), and if it later goes into Debian, the -0ubuntu1 part is removed but the package can otherwise remain the same?
[21:33] <jpds> The package would need a -1 entry in the changelog after the -0ubuntu1 one.
[21:33] <AdamDH> hi, been on this allmost 5 hours now, any ideas why this http://www.pastebin.ca/1300420 rules is not installing anything into the completed deb? I get no errors etc
[21:33] <AdamDH> i get a few dh_install: Compatibility levels before 4 are deprecated.
[21:34] <jpds> AdamDH: echo 5 > debian/compat .
[21:34] <AdamDH> but it still goes onto dpkg-deb: building package `msp430-binutils' in `../msp430-binutils_msp430-binutils-2.18-msp430-cvs.0.0.20090105_amd64.deb'.
[21:34] <jpds> AdamDH: And make sure you Build-Dep: debhelper (>= 5).
[21:34] <AdamDH> jpds where do I run that? in the TLD of my package folder?
[21:35] <AdamDH> i am using allot of dh commands in my rule but there is nothing including anything or setting anything is this right?
[21:35] <jpds> AdamDH: You just need a debian/compat file with a number between 5 and 7.
[21:36] <maxb> AdamDH: Is your "cd src && $(MAKE) install prefix=$(CURDIR)/debian/msp430-binutils/usr" line being executed and if not why not?
[21:36] <AdamDH> yes its been ran
[21:36] <AdamDH> I can see the output from it
[21:37] <maxb> Then, why isn't it doing anything?
[21:37] <AdamDH> the deb is just empty
[21:37] <AdamDH> it all runs with no errors apart from the ones about compatability levels
[21:38] <maxb> You are running dh_install twice, that doesn't sound right (though would not cause this problem)
[21:39] <serialorder> I want to replace pt.po in the source tree with a better transation and call it pt_PT.po. The package uses quilt for its patch system. There is also a pt.gmo file do I also need to remove that as well? If so should I removed pt.{po,gmo} using the patchsystem or just delete them from the source tree?
[21:40] <AdamDH> maxb there are no errors as usally it would stop if there was a make error
[21:40] <AdamDH> it just runs and gives me an empty deb
[21:42] <AdamDH> at a quick glance installing fr.gmo as /tmp/buildd/msp430-binutils-msp430-binutils-2.18-msp430/debian/msp430-binutils/usr/share/locale/fr/LC_MESSAGES/bfd.mo
[21:42] <AdamDH> so install is running
[21:43] <maxb> AdamDH: Your problem is that you have not set the debhelper compatibility leve.
[21:43] <AdamDH> just set that and re ran it and it built the package, never spotted that
[21:43] <maxb> In the ancient fallback compatibility level that you are currently using, debhelper expects the package files to be installed somewhere else
[21:44] <AdamDH> do i have to have a compat file or can I set it in the rules file?
[21:44] <maxb> You should have a compat file
[21:44] <maxb> There is a way to set it in the rules file but it is deprecated, so don't do that
[21:44] <AdamDH> thanks maxb and jpds I have a working package now
[21:45] <jpds> AdamDH: Brilliant. :)
[21:45] <AdamDH> i will create a compat file with 5 in it
[21:45] <AdamDH> i can use the same rules to build the others with some slight mods
[21:53] <oliver_g_> I've got another question... When developing some app, the code goes into a version control system, so there's a definite location for original code... But for the debian/ directory files, there is no such location, right?
[21:53]  * serialorder is sad wants to answer my question ;(
[21:54] <oliver_g_> I mean the files in debian/ are hard to make (same as for the app code) but there is no central repository for those files?
[21:59] <maxb> AdamDH: You might consider renaming all those -time-stamp suffixes to just -stamp. That would more match the general convention I've seen in other packages, and also reflect the fact that they are more stamps of a certain step being complete, than anything to do with time, particularly
[21:59] <maxb> serialorder: Do you know what a .gmo file is? I don't off-hand
[22:01] <AdamDH> maxb:I will do that, any other tips for the rules file? I have to remove some files that are made because they are part of the normal binutils package
[22:04] <serialorder> maxb, they are the compiled translations generated from a po file
[22:05] <maxb> AdamDH: You are hardcoding the --build and --host architectures, that's definitely a bad thing
[22:06] <agent47a> can someone name a source package off the top of their head that uses a docbook file to generate a man page with docbook-to-man?
[22:06] <maxb> serialorder: eww. Nasty that the source ships compiled files
[22:07] <maxb> oliver_g_: Most packagers will keep the debian/ directory in a version control system too
[22:09] <maxb> serialorder: I suppose then you'll need to add the pt_PT.po in a quilt-patch, and maybe just patch the build system to ignore the pt.po? Or let it be installed as well, but then delete it from the installation shortly after the "make install"
[22:11] <AdamDH> maxb yes just noticed that will change it
[22:11] <maxb> You don't seem to be using PACKAGE_TARGET for anything
[22:12] <maxb> --prefix=/usr is the default for almost all packages, consider omitting it
[22:12] <maxb> Are the CC and CFLAGS definitions actually doing anything? I doubt it.
[22:13] <maxb> What is the remove-patch target for and does it really want a stamp file?
[22:14] <maxb> oh, sorry, I have just seen the use of CC and CFLAGS
[22:14] <AdamDH> CC and CFLAGS are been used
[22:14] <AdamDH> CFLAGS are needed for gcc4
[22:15] <maxb> My personal opinion is that it would be clearer not to use variables for CONFIGURE_ARGS, CC, and CFLAGS, since they are expanded only once, in fairly simple circumstances
[22:16] <maxb> Overriding prefix= in "make install" is not the recommended way to do it. DESTDIR is the standard make variable for this purpose. I would hope binutils would support it?
[22:17] <AdamDH> yes I dont think the prefix=is required
[22:17] <AdamDH> I can do it with the configure flags
[22:17] <maxb> No!
[22:17] <maxb> That's an even worse way to do it.
[22:17] <maxb> Some packages will hardcode their configured paths into scripts and or binaries.
[22:18] <maxb> The correct way to do it is to configure for the *installed* location, and use the DESTDIR make variable to install into an alternative directory
[22:18] <maxb> The clean target currently does not actually clean up
[22:19] <maxb> The binary-indep target builds no packages, so there is no reason for it to depend on build and install
[22:19] <maxb> "confiure" (sic) is misspelt in .PHONY
[22:19] <maxb> Right, I'm done :-)
[22:21] <AdamDH> thanks maxb I will inplement all of that and see where I go from there
[22:22] <AdamDH> is usr the correct path to install it to?
[22:22] <AdamDH> can I use say /opt/msp430 and ensure its exported correctley
[22:24] <maxb> An official distro package should definitely fit under the /usr hierarchy and stay away from /opt.
[22:25] <serialorder> agent47a,  btpd does I also found a bunch of other packages that do in google with the search string 'build-depends: docbook-to-man'
[22:31] <AdamDH> maxb even a cross compiler?
[22:32] <maxb> Yes. Here is an example for a different architecture: http://packages.ubuntu.com/jaunty/binutils-avr
[22:35] <hanska> night!
[22:38] <crimsun> superm1: RE: 'Digital Input Source' -> can we assume, though, that people will want that instead of 'Mic' or 'Front Mic'?
[22:39] <superm1> it's got nothing to do with that
[22:39] <superm1> separate mixer items
[22:39] <superm1> it's a matter of analog vs digital, not "which analog"
[22:39] <superm1> crimsun, ^
[22:39] <crimsun> except for on the codecs where options for 'Digital Input Source' _offers_ 'Mic' or 'Front Mic'!
[22:40] <superm1> then presetting "Digital Mic 1" wouldn't harm them as the command to set the default would fail
[22:40] <khashayar> I've been trying to learn some packaging recently, so I've been having a few rounds with lintian.
[22:41] <khashayar> What's one supposed to do with with "binary-without-manpage", if there's no manpage provided?
[22:41] <crimsun> not necessarily, because 'Digital Mic' and 'Digital Mic 1' have both been seen as input choices
[22:41] <crimsun> yes, obviously if the latter isn't an option, it will fail nicely
[22:41] <superm1> so perhaps then setting "Digital Mic 1" followed by "Digital Mic"
[22:41] <superm1> so that if it uses the former it works, and then falls back to the latter if that's what's used
[22:42] <AdamDH> maxb so how do i rewrite this so I dont have prefix as that example uses it as well cd src && $(MAKE) install prefix=$(CURDIR)/debian/msp430-binutils/usr
[22:43] <crimsun> superm1: i say go ahead and make the change; we can sort out any mess before 15 jan
[22:43] <superm1> crimsun, okay will do, thanks
[22:48] <maxb> AdamDH: $(MAKE) install DESTDIR=$(CURDIR)/debian/msp430-binutils
[22:58] <superm1> crimsun, something else i've wondered, is there any sane way for filtering extraneous mixers from even being offered at all?  Things like analog loopback mixer?
[22:59] <crimsun> superm1: oh man, that's crazy talk
[22:59] <superm1> crimsun, haha
[23:00] <crimsun> superm1: yes, one could selectively blacklist certain mixer elements in the driver, but deciding which are extraneous would be contentious
[23:00] <crimsun> superm1: which really implies, "why expose those controls at all"? and that's a slippery slope
[23:00] <superm1> crimsun, ah i can see what you'd mean there.
[23:02] <superm1> crimsun, well i suppose as the "defaults" get set better, the need for users to go and check tons of mixers in the gnome tool will decrease, so those will at least be hidden more and more so
[23:04] <AdamDH> thanks for all the help maxb
[23:05] <AdamDH> once I have done this gcc should be half the work
[23:05] <AdamDH> there are no man pages for this apart from the offical binutils ones will that be fine to try and get it submitted?
[23:10] <Laney> you should write ones for any new binaries
[23:21] <AdamDH> I will add that to my todo list but testing can still happen even if there are no man pages
[23:23] <Laney> right
[23:56] <AdamDH> any one spot anything I have missed http://www.pastebin.ca/1300531 the package build and tests out ok
[23:56] <AdamDH> *builds