Hi,
On 09-06-2024 1:56 p.m., rhys wrote:
So given that these no longer fit the "old and busted" description, is Debian
going to stick with the decision to not support them? Or is Debian going to continue to
support this processor, since it is still apparently a viable product, enough that new
Hi
On 14-06-2024 8:09 p.m., rhys wrote:
Even under the bookworm "Intel 686-only" rules, it still works, so I still use
it. It's built, it runs, it serves a purpose, and it costs very little.
And you can keep trying that until it doesn't work for you anymore,
we're not saying we'll hold you
Hi
On 25-06-2024 6:55 p.m., Helmut Grohne wrote:
This is very cool. Running autopkgtests in system containers without
being root (or incus-admin) very much is what I'd like to do. And it's
much better if I don't have to write my own container framework for
doing it. I couldn't get it to work loc
Hi.
On 25-06-2024 8:18 p.m., Gioele Barabucci wrote:
I'd like to take this chance to suggest, instead of writing more
documentation, changing the autopkgtest packaging so that it is split
into various per-backend packages, each of which provides a ready-to-go
pre-configured environment. See
Hi,
On 30-07-2024 10:21, Simon McVittie wrote:
Please note that imtoas...@mail.com is (presumably) not Paul,
Correct.
the subject line is not what the release team
would use,
Correct.
and Paul seems unlikely to send official Debian announcements
through a gmx.com mail relay with a (forge
Hi all,
On 03-08-2024 22:37, Salvo Tomaselli wrote:
At the bottom, is it ok for a package to have a single maintainer or not?
I have never wanted to be the single maintainer of a package, and here I
am, I'm member of a bunch of teams, but most of my packages uploads (not
a lot luckily) are f
Hi,
On 16-08-2024 17:46, Alec Leamas wrote:
All other builds are OK. Has anyone a hint about what might be going on here?
https://release.debian.org/testing/arch_qualify.html armel column.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
Hi helmut,
+1
On 20-08-2024 07:28, Helmut Grohne wrote:
* As packages fail to migrate to testing for a long time, a release
team member eventually looks at the package.
I recognize myself here. But to be totally fair, that's *mostly* about
testing, and we have processes for that. Once
Package: wnpp
Severity: normal
C (?) Programmers help wanted.
Upstream of lesstif is not active anymore and I have committed myself to
help as much as I can to improve the Debian package (also by committing
patches upstream). The popcon of this library is pretty high, currently
around 15694 insta
Package: wnpp
Severity: wishlist
Owner: Paul Gevers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
* Package name: daisy-player
Version : 4.0.2
Upstream Author : Jos Lemmens
* URL : http://web.inter.nl.net/users/lemmensj/
* License : GPL version 2 or higher
Hi,
I am looking into dbconfig-common RC bug 720517 [1] and I was wondering
what the general idea is of maintainer scripts changing the permissions
and/or owners of configuration files and the use of dpkg-statoverride. I
myself find it unacceptable that updating a package changes the
permissions/o
On 07-10-14 15:40, Ian Jackson wrote:
> Also I don't see in your references an explanation from anyone as to
> why dbconfig-common does this.
I you mean with "why": "why is it implemented this way" than that is
exactly the question that I am asking myself looking at the code, if you
mean "why does
On 07-10-14 19:56, Paul Gevers wrote:
> I am trying to come up with a patch against dpkg-statoverride that sets
> the ownership and permissions upon creation, but not upon updates.
OOPS, what a stupid mistake to type. I meant dbconfig-common in the line
above.
@ Henrique de Moraes Ho
On 09-10-14 02:17, Henrique de Moraes Holschuh wrote:
> On Wed, 08 Oct 2014, Paul Gevers wrote:
>> Thanks for the careful response. And no, as mentioned above, I didn't
>> mean to use dpkg-statoverride itself. dbconfig-common uses debconf and
>> ufc to manage the co
Hi
>> BTW there's around 2000 open bugs marked as moreinfo, the oldest is dated
>> Sun, 29 Mar 1998 21:03:03 UTC.
>
> For moreinfo bugs, you are not considered a bad maintainer if you send a "I
> will close this if you don't reply"-response after some time and then do that
> after some more waiti
Hi Jerome,
On 02-06-13 06:30, Jerome BENOIT wrote:
> I have to deal with docbook-xsl for one of my package.
> I am not familiar with docbook-xsl stuff, so my question may sound naive.
> It appears that the upstream stuff play with docbook-xsl version 1.75.2 ,
> but not 1.76.1 : only the last one i
Hi,
On 04-06-13 14:06, Niels Thykier wrote:
> [1] We normally filter out certain type of RC bugs (incl. but not
> limited to license issues), where we consider it unreasonable to demand
> a resolution within the usual deadline (i.e. 14 days of "non-activity" +
> 7 days after a d-d notice).
> # #7
Hi
I agree we need good build logs.
On 14-06-13 14:14, Jakub Wilk wrote:
> * Matthias Klose , 2013-06-14, 13:35:
>> So I'm proposing for jessie:
>>
>> - File and track issues for packages not enabling verbose builds.
>> https://buildd.debian.org/~brlink/bytag/W-compiler-flags-hidden.html
>
> I a
On 15-09-13 11:48, Paul Wise wrote:
> On Sat, Sep 14, 2013 at 8:16 PM, Timo Weingärtner wrote:
>
>> Packaging is prepared, an upload to mentors is waiting for the bug number.
>
> FYI, ITP stands for *intent* to package. The ITP comes before the
> package to prevent duplication of effort. If you m
On 29-09-13 08:40, Norbert Preining wrote:
> What is going wrong here?
For whatever reason, the amd64 build is picking up i386 paths. I don't
know how that happens, except that I expect it is some multi-arch
twitch. I recommend you build your packages in a chroot to avoid this
(an other) issues. I
Hi,
On 08-10-13 11:14, Просветов Евгений wrote:
> What should I do now?
You are asking the wrong forum. This e-mail list is for development of
Debian. If you have trouble installing third-party software, you should
ask this third-party. If you really insist on asking help from Debian,
you could r
Next to Alcester, also a BSP was held in Utrecht, the Netherlands [1].
In total, over two days, we worked with 17 people on a number of bugs:
* 15 RC bugs were fixed or otherwise dramatically improved
* 7 RC bugs were marked notfound in stable and already fixed in wheezy
* 18 release-notes bugs w
On 17-10-12 23:48, Matthias Klose wrote:
> On 17.10.2012 21:49, Steve Langasek wrote:
>> On Wed, Oct 17, 2012 at 11:30:38AM -0700, Christoph Egger wrote:
>>> Also remeber, there are packages like cmucl that can only be built by the
>>> same upstream release of itself and can currently survive in De
> The following SHOULD be 0, 1, and 2 levels of quoting, first to last.
>
>>From blahhityblah Fri Jul 8 12:08:34 2011
>>From foobarbaz Fri Jul 8 12:08:34 2011
>> >From quux Fri Jul 8 12:08:34 2011
So if I understand correctly, I now identified my e-mail provider as
using mboxo? I indeed got 1,
On 29-11-12 01:43, Christoph Anton Mitterer wrote:
> On Wed, 2012-11-28 at 19:55 +0100, Paul Gevers wrote:
>> So if I understand correctly, I now identified my e-mail provider as
>> using mboxo? I indeed got 1, 1 and 2 levels of quoting.
> Depends... were you using his webmail?
Hi all,
I don't know how many of you still care for the motif widgetset, but due
to the way I got involved in Debian, I have kept a small eye on it.
Recently ICS [1] release a new version of openmotif, and this time they
stuck a LGPL license on it. I think this is good news, as it means that
we c
Hi Graham,
On 24-12-12 10:41, Graham Inggs wrote:
> The openmotif package has recently been orphaned since the maintainer
> is MIA.
Not quite, the maintainer said he didn't have time anymore. It is a
detail anyway.
> I have been working on a new packaging of the LGPL motif from scratch
> using d
[You set mail-follow-up to debian-devel, so here it goes to the list.]
On 21-02-13 15:48, Helmut Grohne wrote:
> So yeah, bug reports, comments and of course patches are welcome.
This indeed looks very useful. However, I don't think it is really
useful to trigger on common changelog and copyright
Hi
Is it just me or am I the only one getting bug reports from bugs that
don't seem to exist on bugs.debian.org.
The latest bug that I can find is 703078. The next one [1] fails and
after that it says it can not be found.
An error occurred. Error was: Bad bug log for Bug 703079. Unable
Hi Andre,
On 30-03-13 08:47, DutchGlory wrote:
> i have a question about Partimage: Would it be possible to add EXT4
> support..?? (Wheezy x64)
This is the wrong platform to ask such a question. You should file a
wish-list bug against the partimage package if it is not already
present. However, t
On 05-05-13 04:30, Dmitry Smirnov wrote:
[Disclaimer: I haven't looked at the contents of your concern].
> Since beginning of 2013 I tried to raise concerns about it but got no
> reply from current maintainers whatsoever (see #700917).
>
> I think now would be a good time to upload updated packa
Hi all,
On 15-02-14 21:11, Russ Allbery wrote:
> All I'm saying, and all I think Steve is saying, is that audio not working
> out of the box is some kind of bug. That's fine -- software has bugs. We
> all know that. It might be an important bug, it might be a normal bug, it
> might be a wishlis
On 21-02-14 10:57, John Paul Adrian Glaubitz wrote:
> On 02/21/2014 09:29 AM, Mario Lang wrote:
>> I am sorry, both are not an option for me, since alsamixer is a ncurses
>> program, and pavucontrol apparently requires $DISPLAY to be set.
>>
>> I guess that explains why the accessibility community
Package: wnpp
Severity: wishlist
Owner: Paul Gevers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: pasdoc
Version : 0.13.0
Upstream Author : Michalis Kamburelis
* URL : http://pasdoc.sipsolutions.net
* License : GPL-2+
Programming Lang
Package: wnpp
Severity: wishlist
Owner: Paul Gevers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
* Package name: ebook-speaker
Version : 1.1
Upstream Author : Jos Lemmens
* URL : http://web.inter.nl.net/users/lemmensj/
* License : GPL-2+
Programming Lang
On 09/17/11 11:29, Samuel Thibault wrote:
> Paul Gevers, le Sat 17 Sep 2011 11:14:07 +0200, a écrit :
>> ebook-speaker is a command-line electronic book reader that reads out eBooks
>> using speach synthesis. (Currently only the EPUB format is supported).
>> It has a
Hi,
I applaud this initiative.
On 13-02-15 18:28, Reproducible builds folks wrote:
> If you want to help, a first step is to check the reproducibility of
> your packages [DDLIST]. Feel free to ask for help on the
> mailing list or in
> #debian-reproducible on irc.debian.org.
It would help me if
Hi,
On 27-11-18 12:38, Hideki Yamane wrote:
> Well, we use experimental as "shelter" during freeze, but it's not good
> in my point of view.
>
> - During freeze, it is just ignored by most of the users since they
>wouldn't know there's a newer package in there (and they also afraid
>be
Hi,
On 30-11-2018 20:45, Helmut Grohne wrote:
> * If archive QA gets painful due to broken packages in unstable:
>Ignore those that have no version in testing. It's an easy filter
>with little misclassification.
That may be true for some QA, but for autopkgtesting of migration
candidates
Hi,
On 04-12-2018 20:03, IOhannes m zmölnig (Debian/GNU) wrote:
> as mandated by the policy, i'd like to discuss, whether an epoch bump
> for the new source package "pd-csound" (to be "2:1.01.0-1") is
> warranted, or indeed a good idea.
Can at least the source package not carry the any special ep
Hi Andreas,
On 07-01-2019 11:37, Andreas Tille wrote:
> Any idea what to do?
File a bug against lintian, it's not perfect you know. If you let me
know (maybe in private) the bug number, I may create a merge request for
lintian.
As the creator of the latter warning and as the one that implemented
Hi all,
On 18-01-2019 12:11, Enrico Weigelt, metux IT consult wrote:
> On 18.01.19 01:43, Andreas Beckmann wrote:
>> On Tue, 18 Dec 2018 17:48:06 + Ian Jackson
>> wrote:
>>> Ian Jackson writes ("Re: Conflict over /usr/bin/dune"):
https://www.google.com/search?q=dune+software
https
Hi Jérémy,
On 28-02-2019 16:05, Jérémy Lal wrote:
> the documentations:
> https://release.debian.org/buster/freeze_policy.html
> https://www.debian.org/doc/manuals/developers-reference/ch05.html#bug-security
>
> leave me unsettled about what to do during freeze w.r.t. security
> uploads in testi
Hi Mo,
On 08-03-2019 12:08, Mo Zhou wrote:
> I have two questions given the background:
>
> (1) What is the support status for "isolation-machine" feature?
It's on the todo list, it just that we haven't gotten around to actually
do it. Unfortunately it is slightly more complicated that running l
Hi Shengjing,
On 07-04-2019 03:05, Shengjing Zhu wrote:
> This user case may be not enough to change the default choice of GNOME,
> but I think this should at least be in release notes.
Can you please file a bug against the release-notes package, ideally
with a proposed text?
Paul
signature.a
Hi Christoph,
On 19-07-2019 17:18, Christoph Biedl wrote:
> tl;dr: The file program in unstable is now built with seccomp support
> enabled, expect breakage in some rather uncommon use cases.
This probably warrants an entry in the bullseye release-notes. Should we
already forward your original ma
Hi Lisandro,
On 07-07-2019 16:16, Lisandro Damián Nicanor Pérez Meyer wrote:
>> All autopkgtest failures considered RC for bullseye
>> ===
>>
>> From now on, all autopkgtest failures will be considered release-critical for
>> bullseye. So if your pac
retitle 914333 origami-pdf & pdfproctools both ship /usr/bin/pdfmetadata
reassign -1 src:origami-pdf,src:pdfproctools
thanks
On Thu, 22 Nov 2018 09:37:31 +0100 Jacek Politowski wrote:
> pdfproctools fails to install due to conflicting "/usr/bin/pdfmetadata" file
> which exists also in "origami-pd
Dear all,
TL;DR: please give your constructive feedback on the buster release
period, see the last paragraph.
As the most recent member of the release team [1], I thought it could be
a useful exercise to reflect on the release process and share it with you.
As such a reflection goes, it should s
Hi,
On 07-08-2019 16:57, Ian Jackson wrote:
> Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team:
> ride like the wind, Bullseye!"):
>> No, what I have been perceiving (and pretty please note that this is my
>> personal "feeling") is that maintainers, specially library ma
Hi,
On 18-08-2019 04:46, Lisandro Damián Nicanor Pérez Meyer wrote:
>> I can already trigger all the autopkgtests in unstable for packages that
>> are in experimental, so if you interested in this, please contact me.
>
> **Yes please**. This will certainly help *a lot* specially for us that we
>
Hi Pirate, and other interested parties,
On 09-08-2019 08:22, Pirate Praveen wrote:
> On 2019, ഓഗസ്റ്റ് 9 1:16:23 AM IST, Paul Gevers wrote:
>> I can already trigger all the autopkgtests in unstable for packages
>> that
>> are in experimental, so if you interested in th
Hi,
On 12-09-2019 17:01, Ian Jackson wrote:
> But we need to be clear what's going on and communicate early.
Yes, not on the front page, but there is (first bullet):
https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#deprecated-components
Paul
signature.asc
Des
Hi,
On 30-06-2023 20:14, Jérémy Lal wrote:
is there something like a CI for security uploads ?
Yes.
Paul
OpenPGP_signature
Description: OpenPGP digital signature
Hi,
On 30-06-2023 22:40, Jérémy Lal wrote:
Nice, but how can we see it when we prepare a package for security team ?
You can't. Only the security team has access to the results. After the
packages have been released the results will be published and can be
seen in the history on ci.d.n, e.g.
Hi,
On 21-07-2023 14:20, David Kalnischkies wrote:
How is this to be done? Should some automated mechanism for achieving
this be added, and if so, where?
You already found the retry button from previous replies, but you
don't have to click it to get what you want…
The migration software of
Hi,
On 23-07-2023 17:51, Mark Hymers wrote:
On Tue, 18, Jul, 2023 at 12:45:51PM +0800, YunQiang Su spoke thus..
So I consider to suggest drop mipsel support from the list of official ports.
(And let's keep mips64el port).
Is there consensus on this point? If so, should we start making
arrang
Hi,
On 25-07-2023 16:16, Michael Biebl wrote:
apparently, we in Debian struggle to find good opportunities where to
spend our money.
For ci.d.n, the issue is not money, but the required work to integrate
it into the infrastructure. We need volunteers (or pay people to do the
work), but unles
Hi Helmut,
On 19-08-2023 23:14, Helmut Grohne wrote:
I recognize that this is quite a non-standard way to ask for a MBF. Does
anyone object to me doing it in this way?
I recall I said this before, but just in case. In my opinion (with my
Release Team member hat on, but not on behalf of the t
Hi,
On 15-09-2023 17:52, Andres Salomon wrote:
Any thoughts on this?
Please be aware of bug #1036818 [1]. Currently /proc/cpuinfo is empty on
armel ci.debian.net workers. (I'm failing to spot neon in the list of
features of that machine.)
Paul
[1] https://bugs.debian.org/cgi-bin/bugreport.c
Hi Steve,
On 15-09-2023 21:54, Steve Langasek wrote:
armel != armhf
Of course
and nobody should be running armel on a NEON-capable CPU...
Not sure why you say it like that, I guess you don't meen CI purposes
here. But anyways, it seems that also the arm64 host that runs our armel
and arm
Hi,
On 24-09-2023 10:27, Johannes Schauer Marin Rodrigues wrote:
Is the apt configuration on
those systems set to something that is not the default and should be considered
as well?
How the unstable to testing migration runs work is that they have a
testing testbed (with apt pinning making te
Hi,
On 17-10-2023 22:16, Andrey Rakhmatullin wrote:
Yes, assuming the pre-bookworm Debian i386 architecture fully supports it,
as I don't know what *exactly* was allowed in the "almost i686"
stretch-bullseye i386.
According to the release notes (which *should* be authoritative, but may
have b
Hi,
On 22-10-2023 23:32, r...@neoquasar.org wrote:
If the distinction between "supported" and "not supported" is
going to come down to specific assembler-level instructions, it would
seem that that wont tell most people anything.
Well, if we know which instructions we don't support, it's not
Hi,
On 22-11-2023 12:21, Donald Norwood wrote:
The new attempt is a fresh email to d-d-a via cut and paste from the
original email with the 1 correction that was needed. The email for some
reason seems to be in d-d-a and d-d limbo, so I think we await the next
cron run.
More likely you need
Hi,
On 05-12-2023 03:52, Yadd wrote:
I uploaded src:node-proxy-agents into unstable, which is the new source
of node-proxy and node-https-proxy-agent. This package didn't migrate
but I don't understand the reason of this block.
The tracker[1] reports regressions on node-proxy and
node-https-
Hi,
On 18-12-2023 13:18, Antonio Terceiro wrote:
Will reproducibility regressions block migration to testing?
Not for the near future for 2 reasons:
1) contrary to autopkgtest where removal of the test "fixes" regression,
it feels that currently blocking on regression would give maintainers
Hi
On 18-12-2023 11:29, Santiago Vila wrote:
El 17/12/23 a las 22:40, Steven Robbins escribió:
Does that mean ceasing the "ITP" messages in debian-devel?
I'd certainly welcome that!
I think he really meant debian-release, as this was "Bits from
the Release Team" and he was talking about "Rele
Hi Steve,
On 05-01-2024 17:36, Rene Engelhard wrote:
Also a problem is that experimental also might already contain totally
unrelated updates like new upstream versions...
I share this worry. Have you thought about how to handle the cases where
you don't have experimental to upload to? How bi
Hi Gioele,
On 06-01-2024 14:15, Gioele Barabucci wrote:
Aren't all these problems just inherent in Debian's lack of a mandated
packaging tooling and workflow [1,2]?
Might be, but that doesn't mean that problem goes away.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
Oops, should have waited sending...
On 06-01-2024 14:30, Paul Gevers wrote:
On 06-01-2024 14:15, Gioele Barabucci wrote:
Aren't all these problems just inherent in Debian's lack of a mandated
packaging tooling and workflow [1,2]?
Might be, but that doesn't mean that problem
Hi,
On 12-01-2024 16:42, Blake Gilbert wrote:
I am reaching out to you regarding a recent package submission by our
Engine Connectivity Engineering team. We submitted the package CDImage
M-LINUX-WolframEngine.DEB a few months ago to include Wolfram Engine in
Debian packages, and I wanted to se
Hi,
On 20-01-2024 23:22, Steve Langasek wrote:
So I think an algorithm for deciding the uploads to experimental looks like
this:
- download source from unstable.
- apply the packagename conversion to the source.
- grab the debdiff.
- submit the NMU diff to the BTS.
- download the source again f
Hi,
On 21-01-2024 16:08, Matthias Urlichs wrote:
However according to our release notes we only support upgrading from
release x to x+1, skipping releases is not allowed.
I'm not talking about skipping releases but about partial upgrades.
Thus …
> foo/testing requires bar >=1.1 to work but
Hi,
On 29-02-2024 4:47 a.m., Christoph Anton Mitterer wrote:
@d-d:
- How can it happen that purge *t64 packages and at the same time install
the previous package, and then the so file is missing?
I mean it's clear that they use the same name, but shouldn't DPKG handle
the cleanly?
Wel
Hi,
On 01-03-2024 1:58 p.m., Nilesh Patra wrote:
Have you found any way around these?
https://salsa.debian.org/mbanck/dd-autopkgtest/
Alternative, probably not the best solution, but until better ones are
found (and as long it's not too much used): Antonio and I offer DD's
access to testbed
Hi,
Disclaimer: exception only valid while the time_t transition is ongoing.
On 15-03-2024 6:15 a.m., Steve Langasek wrote:
Migration to testing is largely out of control of the maintainers at this
point, it's very much dependent on folks rebootstrapping armel and armhf
against the new library
Hi zigo,
On 16-03-2024 12:31 a.m., Thomas Goirand wrote:
But when the AUTORM period was announced as reduced, I thought
like it was probably a bad call, and that the previous AUTORM was
aggressive enough.
I'm not aware that we reduced autoremoval times in recent history. Are
you maybe confus
Hi,
On 19-03-2024 11:32 a.m., Ian Jackson wrote:
Paul Gevers writes ("Re: Package marked for autoremoval due to closed bug?"):
For bookkeeping purposes, please usertag downgraded bugs with user
release.debian@packages.debian.org and usertag time_t-downgrade.
I was informed t
Hi Samuel,
On 24-03-2024 11:45 p.m., Samuel Henrique wrote:
In a recent case, the issue was addressed by performing a
testing-proposed-update of the package. This would allow firefox-esr to be
fixed on testing before the transition is over, but it would not work for those
installing the firefox
Hi,
On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
What to do with autopkgtests that fail in testing because of problems with
packages in testing that are fixed in unstable, e.g. the autopkgtest for
speech-dispatcher/0.11.5-2 on
Inform the Release Team and we can either schedule the combi
Hi,
On 24-04-2024 7:38 p.m., Paul Gevers wrote:
On 24-04-2024 7:35 p.m., Andrey Rakhmatullin wrote:
What to do with autopkgtests that fail in testing because of problems
with
packages in testing that are fixed in unstable, e.g. the autopkgtest for
speech-dispatcher/0.11.5-2 on
Inform the
Hi,
On 24-04-2024 7:42 p.m., Jérémy Lal wrote:
Inform the Release Team and we can either schedule the combination
manually, add a hint or both.
Isn't it processed automatically ? What needs manual intervention and
what doesn't ?
Well, the migration software *tries* to figure out com
Hi,
On 27-04-2024 7:52 p.m., Andrey Rakhmatullin wrote:
Can you please look at libproxy<->glib-networking? libproxy excuses show
glib-networking tests failing, but they are working in sid.
And that's not missing a versioned Depends and/or Breaks? I.e. this is a
test only failure?
Paul
Ope
Hi,
On 04-05-2024 11:39 a.m., Jerome BENOIT wrote:
What would be the best way to unblock the migration of gap and gap-io ?
If gap isn't going to change (which might be the easiest solution), then
file bugs and fix those reverse dependencies. Those bugs are RC and in
due time will cause autor
Hi Luca,
On 05-05-2024 10:04 p.m., Luca Boccassi wrote:
> Hence, I intend to apply these changes in the next src:systemd upload
> to unstable, probably next week.
In case anybody is aware of packages/programs needing an update to cope
with these changes, or any other issue, please let me know
Hi,
On 08-05-2024 6:06 p.m., Bill Allombert wrote:
Agreed, but gap does not actually breaks anything, it is just the tests
in testing that are broken. So I can do that but that seems a bit artificial.
Aha, that wasn't at all clear to me. If you don't want to do the
artificial thing (which is
Hi Jonas,
On 16-05-2024 10:35 a.m., Jonas Smedegaard wrote:
Just to clarify, the package in question does not directly depend on
rust-ahash 0.8.9-2, that Built-Using information is (as is the general
purpose of that field, I believe) transitive.
Built-Using is used for license compliance so we
Hi
On 17-05-2024 9:58 p.m., Victor Gamper wrote:
Is it correct that debian 13 is planned to be released without
an i386 iso and i386 is planned to be deprecated?
Our current position is described here:
https://lists.debian.org/debian-devel-announce/2023/12/msg3.html
Paul
OpenPGP_signa
Hi Andrew,
Release team member hat on
On 18-05-2024 12:28 p.m., Andrew M.A. Cater wrote:
In reality, i386 should probably have been dropped early (or at the last
minute) for bookworm; some libraries will be kept for compatibility
but it's not realistic to maintain i386 for the whole of the trixi
Hi all,
In this discussion about mandating things, I've been wondering
On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote:
* mandate VCS-tracking
* Yes
* mandate the use of one specific VCS
* Yes: git
What do people think this should mean, a *should* or *must* in policy?
That th
Two mistakes spotted
On 19-05-2024 10:05 a.m., Paul Gevers wrote:
I think there's a large majority (maybe
even consensus) that believe you *should* have the packaging in VCS
I meant "at least should", as in "should or must".
I think what
Hi,
On 20-05-2024 4:50 p.m., Ben Hutchings wrote:
There is a tension here between the interests of (a) users that want to
run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to
keep using 32-bit CPUs. If i386 is meant for group (a) then the
baseline should be raised to include
Hi
On 21-05-2024 1:08 p.m., Sean Whitton wrote:
PS: I've always wondered if the dgit server shouldn't track history, even if
uploads don't happen via it. A dgit clone could (should?) already provide
available history, even if no upload happened via it yet.
Well, 'dgit clone' adds a vcs-git rem
Hi Andreas,
On 10-11-2020 13:21, Andreas Tille wrote:
> Yes, that's true but its part of my question: Why should all these
> tests be run if the dependencies are not available on that architecture.
> Wouldn't it be more sane to check dependencies first before running
> a test that will fail for s
Hi Andreas,
On 18-11-2020 12:45, Andreas Tille wrote:
> On Tue, Nov 10, 2020 at 09:02:56PM +0100, Paul Gevers wrote:
>> On 10-11-2020 13:21, Andreas Tille wrote:
>>> Yes, that's true but its part of my question: Why should all these
>>> tests be run if the depend
Hi Andreas,
On 19-11-2020 08:22, Andreas Tille wrote:
>> I have the strong impression that we're talking past each other. The log
>> message that you quoted in your initial e-mail said "uninstallable on
>> arch *, not running autopkgtest there". This means the test is not
>> triggered *and* that f
Hi Michael,
On 26-11-2020 08:57, Michael Prokop wrote:
> AFAICS we could:
>
> 1) use 2.0.0+really1.8.3 pattern for our Debian package version
As it seems not unreasonable to expect the upstream version to go past
2.0.0 in the not infinite future, this is the approach I would take.
Because you as
Hi Holger,
On 26-11-2020 10:01, Holger Levsen wrote:
> Also I find 1:1.8.3 not ugly at all, for most use cases this is 1.8.3
> so I would go with that. And if someone complains about the 1: epoch
> one can always point to the upstream issue explaining why this has
> happened.
If I recall correctl
Hi,
On 19-12-2020 01:25, Josh Triplett wrote:
> Given all of the above improvements, it'd be much more feasible for
> tooling to help systematically unbundle and package dependencies, and to
> help manage and transition those dependencies in the archive.
Especially in the JavaScript arena, I thin
1 - 100 of 284 matches
Mail list logo