Re: The future of an SCC that has been given up on
(As a general note, putting empty lines in between quotes
and your own text, as well as removing empty quoted lines,
i.e. those only consisting of '>>> ', at the beginning and
end of quoted text, makes it much more legible, I’ve had a
hard time digging through your mail. The same goes for
disabling(!) format=flowed, PLEASE do that.)
schmitz dixit:
>> And if youb> and let them run the testsuites.
>>
> That option is news to me - running testsuites used to be mandatory.
Dunno, it can’t be mandatory if Policy shows a way to disable them.
It’s probably mandatory if you want support from packagers, but,
honestly, as long as it’s just me, I’d rather have a broken package
that fulfills B-D of another package instead of spending time with
yak-shaving. (Though, one of my own packages benefits from running
a testsuite after native compilation – mksh’s choice of C libraries
for the mksh-static binary is affected.)
> ever looked at radeonfb from an Atari perspective. Didn't even know there is
> Atari support in there.
Not yet, but that’s probably due to lack of a PCI bus attachment
on Atari. From what ragnar76 told me, they basically took the
Linux radeonfb driver and ported it to MiNT…
> So there are non-X packages that depend on X as build dependencies?
Yes. Lots. Also, packages that build X subpackages and nōn-X
subpackages.
> Doesn't seem to specify the protocol clearly. Yes, I know FTP sucks. But what's
> the simple alternative for anonymous uploads?
That’s the point – WHY should these uploads be anonymous? In my opinion,
they must NOT be anonymous. (Not that we’d need the name of the uploader
but the uploads are at least roughly authorised that way.)
> dupload used to have a ssh upload queue option. Even a rsync over ssh one. If
> we use either, I don't see the need for signed log files.
Logfiles aren’t uploaded with dput or dupload. They’re ignored by these
tools, as they’re not listed in the .changes file. Uploading logs is
totally orthogonal to uploading packages.
>> One commit per patch is a lot of work ;-)
> But it allows cherry picking only those needed using the list of patches from
> the build config. I may be off base there.
*shrug* git’s not a favourite tool of mine. I’m probably the odd one.
> See above - it's not that easy. I'll try again but it won't be in 3.5. Maybe
> the EtherNAT (smc91x) is going to be less controversial.
> You can bet that it's my priority to get patches merged upstream. We'd still
> use the old EtherNAT and EtherNEC code otherwise.
OK, good luck then.
bye,
//mirabilos
--
13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good
guy. But he's always right! In every fsckin' situation, he's right. Even
with his deeply perverted taste in software and borked ambition towards
broken OSes - in the end, he's damn right about it :(! […] works in mksh
Reply to: