Re: pcsc-cyberjack needs update to support more apparatus Germany oriented.
On Wed, 18 Sep 2024 11:52:23 +, benatt...@gezapig.nl wrote: > I am not personally interested. > > This is the place I suppose to put such when > suspect a maintainer is not maintaining. > > Thus someone could look into that situation. debian-devel isn’t the right place for this, as has already been explained. If you think that a maintainer is MIA, the right place to communicate that is the MIA team; see https://wiki.debian.org/Teams/MIA for details. If you have noticed that a package is out-of-date, the right place to communicate that is the bug tracker; check the package’s existing bugs to make sure there isn’t already a “new version available” bug, and if there isn’t, file a wishlist bug. > It can't in these cases just wait a couple of years before updating. Debian is built by volunteers; sometimes people’s priorities change, other aspects of life take precedence, etc. Regards, Stephen pgpQH6ADo5fdM.pgp Description: OpenPGP digital signature
Re: Bug#1080344: ITP: bcachfs-tools -- bcachefs userspace tools
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: Intent to MBF: move from fuse to fuse3
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: Strange armel build error
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
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: Bug#1076583: ITP: minio-client -- Simple, fast tool to manage MinIO clusters
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
Bug#1074057: ITP: djstub -- DJGPP-compatible stub manipulation tools
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.
Bug#1073181: ITP: thunk-gen -- 64-bit thunk generator for 16- and 32-bit code
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.
Re: t64 suffix
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#1065924: ITP: lfanew -- tool to manipulate MZ stubs in NE/PE binaries
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.
Bug#1065664: ITP: smallerc -- single-pass C compiler for 16- and 32-bit platforms
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#1065378: ITP: libiir -- DSP IIR realtime filter library
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.
Re: ITP: golang-github-esiqveland-notify -- notify is a go dbus implementation for delivering desktop notifications over dbus
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
Re: ITP: golang-github-esiqveland-notify -- notify is a go dbus implementation for delivering desktop notifications over dbus
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: Mass bug filing / call for testing: dependencies on SDL 1.2
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: Mass bug filing / call for testing: dependencies on SDL 1.2
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
Bug#1037228: ITP: pycrc -- CRC C source code generator
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: Using i386 by mistake on 64-bit hardware [was Re: i386 in the future 32-bit archs: a proposal)]
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#1028050: ITP: pyqt6-charts -- Python 3 bindings for Qt6's Charts module
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pyqt6-charts Version : 6.4.0 Upstream Author : Riverbank Computing * URL : https://riverbankcomputing.com/software/pyqtchart/ * License : GPL-3 Programming Lang: C++ Description : Python 3 bindings for Qt6's Charts module The Charts module of PyQt6 provides widgets and utility classes for chart rendering in a PyQt6 application. This will be maintained in the Debian Python team.
Bug#1022800: ITP: dosbox-x -- DOS emulator with complete, accurate hardware emulation
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: dosbox-x Version : 0.84.3 Upstream Author : Jonathan Campbell * URL : https://dosbox-x.com/ * License : GPL-2+ Programming Lang: C, C++ Description : DOS emulator with complete, accurate hardware emulation DOSBox-X is a comprehensive DOS emulator, supporting DOS applications including Windows 3.x and Windows 9x, and striving to provide accurate hardware emulation. It is based on the original DOSBox and includes features from a number of forks including SVN Daum, ECE, DOSBox Staging, DOSVAX, and vDosPlus. Its features include: * a built-in drop-down menu * a graphical configuration tool * support for save-states * NEC PC-98, AX, and J-3100 emulations * DOS/V support for Chinese, Japanese, and Korean language support * support for CONFIG.SYS commands * printing support * long filename support * DOS SHARE emulation * wheel mouse support (including the CuteMouse wheel mouse API) * 3Dfx Voodoo chip and Glide emulation * NE2000 emulation * MT-32 emulation DOSBox-X isn't a direct upgrade from DOSBox, but DOSBox users should be able to use DOSBox-X without difficulty.
Re: proposed MBF: packages still using source format 1.0
On Mon, 14 Mar 2022 13:52:14 +, Holger Levsen wrote: > On Mon, Mar 14, 2022 at 01:10:19PM +, Wookey wrote: > > > You're trying to produce packages from CI builds or other automation > > > where you sometimes have native Debian revisions. > > > > > > * you are producing a package where you have distinct upstream and > > > debian branches, and you cannot control the upstream version number. > > > > > > > Doesn't this make it 'not a native debian package'? > > yes, exactly, that's the problem. > > > I thought the whole point of debian native packages was that there was > > no 'upstream' and it was only for debian so you _are_ in control of > > the source, the versioning and the releases? > > yes, that was the idea when native packages were introduced over > 20 ago, when there were hardly any Debian forks, and certainly no > CI systems and other automated systems which 'constantly fork'. > > > As soon as that stops > > being true then should one not shift to making it a standard > > 'upstream+debian revision' non-native package? > > yes, we should convert all native packages in our archive, > the idea of a native package has been obsoleted for long. I think there are still some cases where it makes sense, e.g. for “meta-source” packages where the upstream is really another package (e.g. binutils-mingw-w64 and friends). Suffixes for downstreams work fine, see https://launchpad.net/ubuntu/+source/gdb-mingw-w64 for one instance. Regards, Stephen pgpf7WU3HcrNr.pgp Description: OpenPGP digital signature
Re: Bug#1006885: ITP: lumin -- pattern match highlighter
On Mon, 07 Mar 2022 20:29:12 +0100, Vincent Bernat wrote: > ❦ 7 March 2022 18:33 +01, Adam Borowski: > >> lumin highlights matches to a specified pattern (string or regular > >> expression) in files, using color. This is similar to grep with > >> colorized output, but it outputs all lines in the given files, not > >> only matching lines. > > > > .--[ ~/bin/hl ] > > #!/bin/sh > > sed 's/'"$*"'/\c[[1;33m&\c[[0m/g' > > ` > > grep --color -C4000 pattern > > There are other suggestions here: > https://stackoverflow.com/questions/981601/colorized-grep-viewing-the-entire-file-with-highlighted-matches Thanks, I’m aware that the program itself isn’t all that useful (or at least, can be replaced by trivial scripts); it’s been added as a dependency of Miller, which is very useful. I’m planning on suggesting alternatives for Miller itself, but I would like to get the new version of Miller in the archive in the meantime! Regards, Stephen pgpP5BrSfhlzv.pgp Description: OpenPGP digital signature
Bug#1006886: ITP: gocc -- Go lexer and parser generator
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: gocc Version : 0.0~git20211213.7ea6993 Upstream Author : Marius Ackerman * URL : https://github.com/goccmack/gocc * License : ASL-2.0 Programming Lang: Go Description : Go lexer and parser generator Gocc generates lexer-parser pairs or stand-alone DFAs or parsers from a Backus-Naur form (BNF). The generated lexers are deterministic finite automata (DFAs), recognising regular languages. The generated parsers are pushdown automata (PDAs), recognising LR(1) languages. Optional LR(1) conflict handling automatically resolves shift/reduce and reduce/reduce conflicts. This is a new dependency of Miller 6.1.0.
Bug#1006885: ITP: lumin -- pattern match highlighter
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: lumin Version : 1.0.0 Upstream Author : John Kerl * URL : https://github.com/johnkerl/lumin * License : BSD-2-clause Programming Lang: Go Description : pattern match highlighter lumin highlights matches to a specified pattern (string or regular expression) in files, using color. This is similar to grep with colorized output, but it outputs all lines in the given files, not only matching lines. This is a new dependency of Miller 6.1.0.
Bug#1002859: ITP: golang-github-lestrrat-go-envload -- environment variable manipulation library
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-lestrrat-go-envload Version : 0.0~20180221 Upstream Author : Daisuke Maki * URL : https://github.com/lestrrat-go/envload * License : MIT Programming Lang: Go Description : environment variable manipulation library This library provides functions to store, modify, and restore environment variables. This is useful for example to temporarily change values of environment variables for tests, as doable for example with Perl 5’s local variables. This is required for lestrrat-go-strftime. I’m planning on maintaining this within the Go packaging team.
Bug#1002858: ITP: golang-github-lestrrat-go-strftime -- fast strftime implementation for Go
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-lestrrat-go-strftime Version : 1.0.5 Upstream Author : Daisuke Maki * URL : https://github.com/lestrrat-go/strftime * License : MIT Programming Lang: Go Description : fast strftime implementation for Go This is a Go implementation of strftime, optimised for pattern re-use, and with support for as many conversion specifications as possible. It aims for POSIX compliance while still including widely-used non-POSIX format specifications such as "%f" or "%L" for milliseconds. This is required for the new Go version of Miller. I’ll be asking to join the Go packaging team to maintain this there.
Re: Wine MinGW system libraries
On Sun, 12 Sep 2021 20:54:56 +0300, Adrian Bunk wrote: > On Sun, Sep 12, 2021 at 07:03:54PM +0200, Stephen Kitt wrote: > > On Sun, 12 Sep 2021 19:20:16 +0300, Adrian Bunk wrote: > > > On Sun, Sep 12, 2021 at 05:31:41PM +0200, Stephen Kitt wrote: > > > >... > > > > 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, > > > > > > Adding a new release architecture (partial or not) requires convincing > > > the ftp team and the release team. > > > > > > It would also require many software changes. > > > > Yes, it would. However, it requires convincing a well-defined set of > > people *once*. If we handle Windows dependencies using “Architecture: > > all” packages, we would either end up with something like Fedora’s > > MinGW-w64 SIG (with a complete set of independent packages), or we would > > end up having to convince a huge set of package maintainers over and over > > again. > > Based on the package list provided in the initial email in this thread > (and guessing the amount of transitive dependencies) I would have guessed > that there are perhaps ~ 30 packages that would have to be touched once. ... which means ~30 maintainers who need convincing individually. My experience so far is that maintainers tend not to be interested (justifiably) in Windows cross-builds. > And after that things will just continue working, just like with udebs > which are in some ways similar to what is being discussed here. udebs are mostly a packaging concern. Keeping Windows cross-builds working tends to require a bit more effort unfortunately. > > > How would for example the dependencies of wine:amd64 be fulfilled? > > > > > > Just supporting that package dependencies might only be fulfilled by > > > also using packages from a different architecture would require changes > > > in many places, like for example the testing migration scripts that > > > ensure installability after migration. > > > > In the same way as the none-arch packages would be. Yes, it’s a lot of > > work, but it’s useful for more than just Wine, and it can be done once > > for all the interested architectures. > > It is also the kind of change where it might be required that it is > fully supported in one release before it can be used by packages in the > next release, if for example any of dpkg/apt/aptitude/... in the > previous stable gives an error when seeing dependencies to another > architecture. That is indeed a good point, thanks for bringing it up! Regards, Stephen pgp6oea3PS5Hm.pgp Description: OpenPGP digital signature
Re: Wine MinGW system libraries
On Mon, 13 Sep 2021 17:39:25 +0200, Helmut Grohne wrote: > I believe I can speak with my "main cross building porter" hat on. > > On Sun, Sep 12, 2021 at 01:57:44PM +, Bastien ROUCARIES wrote: > > They are a full color gradiant between: > > - freestanding arches pure cross compile without any depends except > > arch:all > > - partial cross built arch > > - partial arch > > - full arch > > > > I believe the first step to get partial cross built arch is to begin > > by freestanding arch. > > Certainly not. As much as I would love to see this happen, it is very > unrealistic. wine can quite simply use -$arch-cross:all packages like > very other bare metal target and switch to our pipe dream once it is > ready (if ever). And even that assumes that we can get agreement on what $arch should be for Windows targets :-(. > cross building is very far off becoming the thing you want it to be. It > presently has a bus factor of around 1.5. Around 59% of source packages > are cross-satisfiable. Around 78% of cross-satisfiable packages are > cross buildable. In other words: less than 50% of packages are cross > buildable. Beyond that, the cross porters cannot keep up with the > current rate of regressions. Fractions are falling. The bus factor is indeed a problem. For Wine (and even a wider MinGW-w64 ecosystem) we don’t need all that many source packages to be cross-satisfiable for the whole endeavour to be useful... The regressions are significant though: if packages can’t stay cross-satisfiable for Debian cross-targets, there’s little hope they can stay cross-satisfiable for Windows! This means that separate source packages are probably the only viable option. > To make cross building a viable thing we'd need at least three more > porters determined to make it happen. Talk doesn't make it happen. > Patches do. Let me know if you want to help. I'll get you started. Is the process documented anywhere? Or does one simply pick a failure from http://crossqa.debian.net and figure out what’s going wrong (and hope that pulling the threads doesn’t reveal a monster...)? Regards, Stephen pgpCQ0PLoIbRU.pgp Description: OpenPGP digital signature
Re: Wine MinGW system libraries
On Sun, 12 Sep 2021 19:20:16 +0300, Adrian Bunk wrote: > On Sun, Sep 12, 2021 at 05:31:41PM +0200, Stephen Kitt wrote: > >... > > 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, > > Adding a new release architecture (partial or not) requires convincing > the ftp team and the release team. > > It would also require many software changes. Yes, it would. However, it requires convincing a well-defined set of people *once*. If we handle Windows dependencies using “Architecture: all” packages, we would either end up with something like Fedora’s MinGW-w64 SIG (with a complete set of independent packages), or we would end up having to convince a huge set of package maintainers over and over again. > How would for example the dependencies of wine:amd64 be fulfilled? > > Just supporting that package dependencies might only be fulfilled by > also using packages from a different architecture would require changes > in many places, like for example the testing migration scripts that > ensure installability after migration. In the same way as the none-arch packages would be. Yes, it’s a lot of work, but it’s useful for more than just Wine, and it can be done once for all the interested architectures. > > and it would end up tying the testing migrations to MinGW-w64... > > If this partial arch (and Wine) should be part of Debian releases, > then testing migrations would have to be tied to it in any case. True, I’d missed that. (In my mind I was comparing this with having separate source packages.) > >... > > 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. > > The first obstacle is that if you want to be the first who does cross > building packages on the buildds, there is likely a lot of work and > bugfixing ahead for you for getting that working. A lot of that work has already been done for http://crossqa.debian.net/ Fixing this would reduce the burden on all the maintainers who currently handle cross-built packages in the archive, so overall I think it would be a net win. Regards, Stephen pgpnUkwnkb6Zl.pgp Description: OpenPGP digital signature
Re: Wine MinGW system libraries
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
Re: Wine MinGW system libraries
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
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
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: Raising the epoch of the 'prboom-plus' package, turning it into a transitional package
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
Bug#986918: ITP: key-mapper -- Input device button mapping tool
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).
Bug#979109: ITP: loggedfs -- Logging file system
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#978725: ITP: ethflop -- Ethernet DOS floppy emulator
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#978711: ITP: etherdfs-server -- Ethernet DOS File System server
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#961866: ITP: gztool -- gzip-compressed file indexer
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: gztool Version : 0.11.2 Upstream Author : Roberto S. Galende * URL : https://github.com/circulosmeos/gztool/ * License : zlib Programming Lang: C Description : gzip-compressed file indexer gztool indexes gzip-compressed files, allowing them to be accessed randomly (instead of from the beginning). It can index existing files, which takes as much time as decompressing the file entirely; it can also compress and decompress files itself, creating optimised indexes as it goes. . Other features include: - watch and index a gzip-compressed file as it is created; - partially extract a gzip-compressed file; - tail a gzip-compressed file (including follow mode).
Re: General Resolution: Init systems and systemd: First call for votes
On Fri, 13 Dec 2019 15:32:32 +0100, Stephen Kitt wrote: > > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- So it turns out Claws Mail does weird things with Reply-To and mailing lists... (Incidentally, that wasn’t my final ballot.) Sorry for the noise, Stephen pgprHHq4uaRFJ.pgp Description: OpenPGP digital signature
Re: General Resolution: Init systems and systemd: First call for votes
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > 7b77e0f2-4ff9-4adb-85e4-af249191f27a > [ 3 ] Choice 1: F: Focus on systemd > [ 1 ] Choice 2: B: Systemd but we support exploring alternatives > [ ] Choice 3: A: Support for multiple init systems is Important > [ ] Choice 4: D: Support non-systemd systems, without blocking progress > [ 2 ] Choice 5: H: Support portability, without blocking progress > [ ] Choice 6: E: Support for multiple init systems is Required > [ ] Choice 7: G: Support portability and multiple implementations > [ 4 ] Choice 8: Further Discussion > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- pgpdThpp1TNpG.pgp Description: OpenPGP digital signature
Bug#935803: ITP: binutils-djgpp -- cross-binutils for DOS using DJGPP
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: B-D on src package? (was: Re: Challenge from Julia's non-standard vendored openblas"64_"
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
Re: B-D on src package? (was: Re: Challenge from Julia's non-standard vendored openblas"64_"
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: Options for 64-bit time_t support on 32-bit architectures
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
Bug#928446: ITP: nulib2 -- NuFX and Binary II archive utility
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...
Bug#924048: ITP: shockolate -- System Shock game engine
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.
Re: sarge bo rex
Hi, On Sun, 24 Jun 2018 18:10:49 +0200, Geert Stappers wrote: > What is the sequence of Debian release names? > > Which Debian web page contains such list? See https://wiki.debian.org/DebianReleases for a complete list. Regards, Stephen pgpgdogVQz8L8.pgp Description: OpenPGP digital signature
Bug#901443: ITP: infnoise -- Infinite Noise TRNG driver and tools
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: infnoise Version : 0.2.6 Upstream Author : Manuel Domke * URL : https://github.com/13-37-org/infnoise * License : public domain Programming Lang: C Description : Infinite Noise TRNG driver and tools This package contains the driver for the Infinite Noise TRNG, enabling it automatically upon insertion and allowing the entropy it generates to be added to the system's entropy pool. It also includes the various tools available in the Infinite Noise repository, including the health check tool.
Bug#895156: ITP: easyloggingpp -- single-header logging library for C++ applications
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: easyloggingpp Version : 9.96.4 Upstream Author : Muflihun Labs * URL : https://muflihun.github.io/easyloggingpp/ * License : MIT Programming Lang: C++ Description : single-header logging library for C++ applications Easylogging++ is a light-weight, high performance logging library for software written in C++11 and higher. It is highly configurable and extensible, supports both severity- and verbosity-based logging, provides crash handling, STL logging, integration with syslog, log rotation, performance-specific logging for profiling, pointcut-style extensions of third-party code... I’m packaging this as a pre-requisite for loggedfs.
Bug#887309: ITP: libevdev-python -- Python wrapper for libevdev
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: libevdev-python Version : 0.2 Upstream Author : Peter Hutterer * URL : https://github.com/whot/libevdev-python * License : MIT Programming Lang: Python Description : Python wrapper for libevdev This is a Python wrapper around libevdev, a wrapper library for evdev devices. It provides a simpler API around evdev and takes advantage of libevdev’s advanced event handling, providing * access to the state of the device (not just the events) * correct handling of fake multitouch devices * synchronisation of slots and per-slot state * transparent generation of missing tracking ids * per-context event handling This package will end up being used by libratbag, piper etc., instead of python-evdev.
Re: Too many Recommends (in particular on mail-transport-agent)
On Sun, 11 Jun 2017 06:12:23 +, Ivan Shmakov wrote: > > Adam Borowski writes: > > gfortran-mingw-w64: gcc-mingw-w64 > > > * BAD: seriously, Fortran? > > Fortran is still widely used (in niche applications; WRF comes > to mind), but I see no good reason for this dependency. Backwards-compatibility, gcc-mingw-w64 used to include the Fortran compiler. I meant to leave the Recommends there for one cycle and remove it, but forgot — it will be gone in Buster. > > gnat-mingw-w64: gcc-mingw-w64 > > > * BAD: see Fortran. > > Agreed. See above. Regards, Stephen pgptw6LGk16se.pgp Description: OpenPGP digital signature
Re: Bug#858916: ITP: kytos -- conceived to ease SDN controllers development and deployment
Hi Paulo, On Tue, 28 Mar 2017 16:19:08 -0300 (BRT), Paulo Henrique de Lima Santana wrote: > - Mensagem original - > > De: "Stephen Kitt" > > > > This doesn't help understand what the kytos package is and/or contains, at > > all... (And I work on SDNs, so imagine what it's like for people who > > aren't familiar with the field). > > Yes, after I sent the ITP, the upstreams improved the description and I > will use this new description on the control file. Should I fix the ITP? Or > it is not necessary? It's not necessary, no, although it would be nice ;-). (Simply reply to the bug with the revised description.) Note that you don't need to depend on upstream for a description; in fact you should really write your own, from a Debian perspective. See https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-desc-basics for more information. Regards, Stephen pgpLgACz1gXlg.pgp Description: OpenPGP digital signature
Re: Bug#858916: ITP: kytos -- conceived to ease SDN controllers development and deployment
On Tue, 28 Mar 2017 12:55:38 -0300, "Paulo Henrique de Lima Santana (phls)" wrote: > Description : conceived to ease SDN controllers development and > deployment It was motivated by some gaps left by common SDN solutions. > Moreover, it has strong tights with a community view, so it is centered on > the development of applications by its users. Thus, our intention is not > only to build a new SDN solution, but also to build a community of > developers around it, creating new applications that benefit from the > SDN paradigm. > . > The project was born in 2014, when the first version of the message > parsing library was built. After some time stalled, the development > took off in earlier 2016. This doesn't help understand what the kytos package is and/or contains, at all... (And I work on SDNs, so imagine what it's like for people who aren't familiar with the field). Regards, Stephen pgpzDAcExFltf.pgp Description: OpenPGP digital signature
Re: SPAM
On Mon, 6 Mar 2017 11:15:23 -0500, Christopher Clements wrote: > On Mon, Mar 06, 2017 at 05:01:40PM +0100, Philip Hands wrote: > >However, because the spam meaasges are created by copying most of the > >headers from a genuine list mail, when you reply to such a message, it > >turns up on our lists, and looks like it might even be a reply to a real > >thread (until you notice that the body of the message they were replying > >to has never previously been seen on the list). > > Wow. > This is the exact reason I sign all my messages. > > Thanks for proving that I'm not _overly_ paranoid! Signatures don't protect you in this case, because they only cover the message body, not even the headers. This also means that signing *everything* isn't necessarily a good idea: if you sign a re-usable message body, anyone can re-send that body and your signature with different headers (different subject, different apparent sender and recipients) and a different envelope (different real sender and recipients). Regards, Stephen pgpJRqBOKqbyL.pgp Description: OpenPGP digital signature
Bug#856158: ITP: g810-led -- LED configuration tool for Logitech G410/G610/G810/G910 keyboards
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: g810-led Version : 0.1.0 Upstream Author : MatMoul * URL : https://github.com/MatMoul/g810-led * License : GPL-3 Programming Lang: C++ Description : LED configuration tool for Logitech Gx10 keyboards g810-led is a configuration tool for the LEDs on Logitech Gx10 gaming keyboards: G410, G610, G810 and G910. The LEDs can be configured in a variety of ways, depending on the keyboards' capabilities: * pre-defined effects (breathing, colour-cycling, waves) * individual key colours and/or intensities * key group colours and/or intensities
Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
On Sun, 11 Dec 2016 09:14:09 +0100, Marc Haber wrote: > And, while we're at it, how is "locale" pronounced? I have a native > speaker in my filter bubble who claims that it's short for "local > environment" and therefore pronounced "local e", but that sounds wrong > for me. Is the example pronouncement given on > http://dict.leo.org/dictQuery/m-vocab/ende/de.html?searchLoc=0&lp=ende&lang=de&directN=0&rmWords=off&search=locale&resultOrder=basic&multiwordShowSingle=on > correct even in AmE? Yes, locale isn't a neologism; it refers to a place: https://www.merriam-webster.com/dictionary/locale The pronunciation given on LEO is correct. Regards, Stephen pgpazyIkvLdan.pgp Description: OpenPGP digital signature
Re: removal instead of orphaning?
On Sun, 18 Sep 2016 15:39:38 +0100, "Adam D. Barratt" wrote: [...] > In order to determine whether a particular upload is "descended" from > any other previous upload, the information used by the BTS is generated > by parsing changelogs and building a tree of uploads, with each stanza > being considered as the descendent of the stanza prior to it. This is > why an upload that does not include the changelog stanza from an NMU > will cause the BTS to consider that any bugs closed in the NMU have been > subsequently reintroduced in the later upload. Thanks, I didn't know about that — that's rather nifty! Regards, Stephen pgp3xKpsQtxIf.pgp Description: OpenPGP digital signature
Re: removal instead of orphaning?
On Sun, 18 Sep 2016 11:28:55 +0100, "Adam D. Barratt" wrote: > On Sun, 2016-09-18 at 11:45 +0200, Marc Haber wrote: > > So when I do the first upload after an NMU all bugs that the BTS has > > as "fixed in NMU" get changed to "closed"? > > "Fixed in NMU" has not been a distinct state for several years, since > the introduction of BTS version tracking. The NMU upload simply marks > the bugs as closed in the version of that upload, the same as it would > for any other upload. > > If your next maintainer upload includes the changelog stanza for the NMU > in its changelog then the BTS will automatically know that your upload > includes those fixes, without your mentioning them in your own stanza > for your upload. Doesn't it just consider that any version after the "fixed" version contains the fixes? Otherwise I thought you'd need to specify the appropriate -v option. There are still cases sometimes of NMU changes being ommitted from the following maintainer upload, so "fixed in NMU" could still be a meaningful state. Admittedly patches get dropped accidentally between maintainer uploads sometimes too, so the distinction isn't all that important... Regards, Stephen pgpAZAA3tesnU.pgp Description: OpenPGP digital signature
Re: Is missing SysV-init support a bug?
On Fri, 2 Sep 2016 05:30:10 +0200, Adam Borowski wrote: > What "wide range of terminals that /can/ /do/ /italics/" do you mean? > > Let's see, printf 'a\e[3mb\e[0mc\n' (b should be italic, a and c should not) > * linux console:- (text does nothing, fb makes it green) > * xfce4-terminal: - > * lxterminal: - > * xterm:✓ > * rxvt-unicode: - > * pterm - > * cool-retro-term: - > And out of Debian: > * osso-xterm: - > * putty:- > * win10 console:- > * Solaris console: - > * OpenBSD console: - (text) FWIW, GNOME Terminal also supports italics. Regards, Stephen pgprG2KYR0Rgf.pgp Description: OpenPGP digital signature
Bug#834010: ITP: ddcci-linux -- DDC/CI driver
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: ddcci-linux Version : 0.2 Upstream Author : Christoph Grenz * URL : https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux * License : GPL-2.0+ Programming Lang: C Description : DDC/CI driver This set of kernel modules provide a DDC/CI driver for compatible monitors, and integration into the backlight system class. With the latter, many desktop environments can control the backlight on external monitors.
Bug#833002: ITP: mednaffe -- front-end for the Mednafen multi-system emulator
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: mednaffe Version : 0.8 Upstream Author : AmatCoder * URL : https://github.com/AmatCoder/mednaffe * License : GPL-3+ Programming Lang: C Description : front-end for the Mednafen multi-system emulator Mednaffe is a graphical front-end for the Mednafen multi-system emulator. It allows all of Mednafen's options to be configured, and provides simple game-management features. This will be packaged under the game team's umbrella. Regards, Stephen
Bug#816838: ITP: ratbagd -- d-bus daemon handling mouse configuration
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: ratbagd Version : 0.0.2 Upstream Author : Red Hat, Inc. * URL : https://github.com/libratbag/ratbagd * License : MIT Programming Lang: C, Python Description : d-bus daemon handling mouse configuration ratbagd provides access over d-bus to mouse settings exposed by libratbag, such as DPI and button mappings on gaming mice. This is a dependency of piper, a GUI for configuring gaming mice.
Bug#816836: ITP: piper -- gaming-oriented mouse configuration GUI
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: piper Version : 0.1 Upstream Author : Peter Hutterer * URL : https://github.com/libratbag/piper * License : GPL-2+ Programming Lang: Python Description : gaming-oriented mouse configuration GUI piper provides a GUI for viewing and configuring gaming-oriented mouse features: profiles, button mappings and macros, sensitivity and resolution. It supports mice supported by libratbag, and uses ratbagd to mediate over d-bus (so that appropriate users can configure mice without being root).
Re: bugs in bootstrap.debian.net (was: Re: The state of cross building)
Hi Johannes, hi Bastien,
On Sun, 31 Jan 2016 01:53:34 +0100, Johannes Schauer wrote:
> Quoting Bastien ROUCARIES (2016-01-31 00:49:14)
> > Could you document on wiki how can we begin as a package manager. For
> > instance I could not achieve to parse
> > http://bootstrap.debian.net/cross_all/imagemagick.html
>
> I apologize. Since I wrote the software it is hard for me to put myself into
> the shoes of someone who is not familiar with the matter. I would very much
> welcome if any questions about the text or tables or tips of how to improve
> the presentation could be directed to me so that I can fix the website.
I'll give it a shot... (And add this later to the wiki.)
As I understand it, the page lists *dependency* problems which prevent:
* cross-building imagemagick
* using imagemagick's packages as build-dependencies when cross-building
The first table lists all the binary packages which prevent cross-compilation
involving imagemagick. This tells you where you need to look if you want to
fix things so that imagemagick can be cross-built and/or used for
cross-compiling.
The second table lists the same information but in more detail. In each line,
imagemagick's packages' involvement is highlighted in green. To determine
issues preventing imagemagick from being cross-compiled, look for it in the
third column ("packages with (possibly transitive) conflicting
dependencies"); this shows that getting imagemagick to cross-compile involves
fixing perl (and perl-base) so that it works in multi-arch contexts. Anything
else is a situation where one of imagemagick's packages' dependencies
prevents it being used for cross-compiling; fixing this might involve
amending imagemagick's dependencies, or it might involve fixing the
conflicting package. For example, hhvm can't be cross-compiled because it
build-depends, directly and indirectly (via imagemagick), on libfreetype6-dev
(which contains /usr/bin/freetype-config and is therefore not multi-arch
co-installable).
I hope that I got that all right and that it clarifies things a little!
Regards,
Stephen
pgp_pNnDyuuPF.pgp
Description: OpenPGP digital signature
Bug#811026: ITP: zoom-player -- player for Z-Code stories or games
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: zoom-player Version : 1.1.5 Upstream Author : Andrew Hunter * URL : http://www.logicalshift.co.uk/unix/zoom/ * License : GPL Programming Lang: C Description : player for Z-Code stories or games Zoom is a player for Z-Code stories or games. These are usually text adventures (also known as interactive fiction), made popular in the eighties by Infocom with its Zork series of games, and others. . Zoom emulates versions 3 through 8 of the Z-Machine; in particular it supports version 6 games properly. This package will be maintained in the games team. I'm introducing it in order to provide full support for the remaining Infocom games which the players already in Debian can't run: Arthur, Journey, Shōgun and Zork Zero.
Re: Copyright file granularity
On Fri, 13 Nov 2015 10:51:11 -0800, Steve Langasek wrote: > On Fri, Nov 13, 2015 at 04:10:14PM +, Wookey wrote: [...] > And we should have better tools to generate debian/copyright files - this > shouldn't be an intensive manual process. Unfortunately the only tool I'm > aware of that does this is coupled to cdbs. I've used debmake which does a reasonable job of generating initial copyright files and checking them. Lintian is also getting better at the latter. Regards, Stephen
Re: Linux kernels v3.18.x and v4.2.x in sid
Hi Dmitry, On Wed, 21 Oct 2015 12:35:47 +0200, Dmitry Katsubo wrote: > I wonder if somebody knows what are the plans for packaging kernels > 3.18.x and 4.2.x? 3.18 was released long time ago, and I think it is > mature. 4.2.x would be nice to play with. I have searched here: > > > https://packages.debian.org/search?suite=all&searchon=names&keywords=kernel-image > > > > but found nothing. Maybe there is some blocking issue? Anyway, even if > something does not work well, would be nice to see latest kernels in > e.g. sid repo. 4.2 has been in sid for over a week: https://packages.debian.org/source/unstable/linux Regards, Stephen pgp9120L7bL_J.pgp Description: OpenPGP digital signature
Bug#801896: ITP: libratbag -- configuration library for gaming mice
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: libratbag Version : 0.1.0 Upstream Author : Benjamin Tissoires * URL : https://github.com/libratbag/libratbag/ * License : MIT Programming Lang: C Description : configuration library for gaming mice libratbag is a configuration library for gaming mice. It provides a generic way to access the various features exposed by these mice and abstracts away hardware-specific and kernel-specific quirks. . It currently supports some Etekcity and Roccat mice, and most Logitech mice (both gaming and generic mice).
Bug#800074: ITP: miller -- name-indexed data processing tool
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: miller Version : 2.2.1 Upstream Author : John Kerl * URL : https://github.com/johnkerl/miller * License : BSD-2-Clause Programming Lang: C Description : name-indexed data processing tool Miller allows name-indexed data such as CSV files to be processed with functions equivalent to sed, awk, cut, join, sort etc. It can convert between formats, preserves headers when sorting or reversing, and streams data where possible so its memory requirements stay small. It works well with pipes and can feed "tail -f".
Bug#799344: ITP: plotnetcfg -- local networking configuration diagram plotter
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: plotnetcfg Version : 0.4.1 Upstream Author : Jiri Benc * URL : https://github.com/jbenc/plotnetcfg * License : GPL-2+ Programming Lang: C Description : local networking configuration diagram plotter plotnetcfg is a lightweight tool capable of scanning a machine's network configuration and producing a diagram of the local network hierarchy. It supports scanning across network namespaces, most types of network interfaces, and understands the specifics of VLANs, bridges, veth pairs and Open vSwitch.
Bug#796916: ITP: osslsigncode -- Authenticode signing tool
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.
Re: Bits from the Wanna Build team
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
Re: Modern Debian packaging system for DevOps: does it exist?
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
Bug#779680: ITP: node-argparse -- command-line argument parser for node.js
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
Bug#775872: ITP: fcml -- machine code manipulation library
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
Unversioned dependencies and empty packages
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#771253: ITP: gcab -- Microsoft Cabinet file manipulation tool
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
Bug#761130: ITP: lgogdownloader -- downloader for GOG.com files
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
Bug#759762: ITP: libz-mingw-w64 -- compression library (targeting Windows)
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
Re: Multiarch capabilities for mingw crossbuilds too?
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
Re: Proposed mass bug filing: /usr/lib/perl5 is changing with Perl 5.20
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
Re: make 4.0: archive rebuild resulted in 73 packages broken (help wanted)
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
Bug#742556: ITP: rr -- application execution recorder, player and debugger
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: dpkg-dev: please reject native/non-native version when building native/non-native source packages
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
Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]
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: Bug#727194: ITP: OpenMW -- Reimplementation of The Elder Scrolls III: Morrowind game engine
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: Bug#727194: ITP: OpenMW -- Reimplementation of The Elder Scrolls III: Morrowind game engine
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: dpkg-buildpackage creating uninstallable packages?
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
Bug#722631: ITP: libevdev -- wrapper library for evdev devices
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: Source build-dependencies
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
Re: jessie release goals
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: Depends: libfoo:foreign ???
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: Bug#666490: O: svgalib -- console SVGA display libraries
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: jessie release goals
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: jessie release goals
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: jessie release goals
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
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
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: Package version numbers
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
