Re: RFC: packages that can be installed by the user but not used as build dependencies

[Samuel Thibault]

Hello,

Lisandro Damián Nicanor Pérez Meyer, le lun. 19 août 2024 20:17:08 -0300, a 
ecrit:
> But users would love to have something like 'qt6-full-dev'. And the
> reason we never provided them with this meta-package is that package
> maintainers would use it almost everywhere, dragging the whole Qt
> installation on each package depending on it... This is a _huge_ waste
> of resources and buildd time (or is it not??)

It is, but also on maintainer systems when testing in bare chroots etc.
So I don't think maintainers would use it that much in practice.
(similarly to no package currently build-depending on texlive-full)

Samuel

Re: About i386 support

[Samuel Thibault]

Hello,

Tomas Pospisek, le mar. 21 mai 2024 17:22:47 +0200, a ecrit:
> > > Quoting Victor Gamper (2024-05-17 21:58:58)
> > > For i386 there is a severe lack of person-power. Do you want to start
> > > contributing your free-time for several years to come to d-i and
> > > other areas
> > > which are needed to keep i386 more alive for longer?
> 
> > On 18.05.24 03:15, r...@neoquasar.org wrote:
> >> That depends. What would be required of such a person? I also have
> >> several i386-class machines that run Debian (though only one that can
> >> run Debian 12).
> 
> On 18.05.24 15:16, Maite Gamper wrote:
> 
> > Whilst I can't for sure say how much free time I'll have, I'd like
> > to try and contribute. How would you get started with that?
> 
> There's somewhere a page that is showing how much of the archive is built by
> architecture. A search engine should help you finding that page. Pick the
> package that is furthest down the stack of package dependencies that is not
> building on i386.

It's probably not that easy to find.

The page I know about that would suit best would be the Build-Attempted
and Failed sections of:

https://buildd.debian.org/status/architecture.php?a=i386&suite=sid

> Find out why. Fix the bug. Check if there's a bug report
> about the problem. Send a patch. If the maintainer doesn't have time then
> become a Debian Maintainer [or] Developer yourself, consult with the
> package's maintainers and upload fixed packages.

Yup

Samuel

Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Samuel Thibault]

Barak A. Pearlmutter, le lun. 06 mai 2024 11:15:35 +0100, a ecrit:
> To me, the purpose of /var/tmp/ when I have my "user" hat on is: a
> place to put files I don't want backed up, particularly large ones,
> and which if I run out of disk space is a place to look for stuff to
> delete. it's not "a place to put files that the system might
> capriciously delete just because."

Definite +1 on this.

My /var/tmp has various "I want to get rid of this at some point"
temporary stuff, and I would be quite annoyed if it would disappear
unexpectedly.

> One compromise would be to enable the /var/tmp/ reaper by default only
> on new installations.

At the very least, yes.

Samuel

Re: time_t progress report

[Samuel Thibault]

Simon McVittie, le dim. 24 mars 2024 16:45:02 +, a ecrit:
> On Sun, 24 Mar 2024 at 13:09:02 +0100, Samuel Thibault wrote:
> > Simon McVittie, le dim. 24 mars 2024 11:59:50 +, a ecrit:
> > > For the specific example of pipewire, I've suggested temporarily
> > > dropping that feature from pipewire on the affected architectures
> > > <https://bugs.debian.org/1067558> which would get the rebuilds further
> > > along (particularly if it unblocks weston, which lots of packages use
> > > in their tests). There are various places where targeted changes like
> > > this can unblock a whole tree of dependencies.
> > 
> > Could we use build profiles for this? That'd avoid full uploads, and
> > document for architecture bootstrapping.
> 
> Only if a porter is willing to do a binary build with the relevant
> build profile on each of the affected architectures, and upload it as
> binary-only, after making a note to get it binNMU'd later. The official
> buildds for release architectures always build with no build profiles,
> and do not have any way (that I'm aware of) to vary this.
> 
> The porter-binary-upload approach is necessary for the actual bootstrap
> phase of the dependency stack, but doesn't seem to be scaling well in
> higher layers, because the number of porters is limited. I'd prefer
> to give porters the opportunity to work on more difficult issues where
> their architecture-specific knowledge is actually relevant, so I'm doing
> my best to unblock some of the dependency chains without having to block
> on porter uploads.

I understand these, but

- making sure that the Debian release eventually only contains
  non-profile builds should be relatively easy thanks to the buildinfo
  files (they currently only contain them in the DEB_BUILD_PROFILES
  environment variable, they could be added as proper field). We already
  track against packages built on non-buildd, we could track packages
  built with profiles.

- it's indeed better to avoid loading porters with this, notably because
  it'll be most often the same for a set of architectures. The buildd
  infrastructure could have an additional build-profile parameter that
  can be set on a binNMU, so that such temporary-profile binNMUs can be
  requested easily.

I'm not saying that this is trivial now, of course, but it seems to
me that it's not so far, and thus something we'd want to aim for
longterm-wise?

Samuel

Re: Re: time_t progress report

[Samuel Thibault]

Simon McVittie, le dim. 24 mars 2024 11:59:50 +, a ecrit:
> On Sun, 24 Mar 2024 at 12:56:52 +0500, Andrey Rakhmatullin wrote:
> > 2. FTBFSing packages (those that block further work, anyway)
> ...
> > An example of a currently existing obstacle of this kind is snapd-glib
> > (mainly because it blocks pipewire).
> 
> For the specific example of pipewire, I've suggested temporarily
> dropping that feature from pipewire on the affected architectures
>  which would get the rebuilds further
> along (particularly if it unblocks weston, which lots of packages use
> in their tests). There are various places where targeted changes like
> this can unblock a whole tree of dependencies.

Could we use build profiles for this? That'd avoid full uploads, and
document for architecture bootstrapping.

Samuel

Re: 64-bit time_t transition: cargo needs manual intervention

[Samuel Thibault]

Andrea Bolognani, le mer. 13 mars 2024 18:03:40 +0100, a ecrit:
> On Wed, Mar 13, 2024 at 12:34:55PM +0100, Samuel Thibault wrote:
> > Simon McVittie, le mer. 13 mars 2024 10:52:35 +, a ecrit:
> > > 2. i386 is 32-bit but has been excluded from the 64-bit time_t transition
> > >because its major purpose this decade is running legacy 32-bit 
> > > binaries,
> > >a purpose that would no longer be possible if it broke ABI
> > >- non-release architectures in the same category: hurd-i386 (I think)
> > 
> > We asked hurd-i386 to be there indeed, because we plan to have
> > hurd-amd64 replace hurd-i386 way before 2038 :)
> 
> Wouldn't it make sense to migrate hurd-i386 to 64-bit time_t
> regardless of the plans for hurd-amd64?

When seeing the pain that arm* suffer, I believe we made the right
choice.

> Contrary to linux-i386, it's not like there is a wealth of (possibly
> proprietary/binary-only) hurd-i386 software out there that we would
> benefit from remaining compatible with.

Sure, but the migration itself takes manpower, for no real benefit.

Samuel

Re: 64-bit time_t transition: cargo needs manual intervention

[Samuel Thibault]

Simon McVittie, le mer. 13 mars 2024 10:52:35 +, a ecrit:
> 2. i386 is 32-bit but has been excluded from the 64-bit time_t transition
>because its major purpose this decade is running legacy 32-bit binaries,
>a purpose that would no longer be possible if it broke ABI
>- non-release architectures in the same category: hurd-i386 (I think)

We asked hurd-i386 to be there indeed, because we plan to have
hurd-amd64 replace hurd-i386 way before 2038 :)

Samuel

Re: Q: uscan with GitHub

[Samuel Thibault]

julien.pu...@gmail.com, le lun. 19 sept. 2022 18:00:37 +0200, a ecrit:
> Le lundi 19 septembre 2022 à 20:50 +0900, Hideki Yamane a écrit :
> > 
> >  Recent changes in GitHub releases pages, I cannot check upstream
> > version with uscan. How do you deal with it?
> 
> It's not that recent ; here is a working example:
> 
> version=4
> opts="\
> dversionmangle=s/\+dfsg.*$//,\
> filenamemangle=s/.+\/[vV]?(\d\S+)\.tar\.gz/coq-$1\.tar\.gz/,\
> repack,repacksuffix=+dfsg,\
> " \
> https://github.com/coq/coq/tags .*/[vV]?(\d[^\s+]+)\.tar\.gz

That works for the tags page, but not for the releases page... The
problem is that the tags page only contains snapshots of the repository,
and not an autoconf-ed tarball. For instance since recently uscan cannot
get the correct tarballs from

https://github.com/brailcom/speechd/releases

Samuel

Re: packages expected to fail on some archs

[Samuel Thibault]

Guillem Jover, le mer. 14 sept. 2022 13:38:01 +0200, a ecrit:
> Something else to consider is that, for packages that make sense
> porting, deny-listing them from building means we do not have build
> failure logs, so deciding what to port or trying to check for patterns
> becomes more costly for humans,

Yes!

> of course at the cost of potentially throwing at it buildd resources.

Ports buildd maintainers can blacklist packages easily if they are seen
to hog buildd resources. That's easier for them to maintain than having
to get a package uploaded.

> we already had something similar with the Packages-arch-specific file,
> but my understanding is that we are moving away from it?

Yes we are because it's tedious to update.

Samuel

Re: packages expected to fail on some archs

[Samuel Thibault]

Tobias Frost, le lun. 12 sept. 2022 18:36:09 +0200, a ecrit:
> On Mon, Sep 12, 2022 at 05:11:46PM +0200, Samuel Thibault wrote:
> > Tobias Frost, le lun. 12 sept. 2022 16:08:08 +0200, a ecrit:
> > > The problem is that if you want to exclude an arch explicitly, you have to
> > > list all archs you want to build it on. IOW,  I'm missing an easy way to 
> > > say
> > > "not on THIS architecture", somthing like "[!armel]"
> > 
> > Yes, but see below.
> > 
> > > There are a few packages I take care of which make trouble on some archs 
> > > or
> > > simply do not make much sense to run on those low-end archs.
> > 
> > If they make trouble, I would say just let the package FTBFS there.
> 
> Well, it compiles there… Of course I could fail it artifically, but that
> isn't something I would say it would be appropiate.

That may still be more informative than hardcoding an Architecture list?
I happen to be doing that in sphinxbase actually:

https://salsa.debian.org/a11y-team/sphinxbase/-/blob/master/debian/rules#L30

> > > I was spending siginifant time in the past weeks on such a package, to fix
> > > autopkgtests issues specific to that arch -- unsuccessfully, I disabled 
> > > the
> > > tests in the end --,
> > 
> > Is it possible to get the same test be performed during package build
> > time? That way, it will be just not built, not shipped, and the state
> > will be clear on the buildd status page, and you can move on to more
> > useful work. For instance in my pocketsphinx package case:
> 
> Would do that if it would be possible; The tests won't run properly without 
> the
> data installed properly.

Ok, so it's a corner case we were discussing on debian-ports indeed.

Samuel

Re: packages expected to fail on some archs

[Samuel Thibault]

Hello,

Tobias Frost, le lun. 12 sept. 2022 16:08:08 +0200, a ecrit:
> The problem is that if you want to exclude an arch explicitly, you have to
> list all archs you want to build it on. IOW,  I'm missing an easy way to say
> "not on THIS architecture", somthing like "[!armel]"

Yes, but see below.

> There are a few packages I take care of which make trouble on some archs or
> simply do not make much sense to run on those low-end archs.

If they make trouble, I would say just let the package FTBFS there.

> I was spending siginifant time in the past weeks on such a package, to fix
> autopkgtests issues specific to that arch -- unsuccessfully, I disabled the
> tests in the end --,

Is it possible to get the same test be performed during package build
time? That way, it will be just not built, not shipped, and the state
will be clear on the buildd status page, and you can move on to more
useful work. For instance in my pocketsphinx package case:

https://buildd.debian.org/status/package.php?p=pocketsphinx

the mips tests fail, I just let it fail. If anybody feels interested
enough to take the time to fix the bug, then great. In the meanwhile it
will just not be available since it is broken. The only work I have done
for that problem is reporting the issue upstream:

https://github.com/cmusphinx/pocketsphinx/issues/252

What was proposed in the thread was to make the buildd page show the
failure in orange, so that people know that it's a known failure, and
not a new bug.

Samuel

Re: packages expected to fail on some archs

[Samuel Thibault]

Paul Gevers, le dim. 11 sept. 2022 21:16:08 +0200, a ecrit:
> On 11-09-2022 17:08, Samuel Thibault wrote:
> > We could for instance:
> > - Add an Architecture-FTBFS field to debian/control
> > - Add an environment variable to debian/rules so that on these archs dh
> >fails with a different exit code that buildds would notice.
> > - Add a Architecture-FTBFS field in the wb database that DDs can set
> 
> - color packages that "never" had a successful built on an architecture
> different. That information is already available because that's what marks
> the package as "uncompiled" vs "out-of-date".

Oh, right, that information is already available in wb.  Mehdi, do you
think you can implement that easily for a start?

That doesn't cover the case when a package stopped building on an arch,
though.

Samuel

packages expected to fail on some archs

[Samuel Thibault]

Hello,

We have been discussing a bit on #debian-ports about packages that fail
to build on less-mainstream architectures.

The issue we see is that some DDs end up setting a hardcoded list in
the "Architecture" field, rather than just letting builds keep failing
on these archs (and then possibly succeeding after some time whenever
somebody contributes a fix upstream that gets propagated to Debian).

First, perhaps it's worth reminding to DDs is that it's fine for a
package to show up as FTBFS on the buildd status for some archs: that's
not RC if the binary packages for that arch are not in testing (and
even then, an RM request can fix that, to just express the unfortunate
regression)

That said, I guess DDs would still set a manual Arch list so as to get
the red flags away from their sight on the buildd page status, e.g. from
https://buildd.debian.org/status/package.php?p=sthibault%40debian.org&comaint=yes&compact=compact
so that they can easily notice which build failures are actually not
expected, to be able to efficiently work on those.

So perhaps what is missing is a way to express that an FTBFS is
expected, so that the buildd page status represents it differently, e.g.
in orange rather than red?  The idea would be that it should be really
easy to set (as easy as setting an Architecture list) so that we can
easily recommend it.

We could for instance:
- Add an Architecture-FTBFS field to debian/control
- Add an environment variable to debian/rules so that on these archs dh
  fails with a different exit code that buildds would notice.
- Add a Architecture-FTBFS field in the wb database that DDs can set

The tricky part I see is that AIUI the buildd status page doesn't
have direct access to debian/control, only to the wb database, so the
first solution is not immediate to implement. The third option would
be the most obvious from the buildd point of view, but that's not very
convenient for DDs. Possibly such field could be automatically set
according to the Packages entry when a newer upload is done?

Samuel

Bug#1019276: ITP: nvda2speechd -- A bridge between Windows applications and Speech dispatcher

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 
X-Debbugs-Cc: debian-devel@lists.debian.org, 
debian-accessibil...@lists.debian.org

* Package name: nvda2speechd
  Version : 0.1
  Upstream Author : Rastislav Kish
* URL : https://github.com/RastislavKish/nvda2speechd
* License : GPL
  Programming Lang: Rust
  Description : A bridge between Windows applications and Speech dispatcher

It is already possible to use SAPI in Wine for quite a some time,
however, the default Microsoft voices are not particularly responsive
or diverse in terms of supported languages, and installing others and
configuring them can be challenging without sighted assistance.

nvda2speechd is a bridge, which can link applications capable of
speaking through NVDA right into Speech dispatcher installed on the
user's computer.


I plan to maintain it within the a11y team. The compilation involves
building windows binaries from rust source, which is not supported
in Debian, so I'll build using upstream rust resources and upload to
contrib.

Bug#1017478: ITP: otf2 -- Open Trace Format support library

[Samuel Thibault]

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

* Package name: otf2
  Version : 2.3.0
  Upstream Author : TU dresden
* URL : https://www.vi-hps.org/projects/score-p/
* License : BSD
  Programming Lang: C
  Description : Open Trace Format support library

OTF is a standard trace format used by several high-performance tools,
using an ASCII encoding, which supports multiple streams. The libotf2
provides support for reading/writing them.

This is a revamped version of the existing otf package.

Samuel

Re: Help needed with a dh_shlibs failure on non amd64 platforms

[Samuel Thibault]

Hello,

Martin Quinson, le lun. 04 juil. 2022 09:29:54 +0200, a ecrit:
>   dpkg-shlibdeps -Tdebian/libns3.36.substvars 
> debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wimax.so.36.1

x86_64-linux-gnu is only valid for amd64.

In

./debian/rules: -DCMAKE_INSTALL_RUNSTATEDIR=/run 
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu 
-DCMAKE_INSTALL_PREFIX=/usr

you want to use $(DEB_HOST_MULTIARCH) instead of hardcoding x86_64-linux-gnu

Samuel

Re: Lintian breaks existing lintian-overrides due to added []

[Samuel Thibault]

Hello,

Axel Beckert, le mer. 29 juin 2022 15:49:11 +0200, a ecrit:
> > I consider these [] not helpful […] no visible advantage.
> 
> The advantage is to clearly mark what is a file with potentially a
> line number in the output of lintian so that further processors like
> the lintian website can do deep links to the proper code position on
> e.g. sources.debian.org or salsa.debian.org. Felix called it "pointed
> hints".
> 
> From my point of view, that's quite an advantage.

Yes, I fully agree.  The format migration poses problem (I had to patch
quite a few lintian files), but it solves a lot other current-and-future
problems: we can now just ignore whole sets of warnings for a given file
(typically one that is generated by some tool such as doxygen)

Samuel

Re: Keep both images but stop pretending no-free is unofficial

[Samuel Thibault]

Pirate Praveen, le mer. 20 avril 2022 19:47:31 +0530, a ecrit:
> 2022, ഏപ്രിൽ 20 1:52:45 PM IST, Ansgar ൽ എഴുതി
> >On Wed, 2022-04-20 at 12:55 +0530, Pirate Praveen wrote:
> >> liberated.computer it is refurbished and some components like wifi
> >> cards replaced so it works with 100% free software.
> >
> >No, it doesn't. It just *hides* the fact that you use non-free
> >software. If you are happy with that, fine, but please don't claim it
> >uses 100% free software.
> 
> So are our official images not 100% free?

They are.

What is not is your computer, that already embeds non-free firmware when
you buy it. Loading newer versions of them or not doesn't change that.

Samuel

Re: Firmware - what are we going to do about it?

[Samuel Thibault]

Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 09:07:47 -0400, a ecrit:
> On 2022-04-20 08:39, Samuel Thibault wrote:
> > Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 08:32:13 -0400, a 
> > ecrit:
> >> Answer bellow this awful piece of text from someone who doesn't know how
> >> to make a space between line.
> > 
> > For information, reading mails with a speech synthesis doesn't
> > necessarily render spaces between lines.
> > 
> > So yes, people using them don't actually "see" the need for such
> > spacing.
> 
> When you talk or read a text out loud, you make pauses ?
> Why wouldn't they apply then you write a text ?

Because it's difficult for software to divine whether line breaks are
really meant to be flow break or not.

Help on this really welcome.  Bullshit words are not welcome.

Samuel

Re: Firmware - what are we going to do about it?

[Samuel Thibault]

Hello,

Polyna-Maude Racicot-Summerside, le mer. 20 avril 2022 08:32:13 -0400, a ecrit:
> Answer bellow this awful piece of text from someone who doesn't know how
> to make a space between line.

For information, reading mails with a speech synthesis doesn't
necessarily render spaces between lines.

So yes, people using them don't actually "see" the need for such
spacing.

Samuel

Re: debian-faq in NEW - or: remove documentation from the archive at all

[Samuel Thibault]

Hello,

Bo YU, le lun. 04 avril 2022 09:09:53 +0800, a ecrit:
> On Sun, Apr 03, 2022 at 01:18:37PM +0200, Holger Wansing wrote:
> > debian-faq is waiting in NEW queue for more than 4 months now (upload is
> > from 23.11.2021), with no visible activity from ftp-masters (and even with 
> > no
> > message at all!).
> > I pinged ftp-masters at the end of January, but got no reaction at all.
> If the mail list does not reply you, I think you can try it in IRC #debian-ftp
> from oftc.

Just as a reminder: the byhand queue is quite different from the new
queue, possibly there are very few ftpmaster who actually know how to
process it.

Samuel

Re: releasing major library change to unstable without coordination

[Samuel Thibault]

Jonas Smedegaard, le jeu. 23 déc. 2021 00:45:23 +0100, a ecrit:
> Is it normal and ok to upload a new major release of a library to 
> unstable, without either a) testing that reverse dependencies do not 
> break, or b) coordinating with maintainers of reverse dpendencies 
> _before_ such upload?

Usually I'd upload to experimental first, for people to easily check&fix
their rdeps package, and notify them with an "important" bug. Then after
some time raise to "severe" and upload to unstable.

Samuel

Bug#995989: ITP: libbraille-input -- Braille input engine for IBus-Braille and Sharada-Braille-Writer.

[Samuel Thibault]

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

* Package name: libbraille-input
  Version : 0.7.3
  Upstream Author : Nalin 
* URL : https://github.com/zendalona/libbraille-input
* License : GPL
  Programming Lang: Python
  Description : Braille input engine for IBus-Braille and 
Sharada-Braille-Writer.

 This engine can convert braille input events to text and call asociated
 callback functions. Here braille input means inputing text in Perkins-like
 way, i.e. braille patterns.

 It supports several braille tables, contracted braille and abbreviations.

Bug#995988: ITP: sbw -- Simple text editor with braille input

[Samuel Thibault]

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

* Package name: sbw
  Version : 3.6
  Upstream Author : Nalin 
* URL : 
https://github.com/zendalona/sbwhttps://github.com/zendalona/sbw
* License : GPL
  Programming Lang: Python
  Description : Simple text editor with braille input

Sharada-Braille-Writer allows one to use the PC keyboard to type text in
graphical desktops in a Perkins-like way, i.e. braille patterns.

It supports several braille tables, contracted braille and abbreviations.

Re: dpkg taking a bit too long ...

[Samuel Thibault]

Norbert Preining, le mar. 05 oct. 2021 21:24:36 +0900, a ecrit:
> $ time eatmydata dpkg -i 
> /var/cache/apt/archives/papirus-icon-theme_20211001-1_all.deb 
> (Reading database ... 1215786 files and directories currently installed.)
> Preparing to unpack .../papirus-icon-theme_20211001-1_all.deb ...
> Unpacking papirus-icon-theme (20211001-1) over (20210901-1) ...
> Setting up papirus-icon-theme (20211001-1) ...
> 
> real15m28.611s

$ dpkg -L papirus-icon-theme| wc -l
106800

I'm not completely surprised that writing a hundred thousand files takes
some time in whatever information system.

Samuel

Re: Looking for Estonian DD-s

[Samuel Thibault]

Wouter Verhelst, le mer. 25 août 2021 17:06:39 +0200, a ecrit:
> On Mon, Aug 23, 2021 at 04:12:43AM +, Paul Wise wrote:
> > On Sun, Aug 22, 2021 at 2:31 PM Aivar Annamaa wrote:
> > 
> > > Is here someone, who can meet me in Tartu, Estonia or is willing to
> > > arrange this over the internet? Perhaps I could sign a statement about
> > > my identity with Estonian ID card?
> > 
> > I checked the list of lists of Debian locations and there are no
> > Debian members that list their location as Estonia. It generally isn't
> > accepted to sign keys over the internet or other electronic means.
> 
> Disagree. Why would that be the case?
> 
> By signing an OpenPGP key you certify that you are sufficiently
> convinced that the key's holder is who they say they are, and that they
> control their key. The easiest way to do that is to meet someone in
> person, but that doesn't mean it's the *only* possible way.
> 
> Am I missing something?

You need to make sure to avoid man-in-the-middle concerns.

Samuel

Re: Proposal to create unstable-proposed-updates suite for use during freeze

[Samuel Thibault]

Nilesh Patra wrote:
> Using experimental directly is risky as it can have changes not ready for 
> unstable also.

No. Enabling experimental in your sources.list doesn't actually change
anything. You have to explicitly request installing a given package from
experimental to pull it from experimental, and only that will be getting
updated from experimental, you won't inadvertently pull other packages
from experimental.

Samuel

Bug#987171: ITP: libdumbtts -- Helper library for dumb speech synthesizers

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 
X-Debbugs-Cc: debian-devel@lists.debian.org, 
debian-accessibil...@lists.debian.org

* Package name: libdumbtts
  Version : 0.3.2
  Upstream Author : Bohdan R. Rau 
* URL : http://www.polip.com/files/
* License : LGPL v2.1+
  Programming Lang: C
  Description : Helper library for dumb speech synthesizers

This library is used between the Ivona synthesizer and
speech-dispatcher. On the other side, it should be as flexible as it can
be to generate output texts for every other synthesizer.

Re: Fixed release dates are hurting quality

[Samuel Thibault]

Andrey Rahmatullin, le dim. 07 févr. 2021 19:41:01 +0500, a ecrit:
> On Sun, Feb 07, 2021 at 02:20:28PM +0100, Samuel Thibault wrote:
> > > the packages being untouched for a long time in some cases meaning there 
> > > is
> > > no guarantee for quality.
> > 
> > Sure, but if there is no serious issue left with the package, we can as
> > well ship it.
> Strictly speaking, there is a big logical error here.
> If a package doesn't have RC bugs that doesn't mean it's fit for a
> stable release, doesn't have serious issues, or even is usable.

If a package has serious issues or is unusable, that makes it an RC bug,
and then the package will get removed, as it shall.

Of course, if nobody filed such an RC bug, the package gets shipped in a
broken state.  But it's perhaps better to just ship the package and let
people report in the case it is broken, rather than not ship it (despite
it is usable and has no serious issue ; no upload in a decade does *not*
necessarily mean that it has bitrotted), and then people not even notice
that the package isn't shipped any more.  I do have some packages on my
system which I do use, and which I just happened to notice that they are
not installable any more, because they got removed at some point.

Samuel

Re: Fixed release dates are hurting quality

[Samuel Thibault]

Hello,

Just answering the subject.

John Paul Adrian Glaubitz, le dim. 07 févr. 2021 13:40:39 +0100, a ecrit:
> I just noticed how maintainers are NMU'ing packages in large quantities to
> get them somehow in a usable state for the release.

I don't think this is related to fixing the release date?

We want to manage to release at some point.

> the packages being untouched for a long time in some cases meaning there is
> no guarantee for quality.

Sure, but if there is no serious issue left with the package, we can as
well ship it.

Samuel

Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

[Samuel Thibault]

Lisandro Damián Nicanor Pérez Meyer, le sam. 09 janv. 2021 15:53:41 -0300, a 
ecrit:
> # __FILE__ is a public, well defined API

? My copy of C11 says

“
__FILE__ The presumed name of the current source file (a character string 
literal)
”

that's not so well-defined.  I would not expect it to necessarily
contain the path to it.

> ## New macro and warning (if they do not exist already)
> 
> This would be the first step.

That would not work long-term-wise.

One of the issues with __FILE__ is that it's used by assert(), and thus
references to __FILE__ are popping up in various software (that is the
largest __FILE__usage I have seen in my packages). And that's written
explicitly in C11 about assert:

“
the latter are respectively the values of the preprocessing macros __FILE__
”

so we can't make assert() use something else than __FILE__, so something
else than __FILE__ cannot provide large reproducibility.

Samuel

Re: On doing 540 no-source-change source-only uploads in two weeks

[Samuel Thibault]

Holger Levsen, le jeu. 31 déc. 2020 12:45:09 +, a ecrit:
> I'll post the list of packages (sorted by ddlist) to debian-devel@lists.d.o
> shortly and will then amend this blog post to link to that mail.

I was about to ask for such a list :D

I'll gladly upload my long-no-upload packages, probably they actually
have changes in the git tree that deserve uploading anyway.

Thanks for your care!
Samuel

Re: apt ignoring check-valid-until flag

[Samuel Thibault]

Hello,

Paul Wise, le mer. 16 déc. 2020 22:53:45 +, a ecrit:
> On Wed, Dec 16, 2020 at 6:06 PM John Paul Adrian Glaubitz wrote:
> > Does anyone have any idea what I'm missing?
> 
> It seems to be saying that the 2019 ports archive signing key used for
> signing the snapshot URLs is expired, I don't think check-valid-until
> ignores key expiry.

Indeed, but one can use trusted=yes

Samuel

Re: Allowed to build-depend a pkg in main on a pkg in non-free?

[Samuel Thibault]

Roland Fehrenbacher, le mer. 30 sept. 2020 20:47:58 +0200, a ecrit:
>Is the only solution here then really to have two source packages
> with exactly the same upstream source and only a difference in
> the way the binaries are built and what they depend upon?

That's what I do with starpu and hwloc. In starpu the packaging
difference is really minimal so I use some sed scripts to switch between
the "main" version and the "contrib" version. In hwloc the difference
is more involved so I use two branches, and just pull from master to
contrib. In the end it's not really much additional work.

Samuel

Re: Trying to get in touch with Sam Hocevar [MIA]

[Samuel Thibault]

Alexis Murzeau, le lun. 24 août 2020 15:41:36 +0200, a ecrit:
> While 7 days in summer is rather small (some may have a month in
> vacation),
> you can have something in your TODO list for 9 years, but
> still reply to anyone asking a mail just saying something like:

Sure, but not everybody will do this, so one shouldn't necessarily
assume MIA from a lack of answer. I have seen quite a few of my bug
reports in our BTS being answered a couple of years later.

Samuel

Re: Trying to get in touch with Sam Hocevar [MIA]

[Samuel Thibault]

Sudip Mukherjee, le lun. 24 août 2020 14:09:21 +0100, a ecrit:
> On Mon, Aug 24, 2020 at 1:50 PM Holger Levsen  wrote:
> >
> > On Mon, Aug 24, 2020 at 12:21:25PM +0100, Sudip Mukherjee wrote:
> > > If the maintainer is truly unavailable [...]
> >
> > well, yes, but here someone hasn't replied to an email within 7 days...
> 
> Thats why the "if" in my reply. :)
> 
> And besides, looking at
> https://github.com/troglobit/editline/issues/42#issuecomment-674494039
> it seems its more than 7 days.

I have mails in my mbox that are 9 years old.

Yes, I still indend to address them some day, it does happen from times
to times that I dig back that long in the past.

Samuel

Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???

[Samuel Thibault]

Russ Allbery, le lun. 30 mars 2020 13:32:05 -0700, a ecrit:
> Samuel Thibault  writes:
> 
> > Concerning base64-encoded text files, it's quite borderline. Possibly
> > some editor do support opening base64-encoded files, then it's fine to
> > have this as source code. Otherwise I don't see it as the preferred
> > format for modifications.
> 
> This is not what preferred form of modification means, as I think is
> apparent from the fact that we distribute tarballs that cannot be opened
> directly by most editors.

No but you can double-click on the tarball and an unpacker will happily
show you the content.

> I do understand the desire to have the URL in a form that's easily
> searchable, but I don't think people are thinking through the implications
> of saying we're not allowed to distribute sources even in formats that are
> round-trip convertable to editable formats, but have to ensure every
> artifact is in a form that can be *directly* edited.  The implications for
> the archive would be massive busywork that would have no significant
> impact on software freedom.

That, however, I do buy as an argument :)

Samuel

Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???

[Samuel Thibault]

Russ Allbery, le lun. 30 mars 2020 12:08:18 -0700, a ecrit:
> Surely the QR code is an encoding of a string?

Yes, but can you easily modify the URL in that form?

Do you have an editor that can open it as such and let you check and
modify the URL?

> In other words, to me this feels like claiming that ISO 8859-1 text files
> are not in the preferred form of modification because they're not Unicode.

That's different: most editors are able to open both ISO-8859-1 and
Unicode files.

Concerning base64-encoded text files, it's quite borderline. Possibly
some editor do support opening base64-encoded files, then it's fine to
have this as source code. Otherwise I don't see it as the preferred
format for modifications.

Samuel

Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???

[Samuel Thibault]

Raphael Hertzog, le lun. 30 mars 2020 10:14:13 +0200, a ecrit:
> And on the opposite, if upstream changes the link, the you break it
> without noticing

Agreed, indeed.

> (unless you put even more code to first extract the link from the
> picture and then re-encode it).

Actually that would argue in favor of doing it, precisely to make sure
that it is still the donation URL, and not a faked one that would go
unnoticed if the URL only shows up as QR code.

I would agree to keep the upstram picture it was really the preferred
form of modification, but it really is not here: I can't check/fix the
URL by just looking at the picture.

Samuel

Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???

[Samuel Thibault]

Shengjing Zhu, le lun. 30 mars 2020 15:53:18 +0800, a ecrit:
> IMO, the QR picture is preferred form of modification as well as the
> origin text.

Is there a program which takes a QR code, allows to modify the URL and
the picture in the middle, and write the new QR code with the picture?

> And, I consider this situation just like I use an MS word to produce a
> .docx file and place it in my source tree.

It's not the same situation: the .docx file is the preferred form of
modification, you can trivially open it with libreoffice and update
it. One can't say the same of the QR code (and also the question of the
legal status of the picture in the middle of the QR code)

Samuel

Re: trimming changelogs

[Samuel Thibault]

Hello,

Boyuan Yang, le jeu. 19 mars 2020 20:58:57 -0400, a ecrit:
> Maybe we can keep changelog of up to 10 entries or till the time of 5 years
> ago

As a user, I would like to see changelog until at least the previous
Debian release, to be able to grep through it for changes when I happend
to find that some package has changed some behavior since the upgrade
from one release to another, and want to know more about it.

Samuel

Re: Debian With Alternate Init Systems

[Samuel Thibault]

Hello,

Svante Signell, le lun. 10 févr. 2020 12:18:37 +0100, a ecrit:
> On Sat, 2020-02-08 at 16:40 +0100, Samuel Thibault wrote:
> > > Nice, the first thing I'll do is to shut down the Debian/GNU Hurd
> > > buildd mahler.
> 
> > Can't you see you are here exactly very precisely here *again* putting
> > pressure to get something through?
> 
> It is not about pressure, definitely not!

That is however how, I believe, everybody understood it.

> It's frustration on you trying to punish me for having an opinion.

I am not trying to "punish" (I don't even see how that would happen). I
am telling Sam that we have never managed to make you change the *way*
you are expressing your opinions through pressure.

> What do you think would be obtained with the above words?

That you perhaps at least understand that what you were writing above
*is* pressure, even if you don't realize it when writing it.

> BTW: How many euros do you think having a buildd running 24/7 cost me 
> personally
> every month? I'm spending a large amount of my time supporting free software,
> including hosting several buildds (without a single (euro)cent in funding).

I really appreciate the effort you spend here, I am grateful for that.

> > Really, please grow up. You have already worded such a threat in the
> > past. That's at best childish.
> 
> I'm asking you to apologize for what you just wrote. The above is an outright
> insult to me.

Right. I apologize for this sentence, I didn't mean to make it an
insult.

The thing is: at some point I don't know how to explain that the way
you are engaging discussions is most often immediately with big words
and everything, and that it's not Okay. On the d-i init question,
there hasn't even been any discussion on debian-boot (and thus no
worded opposition), and then you already said that some developers
"out to leave the project". That's really not a good way to start
a discussion... And this is a recurrent scheme I have seen on IRC
etc., your starting topics is most often already "isn't it about time
to do [...]?". Honestly, when I see such a start, I have no other
will than working on something else than what you are talking about,
and thus your way of suggesting improvements is actually completely
anti-productive. If you simply worded it "could we perhaps do [...]?"
things would flow way better.  And similarly on d-i init, discussion can
lead to compromises.  I guess you'll again find this coward, like you
already said previously, but really, long-term wise, I have seen it work
way better than immediate battles that rather antagonize people.

Samuel

Re: Debian With Alternate Init Systems

[Samuel Thibault]

(leaving the other parts of threads to later, when I'll get time to
think what useful answer I can give, beyond just apologizing)

Svante Signell, le lun. 10 févr. 2020 18:27:55 +0100, a ecrit:
> Regarding your opinion about the GR becomes very clear by reading 
> https://hartmans.livejournal.com/99395.html again.
> Not much more to comment about that. This part is especially interesting:
> "Proposal B is a systemd focused proposal. It's very similar to Proposal F. 
> The
> text is different, but the implications of both proposals are similar."
> 
> Not much space for other init systems than systemd within Debian.

Please also quote:

«
My experience is that key maintainers and teams maintaining central
infrastructure or packages often need to work with people who are trying
to integrate new features. The difference between Proposal B and F is
that under Proposal B, we commit to making that happen for technologies
that are important in exploring alternatives to systemd.
»

That *does* leave space for other init systems. Much more than F would
have.

Samuel

Re: Debian With Alternate Init Systems

[Samuel Thibault]

Hello,

Alf Gaida, le sam. 08 févr. 2020 17:18:09 +0100, a ecrit:
> Am 08.02.20 um 16:15 schrieb Svante Signell:
> > Anything else? 
> >
> Yes, you forget something - as long the discussion culture in Debian
> stays this way i'm not motivated to start my NM process again.

Please really do not take Svante as a representative for Debian. He is
not a Debian Developer. His way of discussing is *not* representative of
the general discussion levels in Debian. Really not.

Samuel

Re: Debian With Alternate Init Systems

[Samuel Thibault]

Svante Signell, le sam. 08 févr. 2020 16:15:13 +0100, a ecrit:
> On Sat, 2020-02-08 at 14:51 +0100, Samuel Thibault wrote:
> > Sam Hartman, le sam. 08 févr. 2020 08:27:24 -0500, a ecrit:
> > > Svante> Perhaps all [...] ought to leave the project, including
> > > Svante> those having package not being dependent on systemd.
> > > 
> > > I am frustrated reading this.
> > > It sounds like you were suggesting that people should leave as a way of
> > > pressuring or punishing the project.
> 
> Why not, if the project is heading in the wrong way according to their
> conviction. Some people have already left Debian, as a result of the GR.

Re-read what he wrote. He wrote about pressure and punishment. Not about
people just leaving the boat that is not heading the direction that they
would like.

> > That's the way Svante is always behaving, through diverse forms of
> > pressure. 
> 
> It is not pressure, it is free speech.

No, it really is about pressure. It really seems you do not even realize
it. I guess you have spent your whole life doing things this way, and
thus don't even realize the mechanism.

> > He doesn't seem to know or even be able to learn another way
> > of having his goals received.
> 
> Ok, you teach me how to achieve my goals. Doing like you, keep silent and 
> suffer
> from not voicing your opinion?

No. By actually explaining what the goals are, and discuss about ways
to do it. Yes, that takes time, but that's the only way that will be
not hurtful for everybody. That also explains why I'm not doing it for
everything I'd like to do (which is fine), and even less for everything
*you* would like me to do.

Can't you even realize that the very sentence above "keep silent and
suffer from not voicing your opinion" is again your putting pressure by
trying to make me think I'd be suffering and that I'd have an opinion
worth taking the time to express?

> > I'd say do not try to fix it, we've been trying unsuccessfully within the 
> > Hurd
> > community.
> 
> Samuel, so you want me to stop working on Hurd?

I never wrote anything like that.

And I don't mean it either.

> Nice, the first thing I'll do is to shut down the Debian/GNU Hurd
> buildd mahler.

Can't you see you are here exactly very precisely here *again* putting
pressure to get something through?

Really, please grow up. You have already worded such a threat in the
past. That's at best childish.

Samuel

Bug#950940: ITP: pocketsphinx-python -- Speech recognition tool - Python3 bindings

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 

* Package name: pocketsphinx-python
  Version : 0.1.15
  Upstream Author : Dmitry Prazdnichnov 
* URL : https://github.com/bambocher/pocketsphinx-python/
* License : BSD
  Programming Lang: Python
  Description : Speech recognition tool - Python3 bindings

 CMU Sphinx is a large vocabulary, speaker-independent continuous speech
 recognition engine.
 .
 This package contains Python3 bindings for libpocketsphinx.


This is related to the request in bug 943646: the python bindings from
the pocketsphinx package are not evolving as much as people seem to
want, so Dmitry reworked it, and e.g. pypi is now tracking it.  Nickolay
himself said it should be fine to package these Python bindings instead
of those from pocketsphinx, thus proposing doing so.

Samuel

Re: Debian With Alternate Init Systems

[Samuel Thibault]

Hello Sam,

Sam Hartman, le sam. 08 févr. 2020 08:27:24 -0500, a ecrit:
> Svante> Perhaps all [...] ought to leave the project, including
> Svante> those having package not being dependent on systemd.
> 
> I am frustrated reading this.
> It sounds like you were suggesting that people should leave as a way of
> pressuring or punishing the project.

That's the way Svante is always behaving, through diverse forms of
pressure. He doesn't seem to know or even be able to learn another way
of having his goals received. I'd say do not try to fix it, we've been
trying unsuccessfully within the Hurd community.

Samuel

Re: Debian With Alternate Init Systems

[Samuel Thibault]

Svante Signell, le sam. 08 févr. 2020 13:03:20 +0100, a ecrit:
> On Thu, 2020-02-06 at 21:12 +, Sam Hartman wrote:
> > Unfortunately, I think that Debian has decided that's not directly our
> > focus.
> 
> Just to make sure: If I submit patches for the Debian installer for support of
> more than one init system, they would be outright rejected.

Nope. Nothing said so. Probably debian-boot wouldn't like to make it a
question asked by default, but in expert mode, probably yes.

It's not a question for debian-devel or the DPL anyway, please bring it
to debian-boot.

> Perhaps [...] ought to leave the project,

Please stop bringing in negativity like this: it is useless, whatever
the actual intention was.

Bringing fight into discussion is *never* the best way to move forward,
whatever your goals.

Samuel

Re: Y2038 - best way forward in Debian?

[Samuel Thibault]

Wouter Verhelst, le ven. 07 févr. 2020 14:46:19 +0200, a ecrit:
> On Fri, Feb 07, 2020 at 10:31:16AM +, Simon McVittie wrote:
> > On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
> > > Why not? This seems like the type of problem that SONAMEs are made for.
> > > What am I missing?
> > 
> > SONAMEs are set by the upstream developer in their build system
> 
> Yes, I am aware of that, thank you. I meant to say that this feels like
> something upstream could do a SONAME bump for.
> 
> I'm wondering why they chose not to.

Because the ABI change is voluntary on the application build side. The
existing libc.so is ABI-compatible with previously-built applications.

Samuel

Bug#947955: general: Windows on second (external) screen are blurry after notebook sleep

[Samuel Thibault]

Control: reassign -1 gnome-shell

Matthias Brennwald, le ven. 03 janv. 2020 14:14:28 +0100, a ecrit:
> On Thu, 2 Jan 2020 20:15:29 +0100 Samuel Thibault  
> wrote:
> > Hello,
> >
> > Matthias Brennwald, le jeu. 02 janv. 2020 20:06:27 +0100, a ecrit:
> > > the windows that have been opened before activating sleep mode are
> > > blurry. Newly opened windows are not affected.
> > > The issue happens with windows from all programs, not just a specific
> program.
> > > Moving or resizing the windows does not change the blurry appearance.
> >
> > Oh, that's very odd. Are you running X or wayland? Better reassign
> > to either xorg-server or weston. Perhaps also try different desktop
> > environments to determine in which cases that happens.
> 
> I just tried it with logging in to my account using Wayland or X. The blurry
> issue does not happen with X, only with Wayland.

Ok, so this bug can probably be reassigned to the specific wayland
pieces, doing so.

> If you still need me to test with different desktop environments: which o ne
> would you suggest? I'd prefer one that is easy to install AND remove after the
> test.

I don't know other wayland-based desktops than gnome, so I leave this
question to others :)

Samuel

Bug#947955: general: Windows on second (external) screen are blurry after notebook sleep

[Samuel Thibault]

Hello,

Matthias Brennwald, le jeu. 02 janv. 2020 20:06:27 +0100, a ecrit:
> the windows that have been opened before activating sleep mode are
> blurry. Newly opened windows are not affected.
> The issue happens with windows from all programs, not just a specific program.
> Moving or resizing the windows does not change the blurry appearance.

Oh, that's very odd. Are you running X or wayland? Better reassign
to either xorg-server or weston. Perhaps also try different desktop
environments to determine in which cases that happens.

Samuel

Re: devscripts uninstallable in Debian Sid due to unmet dependencies

[Samuel Thibault]

Hello,

Otto Kekäläinen, le dim. 06 oct. 2019 10:40:17 +0300, a ecrit:
> It seems devscripts cannot be installed in Sid at the moment. I was
> not able to find a bug report about this on bugs.debian.org and I
> cannot follow up the dependencies on what package actually is stopping
> it.
> 
> Anybody else experiencing this as well?

Everybody, yes. Please read debian-devel-announce: the perl 5.30
transition was announced there yesterday.

Samuel

Re: Rethinking tensorflow build (taking shortcuts)

[Samuel Thibault]

Daniele Nicolodi, le ven. 04 oct. 2019 12:27:08 -0600, a ecrit:
> On 04-10-2019 10:04, Mo Zhou wrote:
> > The only officially supported build system for Tensorflow is
> > bazel[1], which is not present in our archive due to some reasons.
> 
> For those not following closely, can you please point to the reasons why
> bazel (cannot?) is (yet?) packaged for Debian?  I recently pumped into
> another software that proposes to use bazel as its build system, thus I
> would like to be aware of any problems with it.

At least, when I tried to have a look, I got scared away by the
magnitude of dependencies :/

Samuel

Re: Rethinking tensorflow build (taking shortcuts)

[Samuel Thibault]

Mo Zhou, le ven. 04 oct. 2019 09:37:25 -0700, a ecrit:
> On the other hand, ff the user wants significantly different stuff,
> they have to re-generate a buildlog and update the parser accordingly.
> 
> Not bad, right?

Better than nothing, sure :)

Samuel

Re: Rethinking tensorflow build (taking shortcuts)

[Samuel Thibault]

Enrico Zini, le ven. 04 oct. 2019 18:33:44 +0200, a ecrit:
> On Fri, Oct 04, 2019 at 06:25:21PM +0200, Samuel Thibault wrote:
> 
> > Interesting :) But then if one wants to add some files to the software,
> > which changes the dependencies, are we able to insert it correctly in
> > the build process? Being able to change the set of files to be built is
> > part of being able to modify the software, for it to be free :/
> 
> My understanding is that the preferred source of modification will still
> be shipped, only with the addition of the preprocessed build
> instructions, to remove the need free software that is not in Debian.
> 
> If someone wants to add things to the software that change the
> dependency, I understand, one can regenerate the build trace with the
> build system that upstream uses (which is free software), and things
> keep working.

Being free software doesn't matter here if it's not available in
Debian. This fails the Desert Island test with only a set of Debian CDs
at hand.

Samuel

Re: Rethinking tensorflow build (taking shortcuts)

[Samuel Thibault]

Hello,

Mo Zhou, le ven. 04 oct. 2019 09:04:25 -0700, a ecrit:
> Another angle for addressing the building problem is in the
> reverse-engineering style: parse the bazel buildlog, rebuild the
> dependency graph and generate a ninja build for it. See [2].

Interesting :) But then if one wants to add some files to the software,
which changes the dependencies, are we able to insert it correctly in
the build process? Being able to change the set of files to be built is
part of being able to modify the software, for it to be free :/

Samuel

Re: Bits from the DPL (August 2019)

[Samuel Thibault]

Hello,

Sam Hartman, le mer. 18 sept. 2019 16:46:14 -0400, a ecrit:
> We could stop caring about sysvinit (which isn't quite the same thing
> but is related).  That would leave non-linux ports in an unfortunate
> position.  But right now there are no non-linux ports in the main
> archive.  So perhaps we don't even care about that.

Not being in the main archive does _not_ mean we don't care about it.

It only means that non-linux are not on par with e.g. hardware support
or security support compared to the mainstream linux ports, so we can't
claim they have the same quality as the released archs, that's all.

A problem with sticking to systemd only is that it means sticking to
linux only, and not leaving any room for any alternative, since systemd
is not to be seen ported on any non-linux.  I don't think we want to
care only about linux, for various reasons.

I'm not saying maintainers should spend time on maintaining init files
etc. but at least leave room for people who want to do it.

Samuel

Re: How to give back a build

[Samuel Thibault]

Hello,

Jeff, le jeu. 12 sept. 2019 19:02:15 +0200, a ecrit:
> How can I give back the build?

Please read the Misc Developer News on d-d-a :)

https://lists.debian.org/debian-devel-announce/2019/08/msg3.html

Samuel

Re: The noudeb build profile and dh-only rules files

[Samuel Thibault]

Theodore Ts'o, le lun. 08 juil. 2019 14:10:13 -0400, a ecrit:
> and it also avoids the double-compilation build time extension.  (I
> assume that's what you were referring to when you mentioned "avoid the
> two-times-longer build time", right?)

Yes.

Samuel

Re: The noudeb build profile and dh-only rules files

[Samuel Thibault]

Hello,

Theodore Ts'o, le lun. 08 juil. 2019 13:25:32 -0400, a ecrit:
> How important is noudeb, and why is defined in the first place?

My usage of noudeb is mostly to avoid the two-times-longer build time 

Samuel

Re: mandatory source uploads

[Samuel Thibault]

Thomas Goirand, le lun. 08 juil. 2019 11:57:45 +0200, a ecrit:
> So if I understand correctly, I can just rebuild everything and do
> source-only uploads, and the Debian infra will be smart enough to
> understand how to build?

Yes.
Only the dependency loops pose problem.

Samuel

Re: Programs contain ads - acceptable for packaging for Debian?

[Samuel Thibault]

Bagas Sanjaya, le jeu. 20 juin 2019 20:16:08 +0700, a ecrit:
> 
> On 20/06/19 20.11, W. Martin Borgert wrote:
> > Quoting Bagas Sanjaya :
> > > Such ads is displayed only when users have Internet connection, and
> > > there is no way to patch ZZZ in order to remove ads (or we have to
> > > buy "pro" version which doesn't contain ads and adds more features).
> > 
> > So it's not free software anyway and does not belong to Debian main.
> > It might be suitable for non-free, but I wonder whether it's worth
> > the trouble to package it.
> > 
> Is it implied that all programs which contain ads are non-free and not
> suitable for Debian main?
> 
> But ZZZ hypothetical package licensed under DFSG-compliant license (such as
> GPL).

The concern here is "there is no way to patch ZZZ in order to". If there
is no way to make the program do what you want, it is not free.

Samuel

Bug#930638: ITP: gla11y -- Automatic check of accessibility of .ui files

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 

* Package name: gla11y
  Version : 0.1
  Upstream Author : Samuel Thibault 
* URL : https://github.com/hypra/gla11y
* License : BSD
  Programming Lang: Python
  Description : Automatic check of accessibility of .ui files

This tool checks accessibility of GtkBuilder .ui files produced e.g. by glade
It looks for various issues, and notably missing or bogus labelling
relations.

It can for instance be used in Continous Integration checks to make sure not to
introduce accessibility regressions.


It is used by libreoffice, and being used by MATE.
The packaging would be handled by the accessibility team.

Re: speeding up installs

[Samuel Thibault]

Hello,

Adam Borowski, le mar. 11 juin 2019 03:15:21 +0200, a ecrit:
> The text console is restricted to 256/512 characters at one time only
> because of some ancient hardware.

D-i uses by default bterm, which avoid such limitation, and has some
support for more languages, e.g. right-to-left.

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Jonathan Carter, le lun. 22 avril 2019 21:42:33 +0200, a ecrit:
> On 2019/04/22 20:00, Samuel Thibault wrote:
> > So I could produce some hurd CD images with the archive from this
> > week-end.  Aurélien injected the hurd-i386 archive to debian-ports, and
> > we got the buildds running. Various scripts will start breaking but at
> > least package building will continue like before. Perhaps I'll have time
> > to fix the CD image building scripts before the Buster release, to make
> > more recent image builds, but as I said I can't promise anything.
> 
> That's fantastic news, is that image somewhere public where we can
> download it?

I'm not really at ease with widely publishing an image which has
"Buster" labels on it while Buster hasn't been published yet.

As a reminder, installation & preinstalled images are produced from
times to times, the latest (20th february) is available on

http://cdimage.debian.org/cdimage/ports/latest/hurd-i386/

as usual.

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Hello,

Samuel Thibault, le sam. 13 avril 2019 12:16:54 +0200, a ecrit:
> Holger Levsen, le sam. 13 avril 2019 09:50:25 +, a ecrit:
> > I can see how the ftpteam doesnt want to delay this *after* the Buster
> > release,
> 
> Ok, if it can't be after Buster releases because e.g. ftpmaster wants to
> clean the archive before it, the discussion is moot, I can just make the
> non-official Hurd release this week (since the scripts currently work
> it's really quick to do) with the RC bugs, and we can make the move and
> let scripts etc. be broken for a couple of months until I have time to
> fix them back.

So I could produce some hurd CD images with the archive from this
week-end.  Aurélien injected the hurd-i386 archive to debian-ports, and
we got the buildds running. Various scripts will start breaking but at
least package building will continue like before. Perhaps I'll have time
to fix the CD image building scripts before the Buster release, to make
more recent image builds, but as I said I can't promise anything.

Samuel

Re: Bits from /me: Difficulties in Deep Learning Framework Packaging

[Samuel Thibault]

Hello,

Thanks for the feedback. In the accessibility team we had interest in
https://github.com/mozilla/DeepSpeech but I got quickly afraid but the
mention of "TensorFlow" in dependencies, it seems I was right in not
taking time to have a look, unfortunately.

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Aurelien Jarno, le dim. 14 avril 2019 16:08:20 +0200, a ecrit:
> On 2019-04-12 23:01, Samuel Thibault wrote:
> > How is the move to debian-ports supposed to happen? I won't have the
> > time to do anything about it within the 2 weeks.
> 
> Note that there is no need for the removed architectures to be hosted on
> debian-ports, especially if you are not satisfied by the way it works.
> Feel free to get them hosted somewhere else.

I don't see a reason for not hosting it on debian-ports, it'll make it
way simpler for the rest of the workflow with buildd etc.

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Carsten Schoenert, le sam. 13 avril 2019 12:41:25 +0200, a ecrit:
> Am 13.04.19 um 12:06 schrieb Samuel Thibault:
> >> Both architectures haven't seen any major development in the past years
> > 
> > They have.
> 
> O.k. need to be more specific, so the same as you mentioned further
> down, ..."in the context of Debian, the packages of Debian and it releases".

In the context of Debian as a distribution itself, there is not much
more to be done actually: the distro can be installed with the normal
debian installer, we don't depend on unreleased patches to have a
working system. We even have gotten llvm working recently.

In a broader Debian meaning, for instance with Helmut we have achieved
cross-bootstrappability of hurd-i386 from amd64, which is really a great
thing, because we know that we can now reboostrap the whole distribution
thanks to this if needed.

> > Patching software should be handled upstream indeed.
> 
> Yes, but most upstreams are a bit reserved

You mean, more than the Debian maintainers?

Well, at some point, "so be it, you won't have the works-on-Hurd badge".

For base packages like librsvg, the question is of a bigger importance,
for the port of course, but also for computer science in general: if
base packages can't easily be ported to new operating systems, the whole
computer science will be just stuck with Linux, and I don't think it's a
good thing.

That reminds me a recent paper about the requirement for fork() in the
Unix interface (https://lwn.net/Articles/785430/), which notably says
that because of the complexity for implementing it, it's hard to create
new operating systems with new ideas while providing a POSIX interface
for being useful in general.

> >> So I disagree on "One person is enough"
> > 
> > I meant only for the Debian-specific things, I am the only DD who
> > currently uses its key for signing packages, making CD images, etc.
> > That's what I meant by "the daily ports things".
> 
> Well, I guess it's not that easy I fear as there are no parts that can
> be seen as separate standalone things, it's all connected in various ways.

Yes, these are very intertwinned, but I like working on it and the
current Debian infrastructure makes it easy enough to do.

> But realistically it's not enough in my eyes to keep Hurd on even
> tracking the normal evolving of Debian.

I have since long stopped hoping that the Hurd port would ever be an
arch released in Debian (see previous threads in the past years about
moving to debian-ports). Just for the security guarantees it would
require, that can't work.

But as a debian-ports, I believe it can continue working just like it
has in the past years.

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Svante Signell, le sam. 13 avril 2019 12:36:54 +0200, a ecrit:
> On Sat, 2019-04-13 at 12:18 +0200, Samuel Thibault wrote:
> > He rightfully means he does not want patches, but patches getting
> > submitted upstream, so he does not have to maintain them. A Debian
> > package maintainer is not supposed to maintain patches long-term.
> 
> Then the question of which responsibilities a package maintainer has
> should be investigated by the CTTE.

Please stop discussing about this, pulling CTTE in won't help with
anything, you can't force volunteers to be doing work.

This was already discussed before, and is out of scope from this thread,
and not the time to discuss about it.

Really, you need to learn to stop trying to bully people into the way
you want things to happen.

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Svante Signell, le sam. 13 avril 2019 12:13:41 +0200, a ecrit:
> On Sat, 2019-04-13 at 11:51 +0200, Carsten Schoenert wrote:
> > So I disagree on "One person is enough" as long this one person can
> > not keep track on all the required main and corner cases so other
> > maintainers get to do the workload here alone.
> 
> Have you seen this? Look at the age of these bugs. Note also that
> several bugs have patches attached to them.

He rightfully means he does not want patches, but patches getting
submitted upstream, so he does not have to maintain them. A Debian
package maintainer is not supposed to maintain patches long-term.

Really, this was already discussed in the past, can't you just accept
it?

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Holger Levsen, le sam. 13 avril 2019 09:50:25 +, a ecrit:
> On Sat, Apr 13, 2019 at 09:31:46AM +0200, Samuel Thibault wrote:
> > Samuel Thibault, le sam. 13 avril 2019 00:11:15 +0200, a ecrit:
> > > Joerg Jaspert, le ven. 12 avril 2019 23:30:31 +0200, a ecrit:
> > > > It seems to exist there, so probably someone who can upload there and
> > > > is interested in hurd-i386 goes and uploads stuff.
> > > Within a two-week timeframe only?
> > (while everybody is supposed to be busy fixing RC bugs)
> 
> would 6 weeks work be better for you?

It's actually exactly the time frame I still can not afford due to
personal scheduling that I can't do anything about.

> I can see how the ftpteam doesnt want to delay this *after* the Buster
> release,

Ok, if it can't be after Buster releases because e.g. ftpmaster wants to
clean the archive before it, the discussion is moot, I can just make the
non-official Hurd release this week (since the scripts currently work
it's really quick to do) with the RC bugs, and we can make the move and
let scripts etc. be broken for a couple of months until I have time to
fix them back.

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Carsten Schoenert, le sam. 13 avril 2019 11:51:51 +0200, a ecrit:
> > Please give up on Debian. They clearly have no interest in anything
> > non-linux or non-systemd, that is fully clear. Let's make a joint
> > effort to make a Guix release of Hurd (and kFreeBSD) happen. Or, if you
> > still want to continue using apt-style distributions, join Devuan.
> > Please, don't support the non-universal OS movement driven by Debian
> > people!
> 
> I can't follow that style of discussion.

Please don't, Svante is only trolling here, please don't feed him.

> I haven't seen a broader supporting from the people who wanting these
> architectures to stay in Debian on some important packages.

I can only agree. I hear a lot of people saying that the Hurd port
existing is a great thing, but a lot less people helping with it.

(I do thank all the people who work on it without necessarily being
noticed).

> Both architectures haven't seen any major development in the past years

They have.

> for me as a maintainer of packages the workload on supporting these
> architectures between the new upstream releases costs a lot of time

Patching software should be handled upstream indeed.

> So I disagree on "One person is enough"

I meant only for the Debian-specific things, I am the only DD who
currently uses its key for signing packages, making CD images, etc.
That's what I meant by "the daily ports things".

For the non-Debian-specific things like patching packages, I am
thankfully really not alone, and I completely agree it can't be a
one-person thing.

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Samuel Thibault, le sam. 13 avril 2019 11:57:20 +0200, a ecrit:
> That kind of mail is useless.

I actually meant: it is also harmful.

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

That kind of mail is useless.

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Joerg Jaspert, le sam. 13 avril 2019 10:24:53 +0200, a ecrit:
> On 15371 March 1977, Samuel Thibault wrote:
> 
> > > > It seems to exist there, so probably someone who can upload there and
> > > > is interested in hurd-i386 goes and uploads stuff.
> > > Within a two-week timeframe only?
> > (while everybody is supposed to be busy fixing RC bugs)
> 
> I just jumped over old threads - its not actually a new thing what we
> discuss now.

Sure. But last time we discussed it in september the debian-ports
workload issue wasn't settled.

> It never ever moved despite knowing that we want it off.

Personally, I never took the initiative of doing it because of the
debian-ports workload question.

> I don't believe that anything changes just because we wait again.

What now changed is that we have a deadline, so somehow it will have to
be done. That's the difference.

But the deadline is two-week in the middle of the full freeze...

> Also, note, that it is a team decision, not me alone, I am just the
> messenger.

Sure, no problem with that.

> If you want us to change it, mail the team with the reasons, and we at
> least discuss it again. No guarantees on outcome.

Well, it's very odd that a team decision is suddenly made with a
two-week effect without asking whether the schedule will be fine.

I guess I have to explicitly confirm here that yes, I know that the
decision _whether_ to move is not sudden. Again, I'm talking about the
schedule here. Asking a Debian team to do something time-consuming
within a two-week timeframe in the middle of the full freeze, really...

I won't have the time to discuss with ftpmaster about it in the coming
days anyway.

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Samuel Thibault, le sam. 13 avril 2019 00:11:15 +0200, a ecrit:
> Joerg Jaspert, le ven. 12 avril 2019 23:30:31 +0200, a ecrit:
> > It seems to exist there, so probably someone who can upload there and
> > is interested in hurd-i386 goes and uploads stuff.
> 
> Within a two-week timeframe only?

(while everybody is supposed to be busy fixing RC bugs)

samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Bernd Zeimetz, le ven. 12 avril 2019 23:32:32 +0200, a ecrit:
> On 4/12/19 11:21 PM, Samuel Thibault wrote:
> > Time will. I will have time later, but that'll be after the Buster
> > release, i.e. a *way* less coherent set of packages since a flurry
> > of package updates will happen, thus less usable, if installable at
> > all. The only alternative I have is to make the release now with the RC
> > bugs.
> 
> There is no real difference between the normal archive and ports.

Sure.

But again, scripts for releasing hurd-i386 Buster images will need to be
fixed in all kinds of places and packages. Experience has taught me that
it takes a lot of time to debunk that kind of thing, which I won't have
until Buster releases.

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Joerg Jaspert, le ven. 12 avril 2019 23:30:31 +0200, a ecrit:
> On 15370 March 1977, Samuel Thibault wrote:
> 
> > > Today we had our regular FTPMaster meeting and discussed hurd and both
> > > kfreebsd architecture and decided to remove them from unstable and
> > > experimental 2 weeks from now.
> > Just before the Buster release? That's far from the easiest timing.
> 
> There is never an easy timing.

Sure, but the deep freeze really is a least easy timing.

> [...]
> > within the coming two-three months (I am already struggling to find time
> > to do what I engaged to). Basically, it means no non-official release of
> > Debian Hurd along Buster. Or at best I could just make that non-official
> > release now, with all the still pending RC bugs.
> 
> It all depending on the amount of people the above shows (one) is one
> good reason why its not viable.

Again, I'm not talking about moving to debian-ports or not, but about
now really not being a good time. Just after the Buster release would be
completely fine.

Also, "one" is really enough to do the daily ports things. But when
it's about moving the archive, "one" is not enough. It's not the
sustainability of the ports which is at question here, but suddenly
having to fix all kinds of scripts in all kinds of places before Buster
releases. This is a unexpected burst of work that you can not hope to
see resolved by any kind of Debian team.

> > How is the move to debian-ports supposed to happen? I won't have the
> > time to do anything about it within the 2 weeks.
> 
> I honestly wonder if it really needs to be anywhere.

It does.

> It itself doesn't seem to have many developers, probably less users,

There aren't many developers and users indeed, but it still does and
moves forward, not backward.

> and heck, last upstream kernel seems to be from 2016.

Releases don't mean anything for such kind of project, just like
projects on github nowadays often don't bother much with doing releases,
they just say "take the master". If you really want a release, let's
just make one. The actual releases that matter are the snapshots I make,
the latest is dated 20190109.

> While it sure has some nice ideas and concepts in it somewhere,
> it doesn't seem to go anywhere, at all.  Not just in Debian, but
> anywhere.

It does. In terms of isolation and flexibility at the same time, Linux
is still lagging behind it, due to its very monolithic nature.

> But then, I am not involved in Debian Ports. So no idea.

Then please don't FUD, that can't help the discussion.

> It seems to exist there, so probably someone who can upload there and
> is interested in hurd-i386 goes and uploads stuff.

Within a two-week timeframe only?

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Bernd Zeimetz, le ven. 12 avril 2019 23:14:10 +0200, a ecrit:
> On 4/12/19 11:01 PM, Samuel Thibault wrote:
> > I was hoping to do a non-official relase of Debian Hurd along Buster as
> > usual, but a change of archive, which means uploading packages, fixing
> > scripts, etc. will take a lot of time, which I simply just will not have
> > within the coming two-three months (I am already struggling to find time
> > to do what I engaged to). 
> 
> While I appreciate your efforts, I have to be honest and say: If there
> are no other people to help here, you've just proven that this
> architecture should be moved to ports.

I am not saying that the hurd-i386 port shouldn't
be moved to ports (see the report I made on
https://lists.debian.org/debian-hurd/2018/09/msg0.html , my only
potential concern was with the workload of debian-ports).

I am only saying that this is really a bad timing.

> Nothing will stop you from releasing a hurd buster release using
> ports.

Time will. I will have time later, but that'll be after the Buster
release, i.e. a *way* less coherent set of packages since a flurry
of package updates will happen, thus less usable, if installable at
all. The only alternative I have is to make the release now with the RC
bugs.

Samuel

Re: Hurd-i386 and kfreebsd-{i386,amd64} removal

[Samuel Thibault]

Hello,

Joerg Jaspert, le ven. 12 avril 2019 22:48:42 +0200, a ecrit:
> back in August 2018 we discussed architecture inclusion into
> unstable/experimental.
> 
> Today we had our regular FTPMaster meeting and discussed hurd and both
> kfreebsd architecture and decided to remove them from unstable and
> experimental 2 weeks from now.

Just before the Buster release? That's far from the easiest timing.

I was hoping to do a non-official relase of Debian Hurd along Buster as
usual, but a change of archive, which means uploading packages, fixing
scripts, etc. will take a lot of time, which I simply just will not have
within the coming two-three months (I am already struggling to find time
to do what I engaged to). Basically, it means no non-official release of
Debian Hurd along Buster. Or at best I could just make that non-official
release now, with all the still pending RC bugs.

How is the move to debian-ports supposed to happen? I won't have the
time to do anything about it within the 2 weeks.

Samuel

Re: deduplicating jquery/

[Samuel Thibault]

Emmanuel Bourg, le lun. 07 janv. 2019 22:25:35 +0100, a ecrit:
> Le 07/01/2019 à 21:13, Nicholas D Steeves a écrit :
> > Do you have any suggestions for working with the following?: (please
> > reply to -devel)
> 
> We've discussed this topic in #903428 and the consensus is roughly that
> it's a waste of time and we would rather drop the mostly unused javadoc
> packages than implementing this.

I'd rather cripple the documentation a bit than removing it :)

Could jh_build perhaps just drop the embedded jquery copy to just avoid
the issue? AFAIK, jquery is only used to implement the "search" feature,
which can sometimes be convenient, but can be done by users with greps &
such.

Samuel

Re: deduplicating jquery/

[Samuel Thibault]

Sean Whitton, le sam. 05 janv. 2019 19:48:35 +, a ecrit:
> Forgive my ignorance of the specifics of this package, but why can't you
> add symlinks to the files shipped by libjs-jquery?  That is the standard
> solution.

openjdk's javadoc not only includes libjs-query, but also jszip,
jszip-utils, some images, etc. It'd be better to have a central provider
for whatever javadoc needs to have its search functionality working,
rather than each package maintainers doing it.

Samuel

deduplicating jquery/

[Samuel Thibault]

Hello,

Quite a few packages have jquery/ embedded in documentation generated by
javadoc. This yields to

«
libfoo-java shares 1.2 MB of similar files with package
liblizzie-java-doc, please investigate whether it is possible to reduce
the duplication.
»

e.g. most of the libbrlapi-java size comes from it, and
liblucene3-java-doc contains a couple dozens copies.

Could openjdk perhaps build a package that would ship jquery/ in a known
place, and packages would just depend on it and the generated jquery/
directory be replaced with a symlink to the known place?

Samuel

Bug#916848: ITP: emerald -- Decorator for compiz

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 

* Package name: emerald
  Version : 0.8.16
  Upstream Author : 2007 Quinn Storm 
   David Reveman 
   2015 Wolfgang Ulbrich 
   2015 Sorokin Alexei 
* URL : https://github.com/compiz-reloaded/emerald
* License : GPLv2
  Programming Lang: C
  Description : Decorator for compiz

 Emerald is a window decorator for the Compiz window manager, using a custom
 theme format (*.emerald). It is highly customizable and supports different
 theme engines, with transparency and precise placement of borders and window
 title elements.

Re: Porting rust

[Samuel Thibault]

Josh Triplett, le mer. 21 nov. 2018 12:39:35 -0800, a ecrit:
> I'm not an expert in that mechanism, but my understanding is that the
> vast majority is shared among multiple systems.
> 
> There probably *should* be a way to autogenerate these, but I don't
> think there is. But I wouldn't be surprised if you could rely *heavily*
> on the Linux glibc support.

Nope :)

Most of the structures have subtly different content, for various
reasons.

I actually rather based on BSD, on which the Hurd happens to base rather
than on Linux.

> I'd suggest starting with src/liblibc/libc-test and trying to get those
> tests running on Hurd, and then doing test-driven development until all
> the tests pass.

Before getting to this, a lot already has to be written. I have indeed
started with copying/pasting structures from BSD ports, just to get the
thing going, but even that way a lot has to be copy/pasted before just
getting libc to build.

Samuel

Re: Porting rust

[Samuel Thibault]

Hello,

Josh Triplett, le lun. 05 nov. 2018 21:02:32 -0800, a ecrit:
> Speaking with an upstream Rust hat on in addition to a Debian hat:
> what could Rust do to make life easier for porters?

After Adrian's announce I tried to have a brief look at the Hurd port.

I appreciated a *lot* that the Debian cross-bootstrap way is documented
and works nicely :)

I am however a bit overwhelmed by the task of filling the
src/liblibc/src/ os-specific .rs files which basically describe each and
every structure, function macro etc. provided by the system.  Is there
no way to generate these from the glibc headers?  Writing them by hand
is both tedious and error-prone, but I didn't find a porting guide that
would describe another way.

Samuel

Re: Uncoordinated upload of the rustified librsvg

[Samuel Thibault]

Mattia Rizzolo, le dim. 04 nov. 2018 10:40:01 +0100, a ecrit:
> On Sat, Nov 03, 2018 at 09:04:49PM -0400, Jeremy Bicha wrote:
> > What is the actual consequence of the latest librsvg being unbuildable
> > on those arches? The old binaries won't automatically be removed
> > there, right?
> 
> In this case not, but be aware that the archive software used in Debian
> Ports doesn't have support for "cruft", which means that if a package
> bumps its soname the old binaries are removed as soon as the last source
> package building them disappear.

AFAIK the decruftification is still manual, the archive software does
provide the different versions for different archs. Even for arch:all
packages, changes were done to expose the proper out-of-date version to
proper archs.

But ftp-master doesn't like lingering packages :)

> > Instead of putting all the blame on the GNOME team, maybe you could
> > have expressed your concerns during the months that librsvg was still
> > in experimental?
> 
> I at least had that impression even while being a bystander.  I do
> recall Adrian mumbling about how annoying rust was for ports and I even
> recall some discussion involving rsvg in it several months ago.
> You really didn't understand that rsvg was a concerns for the ports
> architectures?

I don't think this question is useful. One indeed doesn't always realize
the consequences one's actions, one can't blame somebody for that, shit
just happens :) Let's just work on finding a workable solution.

Samuel

Re: Uncoordinated upload of the rustified librsvg

[Samuel Thibault]

Jeremy Bicha, le sam. 03 nov. 2018 21:04:49 -0400, a ecrit:
> On Sat, Nov 3, 2018 at 6:47 PM Adam Borowski  wrote:
> > Perhaps we should quickly upload a revert, using the last good version of
> > librsvg, before things degrade?  Effectively removing librsvg on 11 archs
> > (not counting non-official ones) stops any GUI there.  Including proverbial
> > fvwm.
> 
> It sounds to me like you're saying that to fix librsvg being out of
> date on 11 arches, we need to make it out of date on every
> architecture.
> 
> What is the actual consequence of the latest librsvg being unbuildable
> on those arches? The old binaries won't automatically be removed
> there, right?

No, but various problems quickly arise:

- no new arch can build it.
- if a bug needs to be fixed in it for ports it can't be built.
- if it is involved in a transition, it can't be rebuilt, thus holding
  the transition for those archs.
- ftpmasters don't like lingering binaries.

A temporary solution could be to upload the previous version under a
different source package name, but that builds the same binary packages,
and only on archs which don't have rust (yet). Such package won't get
upstream updates etc. but it doesn't need to enter testing anyway.

Samuel

Re: Installer: 32 vs. 64 bit

[Samuel Thibault]

Hello,

Juliusz Chroboczek, le ven. 26 oct. 2018 14:41:31 +0200, a ecrit:
> In both cases, the installer crashes with no useful error message

This is not what I get.

- 32bit debian on 64bit machine: this should be working fine
- 64bit debian on 32bit machine: I get the attached message

If it's not what they get, there is some bug and more investigation is
needed.

Samuel

Re: Debian Buster release to partially drop non-systemd support

[Samuel Thibault]

Adam Borowski, le lun. 15 oct. 2018 18:02:37 +0200, a ecrit:
> On Mon, Oct 15, 2018 at 04:18:57PM +0200, Thorsten Glaser wrote:
> > Matthew Vernon wrote:
> > >interest/effort in getting sysvinit (and related bits) in a better state
> > >for buster, do drop me a line.
> > 
> > I’ve volunteered to help out earlier in the thread, within constraints
> > (but rather that than to see things go and break).
> 
> The main problem with sysvinit is the lack of a git repository.

I guess we could just move on and create a collab-maint one?

Samuel

Re: Debian Buster release to partially drop non-systemd support

[Samuel Thibault]

Svante Signell, le lun. 15 oct. 2018 17:49:23 +0200, a ecrit:
> On Mon, 2018-10-15 at 17:06 +0200, Samuel Thibault wrote:
> > It's a matter of people subscribing to the
> > pkg-sysvinit-de...@lists.alioth.debian.org list and discussing there,
> > I
> > don't see why anything heavier would be needed.
> 
> I thought alioth was no more, but maybe the mailing list remains?

See https://alioth-lists.debian.net/
https://wiki.debian.org/Alioth/MailingListContinuation and
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo

Samuel

Re: Debian Buster release to partially drop non-systemd support

[Samuel Thibault]

Evilham, le lun. 15 oct. 2018 16:27:25 +0200, a ecrit:
> Where to now?
> At devuan-dev, Adam Sampson has suggested that the debian-bsd and
> debian-hurd communities are also very interested in keeping non-systemd
> things working,

Yes, but they aren't populated so much either, with already a lot of
things in their plate.

> which is why I'd hope this won't end up in non-systemd
> support being dropped, but that this thread becomes the distress call
> that the topic needed.
> 
> If I had to guess, this requires some organisation first, and since it
> may require cross-communities organisation it may be somewhat tricky.

It's a matter of people subscribing to the
pkg-sysvinit-de...@lists.alioth.debian.org list and discussing there, I
don't see why anything heavier would be needed.

Samuel

Re: installation-guide is marked for autoremoval from testing

[Samuel Thibault]

Michael Biebl, le mer. 26 sept. 2018 19:53:22 +0200, a ecrit:
> Am 26.09.2018 um 19:50 schrieb Holger Wansing:
> > Debian testing autoremoval watch  wrote:
> >> installation-guide 20180603 is marked for autoremoval from testing on 
> >> 2018-10-11
> >>
> >> It is affected by these RC bugs:
> >> 898665: installation-guide: [installation-guide] change "Alioth" and "svn" 
> >> to "Salsa" and "git"
> > 
> > we got this note today.
> > 
> > However, the mentioned bug #898665 has been closed with the latest upload
> > 3 days ago.
> > 
> > What can be done about this?
> 
> ttbomk there were some debbugs related issues the last couple of days
> which should be solved by now.

Actually the real issue is that the 20180603 version of
installation-guide migrated to testing while it shouldn't have. It's
that version which is marked as to be removed, so no worry.

At least, https://packages.qa.debian.org/i/installation-guide.html now
says

Updating installation-guide fixes old bugs: #898665

So I don't think we have anything to do about it.

Samuel

Re: Re-evaluating architecture inclusion in unstable/experimental

[Samuel Thibault]

Svante Signell, le lun. 03 sept. 2018 01:18:20 +0200, a ecrit:
> On Mon, 2018-09-03 at 01:07 +0200, Samuel Thibault wrote:
> > 
> > > So has the debian patch been submitted in #900240 upstream by you or 
> > > Petter
> > > Reinholdtsen yet? I don't believe so!
> > 
> > I don't think so either, it'd be marked forwarded. That doesn't mean you
> > can't help with it.
> 
> Regardless who is submitting patches upstream, two problem remains:
> 1) The delay until upstream makes a new release.

Nope, the maintainer said he was happy to cherry-pick.

> 2) The delay until the Debian Maintainer creates an updated package from that
> release (if ever). Example: emacs26

Again, cherry-pick don't need to wait for the introduction of the new
release to Debian.

> And how many maintainers do cherry-pick patches accepted upstream, very few 
> :( 

Here the maintainer explicitly said we would happily do it.

Samuel

Re: Re-evaluating architecture inclusion in unstable/experimental

[Samuel Thibault]

Svante Signell, le lun. 03 sept. 2018 01:06:11 +0200, a ecrit:
> On Mon, 2018-09-03 at 00:19 +0200, Samuel Thibault wrote:
> > Felix Geyer wrote:
> > > I suggest that instead you respond to questions on bugs you opened.
> > > I'm not interested in maintaining patches for things that clearly
> > > belong upstream.  Once upstream has reviewed the changes I'm happy to
> > > cherry-pick them.
> 
> This is a comment on the Hurd bug, #900200, not the kfreebsd one, #905138.

That doesn't mean the comment doesn't hold generally.

> And I did not open that bug, you did!

That doesn't mean you can't help with it.

> > And I agree with it (and also one of the reasons why I didn't just
> > NMU-ed cmake with the hurd patch).
> 
> So has the debian patch been submitted in #900240 upstream by you or Petter
> Reinholdtsen yet? I don't believe so!

I don't think so either, it'd be marked forwarded. That doesn't mean you
can't help with it.

Samuel

Re: Re-evaluating architecture inclusion in unstable/experimental

[Samuel Thibault]

Svante Signell, le dim. 02 sept. 2018 23:39:08 +0200, a ecrit:
> On Sun, 2018-09-02 at 19:46 +0200, Samuel Thibault wrote:
> > Svante Signell, le dim. 02 sept. 2018 19:45:19 +0200, a ecrit:
> > > On Sun, 2018-09-02 at 15:21 +0200, Samuel Thibault wrote:
> > > 
> > > > 
> > > > > The statistics and graphs available on the debian-ports page[1] may
> > > > > provide some objective statistics or reflection on the actual
> > > > > suitability of your architecture's continued inclusion.
> > > > >  [1]: https://buildd.debian.org/stats/
> > > > 
> > > > Such statistics are really difficult to get any real conclusion from.
> > > > Sometimes 10% packages are missing just for one tricky nonLinux-specific
> > > > issue in one package.
> > > 
> > > Correct: One example is cmake for both hurd-i386 and kfreebsd-any.
> > > It does not even have to be tricky.
> > 
> > If it's not tricky, a NMU should be able to fix it easily.
> 
> I'm sorry Samuel, I asked both you and James Clarke, Cc:ed, for help on this
> issue and you both said it was not possible to NMU cmake, even if you are both
> DD's.

For my part, I was not talking about that patch, but about the
hurd-related patches.

For others, I can simply quote what was said:

Felix Geyer wrote:
> I suggest that instead you respond to questions on bugs you opened.
> I'm not interested in maintaining patches for things that clearly
> belong upstream.  Once upstream has reviewed the changes I'm happy to
> cherry-pick them.

And I agree with it (and also one of the reasons why I didn't just
NMU-ed cmake with the hurd patch).

> I think that the power of a package maintainer is far too big, making it
> possible to reject/ignore important and other bugs, especially with patches, 
> for
> non-released architectures (and effectively block NMUs).

He is not rejecting things, he is saying that belongs to upstream, which
is true.  Help with that and things will flow.

> I think the next step would be to bring the responsibilities and commitments 
> of
> a Package Maintainer to the TC,

Nope.

> Maybe the recent salvaging of packages could be helpful in the future
> regarding this problem.

Nope.

Samuel

Re: Re-evaluating architecture inclusion in unstable/experimental

[Samuel Thibault]

Svante Signell, le dim. 02 sept. 2018 19:45:19 +0200, a ecrit:
> On Sun, 2018-09-02 at 15:21 +0200, Samuel Thibault wrote:
> 
> > 
> > > The statistics and graphs available on the debian-ports page[1] may
> > > provide some objective statistics or reflection on the actual
> > > suitability of your architecture's continued inclusion.
> > >  [1]: https://buildd.debian.org/stats/
> > 
> > Such statistics are really difficult to get any real conclusion from.
> > Sometimes 10% packages are missing just for one tricky nonLinux-specific
> > issue in one package.
> 
> Correct: One example is cmake for both hurd-i386 and kfreebsd-any.
> It does not even have to be tricky.

If it's not tricky, a NMU should be able to fix it easily.

Samuel

Re: Re-evaluating architecture inclusion in unstable/experimental

[Samuel Thibault]

Hello,

Luke W Faraone, le lun. 27 août 2018 00:33:58 -0700, a ecrit:
> So, in the first instance, would you like to continue being part of
> unstable/experimental?

Well, I can simply point at what we said last time (IIRC) the question
was raised, here are the importants point we see in being on debian
instead of debian-ports:

https://lists.debian.org/debian-devel/2015/05/msg00070.html


Samuel Thibault wrote for the debian-hurd team:
> * Appearing on packages' and maintainers' PTS
> pages like http://buildd.debian.org/bash and
> https://buildd.debian.org/sthiba...@debian.org

This has been changed since then: debian-ports architectures show up
there.


> * Getting binNMUs from d-release transitions

I believe this is also now done for debian-ports architectures? This
really saves a lot of duplicate work for porters.


> * Appearing on http://release.debian.org/transitions/ and
> https://qa.debian.org/dose/debcheck/unstable_main/index.html
> We're fine with d-release not looking at the hurd column. But *we*
> however do look at it, and would be sad to completely lose that. It
> could be in a completely separate page or column, that would not pose
> problem.

I don't know if we have this for debian-ports?


> * Being considered as "second-class citizen"

As said at the time, this is rather already the case.



Luke W Faraone, le lun. 27 août 2018 00:33:58 -0700, a ecrit:
> As outlined on the Debian Archive Criteria page[0], the key points to
> consider are whether the architecture has been part of a stable release,
> whether it is *likely* to be part of a stable release, as well as
> whether it currently has a sensible number of active maintainers.

Considering how even quite a few Linux architectures ports are not
making it, I don't think we could say it likely that hurd-i386 be part
of a stable release.

> Whilst you may be happy to continue the work of maintaining the port
> regardless, don't forget that excess or otherwise unnecessary
> architectures involve a shared maintenance burden as well as incurring
> non-trivial requirements on mirror/Debian resources.

Concerning mirroring, it is indeed useless to mirror hurd-i386
worldwide. Considering maintenance burden, I'm a bit afraid of here
simply moving the load from the ftpmaster team to the debian-ports
ftpmaster team. I don't know the details, so can't say, I'm just Cc-ing
both teams.

> The statistics and graphs available on the debian-ports page[1] may
> provide some objective statistics or reflection on the actual
> suitability of your architecture's continued inclusion.

>  [1]: https://buildd.debian.org/stats/

Such statistics are really difficult to get any real conclusion from.
Sometimes 10% packages are missing just for one tricky nonLinux-specific
issue in one package.

Samuel

Re: Debian 10 please update gimp to 2.10....

[Samuel Thibault]

Geert Stappers, le mar. 12 juin 2018 09:41:53 +0200, a ecrit:
> On Tue, Jun 12, 2018 at 08:36:38AM +0200, Samuel Thibault wrote:
> > DutchGigalo, le lun. 11 juin 2018 23:16:21 -0700, a ecrit:
> > > Debian 10 (buster) please update gimp to 2.10   
> > 
> > gimp 2.10 is in unstable already, please be patient.
> 
> Information at https://tracker.debian.org/pkg/gimp
> says there is more needed then just being patient.

It says that users wanting it should be patient for the developers to
have a look at the issues.

Samuel