Bug#546222: RFP: latex-translator -- modular LaTeX string localization system

[Andrey]

Package: wnpp
Severity: wishlist

* Package name: latex-translator
  Version : 1.00
  Upstream Author : Till Tantau (tan...@users.sourceforge.net)
* URL or Web page : http://sourceforge.net/projects/latex-beamer
* License : LaTeX Project Public License or GPL
  Description : modular LaTeX string localization system

The translator package is intended to provide an open platform for
packages that need to be localized. Unlike the babel package (which
can and typically will be used together with translator), the set of
words that can be translated is not fixed and new words and
translations can be added in a simple manner. New translations can be
added in a decentralized manner. The package is written in completely
LaTeX and it is quite lightweight. It could very easily be ported to
plain-TeX or ConTeXt, provided there is a "public demand" for this. A
typical application of this package is the beamer class, which already
uses it, if it present. Then words like "Theorem" will be translated
to "Satz" if the document language is German, for instance. 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#1100579: general: After latest update problems with super key

[Andrey]

Package: general
Severity: normal
X-Debbugs-Cc: andrey.scherstobi...@gmail.com

Dear Maintainer,

After latest update:
can not unassign super key from overview action
can not assign super key to swith keyboard layout
due to onscreen indicator, swithing layout become very slow.
If you localize something, it slows things down a lot


Andrey

Re: Mandatory LC_ALL=C.UTF-8 during package building

[Andrey Rakhmatullin]

On Thu, Jun 06, 2024 at 12:08:17PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Or whether we should switch the default and require that d/rules is run in an
> environment (for example as set-up by dpkg-buildpackage) where these variables
> are set?
(a previous discussion on this:
https://lists.debian.org/debian-devel/2017/10/msg00317.html)



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Enabling some -Werror=format* by default?

[Andrey Rakhmatullin]

We recently increased the time_t size on certain architectures and some
packages started failing to build because they were using a format
specifier too narrow for the wider time_t, e.g. #1067829.
But the only reason those package FTBFS is they enable either -Werror or
some more specific non-default switch like -Werror=format=2, so I suspect
much more packages contain similar code but gained only a warning. Isn't
this a bad thing? Should we enable at least some combination of -Wformat*
switches by default? Should we at least add a new flag to dpkg-buildflags
and do some test rebuilds with it enabled?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Illegal Instruction Using sudo in Bookworm on i686

[Andrey Rakhmatullin]

On Sun, Jun 09, 2024 at 06:56:00AM -0500, rhys wrote:
> The question right now is:  Is this processor supported at all?
No.

> So given that these no longer fit the "old and busted" description, is Debian 
> going to stick with the decision to not support them?
I'm sure we will, yes, though I'm not in a position to decide that.

> Or is Debian going to continue to support this processor, since it is still 
> apparently a viable product, enough that new systems are using it?
Considering the plans for i386 I don't think it makes sense to even ask
this question?

> Only after that issue is addressed does anyone need to worry about sudo.  
> Depending on the answer, that is.
Yes, this indeed looks like one of those "why you don't support my CPU"
threads not specific to any software.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Suggestions about i386 support

[Andrey Rakhmatullin]

On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org wrote:
> >> It's not just a matter of "buy something better." That's easy.  
> 
> >Indeed, that is easier and cheaper.
> 
> Of course, continuing to use a system I already have is cheaper still.
> 
> > What's not easy is that a) that adds another machine to the waste 
> > stream, instead of continuing to get use from it, and b) someone has 
> > to take the time to set up the new machine, test things, migrate 
> > services, etc. to functionally replace the old one. That takes time 
> > and effort, too, multiplied by the number of such systems out there.  
> 
> > (a) is false as newer hardware can already be taken from electronic waste, 
> > so it does not add new waste.
> 
> That is a gross overstatement. Electronics are NOT 100% recyclable. A fair 
> amount of material still goes to waste, and there are all kinds of costs 
> associated with those processes. 
> 
> Reuse is better than recycle for complex things like electronics. 
You were suggested to resuse an old amd64 machine.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Enabling some -Werror=format* by default?

[Andrey Rakhmatullin]

On Mon, Jun 10, 2024 at 07:48:59AM +0200, Helmut Grohne wrote:
> > We recently increased the time_t size on certain architectures and some
> > packages started failing to build because they were using a format
> > specifier too narrow for the wider time_t, e.g. #1067829.
> > But the only reason those package FTBFS is they enable either -Werror or
> > some more specific non-default switch like -Werror=format=2, so I suspect
> > much more packages contain similar code but gained only a warning. Isn't
> > this a bad thing? Should we enable at least some combination of -Wformat*
> > switches by default? Should we at least add a new flag to dpkg-buildflags
> > and do some test rebuilds with it enabled?
> 
> It wasn't quite clear to me what -Werror=format=2 actually means.
> According to the gcc documentation[1], -Wformat=2 currently means:
> 
> -Wformat -Wformat-nonliteral -Wformat-security -Wformat-y2k.
> 
> Of these, we already enable -Werror=format-security, but not the other
> ones. It is not clear to me, which of these actually catches the the
> type mismatches. Would you do more research here?

#include 

void foo()
{
printf("%d", 0L);
}

This produces a warning with just -Wformat ("format ‘%d’ expects argument
of type ‘int’, but argument 2 has type ‘long int’ [-Wformat=]"). It
doesn't look like any more narrow options for this exist (-Wno-* ones
listed in the -Wformat description don't silence this one, and they don't
look like they should anyway).

But I don't know if even -Werror=format is too much to enable by default
globally (I assume it's a good thing to enable it, though).

> It also is unclear how this impacts the archive and yes, I'd recommend a
> rebuild. Note though that we likely need this rebuild both on a 64bit
> architecture and a 32bit architecture that is not i386 (due to how t64
> works). A partial archive rebuild may work to gauge the size of the
> problem.
> 
> I note that this kind of change affects cross builds, so performing
> cross builds for armhf on amd64 will likely show many of these failures
> (in addition to all the regular cross build failures).
> 
> I recommend doing more research before moving forward with this. In
> particular a MBF about introduced problems would be prudent before doing
> the switch and even if we don't switch, such a MBF bears value on its
> own.
Do you think it makes sense to add this a flag that enables -Werror=format
to dpkg-buildflags(1), before, or after a test rebuild, before, or after
the MBF if we do one?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Enabling some -Werror=format* by default?

[Andrey Rakhmatullin]

On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote:
> > > > We recently increased the time_t size on certain architectures and some
> > > > packages started failing to build because they were using a format
> > > > specifier too narrow for the wider time_t, e.g. #1067829.
> > > > But the only reason those package FTBFS is they enable either -Werror or
> > > > some more specific non-default switch like -Werror=format=2, so I 
> > > > suspect
> > > > much more packages contain similar code but gained only a warning. Isn't
> > > > this a bad thing? Should we enable at least some combination of 
> > > > -Wformat*
> > > > switches by default? Should we at least add a new flag to 
> > > > dpkg-buildflags
> > > > and do some test rebuilds with it enabled?
> > > 
> > > It wasn't quite clear to me what -Werror=format=2 actually means.
> > > According to the gcc documentation[1], -Wformat=2 currently means:
> > > 
> > > -Wformat -Wformat-nonliteral -Wformat-security -Wformat-y2k.
> 
> Those are in addition to the ones enabled by -Wformat=1, which are:

(note that -Wformat is already included in that list)

>   -Wnonnull -Wno-format-contains-nul -Wno-format-extra-args
>   -Wno-format-zero-length

(note that -Wformat is not equal to these flags, it just implies -Wnonnull
and those three -Wno-* can be used to turn off some parts of it)


> In general I think it's good (in principle) to enable -Werror flags
> that detect actual bugs in code, the problem is always going to be
> the amount of fallout and work that creates, and whether there's
> consensus about that work commitment being acceptable to maintainers
> in Debian, or whether that can interfere with transitions going on,
> etc.

Yeah.

> > > It also is unclear how this impacts the archive and yes, I'd recommend a
> > > rebuild. Note though that we likely need this rebuild both on a 64bit
> > > architecture and a 32bit architecture that is not i386 (due to how t64
> > > works). A partial archive rebuild may work to gauge the size of the
> > > problem.
> > > 
> > > I note that this kind of change affects cross builds, so performing
> > > cross builds for armhf on amd64 will likely show many of these failures
> > > (in addition to all the regular cross build failures).
> > > 
> > > I recommend doing more research before moving forward with this. In
> > > particular a MBF about introduced problems would be prudent before doing
> > > the switch and even if we don't switch, such a MBF bears value on its
> > > own.
> 
> > Do you think it makes sense to add this a flag that enables -Werror=format
> > to dpkg-buildflags(1), before, or after a test rebuild, before, or after
> > the MBF if we do one?
> 
> If by adding you mean adding a new feature flag that is disabled by
> default, then depending on the feature area, that might unfortunately
> be equivalent to enable it by default (due to the «all» keyword).

That's a good point, though hopefully people who use "all" understand the
implication...

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Enabling some -Werror=format* by default?

[Andrey Rakhmatullin]

On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote:
> > Do you think it makes sense to add this a flag that enables -Werror=format
> > to dpkg-buildflags(1), before, or after a test rebuild, before, or after
> > the MBF if we do one?
> 
> If by adding you mean adding a new feature flag that is disabled by
> default, then depending on the feature area, that might unfortunately
> be equivalent to enable it by default (due to the «all» keyword).

Another related question: if not via dpkg-buildflags, how do we do
rebuilds with changed default flags?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Suggestions about i386 support

[Andrey Rakhmatullin]

On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote:
> On Mon, 10 Jun 2024 at 12:43:27 +, Stefano Rivera wrote:
> > The point here is that the Debian project is not intending to support
> > new hardware on the i386 architecture. The architecture is being kept
> > around primarily to support running old i386 binaries.
> 
> ... and the most appropriate answers to some technical questions are not
> going to be the same for "i386 to run legacy 32-bit binaries on 64-bit
> CPUs" and "i386 to run on 32-bit CPUs", so we cannot simply support
> both equally.

Yeah, it should be made clear that if some people want to bring back
proper support for i386 hardware, they will need to make a new port.
Which is of course more complicated than fixing an existing one (but at
least bootstrapping it should be easier than bootstrapping some non-x86
port).

> If people want a distribution to run on 32-bit x86 CPUs badly enough,
> one possible route would be to start a new port (perhaps called ia32,
> i386t64 or something similar) for that use-case; it would have a baseline
> that is as low as its maintainers want it to be (i586?), and a 64-bit
> time_t for post-2038 future-proofing.
> 
> As far as I'm aware, nobody is yet putting effort into doing this. Also,
> several important upstreams no longer consider i386 to be useful (and
> especially i386-without-SSE2), so so the burden of supporting 32-bit
> CPUs in modern software will fall on the downstream developers who have
> chosen that their aim is to support 32-bit CPUs.

I assume such software already has this status on Debian i386 (and so is
either not built there or supported only by the maintainer, or maybe built
with a raised baseline) so there should be no regression here, though
additional packages will get the same status in the future.
Similarly, we already don't build a noticeable number of packages on armel
(and some of them also on armhf) when we build them on arm64.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Seeking consensus on file conflict between python3-proto-plus and nanopb

[Andrey Rakhmatullin]

On Mon, Jun 10, 2024 at 06:40:02PM -0400, Yogeswaran Umasankar wrote:
> There is a file conflict between python3-proto-plus and nanopb. The
> conflict arises due to both packages has a file at
> /usr/lib/python3/dist-packages/proto/__init__.py [0]. I am maintaining
> python3-proto-plus, and I am seeking guidance.
> 
> The module name "proto" is an integral part of the python3-proto-plus
> package. Renaming the "proto" module in python3-proto-plus would
> significantly impact future dependent packages.
> 
> It appears that nanopb's use of the module name "proto" does not align
> with the conventional identification of a Python module. 

What do you mean? It does look like a Python module to me. It's very
likely that it should be a private one though, but I see you already asked
the maintainer about that.

> I have attempted to reach out to the nanopb maintainer to discuss this
> issue, but I have not yet received a response. In case the maintainer is
> MIA, should I proceed with renaming the "proto" module in nanopb to
> "nanopb-proto"? 

No, it will make it useless.
I don't see a good way forward that doesn't involve NMUing nanopb.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Re: About i386 support

[Andrey Rakhmatullin]

On Fri, Jun 14, 2024 at 05:53:42AM -0500, r...@neoquasar.org wrote:
> A bug that can't be reproduced, effectively doesn't exist. 
Wow.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: WolfSSL and Netatalk

[Andrey Rakhmatullin]

On Sun, Jun 23, 2024 at 05:58:54AM +, Daniel Markstedt wrote:
> > wolfssl is packaged in Debian, did you try to build netatalk with the
> > packaged version?
> > 
> > Debian doesn't like code copies in sources, so if it builds fine with
> > the packaged version, removing it from the source that ends up in
> > Debian will fix all issues.
> > 
> 
> This is a reasonable request. I did try to build with Debian's WolfSSL 
> libraries last year.
> At the time (September 2023) I concluded that the DES compatibility headers 
> (des.h etc.) were missing altogether from Debian's WolfSSL package, and 
> therefore could not be used for this purpose with Netatalk.

libwolfssl-dev: /usr/include/wolfssl/openssl/des.h

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: dh_auto_clean, autoconf, and building packages twice (was: Potential MBF: packages failing to build twice in a row)

[Andrey Rakhmatullin]

On Sun, Jun 23, 2024 at 02:06:04PM +0200, Magnus Holmgren wrote:
> I'm very late to the party, but after reading the entire thread, I'd like to 
> discuss a more specific, but perhaps not uncommon, situation with regard to 
> cleaning and building again:
> 
> We have a [still fairly] typical upstream package using Autotools. The 
> tarball 
> includes some built files (e.g. documentation), i.e. make dist builds them 
> (as 
> long as the right tools are installed) and make distclean deletes them. 
> dh_auto_clean by default runs make distclean if such a target exists. But 
> that's not the case until ./configure has been run, because until then, there 
> are no makefiles. So The first time you run debian/rules build, the shipped 
> version of the files will be untouched and used in the final package, but 
> when 
> you then clean and build again, they will be deleted and rebuilt (or the 
> second build fails because of missing build dependencies).
> 
> Besides building a package twice potentially failing, this can lead to the 
> second build being different from the first. So I'm thinking:
> 
> 1. Do we generally want dh_auto_build to run make distclean, deleting files 
> that we otherwise wouldn't need to build? 

My autotools knowledge is rusty so I don't know what else except docs is
included here, but docs is a perfect example of a thing that we normally
*want* to rebuild.



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Mini-DebConf in Cambridge, UK - October 10-13 2024

[Andrey Rakhmatullin]

On Tue, Jun 25, 2024 at 06:14:54AM -0400, Roberto C. Sánchez wrote:
> > The style of writing mail - everything in one line, CCing several lists is
> > similar to how Luna writes it too. Freaky.
> > 
> AI can already generate audio and video that convincingly imitate real
> people. Why not the same with email? Though, the implications are rather
> serious.

That "style" doesn't seem to be hard to imitate manually...

> Perhaps our policies need to evolve to expect (or require?)
> cryptographic signatures from DDs in mailing list discussion.

Not all people here are DDs anyway.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Reviving schroot as used by sbuild

[Andrey Rakhmatullin]

On Tue, Jun 25, 2024 at 02:02:11PM +0100, Simon McVittie wrote:
> > In this work, limitations with --chroot-mode=unshare became apparent and
> > that lead to Johannes, Jochen and me sitting down in Berlin pondering
> > ideas on how to improve the situation. That is a longer story, but
> > eventually Timo Röhling asked the innocuous question of why we cannot
> > just use schroot and make it work with namespaces.
> 
> I have to ask:
> 
> Could we use a container framework that is also used outside the Debian
> bubble, rather than writing our own from first principles every time, and
> ending up with a single-maintainer project being load-bearing for Debian
> *again*? I had hoped that after sbuild's history with schroot becoming
> unmaintained, and then being revived by a maintainer-of-last-resort who
> is one of the same few people who are critical-path for various other
> important things, we would recognise that as an anti-pattern that we
> should avoid if we can.

100%


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Reviving schroot as used by sbuild

[Andrey Rakhmatullin]

On Tue, Jun 25, 2024 at 10:24:12AM -0700, Russ Allbery wrote:
> Guillem Jover  writes:
> 
> > I manage my chroots with schroot (but not via sbuild, for dog fooding
> > purposes :), and use type=directory and union-type=overlay so that I get
> > a fast and persistent base, independent of the underlying filesystem,
> > with fresh instances per session. (You can access the base via the
> > source: names.) I never liked the type=file stuff, as it's slow to
> > setup and maintain.
> 
> Ah, thank you, I didn't realize that existed.  That sounds like a nice
> generalization of the file system snapshot approach.

(Unless I'm missing something it's the default setup for e.g.
sbuild-createchroot(8))

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: BIMI verified email logo for @debian.org addresses

[Andrey Rakhmatullin]

On Thu, Jun 27, 2024 at 07:29:45PM +0800, Blair Noctis wrote:
> Hi,
> 
> [BIMI], or Brand Indicators for Message Identification, is a specification to
> let supporting email clients show a brand's logo next to verified email 
> domains.
> It would be great to have the Debian logo shown next to @debian.org addresses.
> 
> An email service provider implements it by implementing DMARC with a 
> quarantine
> or reject policy, as well as adding a TXT record pointing to the logo.
> 
> For a quick intro, please see 
> https://postmarkapp.com/blog/what-the-heck-is-bimi
> 
> BIMI: https://bimigroup.org/

(everything I know about BIMI I've learned from
https://16years.secvuln.info/ )


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: How does lintian use groff to validate man pages?

[Andrey Rakhmatullin]

On Fri, Jun 28, 2024 at 11:38:50AM +, c.bu...@posteo.jp wrote:
> > lintian-explain-tags can provide you with extensive information
> > ...
> > N:   LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 \
> > N:   man --warnings -E UTF-8 -l -Tutf8 -Z  >/dev/null
> 
> Do I do something wrong? It is not working in my case (running on Debian
> 12):
> 
> groff LC_ALL=C.UTF-8 MANROFFSEQ='' MANWIDTH=80 man --warnings -E UTF-8 -l
> -Tutf8 -Z ./backintime.1 >/dev/null
> groff: unrecognized option '--warnings'

You prepended "groff" to the command.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Urgent help with upload of netatalk to prevent being autoremoval from testing

[Andrey Rakhmatullin]

On Sat, Jun 29, 2024 at 02:13:04PM +, Daniel Markstedt wrote:
> Netatalk got dropped from Bookworm because there was a changing of the guards 
> of upstream maintainers during the freeze time.
> So I'm just naturally anxious about missing the boat again for Trixie.

Just make sure it's in testing before the appropriate freeze stage.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Q: Ubuntu PPA induced version ordering mess.

[Andrey Rakhmatullin]

On Mon, Jul 01, 2024 at 09:46:11PM +0200, Alec Leamas wrote:
> On 01/07/2024 20:48, Alec Leamas wrote:
> > Dear list,
> > 
> > Still working with the opencpn package. Now trying to normalize the
> > Ubuntu PPA builds so they can are based on the same debian/ directory
> > and tools as the existing Debian opencpn package.
> > 
> > opencpn is currently in a beta phase targeting a 5.10.1 release. The
> > beta versions are like "5.9.2-beta2+dfsg-1ubuntu1~bpo2204.1". The
> > upstream policy is to use 5.9.2-beta2, 5.9.3-beta3 so this ordering is,
> > although a bit strange, still ok.
> > 
> > However, a quite large user base have PPA packages installed. These have
> > versions like 8767+b2cbf5a3f~ubuntu24.04.1. The prefix is a build
> > number, so they are ordered. but all these versions are higher than
> > anything like 5.9.x.
> > 
> 
> After some thought, I tend to think that adding an epoch is the right thing
> here.
> 
> The Policy [1] says:
> ---
> Epochs can help when the upstream version numbering scheme changes, but they
> must be used with care. You should not change the epoch, even in
> experimental, without getting consensus on debian-devel first.
> ---
> 
> With all this said: Is this a case where using a epoch is justified? If not,
> why?

Adding epochs to work around 3rd-party repo version problems sounds quite wrong.
We don't even add epochs that Ubuntu itself adds.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Q: Ubuntu PPA induced version ordering mess.

[Andrey Rakhmatullin]

On Mon, Jul 01, 2024 at 11:59:00PM +0200, Alec Leamas wrote:
> > > After some thought, I tend to think that adding an epoch is the right 
> > > thing
> > > here.
> > > 
> > > The Policy [1] says:
> > > ---
> > > Epochs can help when the upstream version numbering scheme changes, but 
> > > they
> > > must be used with care. You should not change the epoch, even in
> > > experimental, without getting consensus on debian-devel first.
> > > ---
> > > 
> > > With all this said: Is this a case where using a epoch is justified? If 
> > > not,
> > > why?
> > 
> > Adding epochs to work around 3rd-party repo version problems sounds quite 
> > wrong.
> > We don't even add epochs that Ubuntu itself adds.
> > 
> 
> But this is not about third parties, it's about upstream which publishes PPA
> packages. 

I don't think it matters that they are published by the upstream.
Similarly to the versions issue you are not required to guarantee smooth
upgrades from 3rd-party packages and other such things.

> I also hesitate to add an epoch, after all they are basically considered
> evil. But if we should not use them when upstream has a broken versioning we
> are about to replace, when should we use it?

When upstream had a broken versioning *that we used in Debian*.

> I have good relations with upstream, and they are willing to abandon the
> current broken versioning in favor of something sane. But the legacy is
> there, and we need to handle it.

Again, it's just questionable to me if we *need* to handle upgrades from
non-Debian packages.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Q: Ubuntu PPA induced version ordering mess.

[Andrey Rakhmatullin]

(sorry, I replied thinking I've read the entire thread, I didn't notice
that there is a second thread broken off of this one)


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Q: Ubuntu PPA induced version ordering mess.

[Andrey Rakhmatullin]

On Wed, Jul 03, 2024 at 09:27:03AM +0200, Philip Hands wrote:
> IOhannes m zmölnig (Debian GNU|Linux)  writes:
> 
> > anyhow here's my 2¢:
> > according to you¹, upstream have simply botched their package 
> > versioning, which i would consider *a bug*.
> > bugs cause pain.
> 
> AIUI the botching was done by whoever put the PPA together.
> 
> If that's the same as upstream, fair enough, but it seemed to me (having
> glanced at the repo) that upstream has been using sane versions
> throughout.

<83d8755d-5f57-47e1-bda3-5536b7563...@gmail.com> said it's the upstream.



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: DD's, Debian Mentors needs you!

[Andrey Rakhmatullin]

On Sun, Jul 07, 2024 at 07:41:25AM +0800, xiao sheng wen(肖盛文) wrote:
> Hi,
> 
>  Support this become a weekly thing or a monthly thing.
> 
> Can mentors.debian.net sent package list to  debian-devel automatically?

The list of open RFSes is always available at
https://bugs.debian.org/sponsorship-requests



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: DD's, Debian Mentors needs you!

[Andrey Rakhmatullin]

On Sun, Jul 07, 2024 at 07:54:25AM +0200, Andreas Tille wrote:
> Hi Phil,
> 
> thanks for advertising Debian Mentors.
> 
> Am Sat, Jul 06, 2024 at 02:45:33PM +0100 schrieb Phil Wyett:
> > Hi all DD's
> > 
> > Debian Mentors[1] always struggles to find available Debian Developers for 
> > final reviewing and
> > sponsoring of packages submitted too our part of the project.
> 
> One thing I'm missing on mentors.d.n is that I it does not advertise
> existing teams.  It happened from time to time that there was some
> sponsoring request of Debian Science, Debian Med or Debian Python Team
> related packages (surely others I did not notices).  Asking on the
> relevant lists very easily helps getting the package in question
> sponsored.  I have a personal sponsoring policy that I only sponsor from
> a Git repository in a team I'm working in.  This has the advantage I can
> easily help by pushing some commit with extensive comment to teach the
> sponsee in some direct way.  Making a sponsee aware how to work together
> with a team inside Debian is IMHO very important.
> 
> Thus I would welcome if there could be some explicit hint to mentees
> to relevant teams.

Note that "Offer your package directly to relevant teams and individual
developers." is sugested on https://mentors.debian.net/intro-maintainers/
and https://mentors.debian.net/sponsors/

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: DD's, Debian Mentors needs you!

[Andrey Rakhmatullin]

On Sun, Jul 07, 2024 at 10:10:55AM -0400, Jeremy Bícha wrote:
> On Sat, Jul 6, 2024 at 9:46 AM Phil Wyett  wrote:
> > Debian Mentors[1] always struggles to find available Debian Developers for 
> > final reviewing and
> > sponsoring of packages submitted too our part of the project.
> 
> One thing that has disrupted my use of https://mentors.debian.net/ for
> sponsoring is that I am unable to log in. I don't get any of the "sign
> up" or "reset password" emails.

Sponsors don't need an account there though, (optionally) looking at the
package page and downloading the .dsc should be enough.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bug#1075905: ITP: python-fraction -- Fraction carries out all the fraction operations including addition, subtraction, multiplication, division, reciprocation

[Andrey Rakhmatullin]

On Sun, Jul 07, 2024 at 07:00:57PM +0200, Daniele Nicolodi wrote:
> On 07/07/24 17:43, Yogeswaran Umasankar wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Yogeswaran Umasankar 
> > X-Debbugs-Cc: debian-devel@lists.debian.org, y...@debian.org
> > 
> > * Package name: python-fraction
> 
> How is this different from the fractions module in the Python standard
> library?  I was not able to find anything that this library does that the
> standard library equivalent does not do.
Yeah, it looks like a school project.
Is it a revdep of something? If so, that's probably a mistake?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Bug#1075905: ITP: python-fraction -- Fraction carries out all the fraction operations including addition, subtraction, multiplication, division, reciprocation

[Andrey Rakhmatullin]

On Sun, Jul 07, 2024 at 01:54:59PM -0400, Yogeswaran Umasankar wrote:
> Yes, can use the standard library. This dependency chain starts with
> moarchiving, which itself is a dependency for cma, and so on. I can
> create a patch specifically for moarchiving.

As reported elsewhere, moarchiving declares a dep on it but doesn't
actually import it.
This needs to be fixed upstream to.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Ready stage for DD review/sponsoring - Too many DDs may spoil the broth. :-)

[Andrey Rakhmatullin]

On Fri, Jul 12, 2024 at 05:54:59AM +0100, Phil Wyett wrote:
> Morning all,
> 
> As we embark on a new process where packages submitted to mentors are reviewed
> and brought to a "Ready" stage for then busy DDs who are gracious enough to 
> give
> their time to review and possibly sponsor into Debian. We have a unique 
> problem
> (one which is now a nice one to have to be honest :-)) where more than one DD
> may input on the same package review.
> 
> Could submitters to mentors and DDs please ensure that only one DD is working 
> on
> a package. This is to avoid conflicting info and also not waste valuable DD
> time. If a package is taken, please find another to work on, as there are many
> at the "Ready" stage.

Do you also suggest to not review packages one isn't going to sponsor? Or
how should this work?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Ready stage for DD review/sponsoring - Too many DDs may spoil the broth. :-)

[Andrey Rakhmatullin]

On Fri, Jul 12, 2024 at 07:01:41AM +0100, Phil Wyett wrote:
> > > As we embark on a new process where packages submitted to mentors are 
> > > reviewed
> > > and brought to a "Ready" stage for then busy DDs who are gracious enough 
> > > to give
> > > their time to review and possibly sponsor into Debian. We have a unique 
> > > problem
> > > (one which is now a nice one to have to be honest :-)) where more than 
> > > one DD
> > > may input on the same package review.
> > > 
> > > Could submitters to mentors and DDs please ensure that only one DD is 
> > > working on
> > > a package. This is to avoid conflicting info and also not waste valuable 
> > > DD
> > > time. If a package is taken, please find another to work on, as there are 
> > > many
> > > at the "Ready" stage.
> > 
> > Do you also suggest to not review packages one isn't going to sponsor? Or
> > how should this work?
> > 
> 
> Morning Andrey,
> 
> Anyone can review packages, that has been part of mentors forever really. But
> whoever does review a package, I would hope they see it through its journey.
> 
> * For non DDs. Hopefully take it to that ready stage where a DD can then take
> over and finish a packages journey.
> 
> * For DDs. Hopefully take a package on prior to or at the ready stage and take
> it through its full journey.
> 
> Is this reasonable?

Yeah, it's reasonable, I won't do drive-by reviews in the future.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: what about Netplan?

[Andrey Rakhmatullin]

On Sat, Jul 13, 2024 at 09:44:03PM +0200, Lukas Märdian wrote:
> > However, I do not think it should be the default. First of all, only
> > Ubuntu uses it, nobody else - as Simon says, we don't want the
> > defaults to be super-special things that nobody else uses. And then
> 
> Actually, I think this is an agrument FOR Netplan, not against it. Netplan is 
> being used
> by millions of users for 7+ years. Plenty of usecases have been tried and 
> documented. It's
> clearly not a "super-special thing that nodbody uses".
> 
> Whereas I'm not aware of a major Linux distro using systemd-networkd 
> directly, Debian would be
> singeling out itself. I see some of networkd's strengths with advanced users 
> who want to dig deep
> and have full control at minimal resource usage (e.g. Arch Linux). Also with 
> lightweight container
> usecases, where network config only needs minimal manipulation after 
> deployment (if at all).
> 
> The RedHat ecosystem is all-in on NetworkManager. Debian and Ubuntu have 
> (natually) been very close
> to each other (e.g. package management) and together with its derivatives 
> create the Debian ecosystem.

Then it looks like a chance for netplan to go the way of upstart?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: i686 require SSE4.1-capable processor?

[Andrey Rakhmatullin]

On Mon, Jul 15, 2024 at 01:42:50PM +0200, Andreas Ronnquist wrote:
> I'm maintaining a package (filezilla) which just got a bug report that
> it simply crashes on program start - It gets a SIGILL - "Illegal
> instruction". (#1076312 report [1]). 
> 
> After the reporter debugged it, it seems like it crashes on the
> assembler instruction "pinsrd", which looks like it was added in
> SSE4.1, while the reporter runs this on a 
> 
> Intel(R) Celeron(R) M CPU 420  @ 1.60GHz
> 
> which only supports SSE2. (Full cpuinfo available in the report) - So, my
> question is - is this a cpu that is too old for Debian to support, or
> should we support it, and Debian gcc generates invalid code requiring SSE4.1
> while it still should support SSE2? (Or is the problem something else
> completely?)

Neither.
Packages built for the i386 arch need to conform to the i386 baseline,
which is currently i686. If a package contains a newer instruction it's a
bug in that package and gcc is not the cause of it, the package is.
https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.63.0-1%2Bdeb12u3&stamp=1704758683&raw=0
indeed contains at least one compile command with -msse4.1.

(there is also a "workaround", adding a dep on some isa-support
subpackage, but it's unlikely to be the correct course of action here and
I still don't know why is it even allowed in general)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: i686 require SSE4.1-capable processor?

[Andrey Rakhmatullin]

On Tue, Jul 16, 2024 at 12:46:01PM +0100, Phil Wyett wrote:
> > > > Packages built for the i386 arch need to conform to the i386 baseline,
> > > > which is currently i686. If a package contains a newer instruction it's 
> > > > a
> > > > bug in that package and gcc is not the cause of it, the package is.
> > > > https://buildd.debian.org/status/fetch.php?pkg=filezilla&arch=i386&ver=3.63.0-1%2Bdeb12u3&stamp=1704758683&raw=0
> > > > indeed contains at least one compile command with -msse4.1.
> > [...]
> > > Yeah, I have discovered that it is indeed a cause of the d/rules in the
> > > filezilla package. I blame having taken over it recently, and still
> > > haven't learned the ins and outs of it.
> > 
> > It'd also be good to document reasons for such workarounds next time. 
> > Both the changelog and the surrounding comments don't really tell you 
> > what to watch out for in a new gcc version. There's no bug reference 
> > (GCC or Debian bug) or example error message or a pointer to possible 
> > miscompilation.
> > 
> > Kind regards
> > Philipp Kern
> > 
> 
> Hi all,
> 
> The addition to 'debian/rules' was in response to the below.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053804

That bug report looks like the outcome of the "addition", not the reason
for it. Did you mean
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034195 ?

The interactions in both bugs look very weird to me, especially when the
same person proposes compiling software with SSE4.1 and then complains
that it fails on older hardware, and the reason for closing the newer bug
also looks weird to me. I think it should be reopened and bumped to RC.



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages

[Andrey Rakhmatullin]

On Sat, Aug 03, 2024 at 10:37:42PM +0200, Salvo Tomaselli wrote:
> > 2.  Standardizing around a single (or small number of) workflows will make
> > some people unhappy.  But that is an acceptable price to pay because of the
> > general benefit to the project *as long as the correct solution is
> > adopted*.  Unity is more important than minority opinions on this
> > particular issue.
> 
> Keep in mind that unhappy people quit.

Yes, people will resign, but (other) people resign because they got tired
of Debian not having standartized workflows, and the "1000 DDs status quo"
problem also means that more people leave than join *anyway*.

> I don't think that unity is so important that we're willing to sacrifice 
> project members.

Not the unity per se, but having significantly lower barriers to start
contributing.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages

[Andrey Rakhmatullin]

On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:
> one problem I have with NMUs in team-maintained package is that they
> often bypass Salsa…  Would it make sense to add to the DEP a request
> that NMUs are started from and pushed to the default branch?

Only if DEP-18 also includes an easy way to find the workflow used by the
repo, which I'm not seeing there (which may be my fault).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages

[Andrey Rakhmatullin]

On Sun, Aug 04, 2024 at 04:15:13PM +0200, Fabio Fantoni wrote:
> Il 04/08/2024 15:36, Andrey Rakhmatullin ha scritto:
> > On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:
> > > one problem I have with NMUs in team-maintained package is that they
> > > often bypass Salsa…  Would it make sense to add to the DEP a request
> > > that NMUs are started from and pushed to the default branch?
> > Only if DEP-18 also includes an easy way to find the workflow used by the
> > repo, which I'm not seeing there (which may be my fault).
> > 
> something like wrote here can help for you?
> 
> https://lists.debian.org/debian-devel/2024/08/msg00058.html
> 
> https://lists.debian.org/debian-devel/2024/08/msg00062.html
> 
> I think something like this could be useful, even in a possible future where
> all packages would use git and salsa; but from the answers received so far
> it seems to be considered a useless thing. I would be curious to know the
> opinion of more people.

It's similar but different: I'm talking about workflows to build a package
from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs").
And yeah it could be a metadata field.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Who is taking care of storm.debian.net?

[Andrey Rakhmatullin]

On Mon, Aug 12, 2024 at 11:02:04AM +0200, Philipp Kern wrote:
> On 12.08.24 10:57, Carsten Schoenert wrote:
> > Am 12.08.24 um 10:27 schrieb Carsten Schoenert:
> > > Hi,
> > > 
> > > the certificate for the domain storm.debian.net has expired yesterday.
> > > 
> > > The site is not listed on https://wiki.debian.org/DebianNetDomains
> > > 
> > > Knows someone who runs this service so the certificate could get renewed?
> > 
> > O.k., I was unable to find the dedicated wiki page for this service. :-(
> > 
> > https://wiki.debian.org/Services/storm.debian.net
> > 
> > I contacted Laura and Kyle.
> 
> For the next person who has access to master (i.e. is a DD):
> 
> master$ ldapsearch -x '(dnsZoneEntry=storm*)'
> 
> That will give you the account name of the domain "owner".

Or for anyone:

$ host -t txt storm.debian.net
storm.debian.net descriptive text "Kyle Robbertze "
storm.debian.net descriptive text "PGP 96A5 8F18 2BB8 F9B8 1C5F  2733 854F 07BE 
082D F14F"

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Porterbox - impossible efficient debugging?

[Andrey Rakhmatullin]

On Tue, Aug 13, 2024 at 12:15:22PM +0200, julien.pu...@gmail.com wrote:
> And of course, this is where I came to my wits' end: I can compile the
> new elpi successfully... but I have no way to install this new elpi
> binary packages in the schroot to test it against different coq-elpi!

Yes, the usual recommendations are "unpack and try pointing to it via
stuff like LD_LIBRARY_PATH, hopefully such stuff exists for your case".

Consider using local qemu chroots instead.

> dd-cross-schroot-cmd -s $sessionid -a $targetarch apt-get install
> ./*foo*_3.14-159_$targetarch.deb

This still runs random code as root.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Porterbox - impossible efficient debugging?

[Andrey Rakhmatullin]

On Tue, Aug 13, 2024 at 01:35:03PM +0200, julien.pu...@gmail.com wrote:
> > > And of course, this is where I came to my wits' end: I can compile
> > > the
> > > new elpi successfully... but I have no way to install this new elpi
> > > binary packages in the schroot to test it against different coq-
> > > elpi!
> > 
> > Yes, the usual recommendations are "unpack and try pointing to it via
> > stuff like LD_LIBRARY_PATH, hopefully such stuff exists for your
> > case".
> 
> It doesn't: it's a mix of languages. C, OCaml, elpi and Coq I would
> say.
> 
> > Consider using local qemu chroots instead.
> > 
> 
> I'd like a one-page easy-to-use tutorial on this.

It's like normal sbuild but pass --arch=foo to sbuild-createchroot and to
sbuild. You'll need qemu-user-static installed.
That's all IIRC.

> > > dd-cross-schroot-cmd -s $sessionid -a $targetarch apt-get install
> > > ./*foo*_3.14-159_$targetarch.deb
> > 
> > This still runs random code as root.
> > 
> 
> I don't think running random code as root in a virtual environment I'm
> going to delete before the end of the day is a security issue.

Well, that's the only reason I can think for not being able to run root
commands in porterbox chroots directly.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Python2 idiosyncrasies in Python3 scripts

[Andrey Rakhmatullin]

On Thu, Aug 15, 2024 at 12:11:55PM +0200, Jerome BENOIT wrote:
> is there a reliable way to isolate Python2 idiosyncrasies in Python3 scripts ?

Do you mean code that still works in Python 3 but can be simplified?
Lots of linters do this in whole or in part, though I don't have
suggestions for something that does *only* this. You can also look at
pyupgrade.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Python2 idiosyncrasies in Python3 scripts

[Andrey Rakhmatullin]

On Thu, Aug 15, 2024 at 01:11:23PM +0200, Jerome BENOIT wrote:
> > > is there a reliable way to isolate Python2 idiosyncrasies in Python3 
> > > scripts ?
> > 
> > Do you mean code that still works in Python 3 but can be simplified?
> > Lots of linters do this in whole or in part, though I don't have
> > suggestions for something that does *only* this. You can also look at
> > pyupgrade.
> > 
> 
> 
> I look to check if a bunch of Python[2] scripts can run with Python3 as-is or 
> with minor changes.
> The involve scripts are very basic.

Try modernize or any linter.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Accepting DEP14?

[Andrey Rakhmatullin]

On Fri, Aug 16, 2024 at 11:44:38AM +0200, Andreas Tille wrote:
> > In #829444 it has been proposed the addition of a new "layout" option to
> > gbp.conf, which would tell git-buildpackage which layout to follow,
> > allowing for a graceful migration.
> > 
> > I've been thinking about a different approach though. What about adding
> > a warning to git-buildpackage when `debian-branch` and `upstream-branch`
> > are not set in gbp.conf? Compared to the `layout` option, it would have
> > the following benefits:
> > ...
> > How does it sound to you? Am I missing something?
> 
> I prefer having no debian/gbp.conf at all in case the repository layout
> would fit team policy.  So the question is whether git-buildpackage can
> cope with the old
> 
>master + upstream + pristine-tar
> as well as
>debian/latest + upstream/latest  + pristine-tar
> 
> if no gbp.conf exists.

pristine-tar isn't the default either, so you need debian/gbp.conf if your
team uses it.
Unless I've missed some recent changes.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Accepting DEP14?

[Andrey Rakhmatullin]

On Fri, Aug 16, 2024 at 03:59:07PM +0200, Andreas Tille wrote:
> Am Fri, Aug 16, 2024 at 02:58:40PM +0500 schrieb Andrey Rakhmatullin:
> > 
> > pristine-tar isn't the default either, so you need debian/gbp.conf if your
> > team uses it.
> 
> That's correct but the teams I'm working in recommend something like:
> 
> 
> Add the following to the configuration file ~/.gbp.conf or 
> debian/gbp.conf:

Putting team-specific settings into the global ~/.gbp.conf is a bad idea
in my opinion, but also you can set DEP14 branches there in the same
way...

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Accepting DEP14?

[Andrey Rakhmatullin]

On Sat, Aug 17, 2024 at 12:20:16PM +0200, Andreas Tille wrote:
> My personal preference would be if we make a pristine-tar branch default
> since this is what I observed in the wide majority of cases.

Note that there are different opionons whether pristine-tar is
needed/viable/useful. There is at least one objective fact that it's hard
to keep working.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Strange armel build error

[Andrey Rakhmatullin]

On Sun, Aug 18, 2024 at 11:02:03AM +0200, Alec Leamas wrote:
> Hi Stephen,
> 
> On 18/08/2024 09:04, Stephen Kitt wrote:
> > On Fri, 16 Aug 2024 17:46:45 +0200, Alec Leamas  
> > wrote:
> > > Or just exclude that architecture i. e., list all archs but armel?
> > If you can’t fix the build, you don’t need to exclude the architecture — you
> > can ask for removal of the armel package in testing. That will allow the
> > package to migrate even if armel is missing.
> > 
> This looks to me like a sound solution in this case. After all, opencpn is a
> full-fledged GUI leaf package without reverse deps and zero users on armel
> hardware. But then again, how is this done?

If by this you mean asking for a removal then reportbug release.debian.org

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Removing more packages from unstable

[Andrey Rakhmatullin]

On Tue, Aug 20, 2024 at 07:28:52AM +0200, Helmut Grohne wrote:
> please allow me to open a can of worms. Package removal from unstable.
> Deciding when it is time to remove a package from unstable is difficult.
> There may be users still and it is unclear whether keeping the package
> imposes a cost. In this mail I want to argue for more aggressive package
> removal and seek consensus on a way forward.

Yes please.

> What does package removal cost?
> 
> Before a package can be removed, it needs to be reviewed for reverse
> dependencies and if there are any, they have to be switched to something
> else or removed as well. 

(leaf packages are much more straightforward to remove because of this)

> Human readable explanation:
>  * Packages in sid
>  * not in bookworm or trixie
>  * not a key package
>  * affected by an RC bug that has been last modified more than a year ago
>  * not among a few selected exceptions

Makes sense, though non-leaf ones can't be processed automatically and so
I'm not sure what can be done with them.

If we don't want to mass-remove all of these, there are additional
criteria (that I sometimes use to file manual removals) that can be added,
though not all of them are possible to determine automatically:

* Leaf package
* A "library" (something not useful by itself)
* FTBFS - these can't be binNMUed, NMUed etc. without fixing an unrelated
  bug first so they are in a worse condition thatn others in the context
  we are discussing
* "Doesn't work at all" - these are not useful to users.
* Orphaned

> Let us assume that we agree on there being a set of packages to be
> removed. What is a reasonable process? Is it ok to just file a pile of
> RoQA bugs or is more warning warranted? Should we maybe use a process
> similar to salvaging where there is an "ITR" (intent to remove) bug that
> is reassigned to ftp after a reasonable timeout?

Removing packages that aren't formally orphaned always sounds too bold to
me, though it should be fine if we formalize a process (any process) for
that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Removing more packages from unstable

[Andrey Rakhmatullin]

On Tue, Aug 20, 2024 at 11:09:51AM +0200, Bastian Venthur wrote:
> I think popcon does give a good approximation of how much percent of people
> installed a certain package even if not everyone uses it, don't you agree?
> 
> Last time I installed Debian it was still enabled by default.

Was it?

(this should answer your first question too)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Removing more packages from unstable

[Andrey Rakhmatullin]

On Tue, Aug 20, 2024 at 12:12:33PM +, Scott Kitterman wrote:
> >Removing packages that aren't formally orphaned always sounds too bold to
> >me, though it should be fine if we formalize a process (any process) for
> >that.
> >
> The process currently is file an rm but against ftp.debian.org for removal 
> from unstable using RoQA (remember, we're all QA) explaining the rationale 
> and an FTP Team member will assess it and remove the package if it seems 
> reasonable (the above criteria are quite reasonable in that regard).
> 
> There are people doing this, we could use more, but it does happen.  I've 
> processed lots of these and it's virtually always fine.  In the rare case of 
> a mistake, the cost to rectify the mistake is a trip through New.
> 
> I don't think we need more process.  

Oh, I'm sure it's fine both for people filing these and the FTP team, I'm
worried about reactions from the maintainers of those packages.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?

[Andrey Rakhmatullin]

On Tue, Aug 20, 2024 at 06:35:52PM -0700, Otto Kekäläinen wrote:
> Hi!
> 
> In short:
> I would very much like to see all top-150 packages run Salsa CI at
> least once before being uploaded to unstable. What people think is a
> reasonable way to proceed to reach this goal?
> 
> 
> Background:
> We have had several cases recently where an upload to Debian unstable
> causes widespread failure in unstable, and it could have been easily
> prevented if Salsa CI pipeline had run for the package and revealed
> the problem before upload to archive for everyone to suffer.
> 
> This message was prompted by the fact that right now we have a massive
> large of Python packages affected by the "No module named 'packaging'"
> bug [1] which would have been caught by Salsa CI running the
> autopkgtest job before upload [2]. I don't want to blame maintainers
> for missing on some details while doing new releases - it happens. But
> systematically not using available and easy testing facilities does
> annoy me.

Or, if your package has autopkgtests, you could actually run them as a part
of your local building and testing workflow, but (as I'm whining for maybe
a 3rd time here) this is apparently unpopular nowadays so I'm looking
forward to suggestions for integrating non-local checks into the old style
workflow.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?

[Andrey Rakhmatullin]

On Tue, Aug 20, 2024 at 10:44:30PM -0700, Otto Kekäläinen wrote:
> > Something that many developers are probably not aware of is that they
> > can enable CI for a repository with no code changes at all and with
> > a single command:
> >
> >  salsa update_projects $NAMESPACE/$PROJECT \
> >   --jobs yes --ci-config-path recipes/debian.yml@salsa-ci-team/pipeline

Yes, this is hidden knowledge.
I think you can find it on some wiki page if someone points you to that
page.

> Thanks, these are great to point out! i will add them to the Salsa CI
> README in next docs update
> (https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/519).

When can one find that README and how can one know about that?
The MR mentions maint-guide and debmake-doc but I assume nobody reads
those except very new packagers.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Removing more packages from unstable

[Andrey Rakhmatullin]

On Wed, Aug 21, 2024 at 10:06:38AM +, Holger Levsen wrote:
> Hi,
> 
> I also like us to remove more broken and unused packages from unstable.
> 
> On Tue, Aug 20, 2024 at 11:20:10AM +0200, Lucas Nussbaum wrote:
> > Maybe we could also reduce the cost of removals for users and potential
> > new maintainers, by improving the information provided in various places
> > on how to get the latest source and binary packages that were in Debian
> > (pointing to snapshot.debian.org).
> > 
> > Things to look at:
> > - messages sent to the BTS when closing bugs for removed packages
> > - tracker.debian.org
> 
> YES, to all of the quoted stuff above. The BTS removal bug for that
> package should have a pointer to snapshot.d.o with the last sources
> as well as instructions how to reopen all bugs which were closed by
> the package removal.

As a first necessary step, all removals need to leave a link to the
removal bug in the tracker. Currently it looks fragile somehow, as in my
experience not all removed packages even have a link chain to it, and when
they do it's a non-obvious one via the removal email and a comment in it
(I think).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Removing more packages from unstable

[Andrey Rakhmatullin]

On Wed, Aug 21, 2024 at 03:39:11PM +0200, Héctor Orón Martínez wrote:
> I am surprised to not see more of those packages in the list, there
> are many packages in those ecosystems with popcon between 1-10 users.

popcon wasn't used when building this list though (even via the key
packages condition, because AFAIK popcon is no longer used there). Most
libraries just don't have RC bugs.

I checked several from the list:

golang-github-crewjam-saml - unfixed CVE, "Let's remove it from bookworm.
No reverse dependency.". There is a git commit with a new upstream version
that wasn't uploaded.
golang-github-jesseduffield-asciigraph - "Don't release with bookworm",
looks like it's not buggy, just useless.
node-mermaid - FTBFS, has git commits with fixes (not for everything I
guess) that weren't uploaded.
node-trust-webcrypto - FTBFS
ruby-diaspora-federation - FTBFS
ruby-uglifier - FTBFS

> I have also been wondering if we could take a different approach for
> packaging libraries for language ecosystems that already have
> packaging managers to play nicer with Debian packaging
> maintainability. I find myself when I need to use such libraries I
> need to build my own bundle to support specific applications since
> Debian packaged versions don't tend to work well with the application
> (the same is true for Rust, Python, etc.)

It's a very big and very controversial topic (at least if by "don't tend
to work well" you mean that we have too old or in some cases too new
versions).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Removing more packages from unstable

[Andrey Rakhmatullin]

On Wed, Aug 21, 2024 at 08:40:15PM +, weepingclown wrote:
> I believe at least some of these packages were probably packaged as
> dependencies for packaging lazygit. I am not sure which all, but I
> remember atleast gocui, pty and termbox-go to be needed by lazygit in
> one way or another. There has been further work on packaging lazygit
> towards the end of the previous year, which I believe was mostly
> finished, that was then delayed by the person primarily focusing on this
> being the chief organizer for DebConf24. I am not sure removing them is
> the best idea, given it is part of an ongoing work.

This reminded me of some "library" packages (I don't remember the
language) that are RC-buggy and IIRC orphaned that are stated to be deps
of some large project which is no longer in unstable.
I wonder if such leaf libraries should be removed even when not RC-buggy,
but it's unclear who can decide that (in those cases it could be the one
who orphaned them).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?

[Andrey Rakhmatullin]

On Fri, Aug 23, 2024 at 04:00:25PM -0400, Theodore Ts'o wrote:
> On Fri, Aug 23, 2024 at 03:08:11PM +0200, Marco d'Itri wrote:
> > > Salsa CI?)
> > The effort needed to do so is so small that the question really should 
> > be "why should I NOT spend a few seconds enabling Salsa CI?".
> > 
> > > 3)  What's the simple recipe for enable Salsa CI?
> > salsa update_projects $NAMESPACE/$PROJECT \
> >   --jobs yes --ci-config-path recipes/debian.yml@salsa-ci-team/pipeline
> 
> OK, more stupid questions.  What is "$NAMESPACE"?

The parent of the repo.

> And I thought I saw something about a debin/salsa-ci.yml file?

AFAIU it's optional.

> 
> And is this web page authoratative?  Or just a false search positive?
> 
> https://salsa.debian.org/salsa-ci-team/pipeline#basic-use
> 
> It doesn't mention the "salsa" command at all

That salsa(1) command is just a fancy way to change the "CI/CD
configuration file" repo setting.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

[Andrey Rakhmatullin]

On Sat, Aug 31, 2024 at 07:06:30PM -0400, Jonathan Kamens wrote:
> Hey folks,
> 
> I had to step away from working on apt-listchanges
>  for quite a while (nearly
> a year), and upon stepping back into it today and pushing some changes to
> Salsa, I discovered that the build pipeline—which is configured outside my
> Salsa project so as far as I know I am unable to modify it—is failing. See,
> for example, this job
> , in
> particular (note the line in bold):
> 
>...
>|dh clean --with python3 --buildsystem=pybuild dh_auto_clean
>-O--buildsystem=pybuild I: pybuild base:311: python3.12 setup.py
>clean /usr/lib/python3/dist-packages/setuptools/__init__.py:88:
>_DeprecatedInstaller: setuptools.installer and fetch_build_eggs are
>deprecated. !!
>
> 
>Requirements should be satisfied by a PEP 517 installer. If you are
>using pip, you can try `pip install --use-pep517`.
>
> 
>!! dist.fetch_build_eggs(dist.setup_requires) */usr/bin/python3.12:
>No module named pip* Traceback (most recent call last): ...|
> 
> Both debuild and sbuild work fine when I run this build locally, it's just
> the Salsa pipeline that's failing.
> 
> Any advice about what to do here to fix this?

It didn't install B-D-Indep, because it only wanted to run clean, and to
run clean your package actually needs at least pyyaml and pytest, per
`setup_requires`, and maybe more.

sbuild -s --no-arch-all --no-arch-any fails with the same error.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing

[Andrey Rakhmatullin]

On Mon, Sep 02, 2024 at 11:15:50AM -0400, Jonathan Kamens wrote:
> P.S. Wow, diffoscope has a /lot/ of dependencies. I understand why, but
> still... wow.

(Note that those are Recommends and that there is diffoscope-minimal)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

backward/forward binary compatibility checker

[Andrey Ponomarenko]

Colleagues, I'm software engineer from Institute for System
Programing of Russian Academy of Sciences and we are developing a free
lightweight tool for checking backward/forward binary compatibility of
shared C/C++ libraries in OS Linux. It checks interface signatures and
data type definitions in two library versions (headers and shared
objects) and searches ABI changes that may lead to incompatibility.
We have released 1.1 version of this tool and we'd like you to consider
its usefulness for your project.
The wiki-page with the latest release of binary compatibility checker is
http://ispras.linux-foundation.org/index.php/ABI_compliance_checker

Andrey Ponomarenko


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: backward/forward binary compatibility checker

[Andrey Ponomarenko]

Guillem Jover wrote:
> Hi!
>
> On Thu, 2009-08-06 at 18:38:41 +0400, Andrey Ponomarenko wrote:
>   
>> Colleagues, I'm software engineer from Institute for System
>> Programing of Russian Academy of Sciences and we are developing a free
>> lightweight tool for checking backward/forward binary compatibility of
>> shared C/C++ libraries in OS Linux. It checks interface signatures and
>> data type definitions in two library versions (headers and shared
>> objects) and searches ABI changes that may lead to incompatibility.
>> We have released 1.1 version of this tool and we'd like you to consider
>> its usefulness for your project.
>> The wiki-page with the latest release of binary compatibility checker is
>> http://ispras.linux-foundation.org/index.php/ABI_compliance_checker
>> 
>
> How does this compare with projects like icheck or abicheck?
>
> regards,
> guillem
>
>
>   

1) ABIcheck was intended for entirely other purposes. ABIcheck is a tool
for checking an application's compliance with a library's ABI.
ABI-compliance-checker was intended for checking backward binary
compatibility of a library. For more information about icheck see:
http://abicheck.sourceforge.net/

2) icheck was intended for the same purposes as an
ABI-compliance-checker, but icheck has many drawbacks:
a) icheck does not support C++ libraries (or C libraries with C++
parts).
b) icheck does not divide ABI and API changes because it does not
check shared objects.
c)  icheck contains 467 files and 61 sub-folders;
ABI-compliance-checker is a single file.
d) icheck searches changes in `gcc -E -x c-header header_name.h`
output, that represent a header after preprocessing - it is a very
inconveniently  method because it need a lot of code for parsing header
(about 750 kb of code); ABI-compliance-checker searches differences in
the `gcc -fdump-translation-unit header_name.h` output, that represents
a syntax tree of the header files.
e) as described in the documentation
(http://www.digipedia.pl/man/icheck.1.html) icheck need three runs to
get compatibility report - it is not easy.  
f) icheck compliance report is a plain text file,
ABI-compliance-checker provide convenient report in HTML format.
g) icheck 0.9.7 failed to run from the first time on my OpenSUSE11.1
with error message like "Can't locate CParse/Parser/PerlXS.pm".

Re: backward/forward binary compatibility checker

[Andrey Ponomarenko]

Steve Langasek wrote:
> On Fri, Aug 07, 2009 at 04:57:38PM +0400, Andrey Ponomarenko wrote:
>   
>> 2) icheck was intended for the same purposes as an
>> ABI-compliance-checker, but icheck has many drawbacks:
>> 
>
> [...]
>
>   
>> c)  icheck contains 467 files and 61 sub-folders;
>> ABI-compliance-checker is a single file.
>> 
>
> I am concerned that you think this is a feature.
>
>   
I think that tool designed for one simple feature must be in one file.
>   
>> d) icheck searches changes in `gcc -E -x c-header header_name.h`
>> output, that represent a header after preprocessing - it is a very
>> inconveniently  method because it need a lot of code for parsing header
>> (about 750 kb of code); ABI-compliance-checker searches differences in
>> the `gcc -fdump-translation-unit header_name.h` output, that represents
>> a syntax tree of the header files.
>> 
>
> I'm not familiar with -fdump-translation-unit.  Is there any possibility
> that ABI-compliance-checker will overlook ABI changes that icheck will
> catch?
>   
-fdump-translation-unit compiler option provides only more convenient
output (syntax tree) for checking compatibility.
> Does ABI-compliance-checker's representation of the ABI behave in an
> architecture-independent fashion, so that it's possible to draw conclusions
> about ABIs on other architectures than the architecture on which you're
> running the check?
>
>   
ABI-compliance-checker's representation of the ABI really depends on
architecture. But it is not important. You may transfer all your header
files to another host and compare it.
>> e) as described in the documentation
>> (http://www.digipedia.pl/man/icheck.1.html) icheck need three runs to
>> get compatibility report - it is not easy.
>> 
>
>   
I was completely wrong, icheck may generate compatibility report in one
run, sorry.
> Huh?  You have to have a representation of the baseline ABI to compare
> against.  Does ABI-compliance-checker assume that both copies of the header
> will be unpacked and available locally at the same time, in order to be able
> to do everything in "one run"?  That would be much less useful; we don't
> want to have to carry around the actual headers or objects from the
> reference version of the library in order to be able to run these tests, we
> would want to be able to ship a "manifest" representation of the reference
> ABI in our sources to compare against.
>   
You are right, ABI-compliance-checker does not allow such advantages
yet. But usually upstream library developers have all installed versions
on one host (if not, they may install it), and you may transfer all your
header files as well as your "manifest" representation to other host and
check it.
>   
> Cheers,
>   
In general icheck may be used for checking binary compatibility of C
libraries, but it has several drawbacks.

Bug#540458: ITP: eiskaltdc -- Direct Connect protocol client (Valknut fork)

[Tataranovich Andrey]

Package: wnpp
Severity: wishlist
Owner: Tataranovich Andrey 

* Package name: eiskaltdc
  Version : 0.5a
  Upstream Author : Mathias Küster 
* URL : http://sourceforge.net/projects/eiskaltdc/
* License : GPL, LGPLv3
  Programming Lang: C++
  Description : Direct Connect protocol client (Valknut fork)

EiskaltDC++ is a program that uses the Direct Connect protocol.
It is compatible with other DC clients, such as the original DC
from Neomodus, DC++ and derivatives. EiskaltDC++ also interoperates
with all common DC hub software.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

eiskaltdc extra licence

[Andrey Tataranovich]

Hi all, 

I working on packaging eiskaltdc - direct connect client (see #540458).
This program have extra licence information (you can see it on 
http://rootshell.be/~ice/tmp/COPYING) wich installed by default in
/usr/share/eiskaltdc/COPYING. This produced lintian warning
(W: eiskaltdc: extra-license-file usr/share/eiskaltdc/COPYING).

This file is used in About/Licence dialog.

What should I do to satisfy DEBIAN policy?

a) rename/move this file another place and patch code
b) add lintian override

Thanks in advance.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

unit test generator for shared C/C++ library API

[Andrey Ponomarenko]

Dear colleagues,

Linux Verification Center at the Institute for System Programming of RAS
and the Linux Foundation have released a free unit test generator for
shared C/C++  library API. It helps to quickly generate simple ("sanity"
or "shallow"-quality) tests for all functions from the library API using
their signatures and data type definitions straight from the library
header files. The quality of generated tests allows to check absence of
critical errors in simple use cases and can be improved by involving of
highly reusable specialized types for the library. API Sanity Autotest
can execute generated tests and detect all kinds of emitted signals,
early program exits, program hanging and specified requirement failures.
API Sanity Autotest can be considered as a tool for low-cost sanity
checking of library API or as a powerful test development framework.
Also it supports universal Template2Code format of tests, random test
generation mode and other useful features. This tool is free software:
you can redistribute it and/or modify it under the terms of the GNU GPLv2.

We suppose this tool can be very useful for shared library developers
and recommend it for including to Debian Linux.
For more information, please see: 
http://ispras.linux-foundation.org/index.php/API_Sanity_Autotest

Andrey Ponomarenko
Linux Verification Center at the Institute for System Programming of RAS


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b7ab9df.7060...@ispras.ru

Upstream Tracker

[Andrey Ponomarenko]

Hello, Colleagues!

The new service for tracking ABI changes in various C/C++ libraries is
now available for Linux distribution maintainers and upstream developers
- "Upstream Tracker". It may be helpful for analyzing risks of libraries
updating in the Debian Linux. The service includes more than 100
libraries at the moment: OpenSSL, ALSA, glib, cairo, libssh, fontconfig etc.

The service is freely available at:
http://linuxtesting.org/upstream-tracker/

Suggestions for libraries inclusion and feature/bug requests are very
welcome. Thanks!

-- 
Andrey Ponomarenko

Linux Verification Center, ISPRAS
 web:http://www.linuxtesting.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c3d9b07.1000...@ispras.ru

Re: Upstream Tracker

[Andrey Ponomarenko]

On 07/19/2010 04:34 AM, Erik de Castro Lopo wrote:
> Andrey Ponomarenko wrote:
>
>   
>> Hello, Colleagues!
>>
>> The new service for tracking ABI changes in various C/C++ libraries is
>> now available for Linux distribution maintainers and upstream developers
>> - "Upstream Tracker". It may be helpful for analyzing risks of libraries
>> updating in the Debian Linux. The service includes more than 100
>> libraries at the moment: OpenSSL, ALSA, glib, cairo, libssh, fontconfig etc.
>>
>> The service is freely available at:
>> http://linuxtesting.org/upstream-tracker/
>>
>> Suggestions for libraries inclusion and feature/bug requests are very
>> welcome. Thanks!
>> 
> That is fantastic
>
> I was very pleased to see my libsrary libsndfile up there:
>
> http://linuxtesting.org/upstream-tracker/versions/libsndfile.html
>
> Would also love to see my other library libsamplerate up there:
>
> http://www.mega-nerd.com/libsamplerate/download.html
>   

Added to:
http://linuxtesting.org/upstream-tracker/versions/libsamplerate.html

> Cheers,
> Erik
>   


-- 
Andrey Ponomarenko

Linux Verification Center, ISPRAS
 web:http://www.linuxtesting.org
 mail:   upstream-trac...@linuxtesting.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c43f898.1020...@ispras.ru

Re: Upstream Tracker

[Andrey Ponomarenko]

Hello!

On 07/16/2010 02:28 PM, Guus Sliepen wrote:
> On Wed, Jul 14, 2010 at 03:09:59PM +0400, Andrey Ponomarenko wrote:
>
>   
>> The new service for tracking ABI changes in various C/C++ libraries is
>> now available for Linux distribution maintainers and upstream developers
>> 
> [...]
>   
>> Suggestions for libraries inclusion and feature/bug requests are very
>> welcome. Thanks!
>> 
> It looks very nice already! A few suggestions:
>
> - Allow overrides to be defined (like how lintian does this), so that you can
>   remove selected warnings. For example, I see a lot of warnings when a 
> library
>   #defines its version number.
>
> - Check whether the soname is bumped or not, because changes to the ABI are
>   allowed then. Perhaps the different versions of a library could be grouped 
> by
>   the sonames used.
>   

Done. Thank you for an idea.
The example is here:
http://linuxtesting.org/upstream-tracker/versions/libjpeg.html

> - Can you subscribe and get emails when a new version of a certain library has
>   been checked? That would be most helpful for both upstream and downstream
>   developers.
>   

If you want to subscribe to the Upstream Tracker news then send a
message to mailto:upstream-trac...@linuxtesting.org with the subject
"subscribe".

> And I agree with Paul Wise that an article on LWN about this would be a good 
> thing :)
>
>   


-- 
Andrey Ponomarenko

Linux Verification Center, ISPRAS
 web:http://www.linuxtesting.org
 mail:   upstream-trac...@linuxtesting.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c470f1e.5000...@ispras.ru

Re: Upstream Tracker

[Andrey Ponomarenko]

Hello!

On 07/20/2010 06:58 AM, Jay Berkenbilt wrote:
> Andrey Ponomarenko  wrote:
>
>   
>> - "Upstream Tracker". It may be helpful for analyzing risks of libraries
>> updating in the Debian Linux. The service includes more than 100
>> libraries at the moment: OpenSSL, ALSA, glib, cairo, libssh, fontconfig etc.
>> 
> I'd like to throw my voice in among those who think this is an excellent
> idea.  I've often thought about implementing something like this as a
> checker for code I've worked with in a commercial environment, but
> somehow this idea never occurred to me.  I hope it catches on.
>
>   
>> Suggestions for libraries inclusion and feature/bug requests are very
>> welcome. Thanks!
>> 
> The tiff library has been notorious about introducing accidental ABI
> changes.  I've sort of taken on the role as ABI police in recent years.
> Actually, I got my start as a Debian developer by managing a libtiff
> soname bump that was required as a result of an accidental ABI change.
> Analyzing the ICU library would also be interesting

Added to:
http://linuxtesting.org/upstream-tracker/versions/icu4c.html
and
http://linuxtesting.org/upstream-tracker/versions/libtiff.html

> though less useful
> since they bump the soname to match the version number (not generally
> good practice, of course).  They make an effort to keep most of their
> ABI stable, though there are interfaces marked "experimental" that
> change.  I don't see how a tool like this could track that since it's
> just indicated in comments, though there are certainly possibilities
> that come to mind (like special markers, etc.).
>
> tiff: http://libtiff.maptools.org
> ICU: http://www.icu-project.org
>   


-- 
Andrey Ponomarenko

Linux Verification Center, ISPRAS
 web:http://www.linuxtesting.org
 mail:   upstream-trac...@linuxtesting.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c4712b8.60...@ispras.ru

Re: Upstream Tracker

[Andrey Ponomarenko]

On 07/22/2010 05:40 AM, Paul Wise wrote:
> On Wed, Jul 14, 2010 at 7:09 PM, Andrey Ponomarenko  wrote:
>
>   
>> Suggestions for libraries inclusion and feature/bug requests are very
>> welcome. Thanks!
>> 
> I'd suggest looking at each library in Debian
Do you mean the http://packages.debian.org/testing/libs/ list?

> and seeing which
> libraries you are missing that have very high numbers of reverse
> dependencies and which have very high numbers of recursive reverse
> dependencies. You could also search the BTS for bugs about ABI issues
> and include any libraries affected by those.
>
>   


-- 
Andrey Ponomarenko

Linux Verification Center, ISPRAS
 web:http://www.linuxtesting.org
 mail:   upstream-trac...@linuxtesting.org


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

Re: Upstream Tracker

[Andrey Ponomarenko]

On 07/23/2010 12:22 PM, Paul Wise wrote:
> On Fri, Jul 23, 2010 at 3:49 PM, Andrey Ponomarenko  wrote:
>   
>> On 07/22/2010 05:40 AM, Paul Wise wrote:
>> 
>>> I'd suggest looking at each library in Debian
>>>   
>> Do you mean the http://packages.debian.org/testing/libs/ list?
>> 
> Yes, or any package shipping a library in /lib or /usr/lib.
>
>   
OK, I've started to add one by one ...

-- 
Andrey Ponomarenko

Linux Verification Center, ISPRAS
 web:http://www.linuxtesting.org
 mail:   upstream-trac...@linuxtesting.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c49519f.5060...@ispras.ru

Using ccache with git-buildpackage

[Andrey Rahmatullin]

Hello. I use git-buildpackage and want to use ccache. I tried exporting
overriden CC and PATH, but that had no effect and `echo' in debian/rules
shows that both variables are reverted to the defaults. Does
git-buildpackage clear the environment? How can I use ccache in this
configuration?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Using ccache with git-buildpackage

[Andrey Rahmatullin]

On Mon, Oct 04, 2010 at 12:28:06PM +0100, Simon McVittie wrote:
> I believe git-buildpackage calls debuild, which itself clears the environment.
> debuild is controlled by ~/.devscripts, in which I have, among other things:
> 
> DEBUILD_PREPEND_PATH=/usr/lib/ccache
> DEBUILD_PRESERVE_ENVVARS=CCACHE_DIR
Thanks, that works.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Misc Developer News (#24)

[Andrey Rahmatullin]

On Mon, Nov 08, 2010 at 09:48:13AM +0800, Paul Wise wrote:
> > I suspect that wouldn't be received very well. I'll file it on debshots 
> > though.
> There isn't much the debshots author can do if upstreams for the
> screenshot programs don't want support for uploading screenshots to
> screenshot sites.
The issues for ksnapshot are (at least):
https://bugs.kde.org/show_bug.cgi?id=253375
https://bugs.kde.org/show_bug.cgi?id=175128
https://bugs.kde.org/show_bug.cgi?id=138443

-- 
WBR, wRAR


signature.asc
Description: Digital signature

compatibility analysis for Java libraries

[Andrey Ponomarenko]

Hello,

I know that some Debian maintainers use ABI Compliance Checker (ACC)
tool along with Ustream Tracker at LinuxTesting.org [1] for testing
backward compatibility of C/C++ libraries. Now I want to inform you
about opened Upstream Tracker for Java libraries [2]. Any feedback is
much appreciated. Proposals to add libraries will be accepted at [3].
Thanks!

[1] http://linuxtesting.org/upstream-tracker/
[2] http://linuxtesting.org/upstream-tracker/java/
[3] mailto:upstream-trac...@linuxtesting.org


BTW
We are looking for sponsorship to continue development of our tools.
Please send any proposals to upstream-trac...@linuxtesting.org
<mailto:upstream-trac...@linuxtesting.org>

-- 
Andrey Ponomarenko
Department for Operating Systems at ISPRAS
 web:http://www.LinuxTesting.org
 mail:   aponomare...@ispras.ru

Bug#607445: ITP: gkrellm-gkrellmpc -- GKrellM plugin for controlling MPD

[Andrey Rahmatullin]

Package: wnpp
Severity: wishlist
Owner: Andrey Rahmatullin 

* Package name: gkrellm-gkrellmpc
  Version : 0.1+beta10
  Upstream Author : Mina Naguib 
* URL : http://mpd.wikia.com/wiki/Client:GKrellMPC
* License : GPL 2.0
  Programming Lang: C
  Description : GKrellM plugin for controlling MPD



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

Bug#610009: ITP: xboxdrv -- A Xbox360 gamepad driver for the userspace

[Andrey Rahmatullin]

Package: wnpp
Severity: wishlist
Owner: Andrey Rahmatullin 

* Package name: xboxdrv
  Version : 0.6.4
  Upstream Author : Ingo Ruhnke 
* URL : http://pingus.seul.org/~grumbel/xboxdrv/
* License : GPL3+
  Programming Lang: C++
  Description : A Xbox360 gamepad driver for the userspace



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

Re: Does it matter that the squeeze installer...

[Andrey Rahmatullin]

On Mon, Jan 24, 2011 at 02:28:28PM +, David Goodenough wrote:
> thinks that Window 7 is Windows Vista.  I am installing an amd64 machine
> which already has the 64 bit version of Windows 7 Professional on it, and
> when I came to install Debian using the squeeze installer RC2 in the grub
> bit it said that it had detected Windows Vista loader.  I am not sure this
> matters, but it might confuse the novice.  If they are the same then it
> should say Windows Vista or 7 loader.
They are not the same and here os-prober successfully detected Win7 as
"Windows 7 (loader) (on /dev/sdb1)".

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Cedilla removed from sid, users complain

[Andrey Rahmatullin]

On Tue, Jan 25, 2011 at 07:14:39PM +0100, Juliusz Chroboczek wrote:
> I'm upstream for Cedilla [1,2], which has been orphaned and removed from
> Sid.  I'm receiving e-mail from Debian users of Cedilla, asking me what
> is the suggested replacement.  What shall I answer?
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610903

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Make Unicode bugs release critical?

[Andrey Rahmatullin]

On Fri, Feb 11, 2011 at 11:14:42AM +0100, Miroslav Kure wrote:
> > However, I'm curious: is there a lot of software that is broken with
> > Unicode, particularly with the UTF-8 encoding? I can't remember anything
> > much in recent times.
> Mostly it is just the old stuff like
>  - eterm, aterm
>  - elvis
>  - X tools from the basic package (xman, xmessage, xmore, ...)
>  - TeX without additional packages
- tr(1)

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Make Unicode bugs release critical?

[Andrey Rahmatullin]

On Fri, Feb 11, 2011 at 01:20:24PM +0100, Torsten Werner wrote:
> >>> However, I'm curious: is there a lot of software that is broken with
> >>> Unicode, particularly with the UTF-8 encoding? I can't remember anything
> >>> much in recent times.
> >> Mostly it is just the old stuff like
> >>  - eterm, aterm
> >>  - elvis
> >>  - X tools from the basic package (xman, xmessage, xmore, ...)
> >>  - TeX without additional packages
> > - tr(1)
> grep, sed, awk, bash, ...
http://bugs.debian.org/495677

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: RFA: sonata, mpdscribble,...

[Andrey Rahmatullin]

On Fri, Feb 11, 2011 at 03:14:51PM +0100, Michal Čihař wrote:
> mpdscribble
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612908
I use this so I'll take care.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: RFA: sonata, mpdscribble,...

[Andrey Rahmatullin]

On Fri, Feb 11, 2011 at 03:03:06PM +, Simon McVittie wrote:
> > as I don't use MPD for quite a long time now, it somehow does not make
> > sense to maintain MPD related packages anymore. Simply I don't
> > have environment to test them.
> On Decklin Foster's RFA thread, there was talk of forming a mpd team, or
> possibly maintaining mpd and friends in pkg-multimedia. It'd seem sensible
> for them all to go to the same team?
I already have two MPD client packages (qmpdclient and gkrellm-gkrellmpc)
so I'm interested too.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Upcoming FTPMaster meeting

[Andrey Rahmatullin]

On Sat, Feb 12, 2011 at 02:57:59PM +0100, Adam Borowski wrote:
> Trying to run unmodified Debian on 64MB is a suicide, I'd say the weakest
> type that are going to run stock Debian are chroots on n900, which, with
> 256MB, can handle all the phony stuff together with decompression just fine.
> If you allow for everything but the decompression to be swapped out, even
> 128MB would work reasonably.
I think that VPS'es with 128Mb RAM are still sold, not to mention existing
installations.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: dh_make and dep5

[Andrey Rahmatullin]

On Thu, Mar 10, 2011 at 09:54:19AM +, Alessio Treglia wrote:
> >  Should I fill a bug report ?
> By reading the changelog [1], it seems the maintainer has already
> accomplished that.
> 
> [1] http://goo.gl/oomj3
Yes, see /usr/share/debhelper/dh_make/licenses/

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Setting file capabilites of files shipped in binary packages

[Andrey Rahmatullin]

On Sun, Mar 13, 2011 at 08:24:16PM +, Emilio Pozuelo Monfort wrote:
> That's exactly what gnome-keyring from experimental does (for CAP_IPC_LOCK). 
> You
> can have a look at its postinst.
wireshark-common also does that since 2010.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Best practice for cleaning autotools-generated files?

[Andrey Rahmatullin]

On Thu, Mar 17, 2011 at 09:17:27AM +, Lars Wirzenius wrote:
> > > My rule is: when there is something non-free or when the amount of
> > > useless stuff is huge. For example I would repack a tarball with a
> > > small program and 20Mb of embedded code copies of all its dependencies
> > > to remove the deps.
> > What about .svn dirs?
> I would not re-package a tarball because of .svn dirs, unless they
> actuall cause breakage or are large. 
.svn dirs are usually exactly the same size as all other files, unless
there are huge non-committed files in the tarball.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: m68k too slow for https? Re: people.debian.org will move from ravel to paradis and become HTTPS only

[Andrey Rahmatullin]

On Mon, Jul 14, 2014 at 10:36:10AM +0100, Iain R. Learmonth wrote:
> If Debian stops supporting embedded platforms, it stops being a universal
> operating system.
FSVO universal.
I think this is not a good argument unless/until we have some more-or-less
common and official agreement about what does universal mean for us.

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140714094817.ga28...@belkar.wrar.name

Re: Override disparity checks (Was: Re: Transition plan for changing the default init system)

[Andrey Rahmatullin]

On Thu, Jul 17, 2014 at 09:10:24PM +0200, Michael Banck wrote:
> > Looking at the policy again, I think extra is (mis)used quite too
> > often.
> 
> Part of the problem could be that dh_make at least at one point (maybe
> still does) put "extra" as defalt Priority in its templates and it
> might've gotten copy-pasted further on.
Also #660249.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Bug#756446: ITP Backgammon2 - a C# implementation of Backgammon game

[Andrey Rahmatullin]

Control: retitle -1 RFP: backgammon2 -- another implementation of the 
Backgammon game

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140730084304.ga3...@belkar.wrar.name

Re: Bug#756446: ITP Backgammon2 - a C# implementation of Backgammon game

[Andrey Rahmatullin]

On Wed, Jul 30, 2014 at 12:16:25PM +0200, Jelmer Vernooij wrote:
> > Control: retitle -1 RFP: backgammon2 -- another implementation of the 
> > Backgammon game
> The implementation language indeed isn't very relevant to users, but "another"
> is even more vague. What distinguishes it from other backgammon 
> implementations?
The name is bad too.
But this is just an RFP, so...

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140730113518.ga8...@belkar.wrar.name

Re: Bug#756446: ITP Backgammon2 - a C# implementation of Backgammon game

[Andrey Rahmatullin]

On Thu, Jul 31, 2014 at 07:04:42PM +0200, Alexander Alemayhu wrote:
> > The name is bad too.
> > But this is just an RFP, so...
> Why is the name bad?
Too generic.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Andrey Rahmatullin]

On Wed, Sep 03, 2014 at 07:32:49AM +0200, Christian PERRIER wrote:
> At the time, we (font team) decided to go with z9, the fact that
> packages were arch:all (and therefore that the memory cost of
> compression had only an impact on the machine of the developer who
> builds packages), was a strong argument to go with z9.
> 
> Of course, if we go to source only uploads for arch:all, we'll
> reconsider this and eventually revert to default settings.
> 
> (still, this memory impact has never been one on the good old Dell
> Poweredge 2650 that sits in my garage and builds most of the font
> packages I upload. Of course, it is not a buildd that builds
> hundreds of packages a day)
Decompression costs were mentioned too, and they always matter (if they
are significant). Does anyone have numbers about them?

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140903054929.ga16...@belkar.wrar.name

Re: Seeking help with OpenVPN scripts and systemd

[Andrey Rahmatullin]

On Tue, Sep 09, 2014 at 09:26:28PM +0100, Noel Torres wrote:
> openvpn package should Conflitcs systemd in order to avoid systemd being 
> installed 
ITYM "to avoid openvpn being installed".

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140910042544.ga29...@belkar.wrar.name

Re: ppc64 not in any-powerpc ?

[Andrey Rahmatullin]

On Fri, Sep 12, 2014 at 11:48:26AM +0200, Mathieu Malaterre wrote:
> I could not find the answer anywhere. Why is arch:ppc64 not in the
> `any-powerpc` definition ? I would have guessed arch:ppc64 to be very
> close to arch:powerpc...
any means "any OS", not "any arches for this hardware"
https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-wildcard-spec

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912101719.ga11...@belkar.wrar.name

Re: ppc64 not in any-powerpc ?

[Andrey Rahmatullin]

On Fri, Sep 12, 2014 at 03:11:08PM +0200, Johannes Schauer wrote:
> The common fallacy is that the "foo" in "any-foo" is the name of a Debian
> architecture while in fact it is the name of the CPU which is mapped to one or
> more Debian architectures by /usr/share/dpkg/triplettable
Indeed, maybe we need to spell this more explicitly in the Policy?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Aborting installation on unsupported systems

[Andrey Rahmatullin]

On Mon, Sep 15, 2014 at 09:28:45PM +0100, Barak A. Pearlmutter wrote:
> The package "ikarus", another programming language implementation,
> also requires SSE2 support.
> There is a check in the preinst script which aborts installation if
> sse2 is unavailable.
One of my packages works only on certain CPUs and by design it fails to
start on others. The package starts its initscript on install, so the
installation fails on unsupported hardware. I have a grave bug #738927
asking me to fix this behavior and I was told by someone on IRC to leave
it as is. Now I see there are other people doing this so I think I should
ask here for more opinions.

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140916082549.ga23...@belkar.wrar.name

Re: Aborting installation on unsupported systems

[Andrey Rahmatullin]

On Tue, Sep 16, 2014 at 12:02:24PM +0200, Matthias Urlichs wrote:
> You might want to pop up a preinst debconf notice which tells the admin
> that the package will not run here (with an option to fail the install
> if it's an honest mistake).
This may require reimplementing some part of the program in shell (in my
case it's parsing of /proc/cpuinfo, so it's at least possible, but still).

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Aborting installation on unsupported systems

[Andrey Rahmatullin]

On Tue, Sep 16, 2014 at 04:37:00PM -0300, Henrique de Moraes Holschuh wrote:
> > > You might want to pop up a preinst debconf notice which tells the admin
> > > that the package will not run here (with an option to fail the install
> > > if it's an honest mistake).
> > This may require reimplementing some part of the program in shell (in my
> > case it's parsing of /proc/cpuinfo, so it's at least possible, but still).
> 
> Well, depends on how strict you want that parsing to be:
http://git.kernel.org/cgit/utils/cpu/mce/mcelog.git/tree/mcelog.c#n479

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Packaging proprietary software

[Andrey Rahmatullin]

On Wed, Oct 08, 2014 at 03:48:22PM +0200, Mathieu Slabbinck wrote:
> I'm creating a .deb installer for Ubuntu which contains a proprietary
> binary.
> I was wondering if anyone could point me to the best practice way of doing
> this.
>From the purely technical point of view the license doesn't matter.
If you are going to upload your package into the Debian non-free repo,
though, you need to make additional steps, but you didn't mention that.

> Currently I use dh_make to set everything up, but to have everything
> legally compliant, I don't think this is the best choice.
dh_make just creates some files from templates, nothing more. It's up to
you to make sure the result complies with everything you need it to be
compliant with.

> Any advise on how to accomplish a good proprietary binary is appreciated!
If "good" means "compliant with technical parts of Debian policies" then
you can use the same docs as for other packages.

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141009103652.ga7...@belkar.wrar.name

Re: Re: Bug#760592: ITP: bsdowl -- bmake macros for building OCaml projects, TeX projects, and more

[Andrey Rahmatullin]

On Mon, Oct 27, 2014 at 12:11:33PM +0100, Michael Grünewald wrote:
> I started to work on packaging. This is pretty stalled, as it is very
> hard to find adequate documentation or help. I am unsure how I can
> package the software I write to help Debian users to install and use it.
> 
> The problem I have now is:
> 
> % debuild -us -uc
> …
> dpkg-source: info: local changes detected, the modified files are:
>  bsdowl-2.2.1/config.log
> …
> 
> Writing a config.log file is a normal side-effect of the configuration
> step. How do I tell the package building system about this?
Does your orig tarball contain config.log?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: A concerned user -- debian Guidelines

[Andrey Rahmatullin]

On Mon, Nov 10, 2014 at 09:57:50AM +0100, Nathael Pajani wrote:
> You certainly heard about "debianfork" (http://debianfork.org/) and from a 
> user point of
> view this is a tragedy.
Don't worry, this is a joke.

> When a (big ?) pool of users is not happy to the point of suggesting to fork 
There is no evidence of this.

> You'll notice that the fork has not been started yet, as (I think) many still 
> hope this
> can end the right way, with USERS taken into account. All of them.
I guess there is another reason it's not started.

> Still from my point of view, this means that the user can choose between 
> alternatives for
> almost everything when there is a choice. Let's cite a few to make it evident 
> : Vim/emacs,
> KDE/Gnome/All/the/others/ones, Debian kernel/custom kernel, 
We don't support every custom kernel.
We don't try to make every WM/DE have every option or support
interoperability with all other software if it wasn't done by the
upstream.

> Then, when Debian developers are about to choose to impose a given init 
> system on it's
> users instead of giving them the choice, I feel like it being a breach in 
> Debian's Social
> contract and Ian Murdock's initial intention when he created Debian.
You weren't given a choice of a libc either.

> Yes, making an init-independent system is more work than the easy, "single 
> init" solution.
> But I think there are people out there which will be willing to spend time on 
> this.
There is no evidence of this.

> But GNU/Linux is NOT uniformity. It is choice. It is alternatives. It is 
> options.
http://islinuxaboutchoice.com/


-- 
WBR, wRAR


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141110093717.ga13...@belkar.wrar.name