On Sun, 24 Mar 2024 at 18:20:30 +0100, Samuel Thibault wrote:
> - it's indeed better to avoid loading porters with this, notably because
> it'll be most often the same for a set of architectures. The buildd
> infrastructure could have an additional build-profile parameter that
> can be set
Sent from Workspace ONE Boxer
On Mar 25, 2024 7:44 AM, Niels Thykier wrote:
>
> Niels Thykier:
> A follow up on this:
>
> * The proposal is now implemented in debhelper compat 14 (as of version
> 13.15+) and debputy (0.1.21+).
>
> * The `debputy` migration tool will flag
Niels Thykier:
Hi
It seems the discussion on this topic has settled, so I am now doing a
summary of the discussion as I understand it.
* Generally, the original proposal seems to have been received
favorably at a conceptual level.
[...]
A follow up on this:
* The proposal is now
Hi,
On Mon, Mar 25, 2024 at 2:18 AM Paul Wise wrote:
>
> On Sun, 2024-03-24 at 22:45 +, Samuel Henrique wrote:
>
> > I'm sending this to d-devel because there should be a lot of testing and
> > unstable users on this list. If you're not running firefox 124.0.1 or
> > firefox-esr
On Sun, 2024-03-24 at 22:45 +, Samuel Henrique wrote:
> I'm sending this to d-devel because there should be a lot of testing and
> unstable users on this list. If you're not running firefox 124.0.1 or
> firefox-esr 115.9.1esr-1, you should find a way of upgrading to those
> versions.
Quoting Samuel Thibault (2024-03-24 18:20:30)
> - making sure that the Debian release eventually only contains non-profile
> builds should be relatively easy thanks to the buildinfo files (they
> currently only contain them in the DEB_BUILD_PROFILES environment variable,
> they could be added as
Simon McVittie, le dim. 24 mars 2024 16:45:02 +, a ecrit:
> On Sun, 24 Mar 2024 at 13:09:02 +0100, Samuel Thibault wrote:
> > Simon McVittie, le dim. 24 mars 2024 11:59:50 +, a ecrit:
> > > For the specific example of pipewire, I've suggested temporarily
> > > dropping that feature from
On Sun, 24 Mar 2024 at 13:09:02 +0100, Samuel Thibault wrote:
> Simon McVittie, le dim. 24 mars 2024 11:59:50 +, a ecrit:
> > For the specific example of pipewire, I've suggested temporarily
> > dropping that feature from pipewire on the affected architectures
> >
Simon McVittie, le dim. 24 mars 2024 11:59:50 +, a ecrit:
> On Sun, 24 Mar 2024 at 12:56:52 +0500, Andrey Rakhmatullin wrote:
> > 2. FTBFSing packages (those that block further work, anyway)
> ...
> > An example of a currently existing obstacle of this kind is snapd-glib
> > (mainly because it
On Sun, 24 Mar 2024 at 12:56:52 +0500, Andrey Rakhmatullin wrote:
> 2. FTBFSing packages (those that block further work, anyway)
...
> An example of a currently existing obstacle of this kind is snapd-glib
> (mainly because it blocks pipewire).
For the specific example of pipewire, I've suggested
On Sat, Mar 23, 2024 at 04:50:48PM -0500, Steven Robbins wrote:
> Wondering about the current state of this transition.
It's still in the stage of re-bootstrapping armel and armhf.
https://buildd.debian.org/stats/armel.png
https://buildd.debian.org/stats/armhf.png
https://buildd.debian.org/st
Wondering about the current state of this transition. Is there a tracker of
any kind for this? Or would someone be willing to post an email here
periodically? Weekly maybe?
I looked at the release goals wiki and at the "brain dump" page but failed to
find anything dated more precisely than
On 23 March 2024 at 07:25, Dirk Eddelbuettel wrote:
|
| On 22 March 2024 at 11:12, Dirk Eddelbuettel wrote:
| |
| | On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| | | A couple of days ago, the (effective) Maintainer and rather active
developer
| | | of the Matrix package Mikael
On 22 March 2024 at 11:12, Dirk Eddelbuettel wrote:
|
| On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| | A couple of days ago, the (effective) Maintainer and rather active developer
| | of the Matrix package Mikael Jagan (CC'ed) posted on the r-package-devel
list
| | (the primary
On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| A couple of days ago, the (effective) Maintainer and rather active developer
| of the Matrix package Mikael Jagan (CC'ed) posted on the r-package-devel list
| (the primary list for R package development) that the upcoming change of
|
I’m back from holiday now and working on this properly. Yes, the below is what
I had in mind but haven’t had a chance to go through all the permutations yet
and see if we can patch this up at run-time without potentially missing any
calls.
The good news at least is once you detect one one
On 3/21/24 11:47 AM, Ian Jackson wrote:
Ian Jackson writes ("Re: Package marked for autoremoval due to closed bug? [and 1
more messages]"):
Steve, could you please do this for *all* the time_t transition RC
bugs?
IMO things are currently ON FIRE.
Exaggeration is an art.
If n
On Thu, Mar 21, 2024 at 10:47:21AM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: Package marked for autoremoval due to closed bug?
> [and 1 more messages]"):
> > Steve, could you please do this for *all* the time_t transition RC
> > bugs?
> IMO things are
Ian Jackson writes ("Re: Package marked for autoremoval due to closed bug? [and
1 more messages]"):
> Steve, could you please do this for *all* the time_t transition RC
> bugs?
IMO things are currently ON FIRE.
If no-one else has put this fire out by 24h from now, I will attem
I think you're missing the point of this package.
Firstly, it is a _library_, not a daemon, so it is intended to be
compiled / linked into other Go applications. It provides an easy
jumping-off point for developers to customize the output of logs,
particularly with respect to color and syntax
Hi!
On Tue, 2024-03-19 at 10:32:04 +, Ian Jackson wrote:
> [2] In my case src:dgit depends on git-buildpackage. The autoremoval
> robot wants to remove git-buildpackage because of the time_t bugs
> against rpm, xdelta, and pristine-tar. One root cause is that
> src:dpkg isn't migrating
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 Paul,
Am Fri, Mar 15, 2024 at 09:52:06PM +0100 schrieb Paul Gevers:
> For bookkeeping purposes, please usertag downgraded bugs with user
> release.debian@packages.debian.org and usertag time_t-downgrade.
>
> Please be careful with downgrading RC bugs.
I agree with Ian that it might make
Steve Langasek writes ("Re: Package marked for autoremoval due to closed bug?"):
> 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 names. Should these
Hi Simon and Simon,
On Sun, Mar 17, 2024 at 12:08:21PM +, Simon McVittie wrote:
> On Sun, 17 Mar 2024 at 11:23:28 +0900, Simon Richter wrote:
> > When /bin is a symlink to usr/bin,
> > and I install two packages, where one installs /bin/foo and the other
> > installs /usr/bin/foo
>
> My
On Sun, 17 Mar 2024 at 11:23:28 +0900, Simon Richter wrote:
> When /bin is a symlink to usr/bin,
> and I install two packages, where one installs /bin/foo and the other
> installs /usr/bin/foo
My reading of Policy is that this situation is already a Policy violation:
To support merged-/usr
On Sun, Mar 17, 2024 at 06:53:34AM +0100, Emanuele Rocca wrote:
>
> On 2024-03-16 04:21, Emanuele Rocca wrote:
> > With libcurl3t64-gnutls cargo can now be rebootstrapped on armhf
>
> And on armel too. Fixed armhf/armel packages uploaded.
>
> > Fabian: it seems that cargo's build-depend on git
On 2024-03-16 04:21, Emanuele Rocca wrote:
> With libcurl3t64-gnutls cargo can now be rebootstrapped on armhf
And on armel too. Fixed armhf/armel packages uploaded.
> Fabian: it seems that cargo's build-depend on git can be dropped? The
> package builds fine without, tests included.
I haven't
b to be installed), while also making life easier for the people trying
> to re-bootstrap cargo.
I've uploaded curl 8.6.0-4 with the patches from #1066981 and #1066982, thank
you for those, Simon!
Cheers,
--
Samuel Henrique
On 16.03.24 18:41, Steven Robbins wrote:
This recent transition has really illuminated how little I know of the dark
corners of Debian infrastructure...
Some packages (e.g. libcdk5/experimental) aren't buildable on the armel/armhf
because the build-deps don't install, and in particular:
The
On Sat, 16 Mar 2024 at 15:37:20 +0100, Matthias Klose wrote:
> build gdb without libdebuginfo on the bootstrap archs for a while.
That's likely also good advice, but the cycle involving gdb isn't the
only one involving curl.
smcv
installed), while also making life easier for the people trying
> to re-bootstrap cargo.
Thanks Simon. I can confirm that curl does indeed build properly on
armhf with DEB_BUILD_PROFILES='pkg.curl.noldap nocheck'.
With libcurl3t64-gnutls cargo can now be rebootstrapped on armhf
(haven't tr
would
now be enough to unblock curl, which would hopefully unblock a lot of
the C/C++ ecosystem (in particular fixing the unsatisfiable dependency
libdebuginfod1t64 -> libcurl3t64-gnutls on armel/armhf, which would allow
gdb to be installed), while also making life easier for the people trying
to
which would hopefully unblock a lot of
the C/C++ ecosystem (in particular fixing the unsatisfiable dependency
libdebuginfod1t64 -> libcurl3t64-gnutls on armel/armhf, which would allow
gdb to be installed), while also making life easier for the people trying
to re-bootstrap cargo.
As a
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
On 3/15/24 07:14, Andreas Tille wrote:
I simply remove all those testing removal warnings in my
mailbox to cope with this and by doing so I'm probably missing real
issues I should rather care about.
I know what you're talking about: anyone that maintains a lot of
packages always receive waves
On 3/15/24 21:52, Paul Gevers wrote:
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
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
ee the (linked) t64 transition bug:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036884#197
>
>
> That link doesn't answer my question. The link is to bug report summarizing
> that cargo is broken and suggesting it needs to be re-bootstrapped.
>
> Cu
On Thu, Mar 14, 2024 at 08:42:14PM -0700, Steve Langasek wrote:
> On Thu, Mar 14, 2024 at 10:47:02PM +0100, Micha Lenk wrote:
> > The time_t transition seems to be stalled due to issues on armel/armhf
> > architecture. My understanding is, as long as this transition isn't over,
> > uploaders of
On 2024-03-14 22:03 -0700, Otto Kekäläinen wrote:
> Hi!
>
> Is anyone perhaps planning to fix cargo?
Yes. We have been working on it this week (e.g. ema built cargo for armhf),
but that is not sufficient to unbung the
curl->stunnel4->python->crypography->cargo loop.
I tried building the patched
ion. The link is to bug report summarizing
that cargo is broken and suggesting it needs to be re-bootstrapped.
Currently we haven't seen anybody step up to do it. I would be very
grateful if somebody with enough expertise would be available to do it and
thus help resolve the whole chain of broken builds.
>
>
On Thu, Mar 14, 2024 at 10:03:57PM -0700, Otto Kekäläinen wrote:
> Hi!
>
> Is anyone perhaps planning to fix cargo?
>
> For example curl isn't building on armel/armhf now and numerous packages
> that depend of curl are not building on armel/armhf.
>
> Thanks in advance to the person who steps
Hi Andreas,
* Andreas Tille [2024-03-15 07:31]:
Hi,
thanks to the next round of Lucas' FTBFS QA rebuilds (at least) one
package of the R pkg team is affected by some strange linker issue
#1066409 r-cran-v8: FTBFS: ld: cannot find -lv8: No such file or directory
which boils down to[1]
g++
On 3/15/24 7:31 AM, Andreas Tille wrote:
g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o V8.so RcppExports.o
bindings.o -lv8 -lv8_libplatform -L/usr/lib/R/lib -lR
It likely works by adding the library path, e.g.:
g++ -std=gnu++17 -shared -L/usr/lib/R/lib -Wl,-z,relro -o V8.so
Am Thu, Mar 14, 2024 at 10:15:18PM -0700 schrieb Steve Langasek:
>
> 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 names. Should these bugs be downgraded again to
>
Hi!
Is anyone perhaps planning to fix cargo?
For example curl isn't building on armel/armhf now and numerous packages
that depend of curl are not building on armel/armhf.
Thanks in advance to the person who steps up.
On Fri, Mar 15, 2024 at 05:03:55AM +, Scott Kitterman wrote:
> On March 15, 2024 3:54:05 AM UTC, Steven Robbins wrote:
> >According to the "action needed" section for nifticlib [1], it is:
> >Marked for autoremoval on 31 March: #1063178
> >But that bug is fixed for the version in unstable.
On March 15, 2024 3:54:05 AM UTC, Steven Robbins wrote:
>According to the "action needed" section for nifticlib [1], it is:
>
>Marked for autoremoval on 31 March: #1063178
>
>But that bug is fixed for the version in unstable.
>Why does that cause the package to be removed?
>
>[1]
Hi,
On Thu, Mar 14, 2024 at 10:47:02PM +0100, Micha Lenk wrote:
> The time_t transition seems to be stalled due to issues on armel/armhf
> architecture. My understanding is, as long as this transition isn't over,
> uploaders of affected packages are discouraged to upload anything
> unrelated to
Hi all,
The time_t transition seems to be stalled due to issues on armel/armhf
architecture. My understanding is, as long as this transition isn't over,
uploaders of affected packages are discouraged to upload anything unrelated to
this transition (to avoid any delays to get it through).
Do
Hello Mo,
May I address you Mo?
I am happy to co-maintain hyprland with you. :)
The ITP for hyprland[0] was created by werdahias@ who had created an
initial skeleton for the packaging a while ago. Under his advise,
I decided to de-vendor all of udis86, tracy and hyprland-protocols.
As far as I
Hi Alan,
Thank you for your work!
I did not check the ITP bugs before we make overlapping efforts:
https://salsa.debian.org/debian/hyprlang
https://salsa.debian.org/debian/hyprland
I just rushed the two packages within a short time the last night.
They work properly on Sid with my laptop.
I
On Wed Mar 13, 2024 at 6:52 PM GMT, Lucio Marinelli wrote:
> gtk-gnutella is a server/client for the Gnutella peer-to-peer network.
> It was previously included in Debian repository.
> The source code is hosted in Github:
> https://github.com/gtk-gnutella/gtk-gnutella
> I already prepared the
> On Thu, Mar 07, 2024 at 05:02:29PM +0200, Peter Pentchev wrote:
>> On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote:
>>> On 7 Feb 2024, at 18:27, Dima Kogan wrote:
>>>
>>> Hi. Thanks for your contribution. I looked at the upstream code a tiny
>>> bit, and it looks like it might
On Wed, Mar 13, 2024 at 1:57 AM Bernd Schubert
wrote:
>
> Hi Amir,
>
> thanks for your help!
>
> On 3/9/24 03:46, Amir Goldstein wrote:
> > On Thu, Mar 7, 2024 at 8:47 PM Bernd Schubert
> > wrote:
> >>
> >> Hi all,
> >>
> >> this is certainly not kind of the mail I was hoping for as a new
Andrea Bolognani, le mer. 13 mars 2024 18:03:40 +0100, a ecrit:
> On Wed, Mar 13, 2024 at 12:34:55PM +0100, Samuel Thibault wrote:
> > Simon McVittie, le mer. 13 mars 2024 10:52:35 +, a ecrit:
> > > 2. i386 is 32-bit but has been excluded from the 64-bit time_t transition
> > >because its
On Wed, Mar 13, 2024 at 12:34:55PM +0100, Samuel Thibault wrote:
> Simon McVittie, le mer. 13 mars 2024 10:52:35 +, a ecrit:
> > 2. i386 is 32-bit but has been excluded from the 64-bit time_t transition
> >because its major purpose this decade is running legacy 32-bit binaries,
> >a
On Wed, Mar 13, 2024 at 10:40:51AM +, Traut Manuel LCPF-CH wrote:
> > On Thu, Mar 07, 2024 at 05:02:29PM +0200, Peter Pentchev wrote:
> >> On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote:
> >>> On 7 Feb 2024, at 18:27, Dima Kogan wrote:
> >>>
> >>> Hi. Thanks for your
Simon McVittie, le mer. 13 mars 2024 10:52:35 +, a ecrit:
> 2. i386 is 32-bit but has been excluded from the 64-bit time_t transition
>because its major purpose this decade is running legacy 32-bit binaries,
>a purpose that would no longer be possible if it broke ABI
>- non-release
er to satisfy build-dependencies. The last category is the only one
where there has genuinely been a compatibility break and therefore this
Provides would be wrong, so it is also the category where some packages
need re-bootstrapping.
smcv
On Mon, 11 Mar 2024 07:02:38 +0200, Martin-Éric Racine
wrote:
>Meanwhile a bare minimal system needs a non-GUI solution and swaping
>which DHCP client gets pulled by ifupdown is the simplest, least
>disruptive way of accomplishing this.
Most bare minimal non-GUI systems run fine with
On Mon, 11 Mar 2024 20:26:40 +, Holger Levsen
wrote:
>foo="bin1
>bin2
>bin3"
>
>$file=/some/path/to/bugreport_without_package_line.txt
>tmpfile=$(mktemp)
>
>for package in $foo ; do
> ( echo "package: $package" ;
> cat $file ) > $tmpfile
> do mutt -s "RM: remove $package"
Hi Micha,
Am Wed, Mar 13, 2024 at 06:25:02AM +0100 schrieb Micha Lenk:
> What you are trying to accomplish is no regular bug reporting but some
> manipulation of existing bugs. Hence the control server must be used directly
> by sending your mail to cont...@bugs.debian.org instead of submit@...
On Tuesday, March 12, 2024 1:24:25 A.M. CDT Steve Langasek wrote:
> The quickest fix for this based on what we've done in Ubuntu is:
>
> - unpack cargo and libstd-rust debs to the root via dpkg-deb -x
> - use equivs to mock up packages by these names with no dependencies and
> install those
>
Hi Andreas,
Am 12. März 2024 19:55:27 MEZ schrieb Andreas Tille :
>Am Mon, Mar 11, 2024 at 11:35:55PM +0100 schrieb Mattia Rizzolo:
>> clone the bug however many time you need and retitle the clones? What
>> matters for the ftp tooling is just the bug title, pretty much.
>> That's one single
On 3/11/24 14:32, Andrea Bolognani wrote:
> On Thu, Mar 07, 2024 at 07:47:23PM +0100, Bernd Schubert wrote:
>> Hi all,
>>
>> this is certainly not kind of the mail I was hoping for as a new libfuse
>> maintainer.
>>
>> As you can see from the title and from discussion below (sorry this is
>>
Hi Amir,
thanks for your help!
On 3/9/24 03:46, Amir Goldstein wrote:
> On Thu, Mar 7, 2024 at 8:47 PM Bernd Schubert
> wrote:
>>
>> Hi all,
>>
>> this is certainly not kind of the mail I was hoping for as a new libfuse
>> maintainer.
>>
>> As you can see from the title and from discussion
Hi Mattia,
Am Mon, Mar 11, 2024 at 11:35:55PM +0100 schrieb Mattia Rizzolo:
> On Mon, Mar 11, 2024 at 09:12:30PM +0100, Andreas Tille wrote:
> > I hope there is some better solution than sending single bug reports
> > for those packages. If ftpmaster tooling really needs single bug
> > reports I
On Tue, Mar 12, 2024 at 9:30 AM Mathias Krause wrote:
> That works for me. The 32-bit time_t transition Jeremy mentioned seems
> like a good candidate to force a rebuild of a lot of packages. Is there
> an ETA for it? I found [1] which mentions to do the transition in
> January but we've March
On 11.03.24 00:41, Bernd Zeimetz wrote:
> On Thu, 2024-03-07 at 11:48 +0100, Mathias Krause wrote:
>> To get rid of the over-alignment, a rebuild with a linker that
>> doesn't enforce the overly huge alignment any more is sufficient.
>> In Debian terms that would be anything starting with
On Mon, Mar 11, 2024 at 09:07:17PM -0500, Steven Robbins wrote:
> Peter convincingly argues (details in bug) that manual intervention is needed
> for package "cargo":
> On Sun, 10 Mar 2024 00:48:32 + Peter Michael Green
> wrote:
> > This will require manual intervention to resolve, either
On Mon, Mar 11, 2024 at 09:12:30PM +0100, Andreas Tille wrote:
> I hope there is some better solution than sending single bug reports
> for those packages. If ftpmaster tooling really needs single bug
> reports I wonder how I can automatically create such bug reports with
> always the same text,
On Mon, Mar 11, 2024 at 09:12:30PM +0100, Andreas Tille wrote:
> Hi,
>
> Am Mon, Mar 04, 2024 at 06:25:50PM + schrieb Thorsten Alteholz:
> > Control: tags -1 + moreinfo
> >
> > please file one RM bug for each package that needs to be partially removed.
> > This needs to be done even for
On Mon, Mar 11, 2024 at 08:26:40PM +, Holger Levsen wrote:
> do mutt -s "RM: remove $package" -i tmpfile $package
the 2nd $package in that line must be sub...@bugs.debian.org
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀
On Mon, Mar 11, 2024 at 09:12:30PM +0100, Andreas Tille wrote:
> I hope there is some better solution than sending single bug reports
> for those packages. If ftpmaster tooling really needs single bug
> reports I wonder how I can automatically create such bug reports with
> always the same text,
On Mon, Mar 11, 2024 at 09:28:06PM +0530, Praveen Arimbrathodiyil wrote:
> cat > work-request-ruby-semver-dialects.debusine << END
> build_components:
> - any
> - all
> host_architecture: amd64
> input:
> source_artifact_id: 788
> environment_id: 154
> END
>
> debusine create-work-request
On 7/3/24 10:36 PM, Colin Watson wrote:
While for the moment Debusine may seem like a less polished version of
Salsa CI, it has very different goals, and we are working towards those.
In the next milestone
(https://salsa.debian.org/freexian-team/debusine/-/milestones/9), which
is well underway,
On Thu, Mar 07, 2024 at 07:47:23PM +0100, Bernd Schubert wrote:
> Hi all,
>
> this is certainly not kind of the mail I was hoping for as a new libfuse
> maintainer.
>
> As you can see from the title and from discussion below (sorry this is
> not typical ML discussion style), we have a bit of of
Am Mon, Mar 11, 2024 at 12:12:45PM + schrieb Colin Watson:
> "rmadison clustalw" shows:
Shame on me I always forget about rmadison which explains things
perfectly.
> So since clustalw/2.1+lgpl-7/i386 is still in oldstable and stable, it
> has to be kept in the pool; files are only expired
On Mon, Mar 11, 2024 at 01:06:49PM +0100, Andreas Tille wrote:
> Yes, I've filed this and this was perfectly intended (even if I forgot
> that the bug is done meanwhile which I should have checked before asking
> here - sorry about this). It was just that all signs that this package
> exists are
Am Mon, Mar 11, 2024 at 11:41:42AM + schrieb Colin Watson:
> Search for "clustalw" in https://ftp-master.debian.org/removals.txt:
>
> [Date: Mon, 26 Feb 2024 18:19:39 -] [ftpmaster: Thorsten Alteholz]
> Removed the following packages from unstable:
>
> clustalw | 2.1+lgpl-7 |
On Mon, Mar 11, 2024 at 12:06:58PM +0100, Andreas Tille wrote:
> Debci seems to be fine in testing clustalw on all architectures[3] and
> according to build logs[4] all should be fine. Unfortunately
>
>wget -q -O -
> http://ftp.debian.org/debian/dists/sid/main/binary-i386/Packages.xz |
; Hi Colin,
>
> Am Fri, Mar 08, 2024 at 11:41:27AM + schrieb Colin Watson:
> > > Speaking about Salsa CI: I would like to do what Enrico mentioned to
> > > somehow re-run building some Salsa commit using sbuild and (optionally)
> > > the autopkgtest on the re
Hi Colin,
Am Fri, Mar 08, 2024 at 11:41:27AM + schrieb Colin Watson:
> > Speaking about Salsa CI: I would like to do what Enrico mentioned to
> > somehow re-run building some Salsa commit using sbuild and (optionally)
> > the autopkgtest on the result.
>
> We d
ma 11. maalisk. 2024 klo 1.29 Bernd Zeimetz (be...@bzed.de) kirjoitti:
> On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote:
> > I hereby propose bin:dhcpcd-base:
> >
> > 1) already supported by ifupdown.
> > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege
> >
On Thu, 2024-03-07 at 11:48 +0100, Mathias Krause wrote:
>
> To get rid of the over-alignment, a rebuild with a linker that
> doesn't enforce
> the overly huge alignment any more is sufficient. In Debian terms
> that would be
> anything starting with buster.
>
> I, thereby, request to rebuild
Hi,
On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote:
> I hereby propose bin:dhcpcd-base:
>
> 1) already supported by ifupdown.
> 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege
> separation.
> 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
> 4)
> > > > > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> > > > > > > > wrote:
> > > > > > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > > > > > > > > > Greetings,
> > > > > >
scribió:
> > > > > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió:
> > > > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> > > > > > > wrote:
> > > > > > > > El 19/06/23 a las 13:54, Martin-Éric R
On Sat, Mar 09, 2024 at 01:43:18PM +, Stefano Rivera wrote:
> Hi Martin (2024.03.09_11:43:54_+)
> > thank you for this project, it looks very interesting. Would you also
> > support running ratt there? For some packages ratt often fails on my local
> > machines due to RAM constraints.
>
>
On Sat, Mar 09, 2024 at 01:12:06PM +0100, Salvo Tomaselli wrote:
>
> In data venerdì 8 marzo 2024 18:08:11 CET, aquilamac...@riseup.net ha scritto:
> > Package: wnpp
> > X-Debbugs-Cc: debian-devel@lists.debian.org
> > Owner: Aquila Macedo Costa
> > Severity: wishlist
> >
> > * Package name:
Hi Martin (2024.03.09_11:43:54_+)
> thank you for this project, it looks very interesting. Would you also
> support running ratt there? For some packages ratt often fails on my local
> machines due to RAM constraints.
We are building out the pieces that will lead to being able to
reimplement
Dear Colin,
thank you for this project, it looks very interesting. Would you also
support running ratt there? For some packages ratt often fails on my
local machines due to RAM constraints.
Best regards,
Martin
signature.asc
Description: PGP signature
On Fri, Mar 08, 2024 at 01:58:22PM +0100, John Paul Adrian Glaubitz wrote:
> debbootstrap first downloads perl-modules-5.38_5.38.2-3_all.deb, then later
> tries
> to install perl_5.38.2-3.2_powerpc.deb which causes dpkg to bail out. It can
> be
> reproduced with:
> # debootstrap --no-check-gpg
On Thu, Mar 7, 2024 at 8:47 PM Bernd Schubert
wrote:
>
> Hi all,
>
> this is certainly not kind of the mail I was hoping for as a new libfuse
> maintainer.
>
> As you can see from the title and from discussion below (sorry this is
> not typical ML discussion style), we have a bit of of problem
On 2024-03-07 19:47 +0100, Bernd Schubert wrote:
> Hi all,
>
> this is certainly not kind of the mail I was hoping for as a new libfuse
> maintainer.
>
> As you can see from the title and from discussion below (sorry this is
> not typical ML discussion style), we have a bit of of problem with
Hi,
On Tue, 2024-03-05 at 09:56 +0100, John Paul Adrian Glaubitz wrote:
> I would like to ask for help with the t64 transition for m68k, powerpc and
> sh4 because it's getting too much for me alone and I'm really exhausted.
>
> I have build many packages for powerpc already and some for m68k and
: I would like to do what Enrico mentioned to
> somehow re-run building some Salsa commit using sbuild and (optionally)
> the autopkgtest on the result.
We don't have direct support for building from git yet. Ian asked about
that in Cambridge, and it's certainly a good idea though not c
On Fri, Mar 08, 2024 at 07:38:01AM +0100, Rene Engelhard wrote:
> Hi,
>
> Am 08.03.24 um 00:12 schrieb Eric Valette:
> > On 07/03/2024 21:16, Rene Engelhard wrote:
> > ct more people.
> > >
> > > But not so much for dependency issues like this. Which is my sole
> > > point. In 99,9% of cases
801 - 900 of 172865 matches
Mail list logo
