1 11:50 <aj> heh
   2 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
   3 11:54 <neuro> but it's playing early!
   4 11:58 <fs> hello
   5 11:59 <neuro> Hi!
   6 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.
   7 12:02 <aj> hey, so it begins
   8 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?
   9 12:06 <neuro> aj: whichever the customer wants, I'd think...
  10 12:06 <neuro> mipsen is the same way for embedded stuff.
  11 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
  12 12:06 <nchip> aj: long story :) originally it was not agnostic, it worked only properly in bigendian mode
  13 12:07 <rwhitby> The long story is at http://article.gmane.org/gmane.comp.misc.nslu2.linux/10693 if anyone is interested.
  14 12:07 <aj> elmo!
  15 12:09 <intero> hi
  16 12:10 <Q_> Are we waiting for something?
  17 12:10 <aj> not really
  18 12:10 <aj> i'm filling in http://ftp-master.debian.org/archive-criteria.html
  19 12:10 <rwhitby> I figured people would introduce themselves while waiting ...
  20 12:11 <aj> rwhitby: so can you comment on armeb's prospects for being an official port?
  21 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.
  22 12:13 <Q_> rwhitby: Are there any others that might want to use armeb other than the nslu2?
  23 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.
  24 12:14 <neuro> how fast are nslu2s?
  25 12:14 <aj> 95% is the release requirement, though
  26 12:14 <nchip> Q_: highend intel routing gear
  27 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
  28 12:16 <rwhitby> nslu2's are 133MHz out of the box, but remove a resistor and they are de-underclocked to 266MHz.
  29 12:16 <neuro> and what's the I/O like?  IDE?  udma5?
  30 12:17 <rwhitby> nslu2 is USB to hard disks.  Iomega NAS 100d (our other potential debian target) is IDE.
  31 12:18 <Q_> usb2?
  32 12:19 <aj> okay, so http://ftp-master.debian.org/archive-criteria.html has what i can think of for linux arches
  33 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
  34 12:20 <aba> aj: the 50 admin criteria is tougher than the 50 user release criteria
  35 12:21 <aj> hrm
  36 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
  37 12:22 <aj> i'm tempted to leave it as 50 admins, except popcon probably won't measure that
  38 12:22 <nyu> do we need a single >=50 list?
  39 12:22 <Q_> rwhitby: For the nas100d, what's hda and sda?
  40 12:23 <rwhitby> Q_: hda is internal IDE, sda is external USB2
  41 12:25 <rwhitby> aj: Is a list like http://www.debonaras.org/wiki/Info/OpenDebianSlugUsers acceptable?
  42 12:25 <nchip> what do people think of handling ABI transition with a new arch name?
  43 12:26 <nchip> and accepting such "new" archs to debian official?
  44 12:26 <Mithrandir> nchip: it was mentioned as a possibility which multiarch will give us in the discussions at debconf4, iirc.
  45 12:26 <Q_> nchip: And do what with the old one?
  46 12:27 <aba> nchip: I think best would be to make a seamless migration, if possible.
  47 12:27 <aba> Mithrandir: I would like to see multiarch working before building plans on it
  48 12:27 <nchip> Q_: maintain it as long as it has users who are willing to maintain it
  49 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
  50 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.
  51 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..
  52 12:29 <aj> if m68k can get 100 (according to its release qual page on the wiki) i don't see the problem :)
  53 12:29 <nyu> aj: yes, we did that for wiki userlists, but popcon is anonymous
  54 12:29 <nyu> so we can't really tell
  55 12:29 <aba> nchip: in that case, making a new arch is the only option left AFAICS
  56 12:29 <aj> popcon counts machines, so if you're doing popcon + shell accounts, you can just subtract 1
  57 12:29 <aba> (I think you speak about arm's eabi)
  58 12:30 <nyu> uhm right
  59 12:30 <aj> renaming all libs is what we're almost doing for the C++ changes every other month
  60 12:30 <nchip> yes, and mips nubi (althoug I think NUBI is more controversial)
  61 12:30 <aj> we also did it for libc5->6
  62 12:30 <Mithrandir> aj: it would be considerably worse if we had to rename _all_ libs, wouldn't it?
  63 12:30 <nyu> aj: what if a user has a shell account at the server, plus a machine at home?
  64 12:30 <aba> aj: but only the c++-ones, not *all* packages
  65 12:30 <nyu> then he's being counted twice
  66 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)
  67 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
  68 12:31 <Q_> aj: But a port can't go and rename binary packages.
  69 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
  70 12:31 <aba> aj: well, why not have both variants in parallel for the time of one release, and then kill the old one?
  71 12:31 <neuro> aj: and has happened at least once in the past...
  72 12:32 <aj> nyu: if a user has a workstation at work and a pc at home, he gets counted twice with popcon too
  73 12:32 <nchip> aj: you cant distupgrade a i386 installation to amd64 installation, if you installed i386 originally on your amd64 machine
  74 12:32 <Mithrandir> nchip: people keep dreaming about being able to, though.
  75 12:32 <aba> (anyways, I don't see the arm's eabi will get stable enough very soon)
  76 12:32 <nyu> aj: ah i see.  very nice, then
  77 12:32 <aba> Mithrandir: if the problem is solved for i386->amd64, it should be able to solve it for arm->earm
  78 12:32 <nchip> Mithrandir: what's ubuntu's plans for multiarch (since it probably happens there first, right?)
  79 12:33 <aj> aba: well, why not fix the kernel to support both abis?
  80 12:33 <aba> aj: I'm don't have enough insight to answer to this question.
  81 12:33 <aj> aba: epoching arch names is a horrible, horrible idea
  82 12:33 <aba> aj: but currently, eabi doesn't really run at all, leaving alone the question of "how should a migration look like"
  83 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 :)
  84 12:34 <nchip> aba: I have a eabi root filesystem that boots upto X, so "doesn't really run" is not true
  85 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.
  86 12:35 <aba> nchip: oh, there has been progress? My latest understanding was that there are lots of issues still open.
  87 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.
  88 12:35 <aj> okay, so do we have any m68k people around?
  89 12:36 <aba> aj: I've seen Yoe on #d-devel a few minutes ago
  90 12:36 <Q_> Invite Yoe?  He seems to be around.
  91 12:36 <nchip> aba: the eabi bits just have not been in mainline toolchains until now.
  92 12:36 <aj> okay, how about hurd people?
  93 12:37 <aba> .oO(azeem has even the op-bit here)
  94 12:37 <aj> azeem's on holidays
  95 12:38 <aj> okay, so another question is "what should we do about non release candidate ports?"
  96 12:38 <aj> default answer: unstable + experimental + a pat on the head
  97 12:39 <nyu> any chance we can get testing?
  98 12:39 <aba> nyu: I don't see that, as far as you're away from being a release arch
  99 12:39 <aj> sure, if you meet the release criteria
 100 12:39 <neuro> nyu: testing is where the next release is being prepared, since it's not release candidate, testing makes little sense?
 101 12:39 <nyu> ok
 102 12:40 <Q_> Maybe a snapshot of unstable?
 103 12:40 <aj> i mean, there are two options: try to release; or say "releasing isn't appropriate for our arch, ______ would be instead"
 104 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)
 105 12:40 <nyu> yes, sounds reasonable
 106 12:40 <nyu> for kfreebsd-i386 we expect to be release-capable soon, but not yet
 107 12:40 <aj> arm's problem is apparently upstream toolchain support; and some underpoweredness
 108 12:41 <nyu> for unstable, what are the requirements specific to non-Linux ports? (other than license issues)
 109 12:41 <rwhitby> I thought upstream toolchain support was solved for arm (according to the requal wiki page)
 110 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?
 111 12:41 <kyllikki> aj: the upstream toolchain support is a very red herring
 112 12:41 <neuro> that's a good question.
 113 12:41 <nchip> aj: the upstream toolchain part is not true.
 114 12:42 <aba> aj: on the short term, I think that's the only way (now speaking as someone looking closely at arm*)
 115 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
 116 12:42 <aj> nchip, kyllikki: you should poke mr aba here to update the etch table then
 117 12:43  * aba hides his release manager's hat
 118 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)
 119 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?
 120 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.
 121 12:43 <rwhitby> kyllikki: there have also been offers of nslu2 boxes with hosting for armel or armeb developer access
 122 12:44 <aj> nchip: just whine at aba
 123 12:44  * aba looks something up now
 124 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
 125 12:44 <kyllikki> neuro: email addr to forward the mail from him after the last round of DSA mail?
 126 12:45 <neuro> debian-admin@lists.debian.org is the debian-admin contact address.
 127 12:45 <neuro> debian-admin@d.o if it shouldn't go to local admins
 128 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.
 129 12:47 <aba> nchip: web page updated
 130 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.
 131 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.
 132 12:51 <elmo> kyllikki: umm, I turned down a box that didn't have hosting, not one "sat at black cat"
 133 12:51 <aj> sat on the mat at black cat?
 134 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
 135 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
 136 12:54 <kyllikki> elmo: you said you were gonna go with a box provided by joey hess?
 137 12:54 <neuro> "find a home" != "found a home, host up and ready for DSA setup?"
 138 12:54 <elmo> kyllikki: if the alternative was a box on sledge's ADSL, yes
 139 12:54 <aba> do we still need a hosting place for that box?
 140 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
 141 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?
 142 12:55 <aj> ooo
 143 12:55 <elmo> aba: not if blackcat are happy to host it
 144 12:56 <aj> there's a good question to add: "Is port cursed?"
 145 12:56 <aba> elmo: good. Otherwise, I have 2-4 places in .de/.at where we might have quite good changes
 146 12:56  * aj wonders what ia64's answer would've been
 147 12:56 <kyllikki> elmo: huggie said it was ok
 148 12:56 <neuro> how about the standards that the (lib)C implementations conforms to?
 149 12:57 <Q_> That's for non-linux ports I guess?
 150 12:57  * maswan grumbles about the relevant people at his uni not answering his inquiries about hosting devel machines
 151 12:57 <neuro> yes
 152 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
 153 12:58 <kyllikki> elmo: and drunk in charge of root login shouldnt be allowed
 154 12:58 <Q_> From what I understand, there are 2 netbsd ports, but they use a different libc?
 155 12:59 <aj> okay, reload, there's some OS-specific questions too
 156 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
 157 12:59 <kyllikki> elmo: fil offered to do the admin too, would that be helpful?
 158 12:59 <elmo> kyllikki: fil's already DSA, that's somewhat redundant?
 159 12:59 <aj> fil's DSA? who's fil?
 160 12:59 <kyllikki> elmo: yeah but he offered to do the setup specificaly if others were too busy
 161 12:59 <elmo> phil hands
 162 13:00 <elmo> kyllikki: if he does, then, great
 163 13:00 <aj> wow, he ircs and everything
 164 13:01 <nyu> Q_: yes, but none of them is active
 165 13:02 <nyu> Q_: (besides, most of the ongoing work on gnu/kfreebsd can be reused for gnu/knetbsd)
 166 13:03 <aj> oh, biarch needs a mention
 167 13:03 <aj> why shouldn't gnu/k*bsd be bi/triarch anyway?
 168 13:03 <nyu> tri?
 169 13:04 <nyu> we have Linux abi emulation, with some caveats.  biarch can be provided if someone works on it
 170 13:04 <aj> free, net, open
 171 13:05 <nyu> abi is different
 172 13:05 <nyu> oh, right
 173 13:05 <nyu> free doesn't emulate the other *bsd afaik
 174 13:05 <nyu> net emulates free
 175 13:05 <mlots__> dragonfly bsd?
 176 13:05 <nyu> i don't know about open
 177 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
 178 13:06 <nyu> no idea about dragon either.  perhaps kernel interface is so similar we could just provide a "kernel of dragonfly" package instead
 179 13:07 <nyu> aj: http://wiki.debian.org/Debian_GNU/kFreeBSD_why
 180 13:08 <aj> " kFreeBSD offers an alternative in case Linux is branded illegal by the SCO case or other threats."
 181 13:08 <aj> *cough*
 182 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.
 183 13:09 <mlots____> My appologies for the disconnects. I'm not sure what's happening.
 184 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
 185 13:10 <aj> mlots____: you're still pretty laggy
 186 13:11 <mlots> This connection seems to be pretty unusable. Sorry aj
 187 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
 188 13:12 <neuro> that's a huge undertaking, however.
 189 13:12 <nyu> aj: doesn't sound easy
 190 13:12 <nyu> although there are plans for it
 191 13:13 <nyu> but not short term
 192 13:13 <nyu> besides, there's only one active *bsd port atm
 193 13:13 <neuro> look at how much work has to be done in say, d-i, to go from 2.4 to 2.6.
 194 13:13 <nyu> heh yes
 195 13:13 <nyu> we have problems with 5.x vs 6.x too
 196 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
 197 13:14 <aj> nyu: managing 15G of debs isn't easy either
 198 13:15 <neuro> it also makes packaging more complex, which tends to make it more fragile
 199 13:15 <nyu> aj: i didn't mean it was
 200 13:16 <aj> okay, http://ftp-master.debian.org/archive-criteria.html - updated again
 201 13:17 <neuro> (the patches I've had for !linux archs that break linux are almost at a 1:1 ratio, for example...)
 202 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
 203 13:17 <nyu> Guillem Jover had a document about kernel-independant userland if you're interested, though
 204 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"
 205 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?
 206 13:20 <neuro> nyu: the point is in making clear what the requirements are
 207 13:20 <neuro> and why they exist
 208 13:20 <nyu> ah, ok
 209 13:21 <nyu> ah, found it
 210 13:21 <nyu> http://www.hadrons.org/~guillem/debian/ports/gnu-any/
 211 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"
 212 13:22 <neuro> you can't, as a distribution, integrate all of the components well if your packages limit themselves to gnu-any, however...
 213 13:22 <nyu> yes
 214 13:22 <nyu> it's a difficult issue
 215 13:22 <nyu> but "gnu-any" is just a long-term plan
 216 13:23 <nyu> it needs huge work to even get hello.c, and hasn't even started yet
 217 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)
 218 13:23 <nyu> I don't think we should center the discussion on this
 219 13:23 <aj> the biarch question needs to be answered before you get a "yes", though
 220 13:24 <aj> (same as for mip/mips, sh*, ppc/ppc64, etc)
 221 13:25 <nyu> biarch is no problem.  the problem is making a base system that can boot/work with any of them
 222 13:25 <nyu> we can't handle all kernel-specific apps or libraries in a case-by-case basis
 223 13:25 <aj> that doesn't seem very important? have a base system for kfreebsd, a different one for knetbsd, and common apps
 224 13:26 <nyu> uhm
 225 13:26 <nyu> we could use kfreebsd ABI, and then get knetbsd to run *most* of kfreebsd userland
 226 13:27 <nyu> but is that technicaly possible with biarch?
 227 13:27 <nyu> i thought both arches had to be complete
 228 13:27 <aj> everything's technically possible
 229 13:27 <nyu> well, right
 230 13:28 <nyu> then if someone wants to do a knetbsd port, they'd have to:
 231 13:28 <nyu> - extend biarch to support this combination
 232 13:28 <nyu> - build a base system specific to knetbsd, plus kernel-specific apps/libs
 233 13:28 <nyu> - use kfreebsd-i386 packages for the rest
 234 13:28 <nyu> that sounds plausible?
 235 13:29 <aj> if it was going to support netbsd kernels, it'd make sense to call it kbsd-i386
 236 13:29 <nyu> yes
 237 13:30 <nyu> but:
 238 13:30 <nyu> - what about abi emulation for kfreebsd in non-bsd systems?
 239 13:31 <nyu> - kfreebsd-i386 is not necessarily a wrong name even if knetbsd was added, it would describe the kernel abi
 240 13:31 <nyu> (and it wouldn't be less descriptive than, say, i386)
 241 13:31 <aj> those are things you should note down for the related arches question
 242 13:32 <aj> probably doing some analysis of the differences between freebsd ABI, netbsd ABI and potential gnu-bsd ABI
 243 13:33 <nyu> well, at kernel level we use the same abi as upstream
 244 13:33 <nyu> coming up with something new (and incompatible) doesn't sound like a good idea
 245 13:34 <nyu> btw, will there be a public log of this?
 246 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
 247 13:34 <aj> yeah, i'll probably stick it up on wiki.d.o
 248 13:34 <nyu> i see
 249 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?
 250 13:35 <aj> "we can support netbsd well" ==>. "no need for a knetbsd arch" ==>. reassuring
 251 13:35 <aj> "freebsd rocks, who cares about netbsd" ==>. "if we add this will we be adding netbsd next week? _why??_" ==>. concerning
 252 13:36 <aj> put a response up on the wiki as per the release qualification stuff i think
 253 13:36 <aj> i'm not sure the page is done yet, though; any other comments or additions anyone?
 254 13:37 <nyu> alright
 255 13:37 <nyu> would a proof-of-concept package of knetbsd image for kfreebsd-i386 help?
 256 13:37 <nyu> i mean, rather, a base system
 257 13:38 <aj> numbers on how much it sucks compared to a real freebsd and netbsd system would help too
 258 13:39 <nyu> benchmarks?
 259 13:39 <aj> yeah
 260 13:39 <nyu> i don't think it'll be significantly different
 261 13:40 <nyu> but we can do it, yes..
 262 13:42 <mlots> Ugg, bad DI-624... sorry
 263 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...
 264 13:44 <mlots> but it's dev's don't consider it stable.
 265 13:45 <Q_> What still needs to happen before the mirror split can happen?
 266 13:45 <mlots> It certainly isn't from a packaging point of view. From a running point of view, sometimes it is.
 267 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...)
 268 13:47 <aj> ah, you're here now?
 269 13:47 <aj> so what's this win32 port and reactos stuff?
 270 13:48 <mlots> I figure it's possible given mingw.
 271 13:48 <mlots> ReactOS can deal with the elf format, I'm not sure if that means running linux apps though.
 272 13:49 <aj> what is reactos?
 273 13:49 <mlots> http://www.reactos.org
 274 13:49 <Ganneff> aj: free nt kernel
 275 13:49 <mlots> It uses wine code for some of the userspace.
 276 13:50 <aj> so effectively a windows clone?
 277 13:50 <nchip> Daniel Rouso is not around but is there any issues with uclibc debian ports?
 278 13:50 <mlots> aj: mostly. They diverge in places. They aim for binary compatibility where it makes sence.
 279 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
 280 13:51 <aj> mlots: eg?
 281 13:52 <mlots> aj: The internal parts of the kernel and low level things can be REactOS specific.
 282 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?
 283 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).
 284 13:54 <nchip> neuro: well there is only one technical reason to have uclibc, it uses a low less memory
 285 13:54 <mlots> aj: Think of drivers that can't run on Linux...
 286 13:54 <aba> mlots: why is ReactOS better as kernel than say Linux?
 287 13:54 <mlots> aba: re above. ;-)
 288 13:55 <mlots> aba: and wine has some limitations because of Linux and XWindows.
 289 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...
 290 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?
 291 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?
 292 13:56 <mlots> aj: It's hard to quantify that.
 293 13:57 <aj> "wine has limitations because of linux and xwindows" ?
 294 13:57 <aj> reactos + wine is more capable than linux + wine?
 295 13:57 <nchip> neuro: I don't know. 
 296 13:58 <mlots> aj: for userspace, sometimes. There are scheduler issues, graphics limitations, convertion requirements...
 297 13:58 <neuro> nchip: that's the sort of things that would need to be known before making a port of it.
 298 13:58 <aj> interesting
 299 13:58 <DavidS> neuro: see http://uclibc.org/FAQ.html#doesnt_suck for a short paragraph vs glibc
 300 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?
 301 13:59 <mlots> aj: I beleive so. I'm not sure whether PE or ELF is the right way to go.
 302 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
 303 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
 304 14:00 <mlots> aj: I'd rather just concentrait on ReactOS. Gives people more insentive to develop it.
 305 14:01 <nchip> here's some motivation behind it: https://www.debconf.org/comas/general/proposals/11
 306 14:01 <mlots> aj: where would one draw the line for ulibc Not For Us?
 307 14:01 <DavidS> aj: yes, saving 30MB in the libc and then adding 300MB for KDE makes not much sense
 308 14:01 <aj> mlots: *shrug* that's one of the things that need thought :)
 309 14:02 <nchip> aj: with the same argument compiling kde for m68k is insane.
 310 14:03 <aj> nchip: m68k is (at least currently) a real port, so compiling kde is pretty much expected
 311 14:03 <mlots> aj: Why?
 312 14:03 <DavidS> another problem with uclibc is, that they are never ABI compatible between releases ...
 313 14:03 <aj> mlots: because that's what real ports do -- work the same no matter what hardware they're run on
 314 14:04 <nchip> DavidS: that's a big problem
 315 14:04 <mlots> aj: There's no memory or speed limitations for "real ports"?
 316 14:04 <aj> you could do patches to make "debian/rules binary ULIBC=yes" work for the apps people're actually interested in
 317 14:05 <aj> mlots: "can keep up with building kde" :)
 318 14:05 <mlots> aj: It seems that a port with limited resources (cpu, memory...) would still be useful. e.g. embeded systems.
 319 14:05 <mlots> aj: Perhaps that's  different "class" of ports other than "real" though?
 320 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)
 321 14:06 <mlots> aj: Yes, can the two be seperate though?
 322 14:06 <aj> mlots: yes, that would be an "embedded" port instead of a "real" one, which is entirely hypothetical at this point
 323 14:06 <mlots> It's hard to say has upstream support if the users aren't using the thing supported by upstream.
 324 14:06 <aj> mlots: not really -- an XP port would violate the SC; a reactos port might not pass the "useful?" test
 325 14:07 <nchip> aj: with that sentiment, embedded debian does not make much sense. it will be just easier to compile your own distro.
 326 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
 327 14:07 <aj> nchip: huh?
 328 14:07 <aj> nchip: i'm all for m68k being an "embedded" or some other !real port, it just isn't that currently
 329 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?
 330 14:08 <aj> oh, right, debian/rules ym
 331 14:08 <mlots> aj: ReactOS is used by a reasonable sized community right now.
 332 14:09 <mlots> aj: I'd more like to get a win32 port to "second class citizen" at this point.
 333 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
 334 14:09 <DavidS> nchip: but yes, testing migration would be a pain anyways :)
 335 14:10 <aj> mlots: can't you make XP run ELF binaries or whatever anyway?
 336 14:10 <nchip> mlots: I would like to make it easier
 337 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).
 338 14:11 <aj> is PE that much bigger than ELF?
 339 14:11 <mlots> aj: sure if you need to recompile.
 340 14:11 <aj> ...?
 341 14:11 <nchip> mlots: but currently it seems that the familiar approach is gaining more momentum
 342 14:11 <aj> you have to recompile everything for a new arch anyway?
 343 14:11 <aj> or are you saying "just run the linux binaries" ?
 344 14:12 <mlots> aj: I'm saying just run the linux binaries in the same way that kfreebsd might.
 345 14:12 <aj> kfreebsd was going to have all its own binaries ttbomk
 346 14:13 <mlots> They're not linux binaries neccesarily?
 347 14:13 <aj> we were talking about the freebsd abi earlier, not the linux abi
 348 14:13 <aj> i didn't think any of them were linux binaries
 349 14:13 <aj> i may be mistaken
 350 14:13 <braindmg> mlots: we don't use the linux compat layer
 351 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
 352 14:15 <neuro> nchip: you don't see how the two are related?
 353 14:16 <mlots> I guess I'm not sure if syscalls leak into binaries when things aren't compiled statically.
 354 14:16 <mlots> Anyway I agree with nchip, that's getting a bit into implementation.
 355 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
 356 14:17 <neuro> nchip: why does it need to be on the debian archive server to determine if it is sensical/useful or not?
 357 14:17 <mlots> Aren't most SCC's not sensible until they become part of the archi