|Deletions are marked like this.||Additions are marked like this.|
|Line 4:||Line 4:|
|11:50 <aj> heh
11:50 -!- aj changed the topic of #debian-tech to: Channel info: http://wiki.debian.org/IRC/debian-tech | Now playing: http://lists.debian.org/debian-devel-announce/2005/12/msg00014.html
11:54 <neuro> but it's playing early!
11:58 <fs> hello
11:59 <neuro> Hi!
|Line 371:||Line 366:|
|14:21 <aj> mlots: useful to users ==> ABI stability. ABI instability ==> screwing your users over||14:21 <aj> mlots: useful to users ==>. ABI stability. ABI instability ==>. screwing your users over|
|Line 475:||Line 470:|
|14:50 <Greek0> aj: hmm. is this compatible with the "support updates from oldstable -> stable" policy? I mean what if someone installed sarge, never updated (ok.. probably unlikely and surely dumb, but anyway), and then wanted to update to etch when it's released?||14:50 <Greek0> aj: hmm. is this compatible with the "support updates from oldstable ->. stable" policy? I mean what if someone installed sarge, never updated (ok.. probably unlikely and surely dumb, but anyway), and then wanted to update to etch when it's released?|
|Line 600:||Line 595:|
|15:37 <nchip> 17:22 < nchip> aj: debian was *much* smaller and had only i386 then, so a completly library rename made sense.||15:37 <nchip> 17:22 (nchip) aj: debian was *much* smaller and had only i386 then, so a completly library rename made sense.|
|Line 661:||Line 656:|
|15:58 <aj> DavidS: well, that's what happened for the move from dists/ -> pool/, but i don't see the point?||15:58 <aj> DavidS: well, that's what happened for the move from dists/ to pool/, but i don't see the point?|
1 12:02 * rwhitby represents www.nslu2-linux.org, arm architecture (endian agnostic), installed linux firmware base of over 15K units, 100+ currently with debian installed, working towards integration of nslu2 into debian kernal and installer. 2 12:02 <aj> hey, so it begins 3 12:05 <aj> rwhitby: "endian agnostic" ? as in you use arm, don't care about armeb, but could use it if you flipped a coin and it came up tails? 4 12:06 <neuro> aj: whichever the customer wants, I'd think... 5 12:06 <neuro> mipsen is the same way for embedded stuff. 6 12:06 <rwhitby> actually, those 100+ are mostly running armeb at the moment, but the one barrier to using arm(el) (the IXP ethernet driver) has been overcome 7 12:06 <nchip> aj: long story :) originally it was not agnostic, it worked only properly in bigendian mode 8 12:07 <rwhitby> The long story is at http://article.gmane.org/gmane.comp.misc.nslu2.linux/10693 if anyone is interested. 9 12:07 <aj> elmo! 10 12:09 <intero> hi 11 12:10 <Q_> Are we waiting for something? 12 12:10 <aj> not really 13 12:10 <aj> i'm filling in http://ftp-master.debian.org/archive-criteria.html 14 12:10 <rwhitby> I figured people would introduce themselves while waiting ... 15 12:11 <aj> rwhitby: so can you comment on armeb's prospects for being an official port? 16 12:12 <rwhitby> aj: I would leave that to lennert (who is driving the port). nslu2 is now endian agnostic since getting the ixp driver working in both LE and BE. 17 12:13 <Q_> rwhitby: Are there any others that might want to use armeb other than the nslu2? 18 12:14 <rwhitby> 10% of unstable has been built by the two nslu2 buildd's but we would need more powerful armeb hardware to get ahead of the 95% required. 19 12:14 <neuro> how fast are nslu2s? 20 12:14 <aj> 95% is the release requirement, though 21 12:14 <nchip> Q_: highend intel routing gear 22 12:15 <rwhitby> Q_: most designs based on the IXDP425 reference board are armeb. and the high end stuff that nchip is referring to (and lennert uses) requires armeb 23 12:16 <rwhitby> nslu2's are 133MHz out of the box, but remove a resistor and they are de-underclocked to 266MHz. 24 12:16 <neuro> and what's the I/O like? IDE? udma5? 25 12:17 <rwhitby> nslu2 is USB to hard disks. Iomega NAS 100d (our other potential debian target) is IDE. 26 12:18 <Q_> usb2? 27 12:19 <aj> okay, so http://ftp-master.debian.org/archive-criteria.html has what i can think of for linux arches 28 12:19 <rwhitby> Q_: yes. nslu2 performance is at http://www.nslu2-linux.org/wiki/Info/Performance, nas100d is at http://www.nslu2-linux.org/wiki/NAS100d/Performance 29 12:20 <aba> aj: the 50 admin criteria is tougher than the 50 user release criteria 30 12:21 <aj> hrm 31 12:22 <nyu> it'd be useful to know what is the criteria when there are multiple lists (e.g. popcon and accounts in a shell server), and it's not possible to weed out duplicates 32 12:22 <aj> i'm tempted to leave it as 50 admins, except popcon probably won't measure that 33 12:22 <nyu> do we need a single >=50 list? 34 12:22 <Q_> rwhitby: For the nas100d, what's hda and sda? 35 12:23 <rwhitby> Q_: hda is internal IDE, sda is external USB2 36 12:25 <rwhitby> aj: Is a list like http://www.debonaras.org/wiki/Info/OpenDebianSlugUsers acceptable? 37 12:25 <nchip> what do people think of handling ABI transition with a new arch name? 38 12:26 <nchip> and accepting such "new" archs to debian official? 39 12:26 <Mithrandir> nchip: it was mentioned as a possibility which multiarch will give us in the discussions at debconf4, iirc. 40 12:26 <Q_> nchip: And do what with the old one? 41 12:27 <aba> nchip: I think best would be to make a seamless migration, if possible. 42 12:27 <aba> Mithrandir: I would like to see multiarch working before building plans on it 43 12:27 <nchip> Q_: maintain it as long as it has users who are willing to maintain it 44 12:28 <aj> nyu: if you've got two lists, you could make a single list using "cat", or at least "sort -u"; so probably just depends on the lists 45 12:28 <neuro> having users who are willing to maintain it isn't enough, if those users can't deal with all the similar points of release criteria. 46 12:28 <nchip> aba: agreed, but without multiarch it is not really simple. renaming all libs for a abi change in one arch is clearly even worse.. 47 12:29 <aj> if m68k can get 100 (according to its release qual page on the wiki) i don't see the problem :) 48 12:29 <nyu> aj: yes, we did that for wiki userlists, but popcon is anonymous 49 12:29 <nyu> so we can't really tell 50 12:29 <aba> nchip: in that case, making a new arch is the only option left AFAICS 51 12:29 <aj> popcon counts machines, so if you're doing popcon + shell accounts, you can just subtract 1 52 12:29 <aba> (I think you speak about arm's eabi) 53 12:30 <nyu> uhm right 54 12:30 <aj> renaming all libs is what we're almost doing for the C++ changes every other month 55 12:30 <nchip> yes, and mips nubi (althoug I think NUBI is more controversial) 56 12:30 <aj> we also did it for libc5->6 57 12:30 <Mithrandir> aj: it would be considerably worse if we had to rename _all_ libs, wouldn't it? 58 12:30 <nyu> aj: what if a user has a shell account at the server, plus a machine at home? 59 12:30 <aba> aj: but only the c++-ones, not *all* packages 60 12:30 <nyu> then he's being counted twice 61 12:30 <aba> aj: and we even have to rename all packages, if the kernel cannot cope with old and new abi at the same time (which is true for arm IIRC) 62 12:31 <aj> the main difference is "apt-get dist-upgrade" won't work if you change the arch name, which isn't remotely acceptable for release candidates 63 12:31 <Q_> aj: But a port can't go and rename binary packages. 64 12:31 <aj> if you've got an arch that's not remotely releasable yet, rm -rf'ing the port and starting from scratch isn't /completely/ out of the question, i guess 65 12:31 <aba> aj: well, why not have both variants in parallel for the time of one release, and then kill the old one? 66 12:31 <neuro> aj: and has happened at least once in the past... 67 12:32 <aj> nyu: if a user has a workstation at work and a pc at home, he gets counted twice with popcon too 68 12:32 <nchip> aj: you cant distupgrade a i386 installation to amd64 installation, if you installed i386 originally on your amd64 machine 69 12:32 <Mithrandir> nchip: people keep dreaming about being able to, though. 70 12:32 <aba> (anyways, I don't see the arm's eabi will get stable enough very soon) 71 12:32 <nyu> aj: ah i see. very nice, then 72 12:32 <aba> Mithrandir: if the problem is solved for i386->amd64, it should be able to solve it for arm->earm 73 12:32 <nchip> Mithrandir: what's ubuntu's plans for multiarch (since it probably happens there first, right?) 74 12:33 <aj> aba: well, why not fix the kernel to support both abis? 75 12:33 <aba> aj: I'm don't have enough insight to answer to this question. 76 12:33 <aj> aba: epoching arch names is a horrible, horrible idea 77 12:33 <aba> aj: but currently, eabi doesn't really run at all, leaving alone the question of "how should a migration look like" 78 12:34 <aba> aj: frankly speaking, I'd prefer to being able to migrate soft with e.g. multiarch or so. Well, if I look at eabi's speed, multiarch could be ready in time :) 79 12:34 <nchip> aba: I have a eabi root filesystem that boots upto X, so "doesn't really run" is not true 80 12:34 <Mithrandir> nchip: I've been thinking about just pushing for a transition to new-style paths before deciding on how to do the dpkg/apt/archive bits of it, since it seems that's how far consensus has stretched so far. 81 12:35 <aba> nchip: oh, there has been progress? My latest understanding was that there are lots of issues still open. 82 12:35 <Mithrandir> nchip: and if so, I'd like the changes to happen in Debian first, to not end up with a totally insane merge in ubuntu. 83 12:35 <aj> okay, so do we have any m68k people around? 84 12:36 <aba> aj: I've seen Yoe on #d-devel a few minutes ago 85 12:36 <Q_> Invite Yoe? He seems to be around. 86 12:36 <nchip> aba: the eabi bits just have not been in mainline toolchains until now. 87 12:36 <aj> okay, how about hurd people? 88 12:37 <aba> .oO(azeem has even the op-bit here) 89 12:37 <aj> azeem's on holidays 90 12:38 <aj> okay, so another question is "what should we do about non release candidate ports?" 91 12:38 <aj> default answer: unstable + experimental + a pat on the head 92 12:39 <nyu> any chance we can get testing? 93 12:39 <aba> nyu: I don't see that, as far as you're away from being a release arch 94 12:39 <aj> sure, if you meet the release criteria 95 12:39 <neuro> nyu: testing is where the next release is being prepared, since it's not release candidate, testing makes little sense? 96 12:39 <nyu> ok 97 12:40 <Q_> Maybe a snapshot of unstable? 98 12:40 <aj> i mean, there are two options: try to release; or say "releasing isn't appropriate for our arch, ______ would be instead" 99 12:40 <aba> (it would make sense if there are few things left, and we expect that it would become an release arch soon enough) 100 12:40 <nyu> yes, sounds reasonable 101 12:40 <nyu> for kfreebsd-i386 we expect to be release-capable soon, but not yet 102 12:40 <aj> arm's problem is apparently upstream toolchain support; and some underpoweredness 103 12:41 <nyu> for unstable, what are the requirements specific to non-Linux ports? (other than license issues) 104 12:41 <rwhitby> I thought upstream toolchain support was solved for arm (according to the requal wiki page) 105 12:41 <aj> do any of the arm folks (or armeb folks) think it makes sense to do anything other than fix those problems and be a release arch? 106 12:41 <kyllikki> aj: the upstream toolchain support is a very red herring 107 12:41 <neuro> that's a good question. 108 12:41 <nchip> aj: the upstream toolchain part is not true. 109 12:42 <aba> aj: on the short term, I think that's the only way (now speaking as someone looking closely at arm*) 110 12:42 <kyllikki> aj: and all were missing is the open acess box which there is a suitable one sat at black cat networks which elmo has turned down 111 12:42 <aj> nchip, kyllikki: you should poke mr aba here to update the etch table then 112 12:43 * aba hides his release manager's hat 113 12:43 <aj> aba: (the reason you wear the hat is so you can pull it down over your forehead so no one sees the "bloody idiot" branded there) 114 12:43 <nchip> aj: I sent a mail to debian-release about the issue. can we get a contact address on that page or a bts virtual package? 115 12:43 <neuro> kyllikki: umm, I haven't seen any request made to DSA. elmo is not the appropriate email address for DSA requests. I'm aware of one system pending atm, and it isn't at black cat. 116 12:43 <rwhitby> kyllikki: there have also been offers of nslu2 boxes with hosting for armel or armeb developer access 117 12:44 <aj> nchip: just whine at aba 118 12:44 * aba looks something up now 119 12:44 <kyllikki> tbh Im getting pissed off that I do all this stuff for the arch and others create issues which wernt there before 120 12:44 <kyllikki> neuro: email addr to forward the mail from him after the last round of DSA mail? 121 12:45 <neuro> email@example.com is the debian-admin contact address. 122 12:45 <neuro> firstname.lastname@example.org if it shouldn't go to local admins 123 12:46 <aba> nchip: sorry for not fixing it. Indeed, this mail was prepared for some time, and last when I looked, it was not there. 124 12:47 <aba> nchip: web page updated 125 12:48 <nchip> aba: thanks. it was our fault too.. we knew binutils was supported, but we where not sure by who officially so that part of page was left empty waiting for confirmation. 126 12:49 <aba> nchip: well, having a "binutils: yes [looking by whom personally, nchip/2005-...]" would have helped much, because that would have increased chances of asking you before sending out the mail. 127 12:51 <elmo> kyllikki: umm, I turned down a box that didn't have hosting, not one "sat at black cat" 128 12:51 <aj> sat on the mat at black cat? 129 12:52 <kyllikki> elmo: I thought it was made clear to you when you said Sledges place wasnt apropriate noodles and huggie said they would find a home for it 130 12:53 <elmo> kyllikki: if that's what happened it happened after I was on vacation without internet access (announced on -private); so I haven't even read that email yet, never mind had a chance to turn anything down 131 12:54 <kyllikki> elmo: you said you were gonna go with a box provided by joey hess? 132 12:54 <neuro> "find a home" != "found a home, host up and ready for DSA setup?" 133 12:54 <elmo> kyllikki: if the alternative was a box on sledge's ADSL, yes 134 12:54 <aba> do we still need a hosting place for that box? 135 12:55 <elmo> kyllikki: also, bear in mind (and I think I mentioned this in the email) the last time I asked for hosting in the UK, I couldn't get hosting for an arm box a) as a buildd and b) even from BlackCat 136 12:55 <kyllikki> elmo: shrug, as usual it seems were destined to get wires crossed and make no progress with this box...maybe its cursed? 137 12:55 <aj> ooo 138 12:55 <elmo> aba: not if blackcat are happy to host it 139 12:56 <aj> there's a good question to add: "Is port cursed?" 140 12:56 <aba> elmo: good. Otherwise, I have 2-4 places in .de/.at where we might have quite good changes 141 12:56 * aj wonders what ia64's answer would've been 142 12:56 <kyllikki> elmo: huggie said it was ok 143 12:56 <neuro> how about the standards that the (lib)C implementations conforms to? 144 12:57 <Q_> That's for non-linux ports I guess? 145 12:57 * maswan grumbles about the relevant people at his uni not answering his inquiries about hosting devel machines 146 12:57 <neuro> yes 147 12:57 <kyllikki> elmo: if that is acceptable I will get it so its up and powered when everyones back in the new year? atm people are getting inebriated for th new year 148 12:58 <kyllikki> elmo: and drunk in charge of root login shouldnt be allowed 149 12:58 <Q_> From what I understand, there are 2 netbsd ports, but they use a different libc? 150 12:59 <aj> okay, reload, there's some OS-specific questions too 151 12:59 <elmo> kyllikki: let me catch up on email - there's about 3 different discussions going on about arm machines atm - and get back to you today or tomorrow 152 12:59 <kyllikki> elmo: fil offered to do the admin too, would that be helpful? 153 12:59 <elmo> kyllikki: fil's already DSA, that's somewhat redundant? 154 12:59 <aj> fil's DSA? who's fil? 155 12:59 <kyllikki> elmo: yeah but he offered to do the setup specificaly if others were too busy 156 12:59 <elmo> phil hands 157 13:00 <elmo> kyllikki: if he does, then, great 158 13:00 <aj> wow, he ircs and everything 159 13:01 <nyu> Q_: yes, but none of them is active 160 13:02 <nyu> Q_: (besides, most of the ongoing work on gnu/kfreebsd can be reused for gnu/knetbsd) 161 13:03 <aj> oh, biarch needs a mention 162 13:03 <aj> why shouldn't gnu/k*bsd be bi/triarch anyway? 163 13:03 <nyu> tri? 164 13:04 <nyu> we have Linux abi emulation, with some caveats. biarch can be provided if someone works on it 165 13:04 <aj> free, net, open 166 13:05 <nyu> abi is different 167 13:05 <nyu> oh, right 168 13:05 <nyu> free doesn't emulate the other *bsd afaik 169 13:05 <nyu> net emulates free 170 13:05 <mlots__> dragonfly bsd? 171 13:05 <nyu> i don't know about open 172 13:06 <aj> the *bsd stuff don't seem to rate on the "What's this provide over upstream *BSD distros" or "What's it provide over Debian Linux?" -- two architectures even moreso 173 13:06 <nyu> no idea about dragon either. perhaps kernel interface is so similar we could just provide a "kernel of dragonfly" package instead 174 13:07 <nyu> aj: http://wiki.debian.org/Debian_GNU/kFreeBSD_why 175 13:08 <aj> " kFreeBSD offers an alternative in case Linux is branded illegal by the SCO case or other threats." 176 13:08 <aj> *cough* 177 13:09 <mlots____> As to the freeness of the win32 port, ReactOS is GPL/LGPL. It'd be useful to have second class status for it when it gets packaged. 178 13:09 <mlots____> My appologies for the disconnects. I'm not sure what's happening. 179 13:10 <aj> having a single (Debian GNU) userspace that lets you run either freebsd or netbsd kernel (possibly with different basic tools, firewalling whatever) at your whim would be more plausible 180 13:10 <aj> mlots____: you're still pretty laggy 181 13:11 <mlots> This connection seems to be pretty unusable. Sorry aj 182 13:11 <aba> in fact, I'd like to be able to choose between different kernels (re *bsd). Being able to choose is one of the good things in open source 183 13:12 <neuro> that's a huge undertaking, however. 184 13:12 <nyu> aj: doesn't sound easy 185 13:12 <nyu> although there are plans for it 186 13:13 <nyu> but not short term 187 13:13 <nyu> besides, there's only one active *bsd port atm 188 13:13 <neuro> look at how much work has to be done in say, d-i, to go from 2.4 to 2.6. 189 13:13 <nyu> heh yes 190 13:13 <nyu> we have problems with 5.x vs 6.x too 191 13:14 <neuro> and all of the places we provide glue just by installing a package, which would have to be made to work on the other OS' as well 192 13:14 <aj> nyu: managing 15G of debs isn't easy either 193 13:15 <neuro> it also makes packaging more complex, which tends to make it more fragile 194 13:15 <nyu> aj: i didn't mean it was 195 13:16 <aj> okay, http://ftp-master.debian.org/archive-criteria.html - updated again 196 13:17 <neuro> (the patches I've had for !linux archs that break linux are almost at a 1:1 ratio, for example...) 197 13:17 <nyu> but, again, the other *bsd haven't gathered enough interest to the date for someone to make a functional port. I don't think you should be so much concerned about the space these ports would take since they don't exist yet 198 13:17 <nyu> Guillem Jover had a document about kernel-independant userland if you're interested, though 199 13:18 <aj> saying "yes" to GNU/kFreeBSD serves as a precedent for saying "yes" to GNU/kNetBSD; so before you say the first yes, you need to be clear on why the second one should be "no", or willing to accept both being "yes" 200 13:20 <nyu> I'm not sure about that. If GNU/kFreeBSD meets the requirements (whatever they are), and there was a GNU/kNetBSD port, how can one tell beforehand if the second would meet the requirements too? 201 13:20 <neuro> nyu: the point is in making clear what the requirements are 202 13:20 <neuro> and why they exist 203 13:20 <nyu> ah, ok 204 13:21 <nyu> ah, found it 205 13:21 <nyu> http://www.hadrons.org/~guillem/debian/ports/gnu-any/ 206 13:21 <aj> nyu: because the alternatives are "whoever asks first wins, even if that's not best for our users" or "whoever asks gets in, even if we can't cope with the load" 207 13:22 <neuro> you can't, as a distribution, integrate all of the components well if your packages limit themselves to gnu-any, however... 208 13:22 <nyu> yes 209 13:22 <nyu> it's a difficult issue 210 13:22 <nyu> but "gnu-any" is just a long-term plan 211 13:23 <nyu> it needs huge work to even get hello.c, and hasn't even started yet 212 13:23 <aj> for k*BSD, gnu-any + a smaller number of apps compiled for the specific kernel might be worthwhile (separated into kfreebsd, knetbsd sections say) 213 13:23 <nyu> I don't think we should center the discussion on this 214 13:23 <aj> the biarch question needs to be answered before you get a "yes", though 215 13:24 <aj> (same as for mip/mips, sh*, ppc/ppc64, etc) 216 13:25 <nyu> biarch is no problem. the problem is making a base system that can boot/work with any of them 217 13:25 <nyu> we can't handle all kernel-specific apps or libraries in a case-by-case basis 218 13:25 <aj> that doesn't seem very important? have a base system for kfreebsd, a different one for knetbsd, and common apps 219 13:26 <nyu> uhm 220 13:26 <nyu> we could use kfreebsd ABI, and then get knetbsd to run *most* of kfreebsd userland 221 13:27 <nyu> but is that technicaly possible with biarch? 222 13:27 <nyu> i thought both arches had to be complete 223 13:27 <aj> everything's technically possible 224 13:27 <nyu> well, right 225 13:28 <nyu> then if someone wants to do a knetbsd port, they'd have to: 226 13:28 <nyu> - extend biarch to support this combination 227 13:28 <nyu> - build a base system specific to knetbsd, plus kernel-specific apps/libs 228 13:28 <nyu> - use kfreebsd-i386 packages for the rest 229 13:28 <nyu> that sounds plausible? 230 13:29 <aj> if it was going to support netbsd kernels, it'd make sense to call it kbsd-i386 231 13:29 <nyu> yes 232 13:30 <nyu> but: 233 13:30 <nyu> - what about abi emulation for kfreebsd in non-bsd systems? 234 13:31 <nyu> - kfreebsd-i386 is not necessarily a wrong name even if knetbsd was added, it would describe the kernel abi 235 13:31 <nyu> (and it wouldn't be less descriptive than, say, i386) 236 13:31 <aj> those are things you should note down for the related arches question 237 13:32 <aj> probably doing some analysis of the differences between freebsd ABI, netbsd ABI and potential gnu-bsd ABI 238 13:33 <nyu> well, at kernel level we use the same abi as upstream 239 13:33 <nyu> coming up with something new (and incompatible) doesn't sound like a good idea 240 13:34 <nyu> btw, will there be a public log of this? 241 13:34 <aj> "We can support NetBSD kernels using the FreeBSD-compatability stuff in the kernel, the disadvantages for NetBSD users are _____" would be helpful 242 13:34 <aj> yeah, i'll probably stick it up on wiki.d.o 243 13:34 <nyu> i see 244 13:35 <nyu> i take it we're expected to go through the list of questions in http://ftp-master.debian.org/archive-criteria.html and send a response? 245 13:35 <aj> "we can support netbsd well" ==>. "no need for a knetbsd arch" ==>. reassuring 246 13:35 <aj> "freebsd rocks, who cares about netbsd" ==>. "if we add this will we be adding netbsd next week? _why??_" ==>. concerning 247 13:36 <aj> put a response up on the wiki as per the release qualification stuff i think 248 13:36 <aj> i'm not sure the page is done yet, though; any other comments or additions anyone? 249 13:37 <nyu> alright 250 13:37 <nyu> would a proof-of-concept package of knetbsd image for kfreebsd-i386 help? 251 13:37 <nyu> i mean, rather, a base system 252 13:38 <aj> numbers on how much it sucks compared to a real freebsd and netbsd system would help too 253 13:39 <nyu> benchmarks? 254 13:39 <aj> yeah 255 13:39 <nyu> i don't think it'll be significantly different 256 13:40 <nyu> but we can do it, yes.. 257 13:42 <mlots> Ugg, bad DI-624... sorry 258 13:44 <mlots> I was saying that the win32 port could meat DFSG due to ReactOS (as was the original argument). ReactOS is usable these days... 259 13:44 <mlots> but it's dev's don't consider it stable. 260 13:45 <Q_> What still needs to happen before the mirror split can happen? 261 13:45 <mlots> It certainly isn't from a packaging point of view. From a running point of view, sometimes it is. 262 13:47 <mlots> Sorry if I missed discussion about installers. Fwiw, I think it makes some sence to allow arch specific installers from upstream... for the first part anyway (booting, creating partition, setting up devices...) 263 13:47 <aj> ah, you're here now? 264 13:47 <aj> so what's this win32 port and reactos stuff? 265 13:48 <mlots> I figure it's possible given mingw. 266 13:48 <mlots> ReactOS can deal with the elf format, I'm not sure if that means running linux apps though. 267 13:49 <aj> what is reactos? 268 13:49 <mlots> http://www.reactos.org 269 13:49 <Ganneff> aj: free nt kernel 270 13:49 <mlots> It uses wine code for some of the userspace. 271 13:50 <aj> so effectively a windows clone? 272 13:50 <nchip> Daniel Rouso is not around but is there any issues with uclibc debian ports? 273 13:50 <mlots> aj: mostly. They diverge in places. They aim for binary compatibility where it makes sence. 274 13:51 <neuro> nchip: it would have to have a lot of reasons for why we would want it in addition to the glibc port 275 13:51 <aj> mlots: eg? 276 13:52 <mlots> aj: The internal parts of the kernel and low level things can be REactOS specific. 277 13:53 <aj> mlots: so would there be any point to a win32 port that only ran on reactos, but not on (say) XP? i assume not? 278 13:54 <mlots> aj: Targeting ReactOS only makes sence. It'd be hard to get upstream support from Microsoft (or at least that's my impression). 279 13:54 <nchip> neuro: well there is only one technical reason to have uclibc, it uses a low less memory 280 13:54 <mlots> aj: Think of drivers that can't run on Linux... 281 13:54 <aba> mlots: why is ReactOS better as kernel than say Linux? 282 13:54 <mlots> aba: re above. ;-) 283 13:55 <mlots> aba: and wine has some limitations because of Linux and XWindows. 284 13:55 <DavidS> re uclibc: it's really nice for embedded systems where space is tight; and it'd be hard to have all necessary packages compiled against glibc _and_ uclibc... 285 13:55 <neuro> nchip: why does a port of debian make sense for that? should it be instead of the glibc port, if that's how it's most often used? what functionality is lost by not using glibc? 286 13:55 <aj> mlots: think of drivers that can't run on reactos? seems like linux would be more likely to have quality drivers than reactos? 287 13:56 <mlots> aj: It's hard to quantify that. 288 13:57 <aj> "wine has limitations because of linux and xwindows" ? 289 13:57 <aj> reactos + wine is more capable than linux + wine? 290 13:57 <nchip> neuro: I don't know. 291 13:58 <mlots> aj: for userspace, sometimes. There are scheduler issues, graphics limitations, convertion requirements... 292 13:58 <neuro> nchip: that's the sort of things that would need to be known before making a port of it. 293 13:58 <aj> interesting 294 13:58 <DavidS> neuro: see http://uclibc.org/FAQ.html#doesnt_suck for a short paragraph vs glibc 295 13:59 <aj> mlots: so the obvious other purpose of a win32 port is so people running windows can "apt-get" a nice unix environment; i presume you could do that and support reactos at the same time? 296 13:59 <mlots> aj: I beleive so. I'm not sure whether PE or ELF is the right way to go. 297 13:59 <nchip> neuro: I'm not porting to atm. I'm interested in general issues about alternative libc's/userlands on the same kernel/physical arch 298 14:00 <aj> DavidS, nchip: having a full port (kde, gnome, tetex) would seem insane; having a micro port (like udebs provide) may be interesting, but would need thought 299 14:00 <mlots> aj: I'd rather just concentrait on ReactOS. Gives people more insentive to develop it. 300 14:01 <nchip> here's some motivation behind it: https://www.debconf.org/comas/general/proposals/11 301 14:01 <mlots> aj: where would one draw the line for ulibc Not For Us? 302 14:01 <DavidS> aj: yes, saving 30MB in the libc and then adding 300MB for KDE makes not much sense 303 14:01 <aj> mlots: *shrug* that's one of the things that need thought :) 304 14:02 <nchip> aj: with the same argument compiling kde for m68k is insane. 305 14:03 <aj> nchip: m68k is (at least currently) a real port, so compiling kde is pretty much expected 306 14:03 <mlots> aj: Why? 307 14:03 <DavidS> another problem with uclibc is, that they are never ABI compatible between releases ... 308 14:03 <aj> mlots: because that's what real ports do -- work the same no matter what hardware they're run on 309 14:04 <nchip> DavidS: that's a big problem 310 14:04 <mlots> aj: There's no memory or speed limitations for "real ports"? 311 14:04 <aj> you could do patches to make "debian/rules binary ULIBC=yes" work for the apps people're actually interested in 312 14:05 <aj> mlots: "can keep up with building kde" :) 313 14:05 <mlots> aj: It seems that a port with limited resources (cpu, memory...) would still be useful. e.g. embeded systems. 314 14:05 <mlots> aj: Perhaps that's different "class" of ports other than "real" though? 315 14:05 <aj> mlots: (having the win32 port be usable by people running XP would pass the "is the port likely to be used by anyone?" criterion much more easily than a "must run reactos kernel" port) 316 14:06 <mlots> aj: Yes, can the two be seperate though? 317 14:06 <aj> mlots: yes, that would be an "embedded" port instead of a "real" one, which is entirely hypothetical at this point 318 14:06 <mlots> It's hard to say has upstream support if the users aren't using the thing supported by upstream. 319 14:06 <aj> mlots: not really -- an XP port would violate the SC; a reactos port might not pass the "useful?" test 320 14:07 <nchip> aj: with that sentiment, embedded debian does not make much sense. it will be just easier to compile your own distro. 321 14:07 <DavidS> nchip: libuclibc0 could be parallel-installed in different versions and the new bin-NMU capabilities of the buildd network mitigate the abi troubles 322 14:07 <aj> nchip: huh? 323 14:07 <aj> nchip: i'm all for m68k being an "embedded" or some other !real port, it just isn't that currently 324 14:07 <mlots> nchip: Debian is one of the most used distro's for creating embeded enviromnents (or so I hear). Why not make it more easy? 325 14:08 <aj> oh, right, debian/rules ym 326 14:08 <mlots> aj: ReactOS is used by a reasonable sized community right now. 327 14:09 <mlots> aj: I'd more like to get a win32 port to "second class citizen" at this point. 328 14:09 <aj> mlots: XP is used by a much bigger community :) i mean, that's not a "no", but it seems silly not to make it useful for XP users if it can be 329 14:09 <DavidS> nchip: but yes, testing migration would be a pain anyways :) 330 14:10 <aj> mlots: can't you make XP run ELF binaries or whatever anyway? 331 14:10 <nchip> mlots: I would like to make it easier 332 14:10 <mlots> aj: I'm not sure. If it can't then there's a good reason for only supporting ReactOS (i.e. archive space). 333 14:11 <aj> is PE that much bigger than ELF? 334 14:11 <mlots> aj: sure if you need to recompile. 335 14:11 <aj> ...? 336 14:11 <nchip> mlots: but currently it seems that the familiar approach is gaining more momentum 337 14:11 <aj> you have to recompile everything for a new arch anyway? 338 14:11 <aj> or are you saying "just run the linux binaries" ? 339 14:12 <mlots> aj: I'm saying just run the linux binaries in the same way that kfreebsd might. 340 14:12 <aj> kfreebsd was going to have all its own binaries ttbomk 341 14:13 <mlots> They're not linux binaries neccesarily? 342 14:13 <aj> we were talking about the freebsd abi earlier, not the linux abi 343 14:13 <aj> i didn't think any of them were linux binaries 344 14:13 <aj> i may be mistaken 345 14:13 <braindmg> mlots: we don't use the linux compat layer 346 14:14 <nchip> In away, I'm more interested in how to get new archs to SCC, than debating if a certain combination of a arch/kernel/libc is sensible or not 347 14:15 <neuro> nchip: you don't see how the two are related? 348 14:16 <mlots> I guess I'm not sure if syscalls leak into binaries when things aren't compiled statically. 349 14:16 <mlots> Anyway I agree with nchip, that's getting a bit into implementation. 350 14:16 <nchip> neuro: does and arch to be included in SCC need to be known to be sensible? Isn't better to find out in the SCC phase how usefull it is 351 14:17 <neuro> nchip: why does it need to be on the debian archive server to determine if it is sensical/useful or not? 352 14:17 <mlots> Aren't most SCC's not sensible until they become part of the archive proper? 353 14:17 <neuro> shouldn't that be done before adding it to the archive? 354 14:17 <aj> nchip: no, they need to be sensible before being in the archive; that includes working out combinattions of kernel/ABI and assigning them to debian architectures in order to minimise the number of architectures, and also (hopefully) getting a stable ABI that won't need to be changed in future 355 14:18 <mlots> aj: Does Hurd, sparc etc meet that? 356 14:18 <aj> in so far as hurd doesn't meet it, it's questionable whether it should be in the archive 357 14:19 <aj> i don't think sparc's had any major abi issues; certainly it's avoided needing a sparc64 port in parallel (or a sparcel/sparceb port, etc) 358 14:19 <mlots> aj: It's a working port, it's useful to it's developers, it's useful to it's users. 359 14:20 <mlots> aj: SCC shouldn't need A 360 14:20 <mlots> ABI stability 361 14:20 <nchip> neuro: I guess that depends on who does the work of maintaining SCC archive servers. 362 14:20 <mlots> That's the point of having snapshots right? 363 14:21 <aj> mlots: useful to users ==>. ABI stability. ABI instability ==>. screwing your users over 364 14:21 <mlots> The ABI only has to be stable long enough to compile the relevant parts of the port's archive (granted, for c libaries that's most/all of it). 365 14:21 <aj> mlots: that's fine for development, but not for use 366 14:21 <nchip> neuro: but it would be a bit appalling to expect each porters to maintain the infrastructure outside debian 367 14:21 <mlots> aj: If your users are developers... 368 14:22 <aj> mlots: then your port isn't ready 369 14:22 <DavidS> uclibcs two last releases were a year apart 370 14:22 <mlots> aj: for scc? 371 14:22 <mlots> aj: Debian tools make it easier to work on a port. 372 14:22 <aj> mlots: yes; SCC == letting in other arches of at least m68k/hurd's standard; not lowering it further 373 14:22 <mlots> aj: I'd say API stability is more important. 374 14:23 <aba> mlots: look at e.g. amd64 - there are ports outside the main archive. Why not? 375 14:23 <aj> mlots: that's fine, dak and debbugs are free software, you can setup your own while you stabalise your software 376 14:23 <aba> aj: well, even bugs.d.o could be used to a large extend :) 377 14:23 <aj> mlots: API stability is hopefully a given, there's the C standard and all 378 14:24 <mlots> aj: so no SCC until a port can theoretically have two snapshots where one can upgrade from one to the other? 379 14:24 <aj> mlots: yes, definitely 380 14:25 <mlots> Should there be a requirement that users!=developers? (I hate to ask, but that seems to be the implication of what aj's saying). 381 14:25 * aj makes that explicit 382 14:26 <aj> even if your users are developers, you shouldn't screw them over with an unstable ABI 383 14:26 <Greek0> mlots: if you say all your users are the port developers, why do you want it to be an official debian arch (scc or not) already? 384 14:26 <mlots> aj: are current accepted ports following users!=developers for their user counts? 385 14:26 <Greek0> I mean, an alioth project or something should be enough anyway for that period of time 386 14:27 <mlots> Greek0: Infastructure. 387 14:27 <aba> mlots: all ports reviewed by the release team had more than enough users anyways 388 14:27 <mlots> Greek0: Didn't amd64 have problems using alioth? 389 14:27 <Ganneff> mlots: the size of it, yes. 390 14:27 <aba> mlots: and it was moved out due to too much space usage 391 14:27 <aj> mlots: if you're so wonderful that everyone of your millions of users learns C and contributes back patches, that's not a black mark 392 14:28 <aj> mlots: but if you then break the ABI for them, that is 393 14:28 <mlots> Gannelf: So isn't that a problem for other ports? 394 14:28 <Ganneff> mlots: only if they built all of debian, in testing and unstable and experimental 395 14:29 <mlots> Ganneff: so three ports building one of those would be too much too? 396 14:29 <aj> mlots: Stabilising your ABI isn't that tricky; at worst you just have to provide backwards compatability as Linux and glibc do 397 14:29 <Ganneff> mlots: maybe. 398 14:30 <neuro> making ftp-master run out of space for the port instead isn't really a win, either... 399 14:30 <mlots> So third class citizen's might use alioth, lists.d.o, perhaps bugs.d.o? 400 14:30 <aj> unstable ABIs also screw over mirrors and buildds 401 14:30 <braindmg> aj: well even linux cannot provide backwards compat in all cases 402 14:30 <aj> i'm not convinced arches that can't provide a stable ABI should be using shared resources at all 403 14:30 <Ganneff> mlots: or any other machine out there. 404 14:31 <Ganneff> mlots: if you have a machine and enough bandwith you just need the tools to run an archive. 405 14:31 <aj> braindmg: absolute perfection isn't a requirement; if you meet or exceed Linux's standards, you're fine 406 14:31 <Ganneff> mlots: and that is packaged stuff. 407 14:31 <aj> i'm sorry, Linux/i386's standards 408 14:32 <aj> i can't understand why anyone would want to try maintaining a port that randomly changes its exec format or libc regularly 409 14:32 <Yoe> aj: you'll only meet that rule for Linux/i386 anyhow 410 14:32 <Yoe> aj: other ports are by definition less tested 411 14:32 <Yoe> than the most popular hardware architecture in the world 412 14:33 <aj> Yoe: not breaking an ABI is easy -- don't remove stuff, only add to it 413 14:33 <aj> Yoe: bugs are an entirely different matter 414 14:33 <Yoe> aj: oh, right, missed that bit 415 14:33 <Greek0> mlots: I don't think it's that terrible difficult to setup the infrastructure you need compared to the other work to do for a successful port. and AIUI debian's infrastructure is currently quite near to being overloaded, so using that resources just because it's easier isn't probably the best idea 416 14:33 <mlots> aj: If you're stable per snapshot then there's use. 417 14:34 <aj> mlots: if you're stable permanently you can use it, you can upgrade it, and you can do 3rd party development on it 418 14:35 <mlots> aj: I think the key argument is upgrade. 419 14:35 <mlots> 3rd party development could be done against a snapshot. 420 14:35 <aj> it would have to be done against /every/ snapshot, is the problem 421 14:36 <mlots> aj: If snapshots are as far apart as releases (even at 18 months 422 14:36 <mlots> that might not be a problem. 423 14:36 <aj> just fix your abi once and for all 424 14:37 <Yoe> mlots: I thought the idea is for snapshots to /not/ be so far away from eachother 425 14:37 <aj> mlots: btw, who are you anyway? 426 14:37 <nyu> wrt archive size problems, have you seen http://www.linuks.mine.nu/sizematters/ ? it claims we can save 29.3 % of archive space by using p7zip in .deb format 427 14:37 <mlots> Did anyone have any comments about my installer comment? 428 14:37 <mlots> aj: Drew Scott Daniels 429 14:38 <mlots> nyu: Youc an save about 0.3% by reording the files inside the debs. 430 14:38 <nyu> interesting 431 14:38 <nyu> you mean in the tar? 432 14:38 <Greek0> nyu: as it was pointed out on debian-devel, p7zip is not an option as long as dpkg in stable doesn't support it. so we could only use it for etch+1 433 14:38 <mlots> nyu: yup. I've got code that proves it for the linux kernel. 434 14:38 <Yoe> mlots: there's a serious difference between 29.3% and 0.3% 435 14:39 <mlots> ppmd is better than p7zip for compression. See compression.ca or maximumcompression (.info?) 436 14:39 <Yoe> though of course the reordering doesn't require dpkg code changes to be able to unpack later on 437 14:39 <nyu> Greek0: right. i'm on it (i sent patch to tar already) 438 14:39 <nyu> mlots: URL? 439 14:39 <nyu> ah 440 14:39 <mlots> nyu: for my code? 441 14:40 <nyu> mlots: is it free? 442 14:40 <mlots> nyu: I haven't released my code yet. 443 14:40 <mlots> nyu: ppmd is in Debian. 444 14:41 <nyu> i'll have a look, thanks 445 14:42 <Q_> mlots: ppmd also doesn't work on 64 bit arches. 446 14:42 <mlots> aj: Is an arch specific installer good enough for first class? 447 14:43 <mlots> Q_: Yup. It could be ported though. 448 14:43 <nyu> aj: and if not, is it for second? :) 449 14:43 <mlots> The trouble with switching to 7zip or ppmd etc is that it might raise the mimimum system requirements. 450 14:45 <nyu> i think an i486 is still faster at uncompressing than average internet connection at downloading 451 14:45 <mlots> nyu: how about CD? 452 14:45 <nyu> CD access is usualy faster when the data you're reading is compressed, too 453 14:45 <mlots> nyu: See compression.ca's speed vs size comparison. 454 14:45 <aj> mlots, nyu: it needs to be a working installer, otherwise i don't see a problem 455 14:45 <Q_> nyu: So what is an average internet connection nowadays? 456 14:45 <nyu> maybe not for i486 though 457 14:47 <aj> you could always include p7zip and a (minimally) updated dpkg in a point release 458 14:47 <Q_> (And it doesn't download and decompress at the same time anyway.) 459 14:47 <mlots> More compression does not nessiarily mean more time needed to decompress. 460 14:48 <nyu> mlots: any idea how to contact this guy? FLAC is missing in the audio comparison 461 14:48 <mlots> It'd be worth considering p7zip's decompression requirements. 462 14:48 <mlots> nyu: Use his e-mail address or try it yourself. 463 14:49 <mlots> nyu: maximumcompression was more up to date last time I checked. 464 14:49 <nyu> no public email it seems 465 14:49 <mlots> I read a review showing that FLAC sucks compaired to some general purpose compressers. 466 14:49 <nyu> i'll dig around 467 14:50 <Greek0> aj: hmm. is this compatible with the "support updates from oldstable ->. stable" policy? I mean what if someone installed sarge, never updated (ok.. probably unlikely and surely dumb, but anyway), and then wanted to update to etch when it's released? 468 14:50 <nyu> mlots: the sound comparison is not for general-purpose 469 14:50 <mlots> nyu: whois compression.ca? 470 14:50 <nyu> mlots: ah 471 14:50 <nyu> mlots: really? where's that 472 14:50 <Q_> Greek0: So they should first upgrade to sarge, then to etch. 473 14:50 <aj> Q_: they first upgrade to sarge's dpkg, and install p7zip 474 14:51 <mlots> Greek0: I think we violated that for woody->sarge. 475 14:51 <mlots> nyu: maximumcompression.info or something. 476 14:51 <Greek0> Q_: i.e. to "sarge+stable-security+stable-proposed-updates" or something like this? 477 14:51 <Q_> aj: You're saying we support upgrading from stable - 2 to stable? 478 14:51 <aj> i don't think we've got that sort of policy anyway -- we don't do security updates for people still running oldstable at that point, eg 479 14:52 <mlots> Greek0: I think that's the case for point releases only. 480 14:53 <aj> Q_: not particularly, but in this case how to do it by hand is pretty easy 481 14:54 <mlots> aj: Could a SCC or first class citizen be not "real", but embeded? 482 14:55 <nyu> mlots: i can't see any reference to 7zip there 483 14:56 <mlots> nyu: the files should be available for compression.ca so you could give it a try. 484 14:56 <pkern> nyu: "7-zip"? 485 14:56 <aj> mlots: i'm not sure what it would mean for an embedded architecture to be a release candidate 486 14:56 <aj> mlots: though udebs essentially make up a parallel set of "embedded" architectures 487 14:58 <mlots> aj: I guess it could be given that it'd meet the built requirement through not-for-us? 488 14:58 <mlots> aj: I'm not talking about udebs. 489 14:58 <nyu> pkern: www.7-zip.org, p7zip.sf.net 490 14:59 <nyu> btw, http://www.7-zip.org/ claims 7z outperforms ppmd (but that source is not impartial) 491 14:59 <aj> mlots: i'm not sure it wouldn't make more sense to have a different "built requirement" for "embedded" arches 492 15:00 <nyu> http://www.compression.ru/ybs/e&docs.htm 493 15:00 <mlots> nyu: what about paq5? There's new compressers all the time. 494 15:01 <mlots> aj: I'd say properly using not-for-us makes more sence than lowering the % requirement. 495 15:01 <mlots> aj: less buildd time wasted. 496 15:02 <aj> doing lots of not-for-us when the package could build is cheating for the archive %ge requirement 497 15:03 <aj> but for an embedded arch, building a certain set of packages might still be a useful requirement; i don't really know 498 15:03 <aj> until we've got an arch that it makes sense to consider "embedded" instead of "real", there's not much point trying to go into any detail 499 15:03 <mlots> nyu: If a case for a new compresser is made, one needs to consider: - space savings, - decompression time, -decompression memory requirements, - somewhat reasonable compression requirements such that devs are willing to use it. 500 15:03 <mlots> aj: m86k? 501 15:04 <mlots> 'r m68k? 502 15:04 <Yoe> mlots: we're not going to do that any time soon 503 15:04 <nyu> mlots: right 504 15:04 <nyu> mlots: but first, you have to consider patching dpkg ;) 505 15:05 <nyu> s/dpkg/tar/g 506 15:05 <aj> dpkg has already been patched for bz2 aiui; p7zip should be trivial 507 15:05 <nyu> then dpkg 508 15:05 <Q_> arm* looks more like an arch that might be an embedded one. 509 15:05 <nyu> aj: yes, but i don't want to send a patch that makes dpkg pipe() itself and exec tar/p7zip separately 510 15:05 <aj> there are actual arm workstations on the market today though 511 15:05 <nyu> tar needs fixing first 512 15:06 <aj> nyu: *shrug* it's not brain surgery 513 15:06 <Yoe> mlots: if you're interested in the specifics, we'd have to switch to something that works on ColdFire before making it an 'embedded' arch is going to be any useful 514 15:06 <mlots> nyu: what fixing? file reordering? putting the new compression into tar's code? 515 15:07 <Yoe> mlots: and once we reach that point, we might as well stick to being a full arch, since coldfire CPUs are much faster than the 'classic' m68k ones 516 15:07 <vorlon> are arm workstations anything more than glorified devel systems for embedded work, though? 517 15:08 <Yoe> vorlon: those were intended for being of more use, yes 518 15:08 <nchip> arm workstation I know of are riscpc replacements 519 15:08 <vorlon> ok 520 15:08 <vorlon> (somehow I doubt many people *use* them for anything other than devel systems for embedded work, but. :) 521 15:09 <nyu> mlots: p7zip support 522 15:09 <nyu> aj: no, it's more like planting rice 523 15:09 <nyu> you have to wait till it grows 524 15:09 <nchip> usually people crosscompile for embedded work. powerpc people are lucky enough they have a excuse to get nice devel systems from apple 525 15:10 <aj> nyu: huh? it's changing a few dozen lines of code, it's an undergrad exercise, geez. 526 15:10 <nyu> aj: it's ugly 527 15:10 <nyu> i want to get tar fixed first 528 15:10 <aj> that was including changing tar 529 15:11 <nyu> i have a patch for tar already 530 15:11 <nyu> the difficult part is getting it applied :) 531 15:11 <nyu> then send a patch for dpkg and wait again 532 15:13 <braindmg> aj: so are there plans to remove any arch from the archive? 533 15:15 <aj> braindmg: yes, sh. 534 15:15 <Yoe> yeah, that'd make total sense 535 15:15 <Yoe> is there actually still any binary in the archive which is sh and up-to-date? 536 15:15 <aj> i don't think there are any sh binaries in the archive, up to date or not 537 15:16 <aj> it's all arch:all 538 15:16 <mlots> scc requirements are basically: more useful than an existing scc, or signifigant(?) interest in a scc when there's theoreticaly extra infrastrucure space / man hours available? 539 15:17 <aj> "scc" isn't really a good term to use 540 15:17 <aj> requirements for going in the archive are basically: useful, maintained, stable 541 15:18 <aj> maybe s/maintained/supportable/ 542 15:18 <nchip> "ports" would be quite neutral 543 15:18 <mlots> stable as in abi, and runtime? 544 15:19 <Yoe> aj: okay, and when the thing is stable, but would need an ABI update after having been in the archive for years. What's going to happen? It remains there, or it gets kicked out until the ABI's fixed again? 545 15:19 <braindmg> even linux-i386 may need that eventually 546 15:20 <aj> linux-i386 has gone through a few ABI changes (a.out to ELF, libc5 to libc6, libc6 to libc6 for that matter), it just maintains backwards compatability 547 15:21 <aj> if your arch isn't worth the effort to do the ABI change in a backwards compatible manner, you're giving yourself a hard time arguing that it's worth including in the archive 548 15:21 <aj> cf the hurd 549 15:21 <Yoe> aj: to get this a bit more specific, 550 15:21 <braindmg> aj: what about the hurd? 551 15:21 <Yoe> the example I gave about the ColdFire move earlier isn't just hypothetical 552 15:22 <Yoe> aj: I've been talking to rwhitby, who works at freescale, to see whether we'd be able to get a few eval boards to port Debian/m68k over to them 553 15:22 <nchip> aj: debian was *much* smaller and had only i386 then, so a completly library rename made sense. 554 15:22 <Yoe> they're a factor 5 or so faster than what we currently support 555 15:23 <aj> nchip: a library rename is how we do these things in a backwards compatible manner 556 15:23 <Yoe> but their instruction set is smaller, so we'd need to replace everything we have currently before it'll work. 557 15:23 <nchip> aj: most people are going to object renaming all libs beginning from libc6 only for a minor archs abi transition 558 15:23 <aj> nchip: so do it just for your arch, working out how to make it easy for everyone *shrug* 559 15:24 <aj> Yoe: that sounds like it'd be fairly straightforward to do compatibly? 560 15:25 <nchip> aj: with a new arch name. backward compatability if needed can be solved with multiarch. 561 15:25 <Yoe> aj: yes, but it might be fairly lot of work, with much binNMUs and such 562 15:25 <aj> nchip: a new arch name is a horrible idea 563 15:26 <Yoe> aj: also, because of the instruction set having new instructions as well as losing old ones, I'm not entirely sure it's going to be possible to do this in a backwards-compatible way 564 15:26 <mlots> aj: I'd like scc infrastructure to grow at the same rate as first class. 565 15:26 <Yoe> though I can't be sure before I've tested it on the hardware 566 15:26 <nchip> aj: that's your opinion. I think library rename for one arch is way worse. 567 15:27 <nchip> aj: new arch name only involves porters of the said arch. library transition affects every debian users and needs handwork for every library maintainer 568 15:27 <mlots> I'm not just talking about archive space. Also machiens, bandwidth, potentialy man hours... 569 15:27 <aj> nchip: new arch names involve every single user of the arch, and are a ridiculous waste of disk space and bandwidth, sorry, no. 570 15:28 <aj> mlots: stop thinking in terms of "scc" 571 15:28 <aj> mlots: the only actual difference looks likely to be between release candidates and non release candidates for the time being; and the only different infrastructure between those two will be the testing scripts and stable support 572 15:28 <nchip> aj: then we'll just stop caring about your official debian. sorry. 573 15:29 <vorlon> aj: only a ridiculous waste of disk space if you keep the old arch around in testing/unstable, which it doesn't seem you would want to do? 574 15:30 <nchip> ..since we are expected to maintain all the infra outside debian anyway, it does not seem like a big step anyway. 575 15:30 <mlots> aj: but then there's now the third, those that don't make it into the archive... I get your point though. 576 15:30 <aj> vorlon: you'd probably need to while the new arch was being repopulated, which would likely take a few weeks, then you've got to worry about supporting the people who aren't in a position to upgrade immediately 577 15:32 <Greek0> nchip: debian doesn't have infinite resources. I think noone objects your stuff going into the archive if you have enough users, are willing to maintain your port, and it doesn't add a huge burden of another kind on debian. 578 15:34 <vorlon> aj: would that really be much different, disk-wise, than changing the names of all the libraries, since the latter means recompiling everything and essentially having disparate package sets in testing and unstable for a period? 579 15:34 <Greek0> but whining about "debian doesn't support us" when you have hardly any users and there seems to be quite a cost involved for debian seems a bit questionable. 580 15:34 <aj> one of the major concerns is b/w from ftp-master; ABI bumping a port costs about 10-15GB; we usually try to limit pulses to about 2GB per day 581 15:34 <braindmg> and I can understand that for the mirrors infra but having a new ports (or second class or whatever) ports.debian.org would make life way easier 582 15:34 <Yoe> Greek0: uhh, Debian/arm does have quite some users, actually 583 15:35 <aj> vorlon: if you do it compatibly you don't need to do it all at once, and potentially don't need to do it at all 584 15:35 <aj> having a second set of infrastructure to maintain would make life twice as hard, thanks all the same 585 15:35 <Greek0> Yoe: is this what nchip is talking about? I didn't really get it what his "pet port" was, sorry 586 15:36 <nchip> ...potentially don't need to do it at all 587 15:36 <Yoe> Greek0: I happen to know what nchip works on. That helps :) 588 15:36 <vorlon> I'm not sure how you'd do it compatibly, though? There's certainly no precedent within Debian of maintaining such compatibility through an ABI transition 589 15:37 <aj> vorlon: eh? we did with libc5/libc6 590 15:37 <braindmg> aj: for all arches 591 15:37 <aj> vorlon: there were some rumours of an hppa ABI change a little while ago, iirc, what happened with it? 592 15:37 <nchip> 17:22 (nchip) aj: debian was *much* smaller and had only i386 then, so a completly library rename made sense. 593 15:37 <mlots> aj: I agree, a second set of infrastructure to maintain would make life twice as hard. That's the case with non-release and non-archive. 594 15:37 <vorlon> Package: libpam0g 595 15:37 <vorlon> Conflicts: libpam0 (<= 0.56-2), libpam 596 15:38 <aj> oh, debian didn't have only i386 then, it at least had m68k and i think maybe sparc and alpha? 597 15:38 <vorlon> aj: ^^^ doesn't seem like the kind of thing that happens piecemeal 598 15:38 <nchip> hrmh ok. but still it was necessary for all the archs. 599 15:38 <Greek0> Yoe: hehe. just that "stop caring about official debian" phrase reminded me of the gnu/solaris people (no offense) 600 15:38 <braindmg> mlots: and replicating the infra and work for each new/external port 601 15:38 <Yoe> Greek0: heh 602 15:40 <aj> mlots: no, non-release go with all the other architectures, they just don't release 603 15:40 <mlots> I can see the annoyance with getting bugs against your package for a port that would take time to maintain. 604 15:40 <aj> mlots: non-archive stuff just needs to have a stable ABI, which really isn't that hard 605 15:41 <mlots> aj: non-release wouldn't get the benifit of "testing" or the testing scripts... I guess they'd still be able to grab all the packages after release? 606 15:43 <aj> mlots: there are other things that could be done beyond unstable and experimental, but i'm not going to talk about that until there's an /actual example/ 607 15:43 <nchip> what archs now have their own external infra? this stuff could benefit from co-operation. 608 15:43 <mlots> I guess non-release could still have "testing"/"stable" buildd, and security support? 609 15:43 <aj> at present, the only non-release architecture is hurd-i386, which currently has 4k packages in the archive, compared to ~24k for every other architecture in the archive 610 15:44 <nyu> Greek0: gnu/solaris is much worse than just "no official repository" 611 15:44 <mlots> aj: amd64 released sarge after Debian and didn't use the testing script? 612 15:45 <Q_> amd64 doesn't use britney, which makes it rather hard for us to have a real testing. 613 15:45 <Ganneff> mlots: we are on a different machine, we dont use britney. 614 15:45 <Ganneff> we have some own scripts, fetching the data from ftp-master and running a little "mini-britney", basically following i386 testing 615 15:45 <aj> had we had appropriate criteria in place, and changes to our mirroring, amd64 would've been in the archive and a release candidate years ago 616 15:45 <Greek0> nyu: I followed the whole tragedy. I also didn't mean to imply that anyone here works on that port or hase the same attitude as the people that do. just that single statement remembered me of this issue. 617 15:46 <Q_> aj: So what still needs to happen for the mirroring changes? 618 15:46 <mlots> That's my point. non-release could grab a list of packages from stable or testing and build them later right? 619 15:46 <braindmg> nchip: amd64 kfreebsd-i386 knetbsd-i386 hurd-i386 at least 620 15:47 <mlots> That's mini-britney? Or is mini-briteny something else? 621 15:48 <aj> Q_: work out exactly what mirrors should do; tell mirrors what they should do; wait for mirrors to do that 622 15:48 <Ganneff> mini-britney is a shell script. 623 15:48 <nyu> Greek0: they have an attitude? I thought they simply worked in their own, separate world 624 15:48 <nyu> Greek0: is there a single nexenta patch in bts? :) 625 15:48 <aj> mlots: if you're going to try mimicing the release stuff, you should just be a release arch. the requirements really aren't that challenging 626 15:48 <nyu> nchip: and armeb 627 15:49 <nyu> hurd-i386 is in sid 628 15:49 <nyu> and knetbsd-i386 is.. well, dead ;) 629 15:49 <mlots> aj: Doing it on time with limited man hours is a challenge. 630 15:49 <braindmg> nyu: it needs some stuff for which maintainers have not integrated the patches 631 15:49 <braindmg> nyu: the infra is there ;> 632 15:50 <nyu> braindmg: heh yes it is 633 15:50 <aj> mlots: so get more users, and thus more developers 634 15:50 <Greek0> nyu: attitude, as in: mindset, behavior, .. 635 15:50 <Q_> aj: The "work out what mirrors should do" part is rather vague. 636 15:51 <nyu> Greek0: yes. their behaviour from our POV can be cathegorised as non-behaviour ;) 637 15:51 <aj> mlots: the only real difficulty is when the hardware's difficult to come by and you can't get users, i guess 638 15:51 <mlots> aj: creating a "sarge" snapshot for a port is useful as it limits the non-port RC bugs that ones needs to deal with. 639 15:51 <Q_> They should have some easy script to select which aches they want to have on the mirror? 640 15:52 <Q_> aj: Your blog also said something about making dak scripts better to handle the load? Can you get into more specifics about that? 641 15:53 <aj> Q_: apt-ftparchive does too much stat'ing, rather than just using its cache; i think there was something else along those lines too 642 15:54 <mlots> Well I gotta go to work. Thanks for the discussion. I hope to read the transcript of the rest later. bye 643 15:54 <aj> Q_: there's already a reasonably easy script, it's more the issue of making it easy for people to find a (eg) m68k mirror when the country mirror only had i386 eg 644 15:54 <DavidS> aj: how much work would it be to split out non-mirrored .debs into /pool-non-mirrored/ or something, which can be easily excluded by those mirror -ops who don't want it? 645 15:55 <Q_> aj: Atleast in d-i, it lists which arches are on each mirror. 646 15:55 <aj> insanely painful, since it'd involve moving GBs of data around in a mirror pulse? 647 15:55 <braindmg> DavidS: and then people that want to mirror the non-mirrored? ;) 648 15:56 <aj> anyway, everything gets mirrored by someone, just not most people 649 15:56 <Q_> aj: And http://www.debian.org/mirror/list seems to list the arches too. 650 15:56 <DavidS> braindmg: well, nobody who wants to waste disk space should be hindered ;) 651 15:57 <aj> so are these questions just out of curiousity, or should i be taking down names for my "to be volunteered for mirror maintenance jobs" list? 652 15:57 <DavidS> aj: and only uploading new packages to the new locations? probably defeats the "simple" approach by too much complexity in programming :( 653 15:58 <aj> DavidS: well, that's what happened for the move from dists/ to pool/, but i don't see the point? 654 15:58 <Q_> aj: Well, both curiousity, and I'd like to help if I can. 655 15:58 <aj> DavidS: there's already an rsync-based script that'll do partial mirrors, and with some archive support, something like rsync --delay-updates --files-from:indices/arch-i386.lst --delete-after # should work 656 15:59 <DavidS> aj: just brainstorming. point being: easy separation of seldom downloaded archs for easier capping of mirror disk usage and b/w 657 16:00 <DavidS> aj: then the whole discussion around "we haven't enough mirror b/w and disk" goes out the chimney, isn't it? 658 16:00 <aj> how so? 659 16:01 <aj> mirroring all architectures (which is what we currently expect of pushed mirrors and top level country mirrors) is 160GB or so, an arch-specific mirror including arch:all and source is about 20GB 660 16:02 <Q_> Seems to be at 164GB now. 661 16:03 <aj> yick 662 16:07 <vorlon> we need to get on jvw to remove more stuff 663 16:08 <nyu> unrar 664 16:08 * nyu hides 665 16:09 <aj> hey, how come the linux-kernel-m68k stuff is arch:all? 666 16:10 <Yoe> aj: hmm? isn't that just the patch you're talking about? 667 16:10 * Yoe checks 668 16:10 <aj> hrm, maybe it's just sources 669 16:11 <Yoe> aj: what's the exact package name? packages.d.o doesn't find linux-kernel-m68k 670 16:11 <aj> yeah, it was the patch and sources and for other arches too 671 16:11 <aj> sigh 672 16:11 <aj> toolchain-source is worse 673 16:11 <Yoe> right, thought as much 674 16:11 <Yoe> heh