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