=== asac_ is now known as asac
[00:56] <NCommander> ScottK, I'm glad you agree on debhelper since it would make life a lot easier w.r.t. to backporting stuff
[01:00] <directhex> NCommander, DH7 for hardy!
[01:00] <NCommander> yup
[01:01] <directhex> 7.0.13ubuntu1~dhx1 worked fine for me, before upgrading to intrepid ;)
[01:01] <NCommander> It means making backports will be tons easier since now we don't need to mangle the rules
[01:01] <directhex> 0 changes needed from 7.0.13ubuntu1 according to my changelog
[01:02] <NCommander> right
[01:02] <directhex> i'd be very happy about an official backport, since i could erase it from my ppa
[01:03] <NCommander> We could also do DH7 for dapper
[01:03] <NCommander> So if we backport something, it will stop meaning having to fudge things down to DH4
[01:04] <directhex> ehm... my spidey sense is screaming "check the required version of dpkg-dev" at me
[01:04] <directhex> i wonder why. let me check...
=== jrib is now known as Guest64524
[01:05] <NCommander> directhex, it built w.o issue
[01:05]  * NCommander sees if it installs and works
[01:05] <NCommander> directhex, note, you can't drop dh7 from your PPA, since PPAs don't have backports enabled :-/
[01:05] <directhex> oh anuses -_-
[01:05] <NCommander> Its a long standing bug
[01:06] <directhex> so is lack of debian targets for debian/ubuntu synergy
[01:06] <NCommander> ScottK, when backporting something to hardy from jaunty, do we also need to backport it to intrepid?
[01:06] <directhex> but important things like new launchpad logos take precedence!
[01:06] <NCommander> (since hardy-backports > intrepid base)
[01:07] <Hobbsee> directhex: you'll never win that battle.
=== Guest64524 is now known as jrib
[01:07] <NCommander> Hobbsee, we've been promised it was going to happen "real soon now"
[01:07] <Hobbsee> NCommander: yeah, yeah.
[01:07] <directhex> which battle? i fight a lot of losing battles
[01:07] <directhex> then grumble & move on to other things
[01:08]  * NCommander notes we should just dump everyting in Hardy backports into a PPA, then make it so other PPAs can depend on it 
[01:08] <Hobbsee> directhex: the one about wanting (and getting) launchpad to implement more possibly useful stuff, like fixing regressions, or adding useful features
[01:08] <Hobbsee> NCommander: that would be the sensible optoin
[01:08] <directhex> i probably shouldn't mention that opensuse's PPA-like service can build against pretty much any major distro, from RHEL to Debian
[01:08] <directhex> it might be seen as pushing a pro-novell agenda or some crap
[01:08] <NCommander> directhex, they don't take debian source packages
[01:08] <directhex> NCommander, sure they do
[01:09] <NCommander> I'm told you put a .orig.tar.gz, and then a debian folder
[01:09] <NCommander> not the normal tar.gz/diff/dsc
[01:09] <directhex> it takes orig/diff/dsc
[01:10] <directhex> and some other random undocumented things
[01:10] <directhex> i ran a test build, let me find it
[01:10] <NCommander> ScottK, poke
[01:10] <NCommander> ScottK, if we backport something from jaunty to hardy, should we also backport it to Intrepid?
[01:11] <directhex> NCommander, here we go. an old mono backport build, targeting etch & hardy, from orig/diff/dsc. https://build.opensuse.org/package/show?package=Mono&project=home%3Aoerc
[01:11] <NCommander> ah
[01:11] <NCommander> Neat
[01:11] <StevenK> NCommander:  debhelper | 7.0.13ubuntu1 |      intrepid | source, all
[01:11] <NCommander> Jaunty has a slightly newer one
[01:12] <NCommander> which fixes a few bugs
[01:12] <StevenK> "Meh"
[01:13] <NCommander> StevenK, https://bugs.edge.launchpad.net/intrepid-backports/+bug/295495
[01:13] <NCommander> :-)
[01:13] <ubottu> Launchpad bug 295495 in intrepid-backports "Please backport debhelper 7 from intrepid" [Undecided,Won't fix]
[01:13] <StevenK> Won't fix
[01:13] <NCommander> in intrepid
[01:14] <NCommander> in Hardy its In Progress
[01:14] <StevenK> That was actually my point. Backporting debhelper from Jaunty to intrepid is silly
[01:14] <directhex> because it doesn't fix the core issue of the bug
[01:14] <directhex> since it's still 7
[01:15] <directhex> and the purpose of the bug is to have 7 in 7less versions
[01:15] <directhex> much as bug fixes are nice
[01:15] <NCommander> my concern is the upgrade path
[01:16] <NCommander> Is it a bad thing is hardy-backports > intrepid?
[01:16] <directhex> know what? time for beds.
=== jelmer_ is now known as Guest29580
=== _jason is now known as jrib
[04:39] <ScottK> NCommander: There isn't a strict requirement to backport to every release.  I think it's a good idea for upgraders though.
[04:39] <NCommander> ScottK, Well, I just requested to backport from intrepid. so no issues
[04:39] <NCommander> But we maybe should draft a policy on backporting across multiple releases
[04:41] <ScottK> NCommander: I think that's a good idea.  It needs to be a function of the upgrade path.   For example, if you backport to Dapper there's no need to hit Gutsy because that's not on the upgrade path for Dapper anymore.
[04:41] <NCommander> But ATM, due to our backports, the Hardy->Intrepid upgrade path may not work as expected
[04:41] <NCommander> (well, anything we've backported from jaunty, which isn't much)
[04:41] <ScottK> Agreed.
[04:42] <NCommander> Generally speaking, if you backport to Hardy, intrepid should just work
[04:42] <NCommander> THe only issue is do-release-upgrade disables backports on upgrade AFAIK
[04:42] <ScottK> NCommander: It doesn't.
[04:42] <NCommander> Oh
[04:43] <NCommander> So as long as backports remains enabled, no issues
[04:43]  * ScottK just looked at a box I recenly upgraded and backports is still enabled.
[04:43] <NCommander> We should talk to jdong and make it an offical policy I guess
[06:32] <OltreIrc`1517> .:::] Ci40 @ Tutti [:::. »BuTT3rF|y sCr|pT«»rEvOLuTiOnZ»v3.1.5«
[06:32] <OltreIrc`1517> !list
[06:32] <ubottu> Hi! I'm #ubuntu-devel's favorite infobot, you can search my brain yourself at http://tinyurl.com/5zfb6t - Usage info: http://wiki.ubuntu.com/UbuntuBots
=== dfiloni is now known as devfil
=== RainCT_ is now known as RainCT
=== _nightwish is now known as nightwish
[14:34] <alex-weej> is the console font supposed to be something other than the default, old IBM(?) PC one?
[14:35] <alex-weej> i just booted intrepid live CD and noticed that the console font was different
[14:35] <alex-weej> but in my hardy->intrepid upgraded machine it's not
=== bureflux is now known as afflux
=== chuck_ is now known as zul
=== johanbr_ is now known as johanbr
[17:43] <bdheeman> hello
[17:43] <bdheeman> can i build x86_64 packages of an x86 machine, if yes - how?
[17:44] <directhex> no.
[17:44] <bdheeman> s/of/on/
[17:46] <bdheeman> directhex: but, i saw openwrt build system builds kind of some ARM and other packages even on an x86 machine
[17:47] <directhex> you can cross-compile, but you can't use a cross-compiler for package building in the conventional sense
[17:47] <directhex> cross-compiling means using a different gcc (or different gcc flags)
[17:47] <bdheeman> ok, thanks
[17:47] <directhex> and you need all the libs and so on...
[17:48] <bdheeman> so, better buy an amd64 machine
[17:49] <directhex> well... it's certainly an easier prospect than trying to build packages you can't test, with a cross-compiler
[17:49] <directhex> consider also: a PPA, since PPAs do amd64
[17:55] <bdheeman> directhex: i have not heard about PPA's here in India
[17:56] <bdheeman> but AMD machine are quite popular there days
[18:05] <directhex> bdheeman, PPA. personal package archive. a build service on launchpad.net
[18:07] <bdheeman> directhex: thanks, i was not aware of that service
=== thegodfather is now known as fabbione
[19:08] <superm1> slangasek, I believe i've got all of the important pieces in order for mythbuntu live disks via livecd-rootfs and cdimage now.  i can reliably build livefs'es that are the right size at least.  could you set up the cron job(s) for building those now for whenever dailies start back up again?
[19:37] <jdong> does Ubuntu squashfs support the LZMA compression method?
[19:37] <jdong> i.e. in-kernel?
[19:37] <pwnguin> i doubt it
[19:38] <jdong> I figured
[19:38] <jdong> the userspace tools support it which made me curious
[19:38] <jdong> I'm re-doing my backup strategy... again... and I'm considering squashfs archiving
[19:38] <pwnguin> if squashfs makes it into the kernel
[19:38] <pwnguin> it might make sense to visit it
[19:38] <pwnguin> lzma
[19:39] <pwnguin> the liveCD is perennially out of space
[19:39] <pwnguin> (or maybe perpetually)
[19:39] <jdong> makes it into... the linus tree you mean?
[19:39] <jdong> well bi-anually out of space ;-)
[19:40] <pwnguin> yea, when i looked into it last, squashfs decided to try to get into the linus tree again
[19:40] <jdong> right, I understand that's the reason why there's no LZMA support
[19:40] <hyperair> vlowther: ping
[19:40] <jdong> i.e. upstream doesn't want any more compression methods in the kernel
[19:41] <pwnguin> jdong: you should probably double check with the ubuntu kernel ML
[19:42] <pwnguin> i donno if there's plans or if i missed something, etc
[19:54] <RainCT> (btw, does someone know how to fix/workaround some applications which are displaying solid black instead of input from the webcam? I believe this to be because the webcam uses JPEG compression and the applications don't support it.)
[19:56] <mohbana> hi, anyone familiar with fontconfig? what's wrong with this; http://pastebin.com/m53266bde
[20:12] <jdong> grumble stupid pulse dying after suspend
=== ajmitch_ is now known as ajmitch
[20:17] <hyperair> jdong: there's a bug regarding that
[20:18] <hyperair> jdong: and a fix ready
[20:18] <jdong> hyperair: neat :)
[20:18] <hyperair> jdong: bug 202089
[20:18] <ubottu> Launchpad bug 202089 in pulseaudio "Pulseaudio is blocking normal sound after resume" [Low,In progress] https://launchpad.net/bugs/202089
[20:18] <hyperair> it seems to be assigned to someone else, and in progress
[20:18] <hyperair> i realized that after i came up with a workaround and created a debdiff
[20:19] <hyperair> so now i'm actually wondering what i should do
[20:20] <directhex> cry!
[20:21] <jdong> hyperair: well it's been assigned to crimsun, so I'd say it's in the best hands :)
[20:22] <hyperair> =\
[20:22] <hyperair> directhex: hmph
[20:23] <pwnguin> who assigned it to crimsun?
[20:23]  * hyperair has no idea
[20:23] <pwnguin> if it wasn't crimsun himself, might as well at least attach the debdiff
[20:24] <hyperair> pwnguin: it's attached
[20:24] <jdong> pwnguin: I see a SRU-compatible debdiff attached
[20:24] <ScottK> According to the activity log he assigned it to himself.
[20:25] <pwnguin> hyperair: then i guess you just wait ;)
[20:25] <hyperair> i guess
[20:25] <hyperair> speaking of sru and debdiffs... could someone help me out with bug 267922 /
[20:25] <hyperair> ?
[20:25] <ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/267922/+text)
[20:26] <pwnguin> eep
[20:26] <hyperair> lol
[20:26] <hyperair> i don't have any trouble accessing that
[20:26] <hyperair> bug 267922
[20:26] <ubottu> Launchpad bug 267922 in banshee "Banshee hangs up/crashes when pluggin in MTP-USB-Player" [Undecided,Confirmed] https://launchpad.net/bugs/267922
[20:26] <hyperair> there we go
[20:29] <jdong> hyperair: ok that one is within my umbrella of authority, lemme take a look at your debdiff
[20:30] <hyperair> jdong: thanks =)
[20:31] <jdong> hyperair: where did the patch come from? did you write it?
[20:31] <jdong> it's pretty big, just trying to understand it
[20:31] <hyperair> jdong: extracted from trunk
[20:31] <jdong> hyperair: gotcha
[20:32] <jdong> hyperair: ok I acked the SRU for you
[20:33] <hyperair> thanks
[20:33] <jdong> subscribe ubuntu-universe-sponsors
[20:33] <jdong> let me know if you don't get sponsorship in a reasonable timeframe
[20:33] <hyperair> alright
[20:33] <hyperair> what's a reasonable timeframe?
[20:33] <jdong> within a few days, I'd say.
[20:33] <hyperair> okay
[20:35] <hyperair> jdong: should i unsubscribe motu-sru?
[20:36] <jdong> hyperair: no need ,keep them subscribed
[20:36] <hyperair> okay
[21:04] <Heller_Barde> hai
[21:05] <Heller_Barde> I am an Archlinux user and would like to know how i can find out how ubuntu packages are built and packaged. Can someone help me with that?
[21:05] <directhex> Heller_Barde, specifically...?
[21:06] <Heller_Barde> directhex: actually the background is that i would like to build some packages (around xorg) with ubuntu patches because i have serious performance issues with opengl applications
[21:07] <hyperair> Heller_Barde: what do you want to know?
[21:08] <sebner> !packageing | Heller_Barde
[21:08] <ubottu> Sorry, I don't know anything about packageing
[21:08] <sebner> !packaging | Heller_Barde
[21:08] <ubottu> Heller_Barde: The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
[21:08] <Heller_Barde> and i found my way to the patches and everything and i found out that its not only the patches that made the difference but obviously too how it is built.  i got as far as debian/rules but that's source-package specific, i now would like to know how the actual packages are built
[21:08] <hyperair> debian/rules
[21:08] <hyperair> that's the key to everything
[21:08] <Heller_Barde> ubottu: oh cool, ill look at that and get back to you with questions
[21:08] <ubottu> Error: I am only a bot, please don't think I'm intelligent :)
[21:08] <Heller_Barde> ah
[21:08] <Heller_Barde> ^^
[21:08] <hyperair> heh
[21:08] <Heller_Barde> sebner i meant
[21:08] <Heller_Barde> ^^
[21:09] <hyperair> Heller_Barde: debian/rules is a Makefile. everything goes in there
[21:09] <sebner> Heller_Barde: :) np
[21:09] <Heller_Barde> hyperair: yes, i saw that. but from one source packages several binary packages are made
[21:09] <directhex> okay, the whirlwind tour. source packages (with a few exceptions) come in three files - foo.orig.tar.gz contains the upstream software, converted to gzip where required. foo.diff.gz contains a gzip diff of all the changes between the upstream tarball, and what is needed for packaging - typically it should only contain the "debian" folder, which has the files in it about how to build. foo.dsc is a manifest, pointing to the other tw
[21:09] <directhex> o files
[21:10] <directhex> the key files in the debian/ folder are "rules" and "control"
[21:10] <hyperair> Heller_Barde: patches in debian/patches, configure flags in debian/rules somewhere, post installation stuff also in debian/rules
[21:10] <Treenaks> directhex: hurricane warning ;)
[21:10] <directhex> "control" is the list of information about the package - dependencies, general package metadata, and contains the list of binary packages (and their deps) as well as info on the source package. the metadata is used by apt/dpkg
[21:11] <directhex> Treenaks, i prefer to think of it as a monsoon
[21:11] <Heller_Barde> mhhmhh but lets say i have the source packages, i patched everything and then built it (which is pretty tough without a debian system ^^) and then what? where comes the splitting stuff up in the several packages?
[21:11] <directhex> "rules" is a makefile, which does the configure.make stuff. in most cases, it'll use a "helper" app of some kind, such as debhelper, which will do assorted cleanup - generating automatic deps, putting files into actual packages, and so on
[21:11] <hyperair> Heller_Barde: then there's postinst, postrm, preinst, prerm which are hooks that are run when installing/upgrading/removing the package on the user's system. kinda like the one archlinux has.. what was it called? something.install?
[21:12] <Heller_Barde> hyperair: yep
[21:12] <hyperair> damn my archlinux packaging is rusty.
[21:12] <directhex> Heller_Barde, the splitting is done by a debhelper command in debian/rules
[21:12] <Heller_Barde> hyperair: how so? there is soo little to know ^^
[21:12] <Heller_Barde> directhex: ahh, i seem to have missed that
[21:13] <Heller_Barde> i'll scour through mesa-src again
[21:13] <hyperair> Heller_Barde: i know. i forgot it heh. the names mostly. i still remember how to make a PKGBUILD build() function
[21:13] <directhex> Heller_Barde, specifically, look for lines about dh_install and dh_installdeb
[21:13] <hyperair> wait, you're poking around with mesa? i've got experience with that one.
[21:13] <Heller_Barde> yes
[21:13] <hyperair> Heller_Barde: exactly what are you looking for?
[21:14] <directhex> Heller_Barde, those two will use a list of files matching the binary package name - e.g. libmoon0.install contains the list of files which dh_installdeb will put into the libmoon0 package
[21:14] <Heller_Barde> i use compiz as performance: 3-8 fps in archlinux (with testing) and 30-40 fps in ubuntu 8.10 on a intel x3100 (965gm chipset)
[21:14] <Heller_Barde> and i tracked it down to some packages
[21:15] <hyperair> regarding the package splitting, you needn't really look into those... archlinux doesn't split packages
[21:15] <hyperair> so yo wouldn't be able to use it anyway
[21:15] <Heller_Barde> hyperair: actually it does
[21:15] <hyperair> eh? since when?!
[21:15] <Heller_Barde> *smiles sheepishly*
[21:15] <Heller_Barde> just some
[21:15] <hyperair> O_o
[21:15] <Heller_Barde> exactly the ones i need
[21:16] <hyperair> how?
[21:16] <Heller_Barde> well its just that intel-dri is built from mesa-src
[21:16] <hyperair> @_@
[21:16] <Heller_Barde> no idea why its not integrated
[21:16] <Heller_Barde> no fucking clue (sry for language)
[21:16] <hyperair> lol
[21:16] <hyperair> anyway
[21:16] <hyperair> here's how the build process works.. mostly
[21:17] <hyperair> the debian/tmp folder is ismilar to archlinux's pkg/ folder
[21:17] <Heller_Barde> one moment i'll get my project folder, i have one or two questions
[21:17] <hyperair> that's where everything goes just before splitting happens
[21:17] <hyperair> then it'll go into debian/package_name
[21:17] <Heller_Barde> hyperair: okay
[21:17] <hyperair> well sometimes you can skip debian/tmp
[21:17] <hyperair> and go straight into debian/package_name
[21:18] <hyperair> but generally for stuff with many packages, we dump everything in debian/tmp first
[21:18] <hyperair> and stuff is split based on package.install files
[21:18] <hyperair> which contain lists of files
[21:18] <hyperair> what goes into where kinda thing
[21:18] <Heller_Barde> holy moly, i get it now
[21:19] <hyperair> okay =)
[21:19] <Heller_Barde> i just looked at it again and went am i frickin stupid
[21:19] <hyperair> heh
[21:19] <hyperair> well
[21:19] <Heller_Barde> sry, i had an epiphany
[21:19] <Heller_Barde> i guess i was too tired last time
[21:19] <hyperair> heh
[21:19] <hyperair> no worries i get stuff like that once in a while
[21:20] <Heller_Barde> it was pretty frustrating... well, that's what you get going from warm, fuzzy, easy packaging in arch to the hard world of debian :P
[21:20] <Heller_Barde> brb
[21:20] <hyperair> well it depends on whether they're using raw debhelper or cdbs
[21:20] <hyperair> cdbs packaging is awesome
[21:20] <hyperair> i use it all the time
[21:36] <RAOF> hyperair: CDBS is magic harvested from the rich plumes of arcanum which spew from deep-sea volcanoes.  When you're doing exactly what it's designed for, it's great.  When you try to bend it a bit, you play "chase the make rule" through endless includes, all alike.
[21:37] <hyperair> RAOF: nice analogy
[21:38] <sebner> hyperair: another try would be: "Black magic"
[21:39] <hyperair> xD
[21:40] <hyperair> i like cdbs. it does most of what i need, compared to debhelper and its 186940747134 different dh_* commands
[21:40] <sebner> hyperair: already tried dh7? :)
[21:40] <hyperair> nop
[21:41] <hyperair> i haven't even bothered learning the names of all the dh_* commands
[21:41] <sebner> hyperair: take a look at it and tell me again the difference between dh and cdbs ;)
[21:41] <hyperair> =.=
[21:41] <RAOF> It's all the joy of cdbs, but with the ability to clearly see what the hell's happening.
[21:41] <hyperair> any docs i can read?
[21:41] <RAOF> man dh
[21:42] <lifeless> dh(3SSL)                                                                                            OpenSSL                                                                                           dh(3SSL)
[21:43] <lifeless> NAME
[21:43] <lifeless> :P
[21:43] <lifeless>        dh - Diffie-Hellman key agreement
[21:43] <lifeless> ?
[21:46] <hyperair> lifeless: wrong dh
[21:56] <RAOF> lifeless: You'd be after "man 1 dh", then.  :P
[21:58] <lifeless> RAOF: I think I was hinting that you should be more precise :>
[22:00] <RAOF> lifeless: Pfft.  Precision is for mathematicians!
[22:01] <lifeless> RAOF: zigactly
[22:01] <lifeless> RAOF: unless you're a statistician
[22:01] <RAOF> Then you have precise things to say about how imprecise you are.
[22:02] <lifeless> precisely
=== geser_ is now known as geser
[22:14] <Heller_Barde> okay, i do have some questions now. wtf do all these dh_* commands do?
[22:14] <pecisk> Heller_Barde: dh stands for debian helper scripts
[22:15] <Heller_Barde> ah -.-
[22:15] <directhex> each script has a specific job
[22:16] <Heller_Barde> what is the $* variable in a makefile?
[22:33] <radix> Heller_Barde: each of the dh_ programs has a man page
[22:33] <radix> and there's a 'debhelper' man page