Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #85152 > unrolled thread

Usage of real m68k hardware

Back to article view | Back to linux.debian.devel

Contents

  Usage of real m68k hardware Andreas Tille <andreas@an3as.eu> - 2018-03-28 08:40 +0200
    Re: Usage of real m68k hardware John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2018-03-28 09:00 +0200
      Re: Usage of real m68k hardware Andreas Tille <andreas@an3as.eu> - 2018-03-28 10:00 +0200
        Re: Usage of real m68k hardware Carsten Strotmann <cas@strotmann.de> - 2018-03-28 10:20 +0200
        Re: Usage of real m68k hardware John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2018-03-28 10:20 +0200
          Re: Usage of real m68k hardware Laurent Vivier <laurent@vivier.eu> - 2018-03-28 10:20 +0200
          Re: Usage of real m68k hardware Ole Streicher <olebole@debian.org> - 2018-03-28 11:50 +0200
        Re: Usage of real m68k hardware Chris Lamb <lamby@debian.org> - 2018-03-28 11:10 +0200
          Re: Usage of real m68k hardware John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2018-03-28 11:40 +0200
            Re: Usage of real m68k hardware Andreas Tille <andreas@an3as.eu> - 2018-03-28 12:10 +0200
              Re: Usage of real m68k hardware Emilio Pozuelo Monfort <pochu@debian.org> - 2018-03-28 12:30 +0200
              Re: Usage of real m68k hardware Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-03-28 13:40 +0200
            Re: Usage of real m68k hardware Thorsten Glaser <t.glaser@tarent.de> - 2018-04-17 19:30 +0200
              Re: Usage of real m68k hardware Ingo Jürgensmann <ij@2018.bluespice.org> - 2018-04-17 21:40 +0200
    Re: Usage of real m68k hardware Ingo Jürgensmann <ij@2018.bluespice.org> - 2018-03-28 09:30 +0200
    Re: Usage of real m68k hardware Carsten Strotmann <carsten@strotmann.de> - 2018-03-28 10:50 +0200
    Re: Usage of real m68k hardware Finn Thain <fthain@telegraphics.com.au> - 2018-03-28 11:20 +0200
      Re: Usage of real m68k hardware Andreas Tille <andreas@an3as.eu> - 2018-03-28 12:20 +0200
        Re: Usage of real m68k hardware Geert Uytterhoeven <geert@linux-m68k.org> - 2018-03-28 13:00 +0200
        Re: interpretation of wontfix Simon McVittie <smcv@debian.org> - 2018-03-28 13:10 +0200
          Re: interpretation of wontfix Andreas Tille <andreas@an3as.eu> - 2018-03-28 14:00 +0200
            Re: interpretation of wontfix Marvin Renich <mrvn@renich.org> - 2018-03-28 14:30 +0200
          Re: interpretation of wontfix Marco d'Itri <md@Linux.IT> - 2018-03-28 14:50 +0200
            Re: interpretation of wontfix Holger Levsen <holger@layer-acht.org> - 2018-03-28 17:30 +0200
          Re: interpretation of wontfix Jonas Smedegaard <jonas@jones.dk> - 2018-03-28 15:40 +0200
          Re: interpretation of wontfix Sean Whitton <spwhitton@spwhitton.name> - 2018-03-28 19:10 +0200
            Re: interpretation of wontfix Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-03-29 15:00 +0200
              Re: interpretation of wontfix Sean Whitton <spwhitton@spwhitton.name> - 2018-03-29 17:20 +0200
              Re: interpretation of wontfix Adrian Bunk <bunk@debian.org> - 2018-03-29 20:30 +0200
          Re: interpretation of wontfix Don Armstrong <don@debian.org> - 2018-03-28 20:10 +0200
            Re: interpretation of wontfix Sean Whitton <spwhitton@spwhitton.name> - 2018-03-29 00:10 +0200
              Re: interpretation of wontfix Andreas Tille <andreas@an3as.eu> - 2018-03-29 08:30 +0200
            Re: interpretation of wontfix Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-03-29 15:10 +0200
              Re: interpretation of wontfix Ian Campbell <ijc@debian.org> - 2018-03-29 15:20 +0200
                Re: interpretation of wontfix Scott Kitterman <debian@kitterman.com> - 2018-03-29 16:20 +0200
                Re: interpretation of wontfix Wouter Verhelst <wouter@debian.org> - 2018-03-29 16:30 +0200
                  Re: interpretation of wontfix Adrian Bunk <bunk@debian.org> - 2018-03-29 20:20 +0200
    Re: Usage of real m68k hardware Holger Levsen <holger@layer-acht.org> - 2018-03-28 14:00 +0200
      Re: Usage of real m68k hardware Russ Allbery <rra@debian.org> - 2018-03-28 19:30 +0200
        Enhanced syntax for Architecture field (Was: Usage of real m68k  hardware) Andreas Tille <andreas@an3as.eu> - 2018-03-28 20:30 +0200
          Re: Enhanced syntax for Architecture field (Was: Usage of real m68k  hardware) Adam Borowski <kilobyte@angband.pl> - 2018-03-28 22:30 +0200
            Re: Enhanced syntax for Architecture field Ole Streicher <olebole@debian.org> - 2018-03-29 09:50 +0200
              Re: Enhanced syntax for Architecture field Adam Borowski <kilobyte@angband.pl> - 2018-03-29 19:30 +0200
        Re: Usage of real m68k hardware Adrian Bunk <bunk@debian.org> - 2018-03-28 20:30 +0200
          Re: Usage of real m68k hardware Michael Gilbert <mgilbert@debian.org> - 2018-04-01 01:50 +0200
        Re: Usage of real m68k hardware Philipp Kern <pkern@debian.org> - 2018-03-28 22:00 +0200
          Re: Usage of real m68k hardware Russ Allbery <rra@debian.org> - 2018-03-28 22:30 +0200
    Re: Usage of real m68k hardware Sean Whitton <spwhitton@spwhitton.name> - 2018-03-28 19:10 +0200
    Re: Usage of real m68k hardware Wouter Verhelst <wouter@debian.org> - 2018-03-29 14:10 +0200
      Re: Usage of real m68k hardware Andreas Tille <andreas@an3as.eu> - 2018-03-29 14:20 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#85187 — Re: Enhanced syntax for Architecture field (Was: Usage of real m68k hardware)

On Wed, Mar 28, 2018 at 08:28:23PM +0200, Andreas Tille wrote:
> On Wed, Mar 28, 2018 at 09:24:12PM +0300, Adrian Bunk wrote:
> > 
> > Dependency fields have negative syntax like !m68k, for the Architecture: 
> > field this is only possible with a complete list of all architectures
> > except the one you want to exclude.
> 
> I agree this could really simplify things and I would have used this
> syntax in several cases.

Note that pretty much every place we have a list of architectures expects a
different syntax.  This causes confusion, and, as you say, is painful due to
a lack of such functionality.

I don't remember the details, but IIRC dependencies also have a limit of not
allowing both positive and negative specifiers.

Thus, if we'd change this, what about changing the rules to:
an architecture is allowed iff:
it matches at least one positive specifier -or- there's none,
and it doesn't match any negative specifier.
(Ie, negatives have priority, no positives assumes "any".)

The other change I'd make would be adding extra wildcards:
* {big,little}-endian
* {32,64,128¹}-bit
* "fast" (and/or it's near-complement "slow")

Thus, Andreas would mark his package, avoiding wasting time of either his or
small-arch porters.


Meow!

[1]. riscv128 already exists, although not in dpkg's arch table.  And at
least Google has enough storage in its servers to require more than 64-bits
to address if you use it as virtual memory.  And, recent extension to la57
was just 12 years after la48, which gives an estimate for when 64 bits won't
be enough for anyone even for a single machine.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄⠀⠀⠀⠀ A master species delegates.

[toc] | [prev] | [next] | [standalone]

#85197 — Re: Enhanced syntax for Architecture field

Adam Borowski <kilobyte@angband.pl> writes:
> The other change I'd make would be adding extra wildcards:
> * {big,little}-endian
> * {32,64,128¹}-bit
> * "fast" (and/or it's near-complement "slow")

In principle, these could be simple dependencies: Either empty packages
that exist only on the architectures fullfilling the condition, or
virtual packages that are (arch dependent) Provides of a single,
architecture defining package.

Best

Ole

[toc] | [prev] | [next] | [standalone]

#85225 — Re: Enhanced syntax for Architecture field

On Thu, Mar 29, 2018 at 09:30:47AM +0200, Ole Streicher wrote:
> Adam Borowski <kilobyte@angband.pl> writes:
> > The other change I'd make would be adding extra wildcards:
> > * {big,little}-endian
> > * {32,64,128¹}-bit
> > * "fast" (and/or it's near-complement "slow")
> 
> In principle, these could be simple dependencies: Either empty packages
> that exist only on the architectures fullfilling the condition, or
> virtual packages that are (arch dependent) Provides of a single,
> architecture defining package.

I've tried this approach for the case when a package needs (for various
reasons) an ISA extension above the baseline, and it didn't go well.

Another trouble is that, as it's said, because DAK relies on stable's dpkg
you can't have a package even declaring a relation on an architecture that's
not know to stable's dpkg.  This would make porting tedious.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ When I visited the US a couple decades ago, Hillary molested and
⣾⠁⢰⠒⠀⣿⡁ groped me.  You don't believe?  Well, the burden of proof is on you!
⢿⡄⠘⠷⠚⠋⠀ Flooding a douche with obviously false accusations makes your other
⠈⠳⣄⠀⠀⠀⠀ words dubious even when they happen to be true.

[toc] | [prev] | [next] | [standalone]

#85183

On Wed, Mar 28, 2018 at 10:26:28AM -0700, Russ Allbery wrote:
>...
> The chances of anyone really wanting to run some of this scientific
> software on m68k seem remote, so it feels like it would be an overall
> reduction of friction if the maintainer could just say "I don't support
> this arch" and the porters could stop looking at those packages (unless
> for some reason they disagree with the maintainer and think users of that
> arch are really interested).

The core problem is that in the control file the permitted syntax for 
the Architecture: filed is much more restricticted than the permitted 
syntax for (build) dependencies.

Dependency fields have negative syntax like !m68k, for the Architecture: 
field this is only possible with a complete list of all architectures
except the one you want to exclude.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

[toc] | [prev] | [next] | [standalone]

#85258

On Wed, Mar 28, 2018 at 2:24 PM, Adrian Bunk wrote:
> The core problem is that in the control file the permitted syntax for
> the Architecture: filed is much more restricticted than the permitted
> syntax for (build) dependencies.

This is dpkg bug #807264.

Best wishes,
Mike

[toc] | [prev] | [next] | [standalone]

#85184

On 03/28/2018 07:26 PM, Russ Allbery wrote:
> Back when I was maintaining OpenAFS, I frequently wanted some way as a
> maintainer to easily tag a package as "this will never for the forseeable
> future be supported on this architecture" and move on.  We don't have a
> great mechanism for doing this right now -- there's a thing on the buildds
> that's pretty opaque and that I don't know how to set as a maintainer, and
> one can list a bunch of specific architectures on the package but that's
> really awkward and interacts poorly with arch: all packages.

The recommended way today is to annotate within the package. It does not
actually interact poorly with arch:all packages. When dpkg builds the
source package and there's no arch:any package it will list all
architectures explicitly in the .dsc and if there's an arch:all package
all will be added in addition.

Kind regards
Philipp Kern

[toc] | [prev] | [next] | [standalone]

#85186

Philipp Kern <pkern@debian.org> writes:
> On 03/28/2018 07:26 PM, Russ Allbery wrote:

>> Back when I was maintaining OpenAFS, I frequently wanted some way as a
>> maintainer to easily tag a package as "this will never for the
>> forseeable future be supported on this architecture" and move on.  We
>> don't have a great mechanism for doing this right now -- there's a
>> thing on the buildds that's pretty opaque and that I don't know how to
>> set as a maintainer, and one can list a bunch of specific architectures
>> on the package but that's really awkward and interacts poorly with
>> arch: all packages.

> The recommended way today is to annotate within the package. It does not
> actually interact poorly with arch:all packages. When dpkg builds the
> source package and there's no arch:any package it will list all
> architectures explicitly in the .dsc and if there's an arch:all package
> all will be added in addition.

Ah, good to know.  However, this still means that you have to explode
"any" into a list of every architecture Debian supports except one or two,
and then every time someone wants to port Debian to a new architecture,
they have to ask you to change your package (my prior experience is that
the package would work on new architectures more often than not, since
they were often variations of existing supported architectures, like
64-bit versions of things that already worked with 32 bits).

So unless I'm missing something this still seems less than ideal....

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#85178

[Multipart message — attachments visible in raw view] — view raw

Hello,

There is clearly some dissatisfaction between the science team and the
m68k porters.  Several behaviours have been identified in various mails
to this thread that are causing friction for the other team's work.

ISTM that these issues could well arise between any group of porters and
any team maintaining a large number of packages.  We should be able to
develop BTS usage strategies that reduce this friction.  We've done this
before (e.g. how we do NMUs) and can surely come up with something
sensible.

What do we have right now?  AFAICT our current documentation is just
sections 5.10.1 and 5.10.2 of the Developers' Reference.  These sections
are quite short.  I would like to suggest that we expand those sections
with further best practices.  Perhaps Andreas and Adrian could propose
some patches to devref and get members of the other team to review.

I don't have any concrete suggestions myself because my packages are
almost all arch:all so I have barely had to deal with porting issues.
It seems clear, though, that our best practices are a bit lacking in
this area.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#85204

On Wed, Mar 28, 2018 at 08:38:10AM +0200, Andreas Tille wrote:
> Hi,
> 
> recently some R packages received bugs that seem to stem from a problem
> with the build setup (specifically, a qemu bug).  When I asked back in
> one of the bugs[1] whether there are real m68k users I've got the answer
> 
>   ... there are still some users with actual hardware, but the
>   autobuilders use qemu for better performance and/or reliability
> 
> I conclude that the Debian project is running no real m68k hardware any
> more (please correct me if I'm wrong) and we are possibly doing a
> service for some users who potentially also run qemu (wild guess of
> mine).  I'm wondering when it might be time to fully drop a hardware
> port instead of draining developer time for ethernity.

I understand your desire to not be bothered with bugs that are not
yours. That makes sense.

However, it does *not* make sense to then tell others that their work is
not welcome anymore. If people want to spend time doing what you think
is useless busywork, then, as long as they don't bother you with things
that aren't your fault, why not let them?

Under "don't bother you with things", I mean to say that:
- Bugs should not be filed unless it can be reproduced on actual
  hardware.
- Bugs should not be filed at RC severity unless the bug is reproducible
  on a release architecture, or can be proven to be an actual bug in the
  package

As for the former: Adrian, I recently passed a bunch of m68k machines to
you. Would it make sense to set (some of) those up as secondary buildd
hosts? That is, try to build everything on emulated machines first
(because those are much faster). If something FTBFS, try to rebuild it
on hardware. If it FTBFS there, bugs can be filed; if not, upload the
package and track down the emulator bug...?

(if you're already working on that, then ignore what I said :-)

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
     Hacklab

[toc] | [prev] | [next] | [standalone]

#85205

On Thu, Mar 29, 2018 at 02:07:41PM +0200, Wouter Verhelst wrote:
> > I conclude that the Debian project is running no real m68k hardware any
> > more (please correct me if I'm wrong) and we are possibly doing a
> > service for some users who potentially also run qemu (wild guess of
> > mine).  I'm wondering when it might be time to fully drop a hardware
> > port instead of draining developer time for ethernity.
> 
> I understand your desire to not be bothered with bugs that are not
> yours. That makes sense.
> 
> However, it does *not* make sense to then tell others that their work is
> not welcome anymore. If people want to spend time doing what you think
> is useless busywork, then, as long as they don't bother you with things
> that aren't your fault, why not let them?

ACK.  I confirm that my wording sucks and will be more carefull next
time.  Sorry again

     Andreas.

-- 
http://fam-tille.de

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | linux.debian.devel

csiph-web