Re: Debian on Lenovo Chromebook (ARMv8)

2023-04-14 Thread Brian Sammon
On Mon, 10 Apr 2023 22:54:09 +0300
Alper Nebi Yasak  wrote:

> > Is there anywhere (besides this list) that I should be
> > reading/subscribed to to learn more about debian-installer support
> > for Chromebooks?
> 
> Installer discussion in general happens at the debian-boot@ list and
> #debian-boot IRC channel. I'm not exactly talkative while I work, though
> I'm bound to announce things there eventually. If you want a general
> overview of things, I had a talk at DebConf22 [1], but it's somewhat
> outdated as things progressed.

So, how far have things progressed?  Have they reached the point where I (or 
owners of other model chromebooks) should be testing the latest snapshot of the 
Debian Installer on my (ARM) chromebook, and submitting bug reports?  Or should 
I wait for an announcement?



Re: abi-compliance-checker and library transitions [Re: another attempt at Y2038]

2023-04-14 Thread Steve Langasek
Sorry for the long radio silence on this; I had identified some issues with
my prior report and wanted to rerun it with some fixes, and that analysis
took rather longer than expected (mainly due to infrastructure slowness).

Refreshed output for Ubuntu is here:

  https://people.canonical.com/~vorlon/armhf-time_t/

So comparing with Wookey's results, I see:

Total -dev packages tested: 4603
Time_t changes ABI: 349
LFS changes ABI: 71
ABI unchanged: 2085
Compilation failed: 2098

So certainly this appears to be the same order of magnitude as Wookey's
separate analysis.

The other question is what impact this has on the archive as a whole, with
triggering of rebuild transitions.  Looking at the
reverse-build-dependencies of those 349 packages gives:

$ while read pkg; do grep-dctrl -n -sPackage -w -FBuild-Depends $pkg 
/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_lunar_*Sources  ; done < 
abi-breaks  | sort -u | wc -l
3626
$

NB this is a bit of an undercount as a result of packages that ship headers
but aren't the thing being directly build-depended on.  A more accurate
count is probably to look at binary packages, from the same source as the
-dev package, that the -dev package depends on and look at
reverse-dependencies of those.  But for a first pass, here's where we are.

There are also roughly 2100 packages for which compilation failed.  To know
which packages actually have ABI changes and require transitions, we would
need to work through this list and get the count down to 0.

But as a first-order approximation, this looks doable to me as a transition
we could manage.

What do other folks think?  Are you on board with proposing this to
debian-devel?  Anyone want to help add the necessary quirks to drive down
the list of compilation failures?


On Tue, Mar 21, 2023 at 03:00:41AM +, Wookey wrote:
> On 2023-02-15 17:08 +, Wookey wrote:
> > On 2023-02-04 21:42 -0800, Steve Langasek wrote:
> > 
> > Yes I think we should proceed with this analysis on debian to get a
> > better handle on just how many libraries we are looking at.
> 
> OK. We have over 10,000 *-dev package in debian so this took a while,
> but I've now finished an initial pass.
> The results are:
> Total -dev packages: 10323
> Time_t changes ABI: 329
> LFS changes ABI: 580.6%
> ABI unchanged: 18405.6%
> Compilation failed: 1637 
> No headers in pkg: 3852
> No library in pkg: 5086
> total analysed: 10249
> (note that the no-headers and no-libs categories are not exclusive
> - the other classifications are)
> 
> Not quite sure where we lost 74 packages down the back of the sofa but at 
> 0.7% it's noise.
> 
> So we have about 5000 packages which can basically be ignored for this 
> purpose:
> golang* (1943)
> librust* (1955) - source-only, no dynamic linking, no .so's in any package
> and libghc* (1065) - changes ABI at drop of hat (every new version) anyway. 
> 
> Of the remaining 5360, 5237 have .so files to check. Of those 329
> change ABI and another 58 are not built with LFS currently
> so also change ABI due to that. That's 387 (7%).
> 
> 34% are fine. And an annoyingly large 1637 (30%) did not build under
> Abi-compliance-checker to determine one way or the other. Assuming 7%
> of those are a problem that's another 114 packages.
> 
> I've yet to determine how many of the 'no-libs/no-headers' packages
> actually expose an ABI we need to worry about. There will be some
> more, from stuff like boost and Qt.
> 
> So the scale of the transition task in Debian is quite a lot bigger than in
> Ubuntu: Probably 400-500 packages. 
> 
> I've linked my lists on the wiki page.
> https://wiki.debian.org/ReleaseGoals/64bit-time
> 
> I believe Steve L (who has done most of the heavy lifting on the
> script) is running a check too and will have some results soon.
> 
> Wookey
> -- 
> Principal hats:  Debian, Wookware, ARM
> http://wookware.org/

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature


Re: buildd reliability

2023-04-14 Thread peter green

On 30/03/2023 19:59, Wookey wrote:

OK. I'll see what can be done. I see Altra servers are from
$7000-$53000 on https://store.avantek.co.uk/arm-servers.html.

What does DSA consider 'decent'? I guess we'd prefer the resilience of
a couple of reasonable machines over one ridiculously manly one. A bit
of configury on the Aventek site suggests that basic ARM Altra servers
cost about twice as much as AMD ones for similar specs
(cores/RAM/disk), but then the power consumption is less than half. I
don't know how the performance actually compares for buildd purposes
(nor what sort of spec we prefer in terms of
nodes/cores/RAM/Disk/networkIF), but people describe the Altra's as
'fast'. I'll try and collect some more details to quantify that.


I'm not DSA, but the problem i've found when looking at such hardware
has always been that the "cost of entry" is so high. To me $7K is a
lot of money to put down "on spec".



It may well be worth approaching them to see if they would sponsor
some hardware, or at least provide a steep discount from list prices.
Debian is after-all one of the top Linux distros (and probablly the
top "community" distro).

Also can anyone confirm if these machines support arm32? or if they
are arm64 only?