| === asac_ is now known as asac | ||
| NCommander | ScottK, I'm glad you agree on debhelper since it would make life a lot easier w.r.t. to backporting stuff | 00:56 |
|---|---|---|
| directhex | NCommander, DH7 for hardy! | 01:00 |
| NCommander | yup | 01:00 |
| 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:01 |
| NCommander | right | 01:02 |
| directhex | i'd be very happy about an official backport, since i could erase it from my ppa | 01:02 |
| 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:03 |
| 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... | 01:04 |
| === jrib is now known as Guest64524 | ||
| 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:05 |
| 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:06 |
| Hobbsee | directhex: you'll never win that battle. | 01:07 |
| === Guest64524 is now known as jrib | ||
| 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:07 |
| * 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| NCommander | which fixes a few bugs | 01:12 |
| StevenK | "Meh" | 01:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| NCommander | Is it a bad thing is hardy-backports > intrepid? | 01:16 |
| directhex | know what? time for beds. | 01:16 |
| === jelmer_ is now known as Guest29580 | ||
| === _jason is now known as jrib | ||
| 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:39 |
| 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:41 |
| 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:42 |
| 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 | 04:43 |
| 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 | 06:32 |
| === dfiloni is now known as devfil | ||
| === RainCT_ is now known as RainCT | ||
| === _nightwish is now known as nightwish | ||
| alex-weej | is the console font supposed to be something other than the default, old IBM(?) PC one? | 14:34 |
| 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 | 14:35 |
| === bureflux is now known as afflux | ||
| === chuck_ is now known as zul | ||
| === johanbr_ is now known as johanbr | ||
| bdheeman | hello | 17:43 |
| bdheeman | can i build x86_64 packages of an x86 machine, if yes - how? | 17:43 |
| directhex | no. | 17:44 |
| bdheeman | s/of/on/ | 17:44 |
| bdheeman | directhex: but, i saw openwrt build system builds kind of some ARM and other packages even on an x86 machine | 17:46 |
| 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:47 |
| bdheeman | so, better buy an amd64 machine | 17:48 |
| 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:49 |
| bdheeman | directhex: i have not heard about PPA's here in India | 17:55 |
| bdheeman | but AMD machine are quite popular there days | 17:56 |
| directhex | bdheeman, PPA. personal package archive. a build service on launchpad.net | 18:05 |
| bdheeman | directhex: thanks, i was not aware of that service | 18:07 |
| === thegodfather is now known as fabbione | ||
| 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:08 |
| jdong | does Ubuntu squashfs support the LZMA compression method? | 19:37 |
| jdong | i.e. in-kernel? | 19:37 |
| pwnguin | i doubt it | 19:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| pwnguin | jdong: you should probably double check with the ubuntu kernel ML | 19:41 |
| pwnguin | i donno if there's plans or if i missed something, etc | 19:42 |
| 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:54 |
| mohbana | hi, anyone familiar with fontconfig? what's wrong with this; http://pastebin.com/m53266bde | 19:56 |
| jdong | grumble stupid pulse dying after suspend | 20:12 |
| === ajmitch_ is now known as ajmitch | ||
| hyperair | jdong: there's a bug regarding that | 20:17 |
| 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:18 |
| hyperair | so now i'm actually wondering what i should do | 20:19 |
| directhex | cry! | 20:20 |
| jdong | hyperair: well it's been assigned to crimsun, so I'd say it's in the best hands :) | 20:21 |
| hyperair | =\ | 20:22 |
| hyperair | directhex: hmph | 20:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| jdong | hyperair: ok that one is within my umbrella of authority, lemme take a look at your debdiff | 20:29 |
| hyperair | jdong: thanks =) | 20:30 |
| 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:31 |
| jdong | hyperair: ok I acked the SRU for you | 20:32 |
| 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:33 |
| hyperair | jdong: should i unsubscribe motu-sru? | 20:35 |
| jdong | hyperair: no need ,keep them subscribed | 20:36 |
| hyperair | okay | 20:36 |
| Heller_Barde | hai | 21:04 |
| 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:05 |
| 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:06 |
| hyperair | Heller_Barde: what do you want to know? | 21:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:36 |
| hyperair | RAOF: nice analogy | 21:37 |
| sebner | hyperair: another try would be: "Black magic" | 21:38 |
| hyperair | xD | 21:39 |
| 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:40 |
| 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:41 |
| lifeless | dh(3SSL) OpenSSL dh(3SSL) | 21:42 |
| lifeless | NAME | 21:43 |
| lifeless | :P | 21:43 |
| lifeless | dh - Diffie-Hellman key agreement | 21:43 |
| lifeless | ? | 21:43 |
| hyperair | lifeless: wrong dh | 21:46 |
| RAOF | lifeless: You'd be after "man 1 dh", then. :P | 21:56 |
| lifeless | RAOF: I think I was hinting that you should be more precise :> | 21:58 |
| RAOF | lifeless: Pfft. Precision is for mathematicians! | 22:00 |
| 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:01 |
| lifeless | precisely | 22:02 |
| === geser_ is now known as geser | ||
| 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:14 |
| Heller_Barde | ah -.- | 22:15 |
| directhex | each script has a specific job | 22:15 |
| Heller_Barde | what is the $* variable in a makefile? | 22:16 |
| radix | Heller_Barde: each of the dh_ programs has a man page | 22:33 |
| radix | and there's a 'debhelper' man page | 22:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!