[00:48] is there a way to specify per-architecture maintainer scripts? i think pretty much "no" but taking a hopeful stab in the dark here [00:49] achiang: you can do anything you like in a rules file, including generating the maintainer script dynamically [00:49] achiang: although I would ask why [00:50] you could also conditionalize on dpkg-architecture within the script [00:50] no [00:51] dpkg-architecture is only usable at build-time, being in dpkg-dev [00:51] oh, huh. ok [00:51] however, you can look at the output of 'dpkg --print-architecture' and conditionalise on *that* [00:51] achiang: Mesa says hello! If you need to have different maintainer scripts for different multiarch targets then mesa does that. [00:51] though i bet multiarch makes that rather complicated... [00:51] if you have to do architecture-dependent things, I would generally suggest that approach rather than having entirely different maintainer scripts (which will be a pain to maintain) [00:52] broder: that depends on the use case - multiarch doesn't change 'dpkg --print-architecture', although it introduces 'dpkg --print-foreign-architectures' [00:52] cjwatson: hm, i asked in #ubuntu-packaging but got impatient and re-asked here. i have source package 'foo' which generates N binary packages 'foo-alice', 'foo-bob', ... [00:52] each binary package has their own maintainer scripts: foo-alice.install, foo-bob.install [00:52] that's not a maintainer script - maintainer scripts are preinst, postinst, prerm, postrm [00:52] i'm discovering a need to have foo-alice install a file on armel only, but not x86 (!i386, !amd64) [00:53] .install files are dh_install configuration files [00:53] Then do that in the rules file [00:53] i'm trying to see if there's an easier way to do this rather than create foo-alice-armel.install [00:53] the usual way is to have foo-alice.install.in and run sed over it [00:53] RAOF: working on an oneiric SRU for hedgewars based on yesterday's discussion. does taking 0.9.17-1 from precise, applying http://pastebin.ubuntu.com/745496/ to it, and uploading to -proposed seem acceptable to you? [00:53] IIRC you _can_ have foo-alice.install.armel [00:53] Or just call install -m.... in the rules file directly [00:54] RAOF: yeah, but you have to duplicate everything in the architecture-independent file [00:54] That is a bit annoying, yeah. [00:54] well, the beauty here is that the file i want to install conflicts on x86 [00:54] Replaces: ? [00:54] Which is a bit of a big hammer [00:55] man debhelper, search for 'DEBHELPER CONFIG FILES' [00:55] "In some rare cases, you may want to have different versions of these files for different architectures or OSes" ... [00:55] broder: That seems reasonable to me. [00:55] StevenK: um [00:55] doesn't make sense across architectures [00:56] RAOF: excellent. up it goes, then. (the SRU for older releases is more complicated, unfortunately, due to haskell stack churn, so i may delay on those) [00:57] broder, no progress on that blocking bug? [00:58] RAOF: cjwatson: found what you guys are talking about in the debhelper man page. that solves my immediate problem, thank you. perhaps i can explain what i'm *really* doing to see if there's a better way to do it [00:58] EvilResistance: it has been escalated to the LP devs as being important to Ubuntu, which means they should be treating it as reasonably high priority [00:58] haven't seen any motion on it since then, though [00:58] broder: which bug in particular ? [00:58] (i believe that was about a week ago) [00:58] ah [00:58] lifeless: bug #888665 [00:58] Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [Critical,Triaged] https://launchpad.net/bugs/888665 [00:58] ah [00:59] thanks [00:59] hmm. no, it was escalated last thursday :) [00:59] on this project i'm working on, we have a need to provide a fake dmidecode on armel, which of course doesn't exist. the solution we've come up with is to deliver a bash script called /usr/sbin/dmidecode that simply echoes the 2 fields we need [00:59] my sense of time is apparently just way off whack [01:00] achiang: you should compile it into upstart and hardlink that to dmidecode [01:01] lifeless: well, we were hoping to avoid forking any more upstream packages; if we wanted to do that we could have just forked the dmidecode package and have it install our bash script on armel [01:01] achiang: YHBT, HTH, HAND [01:01] we already have a big ugly package full of hacks [01:02] achiang: I was -totally- trolling based on systemd's approach to things. [01:02] lifeless: is it sad that i thought your solution was technically superior to my bash script? ;) [01:02] uhm [01:02] maybe? [01:03] i'll just stick with what the debhelper man page says [01:03] thanks all [04:31] does devscripts or u-d-t or similar have a "setup an schroot session with the build-deps for this package" script? it always seems like more labor than it should require [04:34] hi alll [04:36] when i type "apt-get install ****"....which script gets involved [04:36] and where do i find it? [04:41] when i type "apt-get install ****"....which script gets involved and where do i find it? [04:43] helder_raptor: try 'which apt-get' [04:47] thnks [05:08] michag: didnt get wwhat i needed [05:09] michag: followed your way but ended up with an app [05:09] i need the script [05:13] #apt-get === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [06:46] broder: I start a build and press ctrl-c when the build-deps are in place :) === al-maisan is now known as almaisan-away [08:03] good morning === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [11:56] Laney: i've managed to get all of hedgewar's haskell dependencies sorted out except for Text.Show.ByteString, which is used in one file: showB = B.concat . BL.toChunks . BS.show [11:56] (BS is Text.Show.ByteString; B is Data.ByteString.Char8) [12:02] oh, and BL is Data.ByteString.Lazy [12:44] backport haskell-bytestring-show too? [12:47] i think i might be able to replace the functoin with showB = read . show [12:48] and change the type declaration from (BS.Show a) => a -> B.ByteString to just (Show a) => a -> B.ByteString [12:48] (my very rudimentary skills with monad-free haskell started to come back to me when i started to dig) [12:53] bah. now it's failing to compile on code that's actually monadic [12:53] * broder will try again tomorrow === koolhead17 is now known as koolhead17|away === almaisan-away is now known as al-maisan [21:48] broder: there, added existing bug report checking [21:48] sweet [21:49] you promised another bug report on requestbackport, can't remember what the issue was [21:50] meow [21:50] * Laney wget http://people.ubuntuwire.org/~stefanor/merged.tar.gz [21:50] tumbleweed: checking non-release pockets [21:51] broder: hrm, how do you want to do that. Allow oneiric-security to be specified as a source? [21:52] Laney: did it break? :) [21:52] tumbleweed: uh, i think i'd prefer to always pull from the newest thing in (Release, Security, Updates) but i'm not sure [21:52] have you been keeping it up to date? [21:52] Laney: it's a day or two old, see the stamp file [21:53] broder: that seems sane [21:53] oh [21:53] tumbleweed: i would also phrase the bug as "please blah blah from oneiric-security" [21:53] the stupid script uses the stamp file in the same cwd as itself [21:53] that is annoying [21:53] which will break backport-helper, but i'll deal [21:54] Laney: I just copied what you did, but yes you'll probably want to move the stamp file) [21:54] s/cwd/directory/ [21:54] Laney: I'm pretty sure I saw some dups in there, btw [21:54] yeah? [21:54] check the december 2011 mbox :P [21:55] erm [21:55] * tumbleweed grumbles about developers' clocks [21:56] that is amusingly wrong [21:56] i wonder if he had christmas already [21:58] I guess lpapicache isn't going to give me any alternative to walking the pockets [21:58] yeah, that's unfortunately a snippet of code i've had to write several times [21:59] next time you write it, put it in lpapicache [21:59] hang on, that's me [21:59] :) [21:59] damn [21:59] i think there's probably code in backportpackage you could steal [22:00] naah, you don't even use lpapicache [22:00] huh, i did. somebody must have changed it [22:01] ah, you use ubuntutools.archive [22:01] that was probably me who changed it [22:01] I probably broke this use-case in the process... === al-maisan is now known as almaisan-away [22:27] the early history looks quite different [22:27] hmm [22:29] straw poll: should "pull-lp-source foo lucid" use Release or highest non-backport version? [22:30] Laney: what sort of differences? [22:30] well obviously the very early history isn't represented at all [22:30] but then 2006-01 contains loads more stuff from the SPPHs [22:31] even excluding langpacks [22:31] well obviously the SPPH stuff will have katie syncs, which -changes won't [22:32] did they not always show up as being Ubuntu Archive Auto Sync [22:32] or whatever it is [22:32] ? [22:32] syncs that weren't explicitly requested don't show up on changes, IIRC [22:32] (but they did for a few weeks in early breezy) [22:33] you could see it here, (but not any more, I must have filtered it) http://people.ubuntu.com/~stefanor/upload_activity/ [22:33] I thought you could identify autosyncs (from SPPHs) by changed-by [22:33] maybe I am misremembering [22:33] also greatest version is probably good as long as there is a way to get the release version [22:34] Laney: thanks, I was thinking -release for that [22:34] (because it's trivial) :P [22:34] wfm [22:34] if documented etc [22:34] pish, documentation :P [22:40] what happened in 2005-12? [22:40] -rw-r--r-- 1 laney Debian 297 Nov 21 00:41 ubuntu-changes-2005-11.mbox.out.gz [22:40] Error: Debian bug 297 could not be found [22:40] -rw-r--r-- 1 laney Debian 1.3M Nov 21 00:41 ubuntu-changes-2005-12.mbox.out.gz [22:40] -rw-r--r-- 1 laney Debian 119K Nov 21 00:41 ubuntu-changes-2006-01.mbox.out.gz [22:40] Error: Debian bug 119 could not be found [22:41] Laney: from my previous graph, that looks like it matches our current data [22:42] this is what i have in the current files [22:42] -rw-r--r-- 1 laney Debian 90K Oct 24 21:31 ubuntu-changes-2005-11.mbox.out.gz [22:42] -rw-r--r-- 1 laney Debian 87K Oct 24 21:31 ubuntu-changes-2005-12.mbox.out.gz [22:42] -rw-r--r-- 1 laney Debian 84K Oct 24 21:31 ubuntu-changes-2006-01.mbox.out.gz [22:45] something broken in lp during that time? [22:45] was that when soyuz started being used maybe? [22:45] cjwatson: does your memory go back this far? [22:47] we need an ubuntu historian [22:48] where's that thar infinity [22:50] anyway, the data is probably not reliable before then [22:58] * ajmitch still has mailboxes from that era [23:00] heh [23:00] any of them announce this new soyuz thing? [23:01] not that I can tell from the headers [23:02] I'm just looking at dapper-changes [23:02] the web archives show activity, but LP SPPH doesn't [23:05] picked one at random [23:05] https://lists.ubuntu.com/archives/dapper-changes/2005-November/000497.html is placed on 21 Dec by SPPH [23:06] https://lists.ubuntu.com/archives/dapper-changes/2005-November/000545.html doesn't show up at all [23:06] tumbleweed: is that when it was superseded? [23:07] nope, theory out the window :) [23:08] https://lists.ubuntu.com/archives/dapper-changes/2005-November/000580.html also 21st Dec [23:08] * tumbleweed looks at ubuntu devel for that month [23:09] Firefox 1.5 out :P [23:09] \o/ [23:11] if you look at it from the perspective of 1.5 to 8 in 6 years, it looks pretty normal :) [23:12] naww, nothing I can see [23:22] errrrm [23:22] i only just got the joke behind the name "malone" [23:22] :-) [23:25] which is? [23:25] bugsy malone [23:25] oh, duh :) [23:29] tumbleweed: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-February/000072.html [23:29] thanks to wgrant [23:31] https://lists.ubuntu.com/archives/ubuntu-devel/2006-February/014998.html [23:31] this is amusing too [23:32] yeah, I was about to comment on "The procedure for uploads, syncs, removal and backport requests is also unchanged (for now)." [23:35] syncs via LP were just around the corner back then [23:35] there were roadworks on the corner unfortunately [23:37] broder: there, made lpapicache smarter and removed your code for doing this from backportpackage.