Bug#1073181: ITP: thunk-gen -- 64-bit thunk generator for 16- and 32-bit code

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: thunk-gen
  Version : 0.0~git20240607.f9cae90
  Upstream Author : Stas Sergeev 
* URL : https://github.com/stsp/thunk_gen
* License : GPL
  Programming Lang: Bison/Flex, C
  Description : 64-bit thunk generator for 16- and 32-bit code

 thunk-gen is a thunk generator for C and assembler code, providing
 wrappers so that code written for 16- or 32-bit environments can be
 compiled for 64-bit environments.
 .
 It is intended for use with 64-bit DOS-style environments running
 code intended for 16- or 32-bit DOS, typically dosemu2.


This is a build-dependency for dosemu2. It doesn't pollute /usr/bin,
all its features are accessed through pkgconf and it installs
everything in /usr/libexec/thunk_gen or /usr/share/thunk_gen.

Bug#1074057: ITP: djstub -- DJGPP-compatible stub manipulation tools

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: djstub
  Version : 0.0~git20240621.49e7ba6-1
  Upstream Author : Stas Sergeev
* URL : https://github.com/stsp/djstub
* License : GPL
  Programming Lang: C
  Description : DJGPP-compatible stub manipulation tools

 This package provides DJGPP-compatible tools to manipulate stubbed
 executables, i.e. the MS-DOS MZ launcher for DOS-extended binaries:
 .
  - djstubify to modify the stub itself, in COFF and PE executables;
  - djlink to link ELF binaries and produce a dj64 executable;
  - djstrip to strip dj64 executables.
 .
 It includes a dj64-compatible stub, for use with dosemu2. It can be
 used with go32-compatible stubs, but no such stub is included.


This is a build dependency for dosemu2-related tools.

Re: Bug#1076583: ITP: minio-client -- Simple, fast tool to manage MinIO clusters

[Stephen Kitt]

On Sat, 20 Jul 2024 10:50:44 +0200, Salvo Tomaselli 
wrote:

> In data venerdì 19 luglio 2024 13:14:11 CEST, Mathias Gibbens ha scritto:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Mathias Gibbens 
> > X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
> > 
> > * Package name: minio-client
> >   Version : 2024-07-03T20-17-25Z-1
> >   Upstream Author : MinIO
> > * URL : https://github.com/minio/mc
> > * License : AGPL-3.0-or-later
> >   Programming Lang: Go
> >   Description : Simple, fast tool to manage MinIO clusters
> > 
> >  MinIO Client (mc) provides a modern alternative to UNIX commands like
> >  ls, cat, cp, mirror, diff, find etc. It supports filesystems and Amazon
> >  S3 compatible cloud storage service (AWS Signature v2 and v4).
> > 
> > There is an existing RFP (#859207) for the server-side component of
> > MinIO.
> > 
> > Incus recently switched from depending on MinIO's library to the MinIO
> > client for interacting with MinIO clusters. This package will be team-
> > maintained within the Go Packaging Team and provide the MinIO client
> > without conflicting with the existing `mc` from Midnight Commander.  
> 
> Just a head's up, /usr/bin/mc is taken by mc.

See the very last sentence of the ITP. The conflict was discussed in April,
see https://lists.debian.org/debian-devel/2024/04/msg00368.html

Regards,

Stephen


pgpu7xYvL8mm4.pgp
Description: OpenPGP digital signature

Re: Intent to MBF: move from fuse to fuse3

[Stephen Kitt]

Hi,

On Tue, 13 Aug 2024 20:02:48 +0200, Chris Hofstaedtler 
wrote:
> fuse (2.x) is long obsolete, yet we still have a long tail of packages
> (Build-)Depending on it. Given fuse and fuse3 are not coinstallable,
> IMO we should get packages off fuse.
> 
> Below is my proposed MBF wording, and a dd-list.
> 
> Chris
> 
> ---
> 
> Subject: SOURCE: move from fuse to fuse3
> 
> Source: SOURCE
> Version: VERSION
> Severity: normal
> 
> Dear Maintainer,
> 
> your package currently (Build-)Depends on fuse - that is
> fuse 2.x. A newer version of fuse, fuse3, is available
> since at least buster.
> 
> fuse (2.x) and fuse3 are not co-installable. On a typical
> Debian Desktop install, fuse3 is installed, and fuse 2.x
> cannot be installed.
> 
> This effect can be observed in the popcon graphs:
> https://qa.debian.org/popcon.php?package=fuse
> https://qa.debian.org/popcon.php?package=fuse3
> 
> Please migrate your package to fuse3, so our users can
> actually use it, and we can remove fuse 2.x in forky.

There are two separate concerns here: the fuse binary package used to provide
fusermount etc., and the library used by FUSE programs.

fuse and fuse3 are not co-installable, but that only affects fusermount and
co. libfuse2 and libfuse3 are co-installable.

This means that packages build-depending on libfuse-dev can produce binary
packages usable with fuse3; see for example loggedfs’s debian/control:

[…]
Build-Depends:
 debhelper-compat (= 13),
 libeasyloggingpp-dev,
 libfuse-dev,
 libpcre2-dev,
 libxml2-dev,
[…]
Depends: fuse (<< 3) | fuse3 (>= 3.10.1-3), ${misc:Depends}, ${shlibs:Depends}


I have a number of libfuse2-based packages running with fuse3, everything
works fine.

This doesn’t mean that the MBF isn’t warranted — migrating off of fuse would
be a good thing. There is some work involved however; see
https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0 for details
(perhaps the MBF message could include that).
https://bugs.debian.org/918984 and
https://bugs.debian.org/927291 are also relevant (although as mentioned
above, the latter isn’t a concern in practice).

Regards,

Stephen


pgpxC6zCt4q25.pgp
Description: OpenPGP digital signature

Re: Strange armel build error

[Stephen Kitt]

On Fri, 16 Aug 2024 17:46:45 +0200, Alec Leamas  wrote:
> Or just exclude that architecture i. e., list all archs but armel?

If you can’t fix the build, you don’t need to exclude the architecture — you
can ask for removal of the armel package in testing. That will allow the
package to migrate even if armel is missing.

Regards,

Stephen


pgpeskC3WTzHw.pgp
Description: OpenPGP digital signature

Re: Intent to MBF: move from fuse to fuse3

[Stephen Kitt]

On Wed, 21 Aug 2024 23:24:23 +0200, Chris Hofstaedtler 
wrote:
> Stephen,
> and everyone else who pointed out that coinstallability is a
> non-issue - thanks!

You’re welcome!

> About the additional work in fuse/fuse3, #918984 and #927291, I
> wonder if they are relevant to the libfuse consumers. Anyway, if we
> believe fuse3 works just fine with libfuse2-* consumers, then it
> seems like we should fix the package relationships between fuse3 and
> fuse.
> I'll followup in #927291 with suggestions.

Your suggestion there seems fine to me. I’d love to hear Laszlo’s thoughts on
the topic too!

> Updated MBF text proposal:
> 
> > Subject: SOURCE: move from fuse to fuse3
> > 
> > Source: SOURCE
> > Version: VERSION
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > your package currently (Build-)Depends on fuse - that is fuse 2.x.
> > A newer version of fuse, fuse3, is available since at least
> > buster.
> > 
> > Please migrate your package to fuse3, which is actively
> > maintained. It would be great if we could remove fuse 2.x in
> > the forky development cycle.

I would add a reference to
https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0 (which isn’t a
great migration guide but does list all the significant changes people
working on this will encounter).

> > If you cannot migrate yet, please at least update your Depends:
> > line. If you currently have:
> >   Depends: fuse
> > please update that to:
> >   Depends: fuse3 (>= 3.10.1-3) | fuse (<< 3)
> >
> > This allows mount.fuse and fusermount to be provided by fuse3,
> > which is what the majority of new installs already have [1].
> >
> > [1] compare https://qa.debian.org/popcon.php?package=fuse
> >  and https://qa.debian.org/popcon.php?package=fuse3  
> 
> Does that sound good?

It does to me, with the added reference above!

Regards,

Stephen


pgpZen7hGYit8.pgp
Description: OpenPGP digital signature

Re: Bug#1080344: ITP: bcachfs-tools -- bcachefs userspace tools

[Stephen Kitt]

On Mon, 02 Sep 2024 16:24:40 +0200, Daniel Gröber  wrote:
> I'm planning to re-introduce bcachefs-tools in Debian after it was
> recently RMed by Jonathan: O: #1078599, RM: #1079375.

You don’t need to re-introduce it, Jonathan took care to ensure that the
package wouldn’t be fully removed, as explained in the blog post.

If you want to go ahead with this, you should close the ITP (which isn’t
needed), update #1078599 to indicate you intend to adopt the package, and
when you upload a new package, close #1078599 in the changelog. See
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#adopting-a-package
and https://www.debian.org/devel/wnpp/#howto-o for details.

Regards,

Stephen


pgprWZkdjxfCf.pgp
Description: OpenPGP digital signature

Re: New stable version after Sarge

[Stephen Kitt]

On Thu, 6 Jan 2005 10:00:32 +0100, Jan Niehusmann <[EMAIL PROTECTED]> wrote:
> Good point. But that problem can be solved by some program checking that
> all installed packages are actually available from the selected
> distribution(s).
> 
> That could be integrated into apt (e.g. apt-get upgrade warning about
> packaged without a current installation canditate, or where the most
> recent version from the archives is older than the installed one), or it
> could be a separate tool. Perhaps it can even be done with existing
> tools?

Aptitude already does this to some extent - packages which aren't available
from a source in sources.list are placed in the "Obsolete and Locally Created
Packages" section.

Having a systematic warning would be annoying for people who have lots of
locally-created packages, e.g. kernel packages...

Stephen

Bug#583621: ITP: dasm -- macro assembler for 8-bit microprocessors

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 
Owner: Stephen Kitt 


* Package name: dasm
  Version : 2.20.11
  Upstream Author : Peter H. Froehlich 
* URL : http://dasm-dillon.sf.net
* License : GPL-2
  Programming Lang: C
  Description : macro assembler for 8-bit microprocessors

dasm is a macro assembler for the following 8-bit microprocessors:
 * MOS 6502 and 6507
 * Motorola 6803, 68705 and 68HC11
 * Hitachi HD6303
 * Fairchild F8
.
It also includes machine runtimes (support headers) for the Atari 2600
VCS and the Fairchild Channel F VES.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100528214509.10058.23101.report...@heffalump.sk2.org

Bug#584888: ITP: boing26 -- Boing! Amiga demo port for the Atari VCS 2600

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 


* Package name: boing26
  Version : 5
  Upstream Author : Rob Kudla 
* URL : http://www.kudla.org/raindog/games/
* License : Public domain
  Programming Lang: Assembler
  Description : Boing! Amiga demo port for the Atari VCS 2600

 Boing! is a small demo based on the famous Amiga-based bouncing ball
 demo.
 .
 This game is distributed as an Atari VCS 2600 ROM.  You will need a
 VCS 2600 emulator in order to view it, such as Stella.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100607114706.14375.46271.report...@heffalump.sk2.org

Re: Bug#584888: ITP: boing26 -- Boing! Amiga demo port for the Atari VCS 2600

[Stephen Kitt]

Hi,

On Mon, Jun 07, 2010 at 03:14:08PM +0200, Holger Levsen wrote:
> On Montag, 7. Juni 2010, Stephen Kitt wrote:
> > * License : Public domain
> >   Description : Boing! Amiga demo port for the Atari VCS 2600
> >
> >  Boing! is a small demo based on the famous Amiga-based bouncing ball
> >  demo.
> 
> What is the value of having this in Debian?

I wanted to package it so that stella could move to main - admittedly
on somewhat of a technicality... (The idea is similar to that behind
the packaging of efp, which allows NES emulators to be in main.) I am
trying to find something else more interesting which would satisfy the
requirements.

Given its size (the current .deb is 6k), it might be worth simply
bundling it with stella, in a multiple-tarball 3.0 format.

Obviously I'll withdraw my ITP if it doesn't make sense. I had
intended to explain all this in the original ITP, but forgot when I
got round to filing it!

Regards,

Stephen


signature.asc
Description: Digital signature

Re: Bug#584888: ITP: boing26 -- Boing! Amiga demo port for the Atari VCS 2600

[Stephen Kitt]

Hi Holger,

On Mon, Jun 07, 2010 at 04:39:20PM +0200, Holger Levsen wrote:
> On Montag, 7. Juni 2010, Stephen Kitt wrote:
> > I wanted to package it so that stella could move to main - admittedly
> > on somewhat of a technicality... 
> 
> /me is speechless, roles eyes and laughs :-)

I'll just laugh along!

> > Given its size (the current .deb is 6k), it might be worth simply
> > bundling it with stella, in a multiple-tarball 3.0 format.
> 
> That sounds way better to me.
> 
> But technically a package doesnt need to have something in main to work with. 
> It just needs to exist. Somewhere. If this bouncing ball demo is like those 
> free games (which are free software( for mame emulators stella can probably 
> go into main anyway.

OK, thanks for clarifying. I'll just mention it in the README.Debian
in the stella package, along with some pointers to other possible
sources of DFSG-free games.

I'm closing the ITP, there's no point poluting Debian with packages
such as these...

Thanks for your time,

Stephen


signature.asc
Description: Digital signature

Re: Bug#595427: ITP: winetricks -- Quick and dirty script todownload and install variousredistributable runtime libraries

[Stephen Kitt]

On Tue, 7 Sep 2010 10:13:15 +0100, David Goodenough
 wrote:
> On Tuesday 07 September 2010, Adam Borowski wrote:
> > Then, in the usual Debian parlance, "nonfree" usually suggests
> > proprietary gratis distributable things.  Winetricks includes a mix of
> > distributable, non-distributable and even non-gratis software (the last
> > cathegory requires that you have a valid Windows license).
> That is not true.  Winetricks is itself entirely free, and is just a simple
> script.  It then downloads the other materials from public web sites,
> but by no measure can those other materials be regarded as part of
> wine-tricks - Microsoft would have something to say about that if it
> were claimed that they were part.

There are even certain winetricks commands which don't install anything at
all, they simply change settings in the given wine prefix.

(Taken in context though I don't think Adam had a significantly different
positions from yours, David; the idea here as I understand it was to package
redistributable downloads referenced by winetricks in a Debian package, which
would go into non-free to avoid having to figure out how to rebuild
everything using tools in main, but to which a "nonfree" qualifier wouldn't
be applicable.)

> On Tuesday 07 September 2010, Adam Borowski wrote:
> > In the past, there was opposition to shipping random free software for
> > Windows inside Debian, for good reasons.  And since most of the rest in
> > undistributable, packaging winetrick as a big installer (in main!) is
> > probably the best idea.

I agree, I don't think it would be appropriate to try to package the
DFSG-free Windows software installable via winetricks (such as 7-zip); in any
case, packaging winetricks needn't involve shipping random free software for
Windows inside Debian.

There are other considerations which haven't been brought up in this thread
so far.

One big objection I can see is that many of winetricks's uses involve
downloading third-party software from web sites and installing it
automatically on the user's system; admittedly the user is requesting it, but
there's a good chance many users will simply be using winetricks because they
are following instructions from a forum post somewhere, so even that doesn't
necessarily mean much. (A similar argument applies to simply letting wine
download wine-gecko rather than packaging it properly in Debian.) That might
be fixable but it's a huge endeavour and it wouldn't earn us any bonus points
with upstream (I'm thinking along the lines of packaging redistributable
components properly, and stripping winetricks of references to
non-redistributable downloads - which would mean our winetricks wouldn't be
the same as upstream's, and following common instructions involving
winetricks wouldn't work in Debian).

Another objection is that providing winetricks increases the support burden;
this could be turned into an advantage (compared to users simply downloading
winetricks themselves) by adding code to (or around) winetricks so that any
changes made to wine prefixes using winetricks can be traced in bug reports.
(In a similar fashion to kernel tainting...)

winetricks also generally only works well with recent versions of wine, so
it's only really sensible to package it once we manage to keep up with wine!

(These last two are simply the first two warnings given on
http://wiki.winehq.org/winetricks .)

All this is rather negative, but I'm not sure myself whether
packaging winetricks would be a good idea or not! I do think that if it does
get packaged, it should be in its own package (since its releases aren't
synchronised with wine, as has been pointed out previously). Alternatively,
one way of "packaging" it could be to add a winetricks installer (and
updater) to the wine package...

Regards,

Stephen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100907231101.7f988...@sk2.org

Bug#602996: ITP: binutils-mingw-w64 -- Cross-binutils for Win32 and Win64 using MinGW-w64

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 


* Package name: binutils-mingw-w64
  Version : 2.20.1
  Upstream Author : Free Software Foundation, Inc.
* URL : http://www.gnu.org/software/binutils/
* License : GPL 3, GFDL
  Programming Lang: C
  Description : Cross-binutils for Win32 and Win64 using MinGW-w64

MinGW-w64 provides a development and runtime environment for 32- and
64-bit Windows applications using the GNU Compiler Collection (gcc).
.
This package contains the toolchain binutils.



I'm thinking of packaging this in relation to
http://bugs.debian.org/594371, my ITA for mingw-w64, because MinGW-w64
has an official set of triplets now so the existing mingw32-binutils
won't work. Since MinGW32 (now simply MinGW) is not MinGW-w64, it
seems preferable to have a different set of packages. MinGW-w64 itself
is useful in Debian notably because it will allow packaging newer
versions of Wine.

The package uses the existing binutils-source package; the packaging
work is available at
http://git.debian.org/?p=collab-maint/binutils-mingw-w64.git



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101110072523.21463.71212.report...@heffalump.sk2.org

Bug#602997: ITP: gcc-mingw-w64 -- The GNU Compiler Collection for MinGW-w64

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 


* Package name: gcc-mingw-w64
  Version : 4.5.1
  Upstream Author : Free Software Foundation, Inc.
* URL : http://www.gnu.org/software/gcc/
* License : GPL 3, GFDL
  Programming Lang: C
  Description : The GNU Compiler Collection for MinGW-w64

MinGW-w64 provides a development and runtime environment for 32- and
64-bit Windows applications using the GNU Compiler Collection (gcc).
.
This package contains the GNU Compiler Collection, supporting
cross-compiling to 32- and 64-bit MinGW-w64 targets.




I'm thinking of packaging this in relation to
http://bugs.debian.org/594371, my ITA for mingw-w64, because MinGW-w64
has an official set of triplets now so the existing gcc-mingw32
won't work. Since MinGW32 (now simply MinGW) is not MinGW-w64, it
seems preferable to have a different set of packages. MinGW-w64 itself
is useful in Debian notably because it will allow packaging newer
versions of Wine. See also http://bugs.debian.org/602996, my ITP for
binutils-mingw-w64.

The package uses the existing gcc-4.5-source package (but see also
http://bugs.debian.org/600502); the packaging work is available at
http://git.debian.org/?p=collab-maint/gcc-mingw-w64.git



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101110073226.24061.73637.report...@heffalump.sk2.org

Re: Multiarch capabilities for mingw crossbuilds too?

[Stephen Kitt]

On Fri, 8 Aug 2014 16:41:22 +0100, Wookey  wrote:
> +++ Joerg Desch [2014-08-08 05:38 +]:
> > Today I've read about Debians Multiarch capabilities for the first time. 
> > Is it possible to use this technique to build deb packages of libraries 
> > for the mingw crosscompile toolchain too?
> 
> In principle, yes. In practice right now, no. Stephen Kitt has looked
> into this and gave a comprehensive talk at this year's mini-debconf
> (But I can't find a URL as I'm not sure that Sylvestre has actually
> uploaded them anywhere). I think this pdf is the slides though:
> http://www.sk2.org/talks/crossporting-to-windows.pdf

That's it; the video isn't available (yet?).

> It has the potential to be exceedingly slick and remove a whole load
> of packaging cruft we currently have to make windows/mingw-ready versions of
> libraries.
> 
> There is some discussion on this therad:
> https://lists.debian.org/debian-devel/2011/04/msg01243.html
> 
> > I have to build Windows executables and therefore need some libraries. 
> > For now, I build and install them locally. It would be fine to have a
> > way just to apt-get install them.
> > 
> > Any chance?
> 
> Yes, but it needs some work. I'm sure Stephen would love some help :-) 
> I don't know if he's made any progress since feb.

I've been mostly working on the change requested by Guillem in 
https://bugs.debian.org/606825 so that we can get "Windows" added as an
architecture in dpkg, which is the first step towards a multi-arched
MinGW-w64 toolchain. I need to write stuff up to follow up on the bug, the
short version is that it's very complicated and I now understand very well
why upstream went for a imperfect triplet.

As Wookey says, I'd love some help, once there are things to help with. Keep
an eye on #606825, and once the architecture exists in dpkg we'll be able to
start fixing up packages (debian-ports style) and anyone interested will be
able to chip in!

> The trickiest part is that, having demonstrated that this works, we
> would have to change the definition of 'architecture independent' a
> little to include 'posix/non-posix' which mostly means moving a lot of
> libc stuff from arch-independent locations to arch-dependent
> locations, and that might be a hard sell in Debian. It _should_ only
> affect libc packaging, but work needs to be done to demonstrate
> that. Everything else is straightforward, and indeed a simplification of
> the current state for any package that produces win32/64 libs.

That's a very accurate summary, thanks! And the next big hurdle after getting
dpkg updated...

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#759762: ITP: libz-mingw-w64 -- compression library (targeting Windows)

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: libz-mingw-w64
  Version : 1.2.8
  Upstream Author : Jean-loup Gailly and Mark Adler
* URL : http://www.gzip.org/zlib/
* License : zlib
  Programming Lang: C
  Description : compression library (targeting Windows)

zlib is a library implementing the deflate compression method found in
gzip and PKZIP. This package provides headers and libraries required
to build Windows software using zlib.



I'm packaging this to allow Python to build its Windows executables,
and also to test Colin Watson's idea of using apt-get during builds in
lieu of full-blown source build-dependencies.

Once (if?) we get proper partial architecture support for Windows this
package will be removed.

Regards,

Stephen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140830015524.20750.12147.report...@heffalump.sk2.org

Bug#761130: ITP: lgogdownloader -- downloader for GOG.com files

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: lgogdownloader
  Version : 2.17
  Upstream Author : Sude-
* URL : https://sites.google.com/site/gogdownloader/
* License : WTFPL-2
  Programming Lang: C++
  Description : downloader for GOG.com files

 lgogdownloader is a client for the GOG.com download API, allowing
 simple downloads and updates of games and other files from GOG.com.
 .
 This package is only useful if you own games on GOG.com. There are a
 few free-as-in-beer games available for Linux, but the DFSG-free
 games are not provided for Linux on GOG.com and are available in
 Debian anyway (lure-of-the-temptress, beneath-a-steel-sky,
 flight-of-the-amazon-queen).

I will maintain this as part of the Debian Games Team.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140910215605.22182.20848.report...@heffalump.sk2.org

Re: [pkg-wine-party] Bug#585409: this bug .. bugs me

[Stephen Kitt]

Hi Mike,

On Tue, Jun 05, 2012 at 01:41:42PM -0400, Michael Gilbert wrote:
> On Tue, Jun 5, 2012 at 1:17 PM, Christian PERRIER wrote:
> > You mean, besides completely hijacking the package?
> >
> > The last maintainer upload is dated 2010/05/23.
> >
> > So, from my POV, you (Michael) and Hilko Bengen seem to be the real
> > package maintainers for wine.
> >
> > My suggestion: do a maintainer upload of 1.4 in unstable, unless it
> > would affect some transition. And do it now.
> 
> I prefer cordiality.  I would rather give Ove a fairly significant
> amount of time before pursuing any such change. And even then, I plan
> to defer the matter to the tech committee because I believe initiating
> a takeover on my own is a conflict of interest, and again I am one for
> cordiality.

I don't know whether you'd noticed - you and I have been added to the
Wine packaging team on Alioth, so technically our uploads now are no
longer NMUs but team uploads!

Regards,

Stephen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120605181751.gc14...@sk2.org

Re: Migration path for 'Multi-Arch:allowed' packages

[Stephen Kitt]

Hi Mike,

On Mon, 11 Jun 2012 15:40:59 -0400, Michael Gilbert 
wrote:
> We've been getting a few bug reports from users attempting to install
> multiarch wine who have yet to manually enable multiarch itself.
> Obviously that is a failure on their part, and is easily correctable.
> However, I wonder if we can't make such migrations a bit more
> straightforward?

I fail to see how it is a failure on the part of the users. How are they
supposed to know that wine is now a multiarch-only package on *-amd64? One
might expect unstable-tracking users to find out for themselves, but what
will happen when users upgrade from Squeeze? We could ask for a specific
mention in the release notes, but we'll still end up with bug reports from
users who haven't read them...

> In particular, I filed a bug against dpkg requesting that it produce
> more informative error messages in these cases [0], but I wonder if a
> part of the solution shouldn't be more automated or at least presented
> at a higher level through apt/aptitude, etc?

Having dpkg produce more informative error messages won't help users
upgrading with apt-get or aptitude. I just rebuilt a Squeeze amd64 system to
try the upgrade, and the only solutions offered are either to hold the wine
package, or remove it - so dpkg never gets a chance to attempt to process the
upgrade.

> Also, limitations in the existing testing migration tools are making
> wine not considered for wheezy, since those tools don't check whether
> dependencies for 'Multi-Arch: allowed' packages are satisfied by
> packages on other architectures.

Short of packaging Wine64, might it be possible to have wine-bin on amd64 and
kfreebsd-amd64 be a dummy package containing only a wine script which
provides appropriate instructions, registered as a very-low-priority
alternative using the existing infrastructure?

Regards,

Stephen


signature.asc
Description: PGP signature

Re: cross-build-essential

[Stephen Kitt]

On Thu, 28 Jun 2012 12:47:48 +0100, Wookey  wrote:
> +++ Svante Signell [2012-06-28 11:43 +0200]:
> > The situation is even more complicated if compiling for different OSes:
> > Like as host (build) Linux:i386 and guest (target) kFreeBSD:amd64 or
> > Hurd:i386. Any plans to support such combinations with
> > cross-build-essential?
> 
> Multiarch should support this and dpkg-architecture already does. So
> if someone wants to maintain toolchains to do this then adding an
> entry to cross-build-essential is easy. (We didn't put everything
> possible supported by dpkg in, because that would be 271 packages :-)
> Does it actually need a conventional cross-toolchain or is it like the
> amd64/i386 case where a chroot and a personality is all that is needed?
> 
> I admit that I haven't thought about the issues for this particular
> case in any detail. Is there actually a demand for being able to do
> this? 

Perhaps for MinGW-w64...

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Minified javascript files

[Stephen Kitt]

On Fri, 17 Aug 2012 23:48:32 +0100, Ben Hutchings  wrote:
> On Fri, Aug 17, 2012 at 07:50:39PM +, Sam Morris wrote:
> > tcltrf (source)
> >  * win/msvcrt.dll
> > 
> > This is part of Windows. I don't expect Debian has been granted 
> > permission to distribute it. :)
>  
> It's the run-time library for Microsoft Visual C++ and is, as I
> recall, distributable along with applications that are built using
> that compiler.  In fact, it is *recommended* to distribute it with
> applications.  However, various applications bundled with Windows also
> need it, so in practice you can get away without doing this if you're
> sure your application doesn't depend on any newer features.

Since Windows 2000 and Visual C++ 7, msvcrt.dll is part of Windows and isn't
redistributable; the redistributable runtimes carry a version number in their
name (msvcr71.dll etc.) and are supposed to be redistributed within their own
installer (vcredist.exe and co.). The DLL included in the tcltrf source is
older though (version 5 corresponds to Visual Studio 97) and dates back to a
time when it was supposed to be redistributed (albeit restrictively, see
below)...

See http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.110%29.aspx for
detais on current versions of Visual C++.
http://kegel.com/wine/isv/visual-studio-6-EULA.html is a copy of the Visual
Studio 6 which would be similar to that covering the DLL in tcltrf. Section 4
covers the distribution requirements; in particular, we're supposed to limit
others' distribution rights so the DLL can't be redistributed outwith the
accompanying software requiring it. I doubt it could be considered DFSG-free
by any interpretation; what's more tcltrf's source is already repacked so
removing the DLL shouldn't be too onerous.

I've filed a bug; it might affect oldstable too, I'll check later.

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#685545: ITP: pthreads-win32 -- POSIX threads library for Windows

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: pthreads-win32
  Version : 2.9.1+dfsg
  Upstream Author : Ross Johnson 
* URL : http://sources.redhat.com/pthreads-win32/
* License : LGPL-2.1
  Programming Lang: C
  Description : POSIX threads library for Windows

 pthreads-win32 provides an implementation of POSIX 1003.1-2001
 threads for 32- and 64-bit Windows.
 .
 This package contains both development and runtime files required to
 develop with and use pthreads using MinGW-w64.


This is required to support libgomp with MinGW-w64 (as well as being
generally useful for software using pthreads).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120821200432.8671.81932.report...@heffalump.sk2.org

Re: Minified javascript files

[Stephen Kitt]

On Sat, 25 Aug 2012 12:27:02 +0200, Jonas Smedegaard  wrote:
> 2) Each source and binary package (+ core parts) is considered a legal 
> entity of its own.  That's why we can refer to licensing texts existing 
> in common-licenses, but for e.g. Apache license cannot refer to the text 
> shipped with Apache but must repeat that text in each package.  So 
> (build-)depending on other packages is not enough - the required source 
> must exist either in same package or in a core package.

Not quite - there's "Built-Using" now as well, so a package can be built
using source from another package, and as long as the appropriate
"Built-Using" relationship is declared in the resulting binary packages all
the required source packages will be preserved in the archives.

(I know this doesn't help in the minified JavaScript case.)

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Minified javascript files

[Stephen Kitt]

Hi Thomas,

On Sun, 26 Aug 2012 23:43:32 +0800, Thomas Goirand  wrote:
> On 08/26/2012 03:37 PM, Charles Plessy wrote:
> > the Built-Using will documented in the next release of the Policy, thanks
> > to the input of the FTP team.
> >
> > http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=commitdiff;h=4953fb7792b9fbe04c27dc817a2eb3cd9ab450b8
> >
> > http://bugs.debian.org/641153
> >
> > Have a nice Sunday,
> >   
> Interesting!
> 
> If a package has Built-Using, where/how will the build
> dependency be downloaded? In /usr/src/package-name-?

Built-Using doesn't determine behaviour before or during the build, it just
records the fact that a binary package was built using some other (binary)
package - the aim is to ensure that all the source code required to build a
package is available in the archives. (So the Built-Using declaration
actually uses the source package and version, not the binary package and
version.)

Take for example my gcc-mingw-w64 package: it build-depends on gcc-4.6-source
which provides the gcc source and Debian patches; the build then uses those
files to build gcc, and records the specific source version used in the
Built-Using field in its binary packages. The declaration doesn't help me
build the packages, it's just a record so that the archive tools can ensure
we honour our license obligations and provide the exact source used to build
the binaries we ship.

I do something similar in my mednafen package: the mednafen source includes
mini-lzo's source, which is also available in liblzo2-dev; to make security
maintenance easier, the build copies mini-lzo from liblzo2-dev, so the
resulting packages declare a Built-Using relationship on lzo2 (the source
package).

It doesn't help packages build using arbitrary source packages; it's only
really useful for builds using -source packages (binutils-source,
gcc-...-source, and so on), or builds using statically-linked libraries.
Being able to build-depend on source packages would be nice but that's
another discussion ;-). (Here's another Built-Using idea: automatic binNMUs
when external source is updated...)

Regards,

Stephen


signature.asc
Description: PGP signature

Re: assumptions about the build environment.

[Stephen Kitt]

On Sat, 22 Sep 2012 19:06:57 +0200, Adam Borowski  wrote:
> And an interesting tidbit:
>checking for suffix of executables... .exe
>checking whether we are cross-compiling... no
> 
> So the concept of "cross-compiling" is pretty fuzzy :)

That typically happens if you have wine and binfmt-support installed, since
the "cross-compiling" test is "can the system run an executable built using
the chosen compiler"!

Regards,

Stephen


signature.asc
Description: PGP signature

Re: jessie release goals

[Stephen Kitt]

On Sat, 11 May 2013 11:39:28 +0200, Goswin von Brederlow 
wrote:
> On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote:
> > The big issue which crops up then isn't so much the directory structure's
> > impact on the build process, but rather its impact on the packaging
> > process. If the target directory structure depends on whether we're
> > building for a full Debian architecture or for a partial architecture or
> > just some cross-compiler target, that means ad-hoc changes in the
> > packaging for the various cases and that much more friction (see for
> > example http://bugs.debian.org/671437 - although in zlib's case packaging
> > changes are necessary to build for Windows).
> 
> But it wouldn't. The target directory structure would be the same
> across all builds. It would always be
> /usr/include/[$(DEB_HOST_MULTIARCH)] and
> /usr/lib/[$(DEB_HOST_MULTIARCH)].
> 
> The effect of partial architecture is simply that not everything needs
> to be build for that architecture and the partial architecture might
> not be self hosting. E.g. we can cross build for mingw but we wouldn't
> be including windows in Debian nor run a buildd on windows.

Yes, but that's not the problem. Take the premise that the target directory
structure is as described above, so most library development packages ship as
many headers as possible in /usr/include. For now we'll assume all
mingw-w64-...-dev headers are in /usr/include/...-w64-mingw32; but to use
mingw-targeted libraries other than mingw-w64-...-dev (libgtk for example),
the mingw toolchain needs to look in /usr/include as well.

This is all fine as long as libc6-dev is not installed (say perhaps with
sbuild and cross-build-essential). But in a typical work environment,
libc6-dev will be installed, and because we'll always be cross-compiling on
the buildds, packages which need to build stuff for the host to run during
the build (wine-gecko does this) need build-essential too, so libc6-dev
headers end up in /usr/include and are picked up by the mingw toolchain.
Likewise for other -dev packages which may be available for the host
architecture but not the target architecture. Imagine the confusion then for
configure scripts!

As far as I can see there are three solutions to this:
* split headers completely
* drop the idea of building mingw packages using the existing Debian
  packaging
* add patches to all supported packages so that they build differently when
  targeting mingw (and any other partial architecture which can't
  share /usr/include)

Fedora went with the second solution; they have mingw-specific packages for
everything they build targeting Windows. If we could build-depend on source
packages (which has been mentioned elsewhere in this thread) this would be
possible on Debian too, although it would be a bit of a chore for me (and
whoever else wants to chip in). But I wouldn't want supporting a non-free
operating system to become a chore for more Debian developers than necessary!

(The aim of all the mingw work as far as Debian is concerned, apart from
providing a nice mingw build environment, is to provide a wine-mono package,
which needs a whole bunch of dependencies. wine-gecko is relatively easy to
support because it's essentially Firefox, which ships all its build
dependencies in its source archives.)

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Bug#666490: O: svgalib -- console SVGA display libraries

[Stephen Kitt]

Hi,

On Sun, Apr 01, 2012 at 02:59:24AM +0100, Ben Hutchings wrote:
> Thanks for your work, but isn't it time we quietly got rid of this
> library?  Video memory and mode setting should be managed by the kernel,
> not by applications.  It's bad enough that we had the X server doing
> this for years (and still do on some hardware).

I've looked into this; svgalib's reverse dependencies are:
* bochs (bochs-svga)
* gnuboy (gnuboy-svga)
* lcdproc (no svgalib-specific package)
* links2 (no svgalib-specific package)
* mplayer (no svgalib-specific package)
* qcam (no svgalib-specific package)
* spectemu (spectemu-svga)
* synaesthesia (no svgalib-specific package)
* thrust (no svgalib-specific package)
* tmview (dvisvga)
* zgv (no svgalib-specific package)

Apart from mplayer and zgv, all of these rebuild fine without
libsvga1-dev; they can use X and some can use fb (I can provide
patches of course and NMU where necessary). mplayer FTBFS anyway
because of changes in liblivemedia (#708140). zgv only builds a
svgalib-based binary; it can in theory be built with SDL instead but
that fails. All the svgalib-specific packages have low popcon scores.

Regards,

Stephen


signature.asc
Description: Digital signature

Re: Depends: libfoo:foreign ???

[Stephen Kitt]

On Mon, 13 May 2013 11:43:05 -0400, The Wanderer  wrote:
> On 05/13/2013 11:00 AM, Wookey wrote:
> > OK. And is 32-bit wine (to be installed on amd64) an amd64 binary
> > that understands i386 code or is it actually i386 code? If the latter
> > to what degree are wine32:amd64 and wine32:i386 any different?
> 
> To the best of my ability to determine, it is the latter.
> 
> On a per-file level, I don't actually know that they are different, and
> what investigation I've done seems to indicate that they may not be. On
> a package-wide level, some components which get built and installed
> during a standalone 32-bit build don't get built for a combined build,
> because they are covered by components provided by the 64-bit build.
> (The same also appears to be true in reverse.)
> 
> > Do we actually (ideally perhaps) just have 2 things:
> > wine64:amd64  (amd64, amd64, win64)
> > wine32:i386   (amd64, i386, win32)
> > 
> > or three things:
> > wine64:amd64  (amd64, amd64, win64)
> > wine32:amd64  (amd64, amd64, win32)
> > wine32:i386   (amd64, i386, win32, if cross-built) (i386, i386, win32, if
> > native-built)
> > 
> > where:  (Build, Host, Target) means: Build is the arch built on, Host
> > is the arch it runs/is installed on, and target is the code/abi
> > '(not)-emulated'
> 
> The "three things" case seems almost accurate, except for one thing:
> wine32:amd64 would be targeted to install on an amd64 host, but would be
> i386 code. That may be what you intended, but I don't see it implied by
> the above statement.

The upstream approach would be "three things", using multilib rather than
multiarch for the wine32:amd64 packages and native building for the i386
packages. It may be possible to support the "two things" approach using
multiarch, but it would make life a bit harder for maintainers and would
introduce yet another change from upstream (but if multilib disappears in
favour of multiarch we'd need to do it anyway). Mike Gilbert is working on
all this just now, he'd be the one to ask!

Regards,

Stephen


signature.asc
Description: PGP signature

Re: jessie release goals

[Stephen Kitt]

On Tue, 14 May 2013 17:37:59 +0100, Wookey  wrote:
> +++ Stephen Kitt [2013-05-13 19:26 +0200]:
> > Yes, but that's not the problem. Take the premise that the target
> > directory structure is as described above, so most library development
> > packages ship as many headers as possible in /usr/include. For now we'll
> > assume all mingw-w64-...-dev headers are in /usr/include/...-w64-mingw32;
> > but to use mingw-targeted libraries other than mingw-w64-...-dev (libgtk
> > for example), the mingw toolchain needs to look in /usr/include as well.
> > 
> > This is all fine as long as libc6-dev is not installed (say perhaps with
> > sbuild and cross-build-essential). But in a typical work environment,
> > libc6-dev will be installed, and because we'll always be cross-compiling
> > on the buildds, packages which need to build stuff for the host to run
> > during the build (wine-gecko does this) need build-essential too, so
> > libc6-dev headers end up in /usr/include and are picked up by the mingw
> > toolchain.
> 
> Thank you for explaining this. I now understand your issue. It is
> helpful to have an example of why a full-split might have advantages
> over an 'only arch-dependent' split. Or at least that we need to be
> careful about what the definition of 'arch-dependent' is, if we want
> to include windows ABIs, or uclibc ABIs (I think those two cases may
> well amount to the same problem). Can anyone from BSD camp tell us
> whether having glibc-dev headers installed in a common dir would break
> cross-building for them too?
> 
> Simon has expanded on this helpfully already: 'glibc is somewhat
> special as part of the ABI' (remembering that multiarch maps to ABIs).

Right, and thank you Simon for explaining things more clearly than I could!

> It's good to know about this before the design is set in stone, so
> this conversation is timely. What I'm not sure about is whether the
> multiarch-cross design is seriously broken or if it's just a matter of
> packaging libc-dev correctly to allow for non-glibc platforms. 
> 
> Multiarch has thus far largely been thought of in terms of platforms
> you can also install Debian to as well as build for. But
> multiarch-cross ought to be a good fit for crossing to other platforms
> (within reason) too. So we should certainly consider whether we can
> sensibly accomodate that or not.
> 
> I'm not quite sure how best to decide that. Some people need to try
> some stuff and report back, I suspect.

Quite likely! I should probably just rebuild the mingw toolchain using
multiarch paths and see what breaks ;-).

> Would simply moving all the libc headers to /usr/include/$multiarch
> fix mingw builds? How many other libraries are similarly affected?

I think as far as libc is concerned, moving the headers away should be
enough.

Off the top of my head the only packages I can see causing trouble is
linux-libc-dev, and kernel-specific packages like it (so basically anything
which is linux-any rather than any, or kfreebsd-specific or hurd-specific,
with files in /usr/include). In a perfect world nothing else should: if a
header file is in /usr/include (or a well-known subdirectory), the
corresponding library should be available on all Debian architectures and
partial architectures. Certainly from the point of view of Debian packages
that should be enough: it's the usual problem of packaging
reverse-dependencies, albeit slightly extended (since a build-dependency for
a host-based portion of a cross-build may confuse the target-specific
portions of the build). For end-users it's not quite so simple, and if we
want Debian to be a nice platform for cross-building we may need to be
stricter (and I realise that's a big if anyway, and cross-builders should
know what they're doing well enough to cope with the deficiencies here). The
easy solution to deal with partial architectures' limitations is to move
everything out of /usr/include, the hard solution is to make sure as many
libraries as possible are available for the partial architectures...

It all boils down to what the baseline is for all Debian architectures, and
hence what is common across all architectures.

As Simon points out stuff which uses pkg-config should be safe enough.
Likewise configure scripts which check the library as well as the header
files.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Source build-dependencies

[Stephen Kitt]

On Thu, 16 May 2013 16:58:13 +0200, Guillem Jover  wrote:
> On Tue, 2013-05-14 at 08:50:39 +0800, Paul Wise wrote:
> > On Mon, May 13, 2013 at 11:17 PM, Stéphane Glondu wrote:
> > > Le 13/05/2013 15:51, Paul Wise a écrit :
> > >> [...] as long
> > >> as there is a way to build-depend on the build-dependencies for a
> > >> source package, that should be fine. As a bonus we can get rid of
> > >> mk-build-deps :)
> > >
> > > How so?
> > 
> > In my case, I already have metapackages for each system, so I can just
> > add foo:build-deps to the Depends for those, instead of building fake
> > packages with mk-build-deps.
> 
> One of the problems with mk-build-deps is that the created packages
> need manual rebuilds whenever the Build-Depends change.
> 
> It's not clear to me from what has been written in this sub-thread, if
> we are talking about magic srcpkg:build-deps substvars to be expanded
> at build time, or if those are supposed to be valid package specifiers
> that are expanded at run-time (ending up in Depends lines unexpanded,
> for example), or something else.

As I understand it (and what I'd like) is just the possibility of specifying
source packages rather than binary packages as build-dependencies. So for
instance in my gcc-mingw-w64 package's control file, instead of specifying

Build-Depends: ..., gcc-4.6-source, ...

I'd specify

Build-Depends: ..., gcc-4.6:source, ...

Because gcc-4.6-source pulls in dependencies that the gcc-mingw-w64 package
also needs, I'd also need to add those; it would be easier then to specify

Build-Depends: ..., gcc-4.6:source, gcc-4.6:build-deps, ...

instead, since gcc-4.6-source's dependencies are a subset of gcc-4.6's
build-dependencies, and I'd rather not have to always change my package when
the latter change.

The only substvar-type treatment which would be useful then would be
something to fill in Built-Using automatically.

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#722631: ITP: libevdev -- wrapper library for evdev devices

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: libevdev
  Version : 0.3
  Upstream Author : Peter Hutterer 
* URL : http://www.freedesktop.org/wiki/Software/libevdev/
* License : MIT/X
  Programming Lang: C
  Description : wrapper library for evdev devices

libevdev is a wrapper library for evdev devices. It provides functions
covering the common tasks when dealing with evdev devices, thus
avoiding erroneous ioctls and other errors.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130912230557.21456.22114.report...@heffalump.sk2.org

Re: dpkg-buildpackage creating uninstallable packages?

[Stephen Kitt]

On Sun, 29 Sep 2013 08:58:36 +0200, Sven Joachim  wrote:
> On 2013-09-28 22:18 +0200, Norbert Preining wrote:
> > since a short time when I build a binary package on my running system,
> > I cannot install the created .deb anymore because it depends on
> > libc-amd64 (>= some.version) which somehow is not what I have although
> > I am running amd64 sid.
> 
> Uninstall the libc6-amd64:i386 package.
> See http://lists.debian.org/debian-mentors/2013/03/msg00139.html.

But watch out for http://bugs.debian.org/699206 - make sure you have a root
sash running somewhere so you can relink /lib64/ld-linux-x86-64.so.2...

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Bug#727194: ITP: OpenMW -- Reimplementation of The Elder Scrolls III: Morrowind game engine

[Stephen Kitt]

Hi Bret,

On Mon, 21 Oct 2013 16:41:43 +0200, Bret Curtis  wrote:
> * Package name: OpenMW
>   Version : 0.26.0
>   Upstream Author : Marc Zinnschlag 
> * URL : http://www.openmw.org/
> * License : GPLv3
>   Programming Lang: C++
>   Description : Reimplementation of The Elder Scrolls III: Morrowind
> game engine
> 
>  OpenMW is a reimplementation of the Bethesda Game Studios game 
>  The Elder Scrolls III: Morrowind.
>  .
>  The Morrowind "Data Files" from the original game are required to play.

Would you be interested in packaging this within the Games Team?

Also, it would be great if game-data-packager could be enhanced to build a
package for the data files (and we can help you with that).

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Bug#727194: ITP: OpenMW -- Reimplementation of The Elder Scrolls III: Morrowind game engine

[Stephen Kitt]

On Wed, 23 Oct 2013 19:22:12 +0200, Stephen Kitt  wrote:
> Would you be interested in packaging this within the Games Team?
> 
> Also, it would be great if game-data-packager could be enhanced to build a
> package for the data files (and we can help you with that).

Never mind, I see Jon beat me to it on your other ITP.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: The mingw* mess in Debian

[Stephen Kitt]

Hi Fabian (and all the other participants in this thread),

On Wed, 09 Nov 2011 13:33:14 +0100, Fabian Greffrath 
wrote:
> Is there a principle behind all this or where can I help to clean this 
> up? ;)

The history has been explained by others. I've been working for a while on
dropping at least gcc-mingw32; see #644769 which tracks the various packages
build-depending on gcc-mingw32 and/or mingw32. There are only three packages
left now; see #623400, #623402 and #623526. Patches are available for all the
bugs so NMUs should be straightforward if they're deemed necessary - I could
do the NMUs but I'd need a sponsor!

On Thu, 10 Nov 2011 14:13:12 +0100, Fabian Greffrath 
wrote:
> Furthermore, the gcc-mingw-w64 package, although misleadingly labeled
> w64, is able to produce object code targeted at both the 32-bit and
> 64-bit Windows platform. I'd thus suggest to split the package into
> one component for each platform to avoid confusion and place
> appropriate Replaces and Provides against the mingw32 package family.

As far as the naming is concerned, see #622276 for details. I've thought
about splitting the packages up, with separate 32- and 64-bit targets, but
I'm not sure whether replacing and providing the mingw32 packages would be
correct, since mingw-w64 isn't a drop-in replacement (the triplets are
different). If that's not a problem then why not! The names for the 32-bit
packages would probably be quite weird though since the upstream name is
mingw-w64 (and I'd rather keep that in the package names...).

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Bug#648306: The mingw* mess in Debian

[Stephen Kitt]

Hi Ron,

On Fri, 11 Nov 2011 07:36:28 +1030, Ron  wrote:
> I was hoping you'd actually been cc'd on this :)

I was a few days behind debian-devel so I found out aboud the discussion
thanks to Fabian's bug report, which you will have received too ;-).

> On Thu, Nov 10, 2011 at 08:16:01PM +0100, Stephen Kitt wrote:
> > As far as the naming is concerned, see #622276 for details. I've thought
> > about splitting the packages up, with separate 32- and 64-bit targets, but
> > I'm not sure whether replacing and providing the mingw32 packages would be
> > correct, since mingw-w64 isn't a drop-in replacement (the triplets are
> > different). If that's not a problem then why not!
> 
> Ewww, why on earth did they change the triplet for the 32bit builds?
> It's not actually a different architecture, or even a substantially
> different toolchain.

There is one major difference I know of: i686-pc-mingw32 (the official MinGW
triplet) builds with Dwarf2 exception handling, whereas the -w64-mingw32 (the
official MinGW-w64 triplets) build with SJLJ exception handling because
Dwarf2 doesn't work on Win64 and isn't compatible with DLLs built with
anything other than gcc. (See
https://sourceforge.net/apps/trac/mingw-w64/wiki/Exception%20Handling for
details.) There may be other non-political differences I'm not aware of.

> If you've actually got this all building from the mainline sources now,
> I'd have been all for folding this into the original mingw packages and
> having some sort of sensible (if somewhat interrupted :) continuity for
> people down that track ...
> 
> but if it's gratuitously incompatible, then I don't really know what to
> do or think about that ...   modulo pity for the people getting burned.

I could be wrong about this, but I don't believe it's gratuitously
incompatible. The thing is though that end-users are now used to the
-w64-mingw32 triplets.

> > The names for the 32-bit packages would probably be quite weird though
> > since the upstream name is mingw-w64 (and I'd rather keep that in the
> > package names...).
> 
> I'm not sure I really follow this, what am I missing here?  What exactly
> are you taking from 'upstream' in this case?  My understanding was that
> the toolchain was mainline gcc/binutils now, and all that the w64 folk
> were providing was the runtime library?  Is that wrong?

That's correct, so the only really upstream package is mingw-w64 which
provides the headers and libraries required to target Windows (it's not even
a runtime library since there is no non-gcc runtime library). The MinGW-w64
developers do submit patches against binutils and gcc now and again, so in a
sense they're still providing the toolchain, they're just upstreaming
everything instead of shipping patches.

> mingw.org has been basically dead for quite some time now, the 'developer'
> list has been closed to the public and the only apparent work going on
> was for native windows installers.  They were even claiming that building
> it for platforms other than windows was officially completely unsupported.
> All the old-blood developers appear to have moved on to other things,
> presumably because the 'hard parts' have all been mainlined now.
> 
> So sourcing the runtime from somewhere else now seems like a useful
> proposition.  But changing more than was really needed to do that does
> make describing this as a "mess" look like a generous understatement ...
> 
> Is it really that bad, and if so is it really too late to back away
> slowly and make this less disruptive to established users?  It would
> be nice to actually have an orderly 'upgrade' path through this rather
> than an "everything is different now" paradigm shift.  It is just a
> toolchain after all.  For a rather old and settled architecture.

I thought it better to follow the MinGW-w64 project's recommendations,
including using their triplets. Because people still encounter bugs fairly
regularly (see the bug trackers at
https://sourceforge.net/tracker/?group_id=202880 and the mailing list
archives), I believe we're better off if we can easily get support from
upstream, and they're more inclined to help us out if we follow their
guidelines.

I'll try a build with the old triplets to see how that goes, and to figure
out what kind of upgrade path we can provide...

Regards,

Stephen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2013011743.38344...@sk2.org

Re: Bug#648306: The mingw* mess in Debian

[Stephen Kitt]

On Mon, 14 Nov 2011 03:03:16 +1030, Ron  wrote:
> On Sun, Nov 13, 2011 at 01:17:43AM +0100, Stephen Kitt wrote:
> > There is one major difference I know of: i686-pc-mingw32 (the official
> > MinGW triplet) builds with Dwarf2 exception handling, whereas the
> > -w64-mingw32 (the official MinGW-w64 triplets) build with SJLJ exception
> > handling because Dwarf2 doesn't work on Win64 and isn't compatible with
> > DLLs built with anything other than gcc. (See
> > https://sourceforge.net/apps/trac/mingw-w64/wiki/Exception%20Handling for
> > details.)
> 
> Actually, that's not quite true.  At least for the case we care about here
> anyway ...  The dwarf2 handling never really was quite finished, and never
> really did work quite right.  That might have changed now, but the mingw32
> toolchain we are migrating from here is also an SJLJ build ...

OK, thanks for the info - I hadn't actually checked the Debian packages. I do
know that some MinGW-build packages "in the wild" use libgcc_s_dw2-1.dll
rather than libgcc_s_sjlj-1.dll as provided by gcc-mingw-w64; but that's
neither here nor there as far as the migration we're discussing is concerned!

> The 'official MinGW' triplet you quote above was also a gratuitous new
> change made 'fairly recently' by the new folks there.  From what I saw when
> they did that it was mostly an arbitrary choice made by new people who had
> no idea that we needed the msvc qualifier because there was *also* a crtdll
> build variant way back in ancient times, which existed before the msvc
> builds were actually reliable, and which was still in use when this
> toolchain was first uploaded to Debian.
> 
> They then went on to foam about distros using i586-mingw32msvc, which had
> been in use for more than 10 years before those people ever came along ...
> Which is about the point that I stopped hoping for sane new releases from
> those people :(

I knew the history of the mingw32msvc name, but not that the change was
gratuitous... Looking around the Internet it seems i586-mingw32msvc is still
in use (if only because of "old" instructions using Debian's own mingw32
packages), and the new mingw-w64 triplets are referenced as well, but there's
not much sign of the new mingw triplets.

[snip]
> > I thought it better to follow the MinGW-w64 project's recommendations,
> > including using their triplets. Because people still encounter bugs fairly
> > regularly (see the bug trackers at
> > https://sourceforge.net/tracker/?group_id=202880 and the mailing list
> > archives), I believe we're better off if we can easily get support from
> > upstream, and they're more inclined to help us out if we follow their
> > guidelines.
> 
> Does this actually successfully build everything that the old mingw
> toolchain did now?  There were some reports of miscompiles with the -w64
> packages that Robert first made, but I don't offhand recall which projects
> that was with. That was one of the main reasons we didn't immediately kill
> the old toolchain.

There's still one issue I know of; see #635439. None of the packages in
Debian caused much trouble migrating to mingw-w64; if I remember correctly
the main issues were related to switching to gcc 4.6 rather than mingw-w64
itself. In software not packaged for Debian I've come across problems where
the software being built defined stuff from Windows which wasn't directly
supported in mingw32 but is now in mingw-w64; that's usually easily worked
around.

> > I'll try a build with the old triplets to see how that goes, and to figure
> > out what kind of upgrade path we can provide...
> 
> Cool.  Despite my grumbling about how people who paid no attention to the
> history are busy reinventing pain that we were supposed to be long past,
> I am actually really grateful for all the work you've put in to sorting
> this out.  :)

You're welcome!

> If things are going to break, it would be really nice to get *everyone*
> with a stake in this to break it the same way and then promise not to
> break it again.  It's one thing for random libraries to fork with no
> attachment to the established users and fiddle with things incompatibly
> just to 'make their mark' on it.  But that's not really something we
> should be doing with toolchains for old architectures.

I tried a build using i586-mingw32msvc, and it worked; things also work if I
just add i586-mingw32msvc- links to the i686-w64-mingw- binaries.

Do you think it would be OK to keep the mingw-w64 packages as is (to make
upstream support easier - they're the only "alive" upstream), and have
mingw32 replacement packages with symlinks as above?

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Increasing minimum 'i386' processor

[Stephen Kitt]

On Sun, 20 Nov 2011 23:31:43 +, Ben Hutchings  wrote:
> On Sun, 2011-11-20 at 13:58 -0800, Steve Langasek wrote:
> > On Sun, Nov 20, 2011 at 08:48:08PM +, Ben Hutchings wrote:
> > > Would it be worth adding a lintian check for instructions that may not
> > > be supported (bearing in mind that a fair few packages will need to
> > > override it)?
> > 
> > I've wanted this for a while, but haven't been sure how to go about it.  I
> > would even favor making this an overrideable archive reject tag, for use
> > of cmov outside of a hwcap directory.
> > 
> > Something similar on armel (armv4t vs. armv7) and powerpc (altivec) would
> > probably be worthwhile.
> 
> 1. Find all ELF executable/library files.
> 2. Either:
>a. Work out which instructions should be excluded, depending on the
>   directory.
>b. Skip files in hwcap directories and exclude all instructions 
>   missing from the minimum processor.
> 3. 'objdump -d | grep' with appropriate instruction regexp; fail if
>there's a match.

http://dev.gentoo.org/~dirtyepic/bin/analyze-x86 is very handy for this,
although it's quite CPU-intensive.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: The mingw* mess in Debian

[Stephen Kitt]

Hi Fabian,

On Fri, 11 Nov 2011 15:33:55 +0100, Fabian Greffrath 
wrote:
> > The history has been explained by others. I've been working for a while on
> > dropping at least gcc-mingw32; see #644769 which tracks the various
> > packages build-depending on gcc-mingw32 and/or mingw32. There are only
> > three packages left now; see #623400, #623402 and #623526. Patches are
> > available for all the bugs so NMUs should be straightforward if they're
> > deemed necessary - I could do the NMUs but I'd need a sponsor!
> 
> thank you very much for taking care of this. It's good to know that 
> you have already taken measures to drop the obsolete packages. How 
> about mingw32 (the one without gcc-) and friends?

I'll let Ron handle mingw32's demise when the time comes... I noticed though
that the remaining reverse build-dependencies only used mingw32, not
gcc-mingw32, so I adjusted the various blocking relationships on #644769 and
#648306. gcc-mingw32 is no longer a build-dependency of any package in Debian
so I'll probably dispose of it with the next gcc-mingw-w64 upload (which
will include a transition package).

> > mingw-w64-i386 and mingw-w64-x64 are a bit ugly but still look sensible
> 
> True, but mingw-w64-i686 and mingw-w64-x86_64 would even somehow match 
> the compilers' GNU tuples.

I was thinking more along the lines of mingw-w64-win32 and mingw-w64-win64 so
that the API names appear in the package names. For people who know about
MinGW-w64 and its tuples the -i686 and -x86_64 approach would make sense, but
they already know to look for mingw-w64; for people who are looking for
Windows build tools it might be more helpful to actually mention win32 in the
32-bit packages (lots of people don't realise mingw-w64 targets 32-bit
Windows too; it seems the package description isn't sufficient).

Regards,

Stephen


signature.asc
Description: PGP signature

Re: The mingw* mess in Debian

[Stephen Kitt]

On Thu, 24 Nov 2011 16:17:32 +0100, Fabian Greffrath 
wrote:
> > 32-bit packages (lots of people don't realise mingw-w64 targets 32-bit
> > Windows too; it seems the package description isn't sufficient).
> 
> Yes, the package descriptions might need some improvement. This is how 
> mingw-w64 introduces itself on its own project home page:
> 
> "The project's goal is to deliver runtime, headers, and libs for 
> developing 64 bit (x64), as well as 32 bit (x86), windows applications 
> using gcc-4.6 or newer versions."
> 
> 
> i think that pretty much hits it. ;)

What I meant originally was more along the lines of "the package description
isn't sufficient, the package name has to be made clearer". Currently the
mingw-w64 package's description is

"MinGW-w64 provides a development and runtime environment for 32- and 64bit
Windows applications using the GNU Compiler Collection (gcc)."

which seems to me quite similar to the description you quote - the only
missing information is the x86/x64 nomenclature. It might also make sense to
mention the "Windows API" as it is now known (see
http://msdn.microsoft.com/en-us/library/Aa383723 for details).

I'm actually undecided regarding the -win32 and -win64 suffixes: while it's
probably a good thing to have at least win32 in the 32-bit package names,
using those two suffixes is restrictive at least in theory: the API itself is
pretty much the same, and Windows supports x86, x64 (x86_64), IA-64 (Itanium)
and presumably some form of ARM processors soon... So your original -i686 and
-x86_64 might be more future-proof. The MinGW-w64 project's site has links to
"WIN32" and "WIN64" downloads, but none of the packages use those terms. The
automated builds use "mingw-w32" for the 32-bit target package, "mingw-w64"
for the 64-bit target package, and i686/x86_64 is used to indicate the host
CPU! rubenvb's personal builds use i686-w64-mingw32/x86_64-w64-mingw32 to
specify the target, and sezero's follow the automated builds' naming
convention.

So there's precedent for using mingw-w32 and mingw-w64, but that would
probably generate more confusion with the similarity to mingw32. I'd vote for
mingw-w64-i686 and mingw-w64-x86_64 in the end, based on the following:
* the upstream project's name is MinGW-w64, hence the mingw-w64 name
* the target CPUs are currently i686 and x86_64
* we don't differentiate Win32 and Win64 because there's no real difference
  in the APIs
* this allows future support for ARM and/or IA-64 without renaming existing
  packages.
In the Windows world i?86 is known as x86 and x86_64 is x64, so those names
should appear in the description.

How about the following base description:

  MinGW-w64 provides a development and runtime environment for 32- and 64-bit
  (x86 and x64) Windows applications using the Windows API and the GNU
  Compiler Collection (gcc).

  This metapackage provides the full MinGW-w64 development environment.

(The binutils, gcc and gdb packages would be updated to suit.)

As far as the packages are concerned, the mingw-w64 source package would
produce mingw-w64, mingw-w64-i686, mingw-w64-x86_64, the corresponding three
-dev variants and a single -tools package (since that varies only by host
architecture); gcc-mingw-w64 would produce all the gcc-based packages
(gcc-mingw-w64, gcc-mingw-w64-i686, gcc-mingw-w64-x86_64; I'm also splitting
the package up into gcc, g++, gnat, gfortran etc.) including the transitional
gcc-mingw32 package; likewise binutils-mingw-w64 and gdb-mingw-w64.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: The mingw* mess in Debian

[Stephen Kitt]

On Fri, 25 Nov 2011 14:03:32 +0100, Fabian Greffrath 
wrote:
> > probably generate more confusion with the similarity to mingw32. I'd vote
> > for mingw-w64-i686 and mingw-w64-x86_64 in the end, based on the
> > following:
> 
> Me too!

I'll go for that then, taking into account Simon's remark (so -x86-64).

> > How about the following base description:
> >
> >   MinGW-w64 provides a development and runtime environment for 32- and
> > 64-bit (x86 and x64) Windows applications using the Windows API and the
> > GNU Compiler Collection (gcc).
> 
> Sounds very good!

Excellent!

> > As far as the packages are concerned, the mingw-w64 source package would
> > produce mingw-w64, mingw-w64-i686, mingw-w64-x86_64, the corresponding
> > three -dev variants and a single -tools package (since that varies only
> > by host
> 
> With "the corresponding three -dev variants" you mean a meta-package 
> mingw-w64-dev, which depends on both mingw-w64-i686-dev and 
> mingw-w64-x86_64-dev?

That's exactly what I had in mind.

> > architecture); gcc-mingw-w64 would produce all the gcc-based packages
> > (gcc-mingw-w64, gcc-mingw-w64-i686, gcc-mingw-w64-x86_64; I'm also
> > splitting
> 
> Will gcc-mingw-w64 also be a meta-package which depends on both 
> gcc-mingw-w64-i686 and gcc-mingw-w64-x86_64?

Yes.

> > the package up into gcc, g++, gnat, gfortran etc.) including the
> > transitional gcc-mingw32 package; likewise binutils-mingw-w64 and
> > gdb-mingw-w64.
> 
> On which package will the transitional gcc-mingw32 package depend? On 
> gcc-mingw-w64-i686 with compatibility symlinks to the binaries to take 
> account of the changed GNU tupel?

To provide all the binaries in gcc-mingw32 it will have to depend on
{gcc,g++,gfortran}-mingw-w64-i686; its only contents will be the
compatibility symlinks you mention (and the usual /usr/share/doc contents).
It will pull in mingw-w64-i686-dev indirectly, and binutils-mingw-w64-i686
too.

As I understand it having the mingw-w64 package produce a gcc-mingw32 package
will make the gcc-mingw32 source package disappear eventually...

Regards,

Stephen


signature.asc
Description: PGP signature

Re: The mingw* mess in Debian

[Stephen Kitt]

On Mon, 28 Nov 2011 09:34:00 +0100, Fabian Greffrath 
wrote:
> > To provide all the binaries in gcc-mingw32 it will have to depend on
> > {gcc,g++,gfortran}-mingw-w64-i686; its only contents will be the
> > compatibility symlinks you mention (and the usual /usr/share/doc
> > contents). It will pull in mingw-w64-i686-dev indirectly, and
> > binutils-mingw-w64-i686 too.
> 
> This sounds like a lot of packages to get lost in. Will you still get 
> *everything* if you install the mingw-w64 meta-package?

Yes; even though few people will use the Fortran or Ada compilers, the
mingw-w64 package description states that it provides the full environment
and it will keep on doing so. Users looking for a smaller set of packages
will be able to install gcc-mingw-w64 for example, or even just
gcc-mingw-w64-i686, and that will pull in the relevant mingw-w64-dev and
binutils packages (and g++ will pull in gcc and libstdc++6 etc.).

> > As I understand it having the mingw-w64 package produce a gcc-mingw32
> > package will make the gcc-mingw32 source package disappear eventually...
> 
> A prior message to ftp-masters won't hurt, however. ;)

Indeed, I'll do that before uploading!

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Bug#648306: The mingw* mess in Debian

[Stephen Kitt]

On Tue, 29 Nov 2011 12:17:54 +, Wookey  wrote:
> I know almost nothing about mingw* use and variants, but it does strike
> me that it just another cross-compiler, and choices about package
> names and triplets should be at least influenced by what we do for all
> the other cross-toolchains, multiarch considerations and
> dpkg-architecture support.
> 
> This was discussed a long time ago on the debian-embedded list and
> this page covers using dpkg-architecture and dpkg-cross to help with
> cross-building debian-style for mingw32:
> http://wiki.njh.eu/Cross_Compiling_for_Win32 (It predates multiarch
> but the fundamentals are there).
> 
> Would it be useful for dpkg to know about w32-i386 and thus to be able
> to use all the dpkg-cross and/or multi-arch machinery to help when
> crossbuilding for win32? If so then is there anything in what you are
> doing that gets in the way of this?

The specifics regarding mingw-w64 have been discussed in the past; there's
an open bug against dpkg at http://bugs.debian.org/606825 which includes part
of the discussion. The result there was that we'd use mingw64...

I haven't taken care of all that yet; I'm waiting for the dust to settle
around multiarch before integrating cross-compiler stuff following the same
ideas (Steve Langasek mentioned a while back that the first priority was to
get multiarch working, without considering cross-compiler issues
particularly, even though there are similarities).

In any case what we've discussed so far in this thread is compatible with the
discussion in the above-mentioned bug.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: GNU/Linux COM development and Wine/Samba

[Stephen Kitt]

Hi Philip,

On Fri, 09 Dec 2011 03:18:32 +, Philip Ashmore
 wrote:
> I've got several projects in SourceForge, one of which is v3c-dcom
> 
> http://sourceforge.net/projects/v3c-dcom/
> 
> I'm quickly coming to the realisation that I would need several 
> headers/tools from Wine
> 
> http://www.winehq.org/
> 
> , the idea being to be able to develop COM components natively.
> 
> I'd rather not simply pick them out of Wine, and was hoping to start off 
> something more productive.

Do you have a list of the headers involved? The MinGW-w64 project regularly
syncs some of its headers from Wine, it may already have what you're looking
for (albeit in an awkward location if you're developing for Linux rather than
for Windows). It's available in Debian as mingw-w64; the headers are in
mingw-w64-dev.

Regards,

Stephen


signature.asc
Description: PGP signature

Package version numbers

[Stephen Kitt]

Hi,

Neither my AM (Christian Perrier) nor myself are sure about the answer to this
one, so he suggested I ask -devel for advice (and I'm throwing -mentors into
the mix too).

I've prepared an update for calibre, to fix a few issues in the package which
is currently in Wheezy (see #686547 for details). The update involves
repacking the original tarball, which was already repacked, and is an NMU.

The version of calibre in Wheezy is 0.8.51+dfsg-1; what should the update's
version be? I'm purposefully not mentioning our ideas (one of them is
obvious from the exchanges in the bug report, but is in all likelihood
incorrect).

Thanks in advance,

Stephen


signature.asc
Description: PGP signature

Re: Package version numbers

[Stephen Kitt]

On Wed, 16 Jan 2013 19:16:26 +0100, Christian PERRIER 
wrote:
> Quoting Raphael Hertzog (hert...@debian.org):
> > On Wed, 16 Jan 2013, Christian PERRIER wrote:
> > > Quoting Jakub Wilk (jw...@debian.org):
> > > > I would paint the bikeshed the following color:
> > > > 0.8.51+dfsg1-0.1
> > > 
> > > Isn't that missing the fact that this is a t-p-u upload, which is
> > > indeed the start of a "wheezy" branch?
> > > 
> > > So something we were naming "+wheezy" in the past and which we
> > > now name "+deb70u1".
> > 
> > It's not really relevant because sid has already diverged and has a higher
> > (upstream) version.
> > 
> > So 0.8.51+dfsg1-0.1 is acceptable IMO.
> 
> Indeed.
> 
> And the theoretical question of "what if sid hadn't diverged wrt
> upstream" is silly as this is a native package.
> 
> Steve, problem solved, then..:). We were bikeshedding a bit too much.

Yup, thanks! A case of “Pourquoi faire simple quand on peut faire
compliqué ?” ;-) (“Why make things simple when they can be complicated?”)

An updated package is coming up shortly...

Regards,

Stephen


signature.asc
Description: PGP signature

Re: jessie release goals

[Stephen Kitt]

Hi Wookey,

On Tue, 7 May 2013 03:04:50 +0100, Wookey  wrote:
> (just a decision to leave arch-independent headers in /usr/include and
> move arch-dependent headers to /usr/include/triplet).

Doesn't this limit us to cross-compiling only across Debian architectures? If
we go for a full /usr/include/triplet split (in the same way as for
libraries) we could support cross-compiling to anything with the same
structure - I'm thinking MinGW-w64 here of course, but I imagine it would
apply to other targets too, some of which are supported in Debian already
using the /usr/triplet/include directories.

Regards,

Stephen


signature.asc
Description: PGP signature

Re: jessie release goals

[Stephen Kitt]

Hi,

On Mon, 06 May 2013 14:49:57 +0200, Andreas Beckmann  wrote:
> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):

http://wiki.debian.org/ReleaseGoals/RemoveOldLibs could do with an update
(and its link moved in http://wiki.debian.org/ReleaseGoals as appropriate).
I'd nominate svgalib, I'm sure there are other libraries we could do without.

Now that we have osspd around, we could probably drop OSS support too!

Regards,

Stephen


signature.asc
Description: PGP signature

Re: jessie release goals

[Stephen Kitt]

On Wed, 8 May 2013 03:57:20 +0100, Wookey  wrote:
> +++ Wookey [2013-05-07 22:31 +0100]:
> 
> [right. 3rd attempt at getting this email to make sense. reposting the
> whole thing this time, hopefully with no remaining howlers]
> 
> +++ Stephen Kitt [2013-05-07 14:38 +0200]:
> > Hi Wookey,
> > 
> > On Tue, 7 May 2013 03:04:50 +0100, Wookey  wrote:
> > > (just a decision to leave arch-independent headers in /usr/include and
> > > move arch-dependent headers to /usr/include/triplet).
> > 
> > Doesn't this limit us to cross-compiling only across Debian
> > architectures? If we go for a full /usr/include/triplet split (in the
> > same way as for libraries)
> 
> Libraries are always different for different architectures. Only a
> fairly small subset of headers is, so you could say we are doing
> exactly the same thing for both libaries and headers: 
> arch-indep stuff goes in /usr/{lib,include}
> arch-dependent stuff goes in /usr/{lib,include}/triplet
> 
> But your point is taken. This is worthy of discussion to check we
> have at least vague consensus
> 
> The tradeoff is:
> 1) (Move _all_ headers to /usr/include/triplet)
>  * Much duplication of installed headers
>  * Only one system include dir, which fits current build-system 
>  expectations

 * Incorrect builds fail faster than with (2) since there's nothing
   in /usr/include

> 2) (Move only arch-dependent headers to /usr/include/triplet)
>  * No duplication of headers
>  * Two system include dirs, which may confuse/break some builds
>  * Relatively little change from status quo

 * Confused builds may seem to build correctly using the wrong headers (not
   an issue with the base Debian use-case but bear with me...)

> In both cases things which manage to explictly look only in '/usr/include'
> may fail to build, (certainly in case 1, possibly in case 2). I have 
> no idea how much of a problem this would be in practice.
> 
> '2)', above, has been reasonably well tested in Ubuntu raring, and telling
> the compiler to look in both dirs for system headers by default works
> well, but there could be issues, e.g.  if giving a path to a subdir
> of a system header(?).
> 
> I'd be interested to hear of problems building against multiarched
> -dev packages with moved headers. Are there any significant ones?

Not that I know of...

But my main point is that all this assumes a level of uniformity in the
target architectures. So if we're building packages for Debian or Ubuntu,
just for different ABIs (mostly different hardware), everything works fine.
Throw non-Debian architectures (which could be partial architectures) into the
mix and things change drastically.

Let me explain where I'm coming from... With MinGW-w64, we have a set of
compilers, headers and libraries which allow building software targeting
native Windows, without Cygwin or much in the way of wrappers at all. This is
definitely non-POSIX and not much like Debian; but I imagine similar problems
crop up when targeting a different libc. Despite the differences, and thanks
to a lot of work by upstream developers, a lot of the libraries in Debian
build fine when targeting Windows, and most of the time the only change
required is to pass the correct target triplet to the configure script. This
makes it sorely tempting to add mingw (i386, amd64 and arm as Dmitrijs
mentions) as partial architectures in Debian and use all the existing
packaging as much as possible to provide at least -dev packages and DLLs for
as many libraries as possible; this would greatly simplify the lives of
people working on building stuff for Windows (currently they basically have
to produce Makefiles which build all their dependencies - and then you end up
with things like the Firefox source packages which include all their
dependencies on all platforms).

The big issue which crops up then isn't so much the directory structure's
impact on the build process, but rather its impact on the packaging process.
If the target directory structure depends on whether we're building for a
full Debian architecture or for a partial architecture or just some
cross-compiler target, that means ad-hoc changes in the packaging for the
various cases and that much more friction (see for example
http://bugs.debian.org/671437 - although in zlib's case packaging changes are
necessary to build for Windows).

I know (2) is well-tested, and it reduces duplication drastically. Does this
outweigh being able to use multiarch and Debian's existing packaging work as
a generic means of supporting cross-compilers?

> > we could support cross-compiling to anything with the same
> > structure - I'm thinking MinGW-w64 here of course, but I imagine it would
> > apply to other targets too, some of which are

Re: jessie release goals

[Stephen Kitt]

On Thu, 9 May 2013 10:10:01 +0200, Mike Hommey  wrote:
> On Mon, May 06, 2013 at 02:49:57PM +0200, Andreas Beckmann wrote:
> > Hi,
> > 
> > now might be the right time to start a discussion about release goals
> > for jessie. Here are some points that come into my mind right now (and
> > some were already discussed very recently):
> > 
> > * multiarch compatible binNMUs
> > * discarding maintainer uploaded binary packages [!arch:all]
> > * discarding maintainer uploaded binary packages [incl. arch:all]
> > * extending binNMUs to allow rebuilding arch:all packages (so it's no
> > longer a "binary only" but a sourceful no-change rebuild - the classic
> > binNMU should stay of course)
> 
> * source build dependencies (such that e.g binutils-mingw-w64 build
>   depends on src:binutils instead of binutils-source)

Yes! That was on my list as well ;-). The Built-Using stanza could even be
filled in automatically in such cases...

Stephen


signature.asc
Description: PGP signature

Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]

[Stephen Kitt]

Hi Dimitri,

On Mon, 6 Jan 2014 15:22:09 +, Dimitri John Ledkov 
wrote:
> But GPL text does confuse me as a whole, no modifications nor derivate
> works of the GPL license text are allowed, and the original text has
> "and later" clause - is licensing without "and later" constitues
> modification of the GPL license text, which is prohibited and thus all
> GPL licensed software is, in-fact, with "and later" clause?

The GPL itself discusses this, in section 9 in GPL v2 and in section 14 in
GPL v3. The notice that mentions the version you apply to your code comes
after the "END OF TERMS AND CONDITIONS" line, so it's not actually part of
the license (although it is part of the license document, which is what the
"verbatim" clause applies to, in its entirety). When you apply the terms to
your code, as I understand it, you're allowed to choose whichever version of
the license you prefer, with or without the "or later" clause; you're not
modifying the license document itself so that's OK.

Regards,

Stephen
(IANAL and all that)


signature.asc
Description: PGP signature

Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages

[Stephen Kitt]

On Tue, 4 Feb 2014 16:20:28 +, Wookey  wrote:
> +++ Dimitri John Ledkov [2014-02-04 13:30 +]:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
> 
> Do I understand this correctly - that it prevents a package 
> cross-binutils-0.1 to generate binaries called
> binutils-arm-linux-gnueabi-2.24-3
> binutils-arm-linux-gnueabihf-2.24-3
> 
> unless cross-binutils-0.1 is package format 1.0 rather than 3.0?

No, the check only involves the source version. My toolchain packages still
build fine, e.g. the binutils-mingw-w64 3 source package builds the
binutils-mingw-w64 2.24-3+3 binary package without complaint from dpkg-dev.

But if I change the source version to 3-1:

dpkg-source: error: can't build with source format '3.0 (native)': native
package version may not have a revision

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#742556: ITP: rr -- application execution recorder, player and debugger

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: rr
  Version : 1.0.0
  Upstream Author : Mozilla Foundation
* URL : http://rr-project.org
* License : BSD and MIT/X
  Programming Lang: C, C++
  Description : application execution recorder, player and debugger

rr allows application executions to be recorded and then replayed with
gdb as many times as desired.
.
This allows intermittent, or complex to reproduce, bugs to be captured
and then debugged at leisure. Replays are deterministic, always
identical from one run to another.
.
rr is incompatible with ptrace hardening, and currently does not
support Haswell or later Intel CPUs.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140324235452.5687.18651.report...@heffalump.sk2.org

Re: make 4.0: archive rebuild resulted in 73 packages broken (help wanted)

[Stephen Kitt]

On Mon, 28 Apr 2014 23:01:58 -0700, Manoj Srivastava 
wrote:
> Stephen Kitt 
>mingw-w64

This one is due to missing B-D-I...

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Proposed mass bug filing: /usr/lib/perl5 is changing with Perl 5.20

[Stephen Kitt]

On Sun, 1 Jun 2014 22:08:07 +0300, Niko Tyni  wrote:
> On Sun, Jun 01, 2014 at 08:33:25PM +0200, Bastien ROUCARIES wrote:
> > On Sat, May 31, 2014 at 10:13 PM, Niko Tyni  wrote:
> > > we're changing the directory where binary Perl modules are installed
> > > from the traditional /usr/lib/perl5 to either /usr/lib//perl5
> > > (containing the multiarch triplet) or /usr/lib//perl5/
> > > (containing additionally the current major Perl version.)
> > >
> > > There's a pending Perl policy change in #748380 advising packages not
> > > to hardcode /usr/lib/perl5 anymore but to expand $Config{vendorarch}
> > > (from the Config module) during the build instead.
> > 
> > How can we make the transition smooth ?
> > 
> > I have a package.install file that contains a line
> > /usr/lib/perl5/
> > 
> > I could not change it to /usr/lib/*/perl5/ because it will fail with
> > old ABI. I use now
> > /usr/lib{/*/,/}perl5/ but it work by chance and lintian warn me.
> 
> Yeah, that's a bit cumbersome. One possibility is what Damyan Ivanov came
> up with for libgtk2-perl: have something like debian/package.install.in
> and preprocess it during the build to expand $Config{archlib}. See
> 
>  
> http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libgtk2-perl.git;a=commitdiff;h=88e0482c234c480e4d86fe44e933f7d38b8bfa43

Alternatively, you can use executable debhelper configuration files; simply
make debian/package.install an executable shell script (or Perl script or
whatever), and the output of its execution will be used instead of the file's
contents.

With reference to the preprocessing above, the equivalent would be to
export ARCHLIB in debian/rules and make libgtk2-perl{,-doc}.install executable
shell scripts using ${ARCHLIB}...

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#620943: ITP: evtest -- utility to monitor input device events

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 


* Package name: evtest
  Version : 1.27
  Upstream Author : Peter Hutterer 
* URL : http://cgit.freedesktop.org/evtest/
* License : GPLv2
  Programming Lang: C
  Description : utility to monitor input device events

 evtest monitors an input device, displaying all the events it generates.
 .
 It can be used to determine mice button bindings, keymaps for exotic
 keyboards... It is commonly used to debug issues with input devices
 in X.Org.


evtest used to be part of joystick (linuxconsole), but is now
maintained separately. I therefore intend to remove evtest from the
joystick package (which I maintain) and introduce a separate source
package for evtest.

Regards,

Stephen



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110405074113.3641.10952.report...@heffalump.sk2.org

Re: Bug#620943: ITP: evtest -- utility to monitor input device events

[Stephen Kitt]

On Tue, 5 Apr 2011 13:14:01 +0200, Julien Cristau  wrote:
> On Tue, Apr  5, 2011 at 09:41:13 +0200, Stephen Kitt wrote:
> 
> > * Package name: evtest
> >   Version : 1.27
> >   Upstream Author : Peter Hutterer 
> > * URL : http://cgit.freedesktop.org/evtest/
> > * License : GPLv2
> >   Programming Lang: C
> >   Description : utility to monitor input device events
> > 
> >  evtest monitors an input device, displaying all the events it generates.
> 
> a Linux input device maybe...

Indeed, thanks for pointing that out; I'll change the description and the
Architecture: field.

> >  It can be used to determine mice button bindings, keymaps for exotic
> >  keyboards... It is commonly used to debug issues with input devices
> >  in X.Org.
> > 
> Thanks for picking this up!

You're welcome! Once I found out about Peter's repository it seemed like the
obvious thing to do.

Regards,

Stephen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110405230141.7c81b...@sk2.org

Multiarch, policy and cross-compiler libraries for non-Debian architectures

[Stephen Kitt]

Hello,

Now that multiarch is here, I've been wondering whether and how it applies to
cross-compiler libraries for non-Debian architectures, for example Microsoft
Windows (I'm the new maintainer of mingw-w64). As I understand it, multiarch
wasn't intended for non-Debian architectures, and this is (indirectly)
reflected in policy (9.1.1 point 3 for example).

It seems to me though that it would be nice to follow the multiarch directory
structure for cross-compilers to non-Debian architectures (basically,
anything for which there is no valid "Architecture" field value for a Debian
package). Thus for example mingw-w64-dev would install headers
in /usr/include/{i686,x86_64}-w64-mingw32 and libraries
in /usr/lib/{i686,x86_64}-w64-mingw32 instead of the
current /usr/{i686,x86_64}-w64-mingw32/{include,lib} (which isn't
FHS-compliant, and thus isn't policy compliant either since section 9.1.1
is based on the FHS).

Unfortunately this appears to go against policy 9.1.1, which forbids packages
installing files into triplet-based directories under /usr/lib other
than /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH). Since the files I'm
thinking of aren't usable on any Debian architecture, they're provided as
"Architecture: all" packages and don't have a corresponding
DEB_HOST_MULTIARCH triplet.

Would it be acceptable to introduce an exception to policy allowing this?
Something along the lines of 

An exception is granted for `Architecture: all' packages containing
libraries targeting platforms for which there is no Debian
architecture. Such packages may use their traditional triplet as
recognised by binutils and gcc.

(The phrasing is certainly not perfect; this ends up being an exception to an
exception...)

Policy also doesn't mention /usr/include/; I saw that possibility
referred to in http://bugs.debian.org/542865.

I'd appreciate your thoughts!

Regards,

Stephen

PS. I realise some may find it odd to spend time on Windows support in
Debian, but it does come in handy, for instance for newer versions of Wine,
or for Windows versions of some tools used to install Debian from a Windows
environment.


signature.asc
Description: PGP signature

Re: Bug#623847: ITP: rescan-scsi-bus -- tool for reliable scsi hotplugging in linux

[Stephen Kitt]

Hello,

On Sat, 23 Apr 2011 21:53:39 +0530, Ritesh Raj Sarraf  wrote:
> This package is just one single shell script. But an important one. The
> rescan-scsi-bus.sh script helps a lot in the SAN space where there could
> be targets with sporadic connecitons. Is it okay to package a single
> shell script as a package?

This is already packaged in scsitools!

Regards,

Stephen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110423183544.02de7...@sk2.org

Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures

[Stephen Kitt]

On Sat, 23 Apr 2011 16:51:53 +0200, Adam Borowski  wrote:
> On Sat, Apr 23, 2011 at 12:29:39PM +0200, Goswin von Brederlow wrote:
> > I would rather add a new architecture to dpkg for this. This does not
> > mean that debian has to create a new port or that the packages have to
> > stop being arch:all. But dpkg should know about it and be the one and
> > only place packages query for the right multiarch triplet. Then you
> > would use
> >/usr/lib/$(dpkg-architecture -aw64-mingw32 -qDEB_HOST_MULTIARCH)
> > when building your package. Problem solved.
> 
> Sounds like a great idea to me!
> 
> It would fix the inconsistency I mentioned in another branch of this thread.
> 
> I'd use just "win32" and "win64" for short names of the architectures, since
> we don't have i386-gcc, i386-clang and i386-tcc when all of them use glibc.
> 
> Once it is hidden inside dpkg's bowels, the triplet might be even
> i586-i686-w32-w64-w128-but-really-w32-klaatu-verata-nikto-mingw-w42.

So if I understand things correctly that would mean using /usr/lib/win32
and /usr/lib/win64, regardless of the binutils/gcc triplet (which is fine as
far as I'm concerned - all I'm wary of is changing the gcc triplet used
upstream, see http://bugs.debian.org/622276 - obviously, Adam, you know about
this, but others probably don't).

Goswin, I take it you're advocating building _win32.deb packages (or
something similar) - is that correct? I didn't even realise that would be
possible without appropriate buildds... I know about “dpkg-buildpackage -a”
or “pdebuild --architecture” for local rebuilds, but would rebuilding such a
package be possible on the existing buildd network?

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Bug#623847: ITP: rescan-scsi-bus -- tool for reliable scsi hotplugging in linux

[Stephen Kitt]

On Sat, 23 Apr 2011 13:59:38 -0500, Peter Samuelson  wrote:
> [Stephen Kitt]
> > This is already packaged in scsitools!
> 
> Huh, I occasionally wondered whatever happened to 'scsiadd'.
> Guess its functionality was subsumed into scsitools.

Effectively, yes, although "subsumed" isn't quite appropriate - both scsiadd
and scsitools required /proc/scsi/scsi which was removed from the default
configuration in the linux-2.6 packages. scsiadd was never updated to cope
with this change, and therefore ended up being removed; scsitools was
(unfortunately not in time for Squeeze though).

Regards,

Stephen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110423230851.20dc1...@sk2.org

Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures

[Stephen Kitt]

On Sat, 23 Apr 2011 16:38:57 +0200, Adam Borowski  wrote:
> On Sat, Apr 23, 2011 at 05:05:33AM -0500, Jonathan Nieder wrote:
> > IIUC then the GNU triplet includes the choice of C library because
> > binaries (e.g., libraries) compiled against mingw32 and mingw-w64
> > cannot be linked (i.e., they do not share ABI).  Though I could easily
> > be wrong.
> 
> Note that the triplets used by mingw-w64 were carefully chosen to produce as
> much confusion as possible.  The two architectures: win32 and win64 have
> both "w32" and "w64" in the name:
> * i686-w64-mingw32
> * x86_64-w64-mingw32

“were carefully chosen” is perhaps a slight exaggeration (see
http://bugs.debian.org/622276 for my understanding of how these triplets
ended up being used), but I do admit it can be confusing.

> The former is ABI-compatible not only with i586-mingw32msvc but also with
> real msvc.  I just tried all combinations of these three, even including
> malloc()ing from an object compiled with one and free()ing from another.
> 
> Everything seems to work fine [1].

I can confirm this too, as far as I've been able to determine the output of
gcc-mingw32 in Debian is compatible with that of gcc-mingw-w64 when
targeting Win32.

> This is for C.  C++ between MSVC10 and mingw32 is not ABI-compatible, but
> even gcc breaks compatibility there completely every a few releases
> (remember -c102 in gcc-4.0?) and in minor points more often.  So does MSVC.
> Our two mingw32 versions seem to be compatible with each other, though.

I haven't checked this but I'll take your word for it.

> > IIRC according to the multiarch spec, paths in Debian use "simplified"
> > triplets (DEB_HOST_MULTIARCH) with i[3456...]86 replaced by i386.
> > Including so much unnecessary detail about the default instruction set
> > in the triplet is unusual (I know of no example other than x86).  As
> > you mention, in the ix86 case it causes problems so we work around it.
> 
> Distinguishing between two ABI-compatible compilers would be even worse. 
> Fortunately, nothing started using these names yet, so it's a perfect moment
> to discuss a common arch name.
> 
> Currently, the following packages use i586-mingw32msvc:
> * gcc-mingw32
> * mingw32
> * mingw32-binutils
> * mingw32-ocaml
> * mingw32-runtime
> * nsis

I'm hoping the mingw-w64 set of packages (mingw-w64, binutils-mingw-w64 and
gcc-mingw-w64) will be good enough to replace gcc-mingw32, mingw32,
mingw32-binutils and mingw32-runtime. I originally started working on
mingw-w64 to get wine-gecko into the archive and thus allow wine packaging to
resume, but it seemed to me a good time as well to work on cleaning up the
whole set of mingw packages in Debian. I've sent patches to allow most of the
reverse-build-dependencies of mingw32 or gcc-mingw32 to build using mingw-w64
(nsis, autorun4linuxcd, cpio, gzip, gnupg and win32-loader so far), and I'm
working on the remaining two (mingw32-ocaml and libreoffice).

Completing all this would mean the i586-mingw32msvc target could be forgotten
entirely; no one outside Debian uses it (any more), upstream and others have
switched to the -w64-mingw32 suffix. (See also http://bugs.debian.org/606825
for extensive discussion and a first patch for dpkg support.)

> There's no need to use the same triplet for multiarch as for compiler,
> so the new path might use something else.  I don't care what, as long as
> it's consistent between all of win32 in Debian.

That's fine by me, regardless of whether mingw-w64 ends up being “all of
win32 in Debian” or not!

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures

[Stephen Kitt]

Hi Steve,

On Sat, 23 Apr 2011 14:44:33 -0700, Steve Langasek  wrote:
> On Fri, Apr 22, 2011 at 11:04:59PM +0200, Stephen Kitt wrote:
> > Unfortunately this appears to go against policy 9.1.1, which forbids
> > packages installing files into triplet-based directories under /usr/lib
> > other than /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH). Since the
> > files I'm thinking of aren't usable on any Debian architecture, they're
> > provided as "Architecture: all" packages and don't have a corresponding
> > DEB_HOST_MULTIARCH triplet.
> 
> > Would it be acceptable to introduce an exception to policy allowing this?
> > Something along the lines of 
> 
> > An exception is granted for `Architecture: all' packages
> > containing libraries targeting platforms for which there is no Debian
> > architecture. Such packages may use their traditional triplet as
> > recognised by binutils and gcc.
> 
> The current wording is quite deliberate in only allowing the use of these
> directories by packages of the given architecture, because one of the ideas
> to be explored in the future is introducing partial architectures for things
> like w64-mingw32 (or sparc64, or armv7+neon, or amd64+sse4) that aren't
> self-hosting but that it's interesting to build a subset of packages for
> (mostly libraries).

Ah, that's all the information I was missing. If there's a plan (or at
least the beginning of a plan) that's great, I'll follow along when the time
comes!

> So I would be opposed to making such a change in policy for the time being;
> I think cross-compilers should stick with the traditional cross-compiler
> directories and stay away from the multiarch directories until we have more
> practical experience with multiarch under our belts and can make some
> educated decisions about how we want this to all fit together.

OK.

Would it make any sense then to add an exception for traditional
cross-compiler directories, or should cross-compiling library packages simply
continue using lintian overrides?

One last question: without considering multiarch, what is the situation
regarding headers? Is the proposal in http://bugs.debian.org/542865 still the
intended approach, or is there another solution?

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures

[Stephen Kitt]

On Wed, 27 Apr 2011 18:44:39 +0200, Goswin von Brederlow 
wrote:
> Stephen Kitt  writes:
> > So if I understand things correctly that would mean using /usr/lib/win32
> > and /usr/lib/win64, regardless of the binutils/gcc triplet (which is fine
> > as
> 
> If that is what dpkg-architecture outputs. The path should never be
> hardcoded.

That makes sense, of course.

> > Goswin, I take it you're advocating building _win32.deb packages (or
> > something similar) - is that correct? I didn't even realise that would be
> > possible without appropriate buildds... I know about “dpkg-buildpackage
> > -aâ€_ or “pdebuild --architectureâ€_ for local rebuilds, but would
> > rebuilding such a package be possible on the existing buildd network?
> 
> No. You would still build a _all.deb. The debian/rules file would just
> ask dpkg-architecture what the right multiarch dir is for the win32 ABI.
> You can ask dpkg-architecture for information of an architecture other
> than what you are building for.

OK, thanks for clarifying that!

Regards,

Stephen


signature.asc
Description: PGP signature

Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures

[Stephen Kitt]

On Sun, 24 Apr 2011 22:46:40 +0100, Wookey  wrote:
> +++ Stephen Kitt [2011-04-24 19:14 +0200]:
> > > So I would be opposed to making such a change in policy for the time
> > > being; I think cross-compilers should stick with the traditional
> > > cross-compiler directories and stay away from the multiarch directories
> > > until we have more practical experience with multiarch under our belts
> > > and can make some educated decisions about how we want this to all fit
> > > together.
> > 
> > OK.
> 
> I expect the multiarch paths to replace the 'traditional
> cross-compiling' paths in due course for all target architectures,
> including ones that aren't Debian-suported (i.e currently
> mingw-whatever-you-call-it, avr32, msp430), for both native use and
> cross-compiling. Steve will have to explain to me why we might want to
> use different paths for non-self-hosting arches. It seems to me that
> having one canonical place to look for arch-dependent files is good
> whether you want them for running or for (cross-)building.
> 
> But we do need to proceed carefully in order to get this right, and
> the cross-only arches are a little way down our list of issues :-) I'd
> be interested to hear how you currently do things in mingw world (and
> more importantly what things you want to be able to do) so that we can
> take your needs into account.

I personnally don't speak for upstream, and most of the documentation
available upstream discusses either Windows builds or sysroot-based builds
in /usr/local. There has been a fair amount of discussion in the past though,
including a proposed patch for dpkg (http://bugs.debian.org/606825) and a
specification document on the Debian wiki (http://wiki.debian.org/Mingw-W64
which also has links to other distributions' documentation). I don't
particularly like the sysroot approach, and I believe multiarch would provide
the same functionality, i.e. being able to host at least the headers and
libraries (and link-time DLLs) for cross-compiled libraries.

I see two immediate requirements for MinGW-w64 in Debian:
* being able to build wine-gecko;
* replacing mingw32 and gcc-mingw32.

Looking further, being able to host -dev packages to provide a nice
cross-building environment would be desirable. Being able to host
cross-compiled runtime binaries and DLLs doesn't seem quite so useful to me,
although people using Debian to build installation packages for Windows would
probably disagree.

> I do think that getting the 'win32' arch name and triplet defined in
> dpkg-architecture is stage 1 for you. I thought we'd already done that
> years ago, when this last came up, but obviously not.
> dpkg-architecture already supports 269 options including such
> not-very-useful combinations as uclibc-linux-s390 and solaris-alpha,
> so it really ought to know about the win32 and win64 ABIs. It's
> generally a very simple patch to a few tables in dpkg to add a new arch. 
> 
> Having the mappings between Debian arch name, gnu triplet and multiarch
> path all in one place is vital to making all this stuff work properly.

It is indeed, see above for the existing bug report. I take it people were
perhaps awaiting Dmitrijs' test results before pursuing things; I've built a
patched dpkg and so far the results seem OK, although perhaps not to Adam's
liking since the multiarch directories still end up being MinGW-w64 specific:

% dpkg-architecture -amingw64-amd64
dpkg-architecture: warning: Specified GNU system type x86_64-w64-mingw32 does
not match gcc system type i486-linux-gnu. DEB_BUILD_ARCH=i386
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=i386
DEB_BUILD_ARCH_BITS=32
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_GNU_CPU=i486
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=i486-linux-gnu
DEB_BUILD_MULTIARCH=i386-linux-gnu
DEB_HOST_ARCH=mingw64-amd64
DEB_HOST_ARCH_OS=windows
DEB_HOST_ARCH_CPU=amd64
DEB_HOST_ARCH_BITS=64
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_GNU_CPU=x86_64
DEB_HOST_GNU_SYSTEM=w64-mingw32
DEB_HOST_GNU_TYPE=x86_64-w64-mingw32
DEB_HOST_MULTIARCH=x86_64-w64-mingw32

% dpkg-architecture -amingw64-i386 
dpkg-architecture: warning: Specified GNU system type i486-w64-mingw32 does not 
match gcc system type i486-linux-gnu.
DEB_BUILD_ARCH=i386
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=i386
DEB_BUILD_ARCH_BITS=32
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_GNU_CPU=i486
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=i486-linux-gnu
DEB_BUILD_MULTIARCH=i386-linux-gnu
DEB_HOST_ARCH=mingw64-i386
DEB_HOST_ARCH_OS=windows
DEB_HOST_ARCH_CPU=i386
DEB_HOST_ARCH_BITS=32
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_GNU_CPU=i486
DEB_HOST_GNU_SYSTEM=w64-mingw32
DEB_HOST_GNU_TYPE=i486-w64-mingw32
DEB_HOST_MULTIARCH=i386-w64-mingw32

Other distributions and upstream always use i686 for 32-bit MinGW-w64, which
i

Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures

[Stephen Kitt]

On Sun, 24 Apr 2011 23:46:10 +0100, Ben Hutchings  wrote:
> On Sun, 2011-04-24 at 22:46 +0100, Wookey wrote:
> [...]
> > I do think that getting the 'win32' arch name and triplet defined in
> > dpkg-architecture is stage 1 for you. I thought we'd already done that
> > years ago, when this last came up, but obviously not.
> > dpkg-architecture already supports 269 options including such
> > not-very-useful combinations as uclibc-linux-s390 and solaris-alpha,
> > so it really ought to know about the win32 and win64 ABIs. It's
> > generally a very simple patch to a few tables in dpkg to add a new arch. 
> [...]
> 
> By the way, it should be something like 'win32-i386' rather than just
> 'win32'.  The non-x86 ports of NT 3.x and 4.0 are not really relevant
> but an ARM port of Windows is supposed to be coming soon.

That's an excellent point, and the dpkg proposal in
http://bugs.debian.org/606825 takes care of it.

% dpkg-architecture -amingw64-arm 
dpkg-architecture: warning: Specified GNU system type arm-w64-mingw32 does not 
match gcc system type i486-linux-gnu.
DEB_BUILD_ARCH=i386
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=i386
DEB_BUILD_ARCH_BITS=32
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_GNU_CPU=i486
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=i486-linux-gnu
DEB_BUILD_MULTIARCH=i386-linux-gnu
DEB_HOST_ARCH=mingw64-arm
DEB_HOST_ARCH_OS=windows
DEB_HOST_ARCH_CPU=arm
DEB_HOST_ARCH_BITS=32
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_GNU_CPU=arm
DEB_HOST_GNU_SYSTEM=w64-mingw32
DEB_HOST_GNU_TYPE=arm-w64-mingw32
DEB_HOST_MULTIARCH=arm-w64-mingw32

Regards,

Stephen


signature.asc
Description: PGP signature

Bug#626588: ITP: gdb-mingw-w64 -- Cross-debugger for 32- and 64-bit Windows using MinGW-w64

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 


* Package name: gdb-mingw-w64
  Version : 7.2
  Upstream Author : Free Software Foundation, Inc.
* URL : http://www.gnu.org/software/gdb/
* License : GPL-3+
  Programming Lang: C, C++, Python
  Description : Cross-debugger for 32- and 64-bit Windows using MinGW-w64

MinGW-w64 provides a development and runtime environment for 32- and
64-bit Windows applications using the GNU Compiler Collection (gcc).

This package contains the gdb debugger which can be used with a
Windows-hosted gdbserver to debug programs running on Windows hosts.
It also contains gdbserver for 32- and 64-bit Windows.



I'll be basing this package on gdb-source (and specifying
"Built-Using") in the same way as binutils-mingw-w64 and
gcc-mingw-w64.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110513101513.16940.39760.report...@heffalump.sk2.org

Bug#771253: ITP: gcab -- Microsoft Cabinet file manipulation tool

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: gcab
  Version : 0.4
  Upstream Author : Marc-André Lureau 
* URL : https://wiki.gnome.org/msitools
* License : LGPL-2.1+
  Programming Lang: C
  Description : Microsoft Cabinet file manipulation tool

 gcab can list, extract and create cabinet (.cab) files, commonly used
 as archives to distribute software on Windows.
 .
 gcab is similar to cabextract but can create cabinet files.

This is a reverse dependency of msitools, see #757007.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141127235834.11896.6464.report...@heffalump.sk2.org

Unversioned dependencies and empty packages

[Stephen Kitt]

Dear fellow developers,

Sorry for the cross-post, I'm not sure what the most appropriate list for
this is.

Recently debhelper was changed to ensure that packages which link to another
package's documentation directory (/usr/share/doc/${package}) have a strictly
versioned dependency on the latter package. (This is dh_installdocs with
the --link-doc option.) The latest version of debhelper now causes an error
if this is done from an arch: all to an arch: any package (or vice versa), to
avoid a common case where binNMUs result in uninstallable packages.

There's nothing wrong with all this, but it brings up an interesting,
somewhat related, point. Can empty packages (such as transitional package or
metapackages) depend on another package for their documentation (including
licensing information) without having a strict versioned dependency on that
package?

An example is gcc-mingw-w64: it produces a number of empty metapackages and
one transitional package (mingw32, containing only links), which all depend on
gcc-mingw-w64-base, and the latter contains the documentation. The
dependencies don't have a version, which means that even though the
empty packages are arch: all, the whole contraption is binNMU-friendly.

I reckon this is OK since there is no content in these binary packages to
license in any way, unless the meta-data itself needs to be licensed. So it
doesn't matter if the versions of the metapackages and the "real" packages
diverge (from a licensing point of view), even if the license on the
corresponding source packages changes...

What do you think?

Thanks for your time,

Stephen


pgpExhcwpDG9H.pgp
Description: OpenPGP digital signature

Bug#775872: ITP: fcml -- machine code manipulation library

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: fcml
  Version : 1.0.0
  Upstream Author : Slawomir Wojtasiak 
* URL : http://fcml-lib.com
* License : LGPL-2.1+
  Programming Lang: C
  Description : machine code manipulation library

 FCML, the Free Code Manipulation Library, is a general-purpose
 machine code manipulation library for i386 and amd64 architectures.
 It includes an assembler and disassembler, instruction renderers and
 parsers, and supports Intel and AT&T (gas) syntax.
 .
 It supports most recent instruction set extensions, including MMX,
 3D-Now!, SSE including 4.2 and 4A, AVX and AVX2, AES-NI, TBM, BMI1
 and BMI2, HLE, ADX, CLMUL, RDRAND, RDSEED, FMA, FMA4, LWP, SVM, XOP,
 VMX and SMX.


One of the highlights of this package is that it includes a HotSpot
disassembler plugin (hsdis), correctly licensed so that it's
redistributable in binary form as well as source. (OpenJDK includes an
hsdis plugin too, but it ends up mixing GPL-2-only and GPL-3+ code.)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150120223552.26261.61604.report...@heffalump.sk2.org

Bug#779680: ITP: node-argparse -- command-line argument parser for node.js

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-argparse
  Version : 1.0.1
  Upstream Author : Vitaly Puzrin 
* URL : https://github.com/nodeca/argparse
* License : Expat
  Programming Lang: JavaScript
  Description : command-line argument parser for node.js

 argparse is a full JavaScript port of Python's argparse module. It supports
 parsing command-line options, both long and short forms, non-option
 arguments, and can build help messages listing all known options.
 .
 Node.js is an event-based server-side JavaScript engine.

This is a requirement for Keybase.


pgpn0WgYrA2M2.pgp
Description: OpenPGP digital signature

Re: Modern Debian packaging system for DevOps: does it exist?

[Stephen Kitt]

Hi Andreas,

On Tue, 19 May 2015 10:12:57 +0200, Andreas Tille  wrote:
> On Fri, May 15, 2015 at 05:57:06PM +0200, gregor herrmann wrote:
> > For pbuilder/cowbuilder I'm using the following hook:
> > 
> > % cat /var/cache/pbuilder/hooks/D10-man-db 
> > #!/bin/sh
> > # Don't rebuild man-db
> > 
> > echo "I: Preseed man-db/auto-update to false"
> > debconf-set-selections < > man-db man-db/auto-update boolean false
> > EOF
> 
> I was always wondering whether I should file a bug report against
> pbuilder to do exactly this but was not clever enough to know how to
> propose a patch.  Now, since I saved this problem for myself due to this
> great tip I keep on wondering whether there is no chance to inject this
> right into official pbuilder since I guess everybody really wants this.

It's already available in pbuilder as
/usr/share/doc/pbuilder/examples/D80no-man-db-rebuild

Regards,

Stephen


pgpED4jW2jxZI.pgp
Description: OpenPGP digital signature

Re: Bits from the Wanna Build team

[Stephen Kitt]

On Sun, 23 Aug 2015 13:30:40 +0200, Aurelien Jarno 
wrote:
> On 2015-08-22 19:19, Steve Langasek wrote:
> > On Sat, Aug 22, 2015 at 10:52:38PM +0200, Aurelien Jarno wrote:
> > > I therefore believe that we should try to work to ensure arch:all
> > > packages can be built on all major architectures. That said, as a
> > > maintainer of such a package, I understand there is still some work to
> > > do first, for example by getting cross-compilers in the archive to build
> > > the firmwares. It would be quite interesting to build a list of such
> > > packages to have a better view of the work that has to be done.
> > 
> > Unless there's other demand for these cross-compilers in the archive, this
> > sounds like a lot of busywork.  Sure, a cross-compiler is a good option
> > for building firmware for some qemu architecture that's not self-hosting
> > in Debian, but are you really volunteering to maintain a sparc
> > cross-compiler just for openbios?
> 
> Yes, and I already do that. For almost a year now, openbios can be built
> on all architectures. And the code for doing that is just less than 100
> of lines (see debian/cross-toolchain.mk). I still have to do the same
> for the other similar packages.

The way I understand Steve's email is that he's thinking of an actual SPARC
cross-compiler package... I think your (Aurélien's) approach is the right
one: CPU time is now so cheap on our big architectures that building a
(small) cross-compiler during a package build makes sense, at least when
weighed against the maintainer burden of a full-blown cross-compiler package.
It may seem sensible to introduce a cross-compiler package to support
building some piece of software in the archive, but once that cross-compiler
package is in the archive users find other uses for it; in absolute terms
that's probably a good thing, but it means more work for the maintainer who
initially just set out to make things buildable.

> > > So in short we should try to fix these packages, but given they are not
> > > always easy to fix, we should just temporarily allow the upload of such
> > > binaries.
> > 
> > This means that, in the meantime, we continue to be unable to prove the
> > correctness of (some subset of) the binary packages in the Debian archive.
> > I don't see why convenience of being able to rebuild an arch: all package
> > on arbitrary architectures, something that up to this point has never been
> > supported, should block / take precedence over providing our users the
> > surety of reproducible builds.
> 
> It's clearly going to block reaching 100%, but it's not a good reason
> enough to block everything when we can easily reach 99.9%.

Yes. Plus we have enough porterboxes to prove correctness of the binary
packages anyway, it just has to be done manually (or am I missing something?).

Regards,

Stephen


pgpqkUQ3jTi6D.pgp
Description: OpenPGP digital signature

Bug#796916: ITP: osslsigncode -- Authenticode signing tool

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: osslsigncode
  Version : 1.7.1
  Upstream Author : Per Allansson 
* URL : https://sourceforge.net/projects/osslsigncode
* License : GPL-3+
  Programming Lang: C
  Description : Authenticode signing tool

 osslsigncode is an Authenticode signing tool for PE binaries
 (Windows executables, DLLs, drivers...), CAB archives and MSI
 installation packages. It also supports timestamping using
 Authenticode and RFC-3161.

Bug#924048: ITP: shockolate -- System Shock game engine

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: shockolate
  Version : 0.7.5
  Upstream Author : Chad Cuddigan 
* URL : https://github.com/Interrupt/systemshock
* License : GPL-3+
  Programming Lang: C, C++
  Description : System Shock game engine

Shockolate is a source port of System Shock, based on the game engine
released by Night Dive Studios. It aims to preserve the original
gaming experience with a few improvements, such as an OpenGL renderer
and support for mods.
.
Shockolate requires the original game assets from the CD-ROM or
Enhanced Edition releases of System Shock. game-data-packager 64 and
greater can package the required files.


This will be packaged within the games team.

Bug#928446: ITP: nulib2 -- NuFX and Binary II archive utility

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: nulib2
  Version : 3.1.0
  Upstream Author : Andy McFadden
* URL : http://nulib.com
* License : BSD
  Programming Lang: C
  Description : NuFX and Binary II archive utility

 NuLib2 is a command-line archive utility for NuFX and Binary II
 archives, as commonly used on Apple II systems. It can handle files
 produced by ShrinkIt. Typical extensions for the files it supports
 are SHK, SDK, BXY, BSE, SEA, BNY, and BQY.
 .
 It can preserve file types, handles resource forks, comments, large
 archives, wrappers...

Re: Options for 64-bit time_t support on 32-bit architectures

[Stephen Kitt]

On Fri, 19 Jul 2019 19:13:28 +0200, Florian Weimer  wrote:
> * Adrian Bunk:
> > For i386 the last newly released 32bit-only hardware were some early
> > Intel Atoms 10 years ago, and when the AMD Geode goes out of production
> > soon there might be no hardware in production left.
> > There are still surprisingly many people using Debian on 32bit-only
> > hardware, but in 20 years this will have changed.  
> 
> You have thankfully edited out the Intel Quark. 8-)

Vortex86 SoCs are still being produced, supposedly for at least another ten
years...

Regards,

Stephen


pgptogQp5yjuF.pgp
Description: OpenPGP digital signature

Re: B-D on src package? (was: Re: Challenge from Julia's non-standard vendored openblas"64_"

[Stephen Kitt]

On Sun, 28 Jul 2019 16:33:21 +0200, Johannes Schauer  wrote:
> Quoting Mo Zhou (2019-07-28 16:03:43)
> > On 2019-07-28 13:13, Ian Jackson wrote:  
> > > This is maybe not directly helpful to you right now, but:
> > > 
> > > If we could build-depend on source packages, you could combine these
> > > two ideas into something that might be less awful.  
> > More than once have I thought of "what if I can B-D on a source package".
> > Is such demand common enough among developers?  
> 
> recently there was some discussion about this in #debian-apt. I don't have
> the logs of that discussion so others might want to expand on what I
> remember from back then. In no particular order plus my own thoughts.
> 
> apt developers are in favour of such a feature but it would need
> implementation in dpkg first. This means that dpkg would have to also track
> "installed" (unpacked) source packages in /usr/src in a similar way of how
> it currently tracks installed binary packages.
> 
> Tons of software that parses the Build-Depends field has to be patched. At
> least: dpkg, sbuild, apt, debhelper, cdbs, pbuilder, lintian, dose3,
> wanna-build, dak, devscripts, python-debian, libconfig-model-perl, augeas,
> haskell-debian, dh-exec, autopkgtest...

Could we avoid (some of) this by treating “source” as a new architecture?
There would be a mostly do-nothing buildd which would repack the source
package as a binary package in /usr/src/...

That would still mean we’d have to add meaningful arch-qualified
build-dependencies in all the affected tools, and it doesn’t help with the
transitive dependencies (although the binary package containing the source
could carry the appropriate dependencies), so perhaps it’s not such a great
idea.

Regards,

Stephen


pgpv5VyQb9Dn8.pgp
Description: OpenPGP digital signature

Re: B-D on src package? (was: Re: Challenge from Julia's non-standard vendored openblas"64_"

[Stephen Kitt]

Hi josch,

On Tue, 06 Aug 2019 20:11:07 +0200, Johannes Schauer  wrote:
> Quoting Stephen Kitt (2019-08-06 18:43:24)
> > Could we avoid (some of) this by treating “source” as a new architecture?
> > There would be a mostly do-nothing buildd which would repack the source
> > package as a binary package in /usr/src/...
> 
> The large number of binary packages needed with this method could of course
> be reduced if only selected source packages get built that way. But such a
> method already exists in the form of foo-source binary packages.
> 
> Changing the build dependency syntax instead would have the advantage, that
> we do not need more binary or source packages at all because all the
> necessary logic would come from the resolvers themselves.

Thanks for the detailed explanations, changing the build dependency syntax
does indeed seem like a better approach.

Regards,

Stephen


pgp4enki5g859.pgp
Description: OpenPGP digital signature

Bug#935803: ITP: binutils-djgpp -- cross-binutils for DOS using DJGPP

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: binutils-djgpp
  Version : 2.32
  Upstream Author : GNU
* URL : https://www.gnu.org/software/binutils/
* License : GPL
  Programming Lang: C
  Description : cross-binutils for DOS using DJGPP

DJGPP provides a development and runtime environment for 32-bit DOS
applications using a specific C library and the GNU Compiler
Collection (gcc).
.
This package contains the toolchain binutils targeting 32-bit DOS.
 

This will be packaged following the same approach as the MinGW-w64
toolchain, using binutils-source. It will be used for DOSEMU2
packaging.

Re: Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)]

[Stephen Kitt]

On Sat, 20 May 2023 18:14:52 +0200, Adam Borowski  wrote:
> On Sat, May 20, 2023 at 09:15:00AM +0200, Josh Triplett wrote:
> > How easily could we add 64-bit system detection to the i386 installer,
> > and a message saying something like:
> > 
> > "You're installing the i386 architecture on a 64-bit system. While this
> > will work, this is the last release it'll be supported. We recommend
> > installing the 64-bit amd64 architecture instead.  
> 
> This is not a valid use for i386.  Running the i386 kernel on _modern_
> hardware is insecure, slower (esp. if you have a non-tiny amount of
> memory), etc.  We should put a big fat warnings for _that_.

And future modern hardware is likely to make it impossible:
https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
which means it will become increasingly difficult to reliably test i386
kernels on sensible hardware; not on a timescale relevant for Trixie, but
still, worth bearing in mind. VMs and/or emulation will end up being the only
possible ways of running legacy software on modern hardware.

Regards,

Stephen


pgpBMXYacDGJr.pgp
Description: OpenPGP digital signature

Bug#1037228: ITP: pycrc -- CRC C source code generator

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: pycrc
  Version : 0.10.0
  Upstream Author : Thomas Pircher 
* URL : https://pycrc.org
* License : MIT
  Programming Lang: Python
  Description : CRC C source code generator

pycrc is a Cyclic Redundancy Check (CRC) C source code generator.
.
It supports different implementations, with various speed-space
compromises. The CRC parameters can be freely chosen, and pycrc
includes a number of well-known CRC models (CRC-16, CRC-32 etc.).


This is a build-dependency for dosbox-x. It will be maintained in the
Python packaging team.

Re: Mass bug filing / call for testing: dependencies on SDL 1.2

[Stephen Kitt]

Hi Simon,

On Mon, 12 Jun 2023 17:24:03 +0100, Simon McVittie  wrote:
> SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives
> upstream maintenance or releases. Maintained software that uses SDL 1.2
> should be ported to SDL 2.

Given the time scales involved, is it worth waiting for SDL 3 (soon...)
before porting SDL 1.2 software? I’m assuming that SDL 3 will be available
for Trixie, and this would avoid two porting efforts.

Regards,

Stephen


pgpNOBwOwE0Bk.pgp
Description: OpenPGP digital signature

Re: Mass bug filing / call for testing: dependencies on SDL 1.2

[Stephen Kitt]

On Wed, 21 Jun 2023 10:33:01 +0100, Simon McVittie  wrote:
> On Wed, 21 Jun 2023 at 08:50:30 +0200, Stephen Kitt wrote:
> > On Mon, 12 Jun 2023 17:24:03 +0100, Simon McVittie 
> > wrote:  
> > > SDL 1.2 was superseded by SDL 2 several years ago, and no longer
> > > receives upstream maintenance or releases. Maintained software that
> > > uses SDL 1.2 should be ported to SDL 2.  
> > 
> > Given the time scales involved, is it worth waiting for SDL 3 (soon...)
> > before porting SDL 1.2 software? I’m assuming that SDL 3 will be available
> > for Trixie, and this would avoid two porting efforts.  
> 
> I don't know what the timescale for a stable release of SDL 3 is like -
> I hope it'll be ready before trixie, but I can't guarantee anything. Many
> games will not be able to move to SDL 3 until additional libraries like
> SDL2_image have a SDL 3 version, so even after everything is API-stable,
> it's going to take several trips through NEW before we can ask maintainers
> to port to it.
> 
> The first step in porting from SDL 1.2 to SDL 3 will be porting to SDL 2
> (both the core library and the version of addons like SDL_image), and
> the second step would be moving away from any deprecated SDL-2-era APIs,
> so I think it's worth doing those regardless.

Right, so in any case the effort involved in porting to SDL 2 won’t be
“wasted” by a subsequent port to SDL 3.

> What I would prefer to try to avoid here is for maintainers to think
> "I'll just wait for SDL 3", and then time passes, maintainers are busy
> with something else, we freeze, and we have to ship trixie with *three*
> major versions of SDL (or at least their -compat equivalents).
> 
> Ideally these bugs would have been opened in 2013 or 2014, but better late
> than never. (I was not involved in SDL maintenance at that point.)

Indeed!

Regards,

Stephen


pgpCmvhueWNnW.pgp
Description: OpenPGP digital signature

Re: ITP: golang-github-esiqveland-notify -- notify is a go dbus implementation for delivering desktop notifications over dbus

[Stephen Kitt]

Hi,

On Wed, 25 Oct 2023 09:01:10 +0300, Ramūnas Keliuotis
 wrote:
> Was not sure if I'm doing this the right way. Forgive me for creating
> troubles.

dh-make-golang is the appropriate tool. Don’t worry about API instability,
it’s well understood in the Go world that v0 releases don’t provide API
guarantees, and
https://qa.debian.org/developer.php?email=team%2Bpkg-go%40tracker.debian.org
shows that there are plenty of v0 Go packages in Debian (even in stable).

Do bear in mind that unstable APIs can create a burden for the maintainer,
since updates may require bumps to other packages.

> I was following the `dh-make-golang` example. I am not the owner of
> this package, but it is a dependency for my primary golang program
> NordVPN.
> Was strange to me that it is an ITP request - it is for the owner or
> maintainer. Probably this should be an RFP.

If you intend to maintain the package in Debian, then an ITP is appropriate.
If you’re asking for someone else to maintain the package in Debian, then an
RFP is appropriate.

> `dh-make-golang` program example/tutorial is probably oriented for go
> package owners or maintainers.
> Here is that tutorial:
> https://people.debian.org/~stapelberg/2015/07/27/dh-make-golang.html
> I found reference to that tutorial in `go-team` packaging page:
> https://go-team.pages.debian.net/packaging.html
> 
> Please, advise me how to proceed with packaging third party golang
> packages which are my golang program's dependencies and are not yet
> available in Debian SID.
> 
> Some examples of my dependencies which are not in SID yet:
> github.com/esiqveland/notify v0.11.2
> github.com/godbus/dbus/v5 v5.1.0

This one is already packaged: https://tracker.debian.org/pkg/golang-dbus

> github.com/Microsoft/go-winio v0.6.0 // indirect

As others have mentioned on your ITP for that, it might not be necessary in
Debian — you need to determine which dependencies are really needed (don’t
look at go.mod or go mod graph, build the binary you’re interested in and run
"go version -m" on it).

Regards,

Stephen


pgpGfnsMemboV.pgp
Description: OpenPGP digital signature

Re: ITP: golang-github-esiqveland-notify -- notify is a go dbus implementation for delivering desktop notifications over dbus

[Stephen Kitt]

Hi Ramūnas,

On Mon, 30 Oct 2023 16:02:38 +0200, Ramūnas Keliuotis
 wrote:
[…]
> On Sat, Oct 28, 2023 at 9:06 PM Stephen Kitt  wrote:
> > On Wed, 25 Oct 2023 09:01:10 +0300, Ramūnas Keliuotis
> >  wrote:  
[…]
> > > I was following the `dh-make-golang` example. I am not the owner of
> > > this package, but it is a dependency for my primary golang program
> > > NordVPN.
> > > Was strange to me that it is an ITP request - it is for the owner or
> > > maintainer. Probably this should be an RFP.  
> >
> > If you intend to maintain the package in Debian, then an ITP is
> > appropriate. If you’re asking for someone else to maintain the package in
> > Debian, then an RFP is appropriate.  
> 
> Could you give more details on what would mean `maintain the package`?
> If I would prepare it for upload, then ask to upload it, polish some
> bits if needed, but not any fixing in code as this is a 3rd party
> package, not my own.
> I guess it would be quicker if I did it by myself. Otherwise I would
> need to wait undetermined time for someone to do it as it is not an
> interesting package to anyone else.
> Will I be obliged to prepare new version upgrades or any other effort
> will be needed? Just trying to evaluate the effort needed if I would
> take this role.

To get an idea of what maintainership entails, see
https://www.debian.org/doc/manuals/developers-reference/developer-duties.en.html#package-maintainer-s-duties
— in short, maintaining a package means getting it into shape for the next
release of Debian, responding to bug reports, and liaising between the
upstream developer and Debian and its users.

It is quite common for Debian maintainers to end up maintaining niche library
packages which are required for the packages they mainly care about. When
that happens, the maintainership can be limited to the needs of the main
package, but it often happens that others then start using the library
package and the maintainership scope expands. So you would typically not
*have* to prepare version upgrades unless your main package needs them, but
that may well change at some point — and in any case, even if your main
package doesn’t require an upgrade, it would be best if you did at least keep
track of new upstream releases and evaluate whether it’s important to package
them or not (e.g. if they fix important bugs).

Go packages are typically team-maintained so the burden doesn’t have to be as
heavy as for packages maintained by a single person.

You would *not* be expected to fix upstream bugs or add upstream features;
Debian maintainers do often end up providing upstream bug fixes but that’s
not a requirement. A maintainer’s role can stop at forwarding relevant bugs
upstream and interacting with upstream as appropriate to help resolve it (or
enlist the original bug reporter’s help to keep things moving). However if a
bug is important enough in Debian, the package can be withheld from a
release, and in some cases the only way to avoid that is to fix the bug
rather than wait for upstream to do so.

> > > `dh-make-golang` program example/tutorial is probably oriented for go
> > > package owners or maintainers.
> > > Here is that tutorial:
> > > https://people.debian.org/~stapelberg/2015/07/27/dh-make-golang.html
> > > I found reference to that tutorial in `go-team` packaging page:
> > > https://go-team.pages.debian.net/packaging.html
> > >
> > > Please, advise me how to proceed with packaging third party golang
> > > packages which are my golang program's dependencies and are not yet
> > > available in Debian SID.
> > >
> > > Some examples of my dependencies which are not in SID yet:
> > > github.com/esiqveland/notify v0.11.2
> > > github.com/godbus/dbus/v5 v5.1.0  
> >
> > This one is already packaged: https://tracker.debian.org/pkg/golang-dbus  
> 
> Right, found it. But only Debian package naming is different from the
> established naming system.

Yes, it’s not obvious.

> > > github.com/Microsoft/go-winio v0.6.0 // indirect  
> >
> > As others have mentioned on your ITP for that, it might not be necessary
> > in Debian — you need to determine which dependencies are really needed
> > (don’t look at go.mod or go mod graph, build the binary you’re interested
> > in and run "go version -m" on it).  
> 
> Thank you! Indeed, have to clean dependencies first.

Note that my comment above is over-simplistic — you obviously need binary
dependencies ("go version -m") but there can be other dependencies required
to build the package (e.g. test dependencies if you run the test suite, or
build tools which aren’t packaged yet).

Regards,

Stephen


pgp259ov9r_t5.pgp
Description: OpenPGP digital signature

Bug#1065378: ITP: libiir -- DSP IIR realtime filter library

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: libiir
  Version : 1.9.4
  Upstream Author : Bernd Porr
* URL : https://github.com/berndporr/iir1
* License : MIT
  Programming Lang: C++
  Description : DSP IIR realtime filter library

libiir is an infinite impulse response library implementing
Butterworth, RBJ, and Chebychev filters. The filter processes data
sample by sample for realtime processing.


This is a dependency of dosbox-staging. The GH repository is named
iir1 but internally the library refers to itself as iir (e.g. for
pkg-config). The current soname is libiir.so.1 so the library binary
package will end up being called libiir1.

Bug#1065664: ITP: smallerc -- single-pass C compiler for 16- and 32-bit platforms

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: smallerc
  Version : 1.0.1
  Upstream Author : Alexey Frunze
* URL : https://github.com/alexfru/SmallerC
* License : BSD
  Programming Lang: C
  Description : single-pass C compiler for 16- and 32-bit x86/MIPS platforms

Smaller C is a simple single-pass C compiler with support for most of
C89 and C99. It targets 16- and 32-bit x86, and MIPS, on DOS,
Windows, Linux, and older versions of macOS.
.
Smaller C is primarily useful for building DOS and UEFI binaries.


This is a prerequisite for dosemu2.

Bug#1065924: ITP: lfanew -- tool to manipulate MZ stubs in NE/PE binaries

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: lfanew
  Version : 0~20230825
  Upstream Author : TK Chia
* URL : https://codeberg.org/tkchia/lfanew
* License : MPL-2.0
  Programming Lang: C
  Description : tool to manipulate MZ stubs in NE/PE binaries

lfanew is a tool manipulating the e_lfanew header field in MZ (DOS)
binaries. It can
 - add a .e_lfanew field to an MZ binary, allowing it to be used as a
   DOS loader stub for a NE or PE binary;
 - stubify a NE/PE binary by combining it with an MZ stub;
 - extract a NE/PE binary from a stubified MZ/NE/PE binary pair.


This is required to build dosemu2.

Re: t64 suffix

[Stephen Kitt]

On Tue, 28 May 2024 11:00:34 +0200, Mathieu Malaterre 
wrote:
> On Mon, May 27, 2024 at 10:26 PM Steve Langasek  wrote:
> > On Thu, May 23, 2024 at 08:14:20PM +0200, Mathieu Malaterre wrote:  
> > > 2. Keep the package-name-doesnt-match-sonames lintian warning (for now)
> > > ?  
> >
> > What package are you seeing such a warning on?  The mass-NMUs included a
> > lintian override to suppress this warning.  
> 
> I think I am missing something big here...anyway here it goes:
> 
> * https://udd.debian.org/lintian/?packages=highway
> 
> (I'll fix the symbols-file-contains-current-version-with-debian-revision
> asap).

The output there indicates that the override added in
https://salsa.debian.org/debian-phototools-team/highway/-/commit/9c4e2b47532c2f8aa781cfd0d11764cc54324e81
doesn’t take into account all the libraries shipped in the package; all you
need to do is update the override to

libhwy1t64: package-name-doesnt-match-sonames libhwy-contrib1 libhwy-test1 
libhwy1

That will fix both warnings.

Regards,

Stephen


pgpbcyJw2RYKI.pgp
Description: OpenPGP digital signature

Bug#978711: ITP: etherdfs-server -- Ethernet DOS File System server

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: etherdfs-server
  Version : 0~20180203
  Upstream Author : Mateusz Viste
* URL : http://etherdfs.sf.net/
* License : MIT
  Programming Lang: C
  Description : Ethernet DOS File System server

 EtherDFS is a DOS installable filesystem, mapping a DOS drive letter
 to a remote share. This package contains the server side of EtherDFS,
 a daemon exporting one or more directories for remote access by the
 EtherDFS DOS TSR.

Bug#978725: ITP: ethflop -- Ethernet DOS floppy emulator

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: ethflop
  Version : 20191003
  Upstream Author : Mateusz Viste
* URL : http://ethflop.sourceforge.net
* License : ISC
  Programming Lang: C, x86 assembly
  Description : Ethernet DOS floppy emulator

 ethflop is a network-backed floppy emulator for DOS, mapping a DOS
 floppy drive to a remote disk image. This package contains the server
 and the DOS TSR.

Bug#979109: ITP: loggedfs -- Logging file system

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: loggedfs
  Version : 0.9
  Upstream Author : Rémi Flament
* URL : http://rflament.github.io/loggedfs/
* License : Apache-2.0
  Programming Lang: C++
  Description : Logging file system

 LoggedFS is a logging file system which can log every operation
 happening in it. It mounts transparently over any directory and logs
 operations inside that directory (and its children).
 .
 The amount of logging is configurable, and since LoggedFS uses FUSE,
 it can be controlled by users without system administrator
 involvement.

Bug#986918: ITP: key-mapper -- Input device button mapping tool

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: key-mapper
  Version : 0.8.1-1
  Upstream Author : sezanzeb
* URL : https://github.com/sezanzeb/key-mapper
* License : GPL-3+
  Programming Lang: Python
  Description : Input device button mapping tool

 key-mapper allows users to map buttons on all input devices
 (keyboards, mice, gamepads...) in X11 and Wayland. It also supports
 combined buttons and programmable macros.
 .
 key-mapper includes a UI to configure button mappings, per device,
 and configuration to automatically apply button mappings at boot and
 on device connection.

This will be maintained in the Python team, and perhaps with help from
upstream (see https://github.com/sezanzeb/key-mapper/issues/40).

Re: Raising the epoch of the 'prboom-plus' package, turning it into a transitional package

[Stephen Kitt]

Hi Fabian,

Le 23/08/2021 10:53, Fabian Greffrath a écrit :

in the short term, I'd like to replace the prboom-plus Doom engine in
Debian with its more actively developed fork dsda-doom. While
developement of the former has mostly stagnated (granted, it had its
2.6.1um release earlier this month), the latter pioneered with new
features like the introduction of the MBF21 modding standard and
DSDehacked (aka unlimited everything). Apart from that, it also keeps
demo compatibility as its highest goal, has added support for Heretic
and Hexen and has the vibrant DSDA speedrunning community behind it.

The downside is that dsda-coom introduced a new versioning scheme which
is currently at v0.21.0, whereas prboom-plus is already at 2.6.1um. To
provide for an easy upgrade path for prboom-plus users, I'd like to
introduce the dsda-doom package with an epoch. Since prboom-plus
already has epoch 2, this would necessarily be epoch 3.


I might be missing something, but I don’t think a new package needs an 
epoch just because it is intended to replace an existing package with an 
epoch. The dsda-doom source package could be versioned at 0.21.0, 
building a 0.21.0 dsda-doom package and a 2:whatever (later than 
2.6.1um) or 3:0.21.0 prboom-plus transitional package.


Regards,

Stephen

Re: Wine MinGW system libraries

[Stephen Kitt]

Hi Zebediah,

On Sat, 4 Sep 2021 20:17:53 -0500, Zebediah Figura 
wrote:
> I'm a contributor to the Wine project. To summarize the following mail, 
> Wine needs special versions of some of its normal dependencies, such as 
> libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm 
> sending out a mail to major distributions in order to get some feedback 
> from our packagers on how these should be built and packaged.
> 
> For a long time Wine has built all of its Win32 libraries (DLLs and 
> EXEs) as ELF binaries. For various reasons related to application 
> compatibility, we have started building our binaries as PE instead, 
> using the MinGW cross-compiler. It is our intent to expand this to some 
> of our dependencies as well. The list of dependencies that we intend to 
> build using MinGW is not quite fixed yet, but we expect it to include 
> and be mostly limited to the following:
> 
> * libvkd3d
> * libFAudio
> * libgnutls
> * zlib (currently included via manual source import)
> * libmpg123
> * libgsm
> * libpng
> * libjpeg-turbo
> * libtiff
> * libfreetype
> * liblcms2
> * jxrlib
> 
> and dependencies of the above packages (not including CRT dependencies, 
> which Wine provides).
> 
> There is currently some internal discussion about how these dependencies 
> should be built and linked. There are essentially three questions I see 
> that need to be resolved, and while these resolutions have a significant 
> impact on the Wine building and development process, they also have an 
> impact on distributions, and accordingly I'd like to get input from our 
> packagers to ensure that their considerations are accurately taken into 
> account.
> 
> (1) Should we build via source import, or link statically, or dynamically?
> 
> Source imports are dispreferred by Debian [1], on the grounds that they 
> cause duplication of libraries on disk and in memory, and make it harder 
> to handle security updates. They also make building and bisecting 
> harder. Static libraries don't seem to be expressly discouraged, but 
> share most of the same downsides (see also [2]).
> 
> Note however that if they are linked dynamically, we need to make sure 
> that we load our packages instead of MinGW builds of open-source 
> libraries with applications ship with. There's some internal discussion 
> about whether this is possible while using "stock" builds of MinGW 
> libraries, but, due to the way the Win32 loader works, we will probably 
> need to compile each library, and its dependencies, with a separate, 
> wine-specific name, e.g. "libwinefreetype-6.dll" and 
> "libwineharfbuzz.dll". For a detailed explantion see footnote [3]. Note 
> that all we actually need to change is the name; we don't need to patch 
> the source.

Assuming Debian provides the dependencies (which is currently true only for
zlib), this could be handled in packaging by providing symlinks, couldn’t it?
Not in the Wine prefixes, but elsewhere.

(The Wine team also maintains libvkd3d and libFaudio, so we can take care of
those at least.)

> Accordingly, although static linking and source imports are generally 
> disprefered, it may quite likely be preferable in our case. We don't get 
> the benefits of on-disk deduplication, since Wine is essentially the 
> only piece of software which needs these libraries.
> 
> (2) If we use dynamic libraries, should dependencies be included in the 
> main wine package, or packaged separately?
> 
> This is mostly a question for packagers, although it also relates to (3).
> 
> I expect that Debian will want to answer "packaged separately" here, on 
> the grounds that this lets them update (say) Wine's libgnutls 
> separately, and in sync with ELF libgnutls, if some security fix is 
> needed. There is a snag, though: we need libraries to be copied into the 
> prefix (there's some internal effort to allow using something like 
> symlinks instead, but this hard and not done yet). Normally we perform 
> this copy every time Wine is updated, but if Wine and its dependencies 
> aren't updated on the same schedule, we may end up loading an old 
> version of a dependency in the prefix.

Debian packaging doesn’t touch anything in users’ home directories, so this
would have to be handled in Wine itself, perhaps in a similar fashion to
existing provisions for Gecko and Mono.

> (3) If dependencies are packaged separately, should Wine build them as 
> part of its build tree (e.g. using submodules), or find and link 
> (statically or dynamically) to existing binaries?
> 
> Linking to existing binaries is generally preferable: it avoids 
> duplication on disk; it reduces compile times when compiling a single 
> package from source (especially the first time). However, we aren't 
> going to benefit from on-disk duplication. And, most importantly, unlike 
> with ELF dependencies, there is no standardized way to locate MinGW 
> libraries—especially if it comes to Wine-specific libraries. We would 
> need a way for Wine

Re: Wine MinGW system libraries

[Stephen Kitt]

Hi Bastien,

On Sun, 5 Sep 2021 08:53:49 +0200, Bastien ROUCARIES
 wrote:
> Le dim. 5 sept. 2021 à 03:34, Zebediah Figura  a
> écrit :
> > I'm a contributor to the Wine project. To summarize the following mail,
> > Wine needs special versions of some of its normal dependencies, such as
> > libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm
> > sending out a mail to major distributions in order to get some feedback
> > from our packagers on how these should be built and packaged.
> >
> > For a long time Wine has built all of its Win32 libraries (DLLs and
> > EXEs) as ELF binaries. For various reasons related to application
> > compatibility, we have started building our binaries as PE instead,
> > using the MinGW cross-compiler. It is our intent to expand this to some
> > of our dependencies as well. The list of dependencies that we intend to
> > build using MinGW is not quite fixed yet, but we expect it to include
> > and be mostly limited to the following:
> >
> > * libvkd3d
> > * libFAudio
> > * libgnutls
> > * zlib (currently included via manual source import)
> > * libmpg123
> > * libgsm
> > * libpng
> > * libjpeg-turbo
> > * libtiff
> > * libfreetype
> > * liblcms2
> > * jxrlib
> >
> > and dependencies of the above packages (not including CRT dependencies,
> > which Wine provides).
> >
> > There is currently some internal discussion about how these dependencies
> > should be built and linked. There are essentially three questions I see
> > that need to be resolved, and while these resolutions have a significant
> > impact on the Wine building and development process, they also have an
> > impact on distributions, and accordingly I'd like to get input from our
> > packagers to ensure that their considerations are accurately taken into
> > account.
> >
> > (1) Should we build via source import, or link statically, or dynamically?
> >
> > Source imports are dispreferred by Debian [1], on the grounds that they
> > cause duplication of libraries on disk and in memory, and make it harder
> > to handle security updates. They also make building and bisecting
> > harder. Static libraries don't seem to be expressly discouraged, but
> > share most of the same downsides (see also [2]).
> >
> > Note however that if they are linked dynamically, we need to make sure
> > that we load our packages instead of MinGW builds of open-source
> > libraries with applications ship with. There's some internal discussion
> > about whether this is possible while using "stock" builds of MinGW
> > libraries, but, due to the way the Win32 loader works, we will probably
> > need to compile each library, and its dependencies, with a separate,
> > wine-specific name, e.g. "libwinefreetype-6.dll" and
> > "libwineharfbuzz.dll". For a detailed explantion see footnote [3]. Note
> > that all we actually need to change is the name; we don't need to patch
> > the source.
> >
> > Accordingly, although static linking and source imports are generally
> > disprefered, it may quite likely be preferable in our case. We don't get
> > the benefits of on-disk deduplication, since Wine is essentially the
> > only piece of software which needs these libraries.
> >
> > (2) If we use dynamic libraries, should dependencies be included in the
> > main wine package, or packaged separately?
> >  
> 
> 
> Improve dpkg to support partial arch. I volonteer to implement none arch
> but i am waiting from guillem here.

Thanks for stepping up!

For MinGW-w64 dependencies, an additional requirement is figuring out a
solution for https://bugs.debian.org/606825;
https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F
gives additional context.

Regards,

Stephen


pgpHCEnwcfbXF.pgp
Description: OpenPGP digital signature

Re: Wine MinGW system libraries

[Stephen Kitt]

On Sun, 5 Sep 2021 12:14:47 -0500, Zebediah Figura 
wrote:
> On 9/5/21 11:19 AM, Stephen Kitt wrote:
> > On Sat, 4 Sep 2021 20:17:53 -0500, Zebediah Figura
> >  wrote:  
> >> I'm a contributor to the Wine project. To summarize the following mail,
> >> Wine needs special versions of some of its normal dependencies, such as
> >> libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm
> >> sending out a mail to major distributions in order to get some feedback
> >> from our packagers on how these should be built and packaged.
> >>
> >> For a long time Wine has built all of its Win32 libraries (DLLs and
> >> EXEs) as ELF binaries. For various reasons related to application
> >> compatibility, we have started building our binaries as PE instead,
> >> using the MinGW cross-compiler. It is our intent to expand this to some
> >> of our dependencies as well. The list of dependencies that we intend to
> >> build using MinGW is not quite fixed yet, but we expect it to include
> >> and be mostly limited to the following:
> >>
> >> * libvkd3d
> >> * libFAudio
> >> * libgnutls
> >> * zlib (currently included via manual source import)
> >> * libmpg123
> >> * libgsm
> >> * libpng
> >> * libjpeg-turbo
> >> * libtiff
> >> * libfreetype
> >> * liblcms2
> >> * jxrlib
> >>
> >> and dependencies of the above packages (not including CRT dependencies,
> >> which Wine provides).
> >>
> >> There is currently some internal discussion about how these dependencies
> >> should be built and linked. There are essentially three questions I see
> >> that need to be resolved, and while these resolutions have a significant
> >> impact on the Wine building and development process, they also have an
> >> impact on distributions, and accordingly I'd like to get input from our
> >> packagers to ensure that their considerations are accurately taken into
> >> account.
> >>
> >> (1) Should we build via source import, or link statically, or
> >> dynamically?
> >>
> >> Source imports are dispreferred by Debian [1], on the grounds that they
> >> cause duplication of libraries on disk and in memory, and make it harder
> >> to handle security updates. They also make building and bisecting
> >> harder. Static libraries don't seem to be expressly discouraged, but
> >> share most of the same downsides (see also [2]).
> >>
> >> Note however that if they are linked dynamically, we need to make sure
> >> that we load our packages instead of MinGW builds of open-source
> >> libraries with applications ship with. There's some internal discussion
> >> about whether this is possible while using "stock" builds of MinGW
> >> libraries, but, due to the way the Win32 loader works, we will probably
> >> need to compile each library, and its dependencies, with a separate,
> >> wine-specific name, e.g. "libwinefreetype-6.dll" and
> >> "libwineharfbuzz.dll". For a detailed explantion see footnote [3]. Note
> >> that all we actually need to change is the name; we don't need to patch
> >> the source.  
> > 
> > Assuming Debian provides the dependencies (which is currently true only
> > for zlib), this could be handled in packaging by providing symlinks,
> > couldn’t it? Not in the Wine prefixes, but elsewhere.  
> 
> Almost :-/
> 
> Copying/symlinking libfreetype-1.dll to libwinefreetype-1.dll is easy. 
> The problem is that libwinefreetype-1.dll is still going to link to 
> libharfbuzz-1.dll, but we need it to link to libwineharfbuzz-1.dll.

Ah yes, I hadn’t thought it through. So really Wine needs its own parallel
ecosystem of DLLs in any case, which effectively means building them along
with Wine (from Wine’s perspective, ignoring distribution constraints and
preferences).

> > This also works in Debian:
> > 
> > $ sudo apt install libz-mingw-w64-dev mingw-w64-tools
> > $ x86_64-w64-mingw32-pkg-config --libs zlib
> > -L/usr/x86_64-w64-mingw32/lib -lz  
> 
> Ah, cool, I looked for that and somehow missed it.
> 
> Note that's the wrong path for dynamic libraries, though; those go in 
> /usr/x86_64-w64-mingw32/bin/. We'll need a way to find those. Maybe 
> hardcoding a list won't be too painful, though...

In Debian they go in /usr/x86_64-w64-mingw32/lib currently, which is why
the .pc file points there. But as you point out, that doesn’t help at
runtime.

Also, having

Re: Wine MinGW system libraries

[Stephen Kitt]

On Sun, 12 Sep 2021 10:38:52 +0300, Adrian Bunk  wrote:

> On Sun, Sep 05, 2021 at 08:53:49AM +0200, Bastien ROUCARIES wrote:
> >...
> > Improve dpkg to support partial arch. I volonteer to implement none arch
> > but i am waiting from guillem here.
> >...  
> 
> There is also plenty of infrastructure on the buildd, archive and 
> release team sides that would likely need changes for supporting 
> anything like that.
> 
> A multilib based approach might be more realistic for bookworm.
> 
> What benefits would a "none arch" even bring compared to building
> binary-all packages?
> The ability to binNMU is the only one that comes into my mind.

IMO the main benefit of using multiarch would be that packages could be built
for the new architectures without changes (ideally). libz is currently built
for MinGW-w64 in an “Architecture: all” package, but it’s a separate source
package; various other libraries are built with specific support in their
source packages. While one could imagine adding support to all the appropriate
source packages to build similar “Architecture: all” packages, that would
require convincing all the relevant maintainers, and it would end up tying
the testing migrations to MinGW-w64...

In this scenario the solution wouldn’t be a “none” arch, but a Windows arch,
if we can ever resolve https://bugs.debian.org/606825

The buildd situation isn’t necessarily that much of an obstacle: it seems to
me we could have “Windows” buildds which are really Linux amd64 systems, that
cross-build for Windows.

Regards,

Stephen


pgpgVleJyWbI1.pgp
Description: OpenPGP digital signature