Respected Sir/Ma’am,
I would like to introduce a translation. *The company has* specialized in
providing t*ranslation and interpretation* (on a contract or permanent
basis) for the last 21 years.
The company is a pioneer in the fields of translation and interpretation
across the globe. It has
On Fri, Jun 07, 2024 at 12:19:28AM +0500, Andrey Rakhmatullin 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
As many were so happy with the upload of the debootstrap set, we want to
direct your attention to the long tail of the /usr-move transition that
we want to see fixed in trixie: Moving aliased files in all remaining
packages to /usr. More precisely, the transition should be fully
completed in trixie
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 tho
> On Jun 10, 2024, at 01:44, Andrey Rakhmatullin wrote:
>
> 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 alread
On 2024-06-10 at 08:09, rhys wrote:
> On Jun 10, 2024, at 01:44, Andrey Rakhmatullin
> wrote:
>
>> On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org
>> wrote:
>>> Reuse is better than recycle for complex things like electronics.
>>>
>> You were suggested to resuse an old amd64 machi
Hi The (2024.06.10_12:22:14_+)
> How to get access to the right parts of the waste stream to be able to
> pull out some working 64-bit hardware is another question, and one where
> I don't have an answer that wouldn't involve spending money (which would
> presumably make the proposed alternativ
Hi!
On Mon, 2024-06-10 at 16:06:13 +0500, Andrey Rakhmatullin wrote:
> 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
> > > specifi
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
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
On Mon, 10 Jun 2024 at 16:24:54 +0200, Guillem Jover wrote:
> 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
Yes. The difficult thing here is balancing "detect ac
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 t
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
On Sat, 08 Jun 2024 at 02:14:36 +0900, Simon Richter wrote:
> Reproducibility outside of sterile environments is however a problem for us
> as a distribution, because it affects how well people are able to contribute
> to packages they are not directly maintaining
If our package-building entry poi
On Mon, 10 Jun 2024 at 20:17:27 +0500, Andrey Rakhmatullin wrote:
> On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote:
> > 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 s
Hi!
On Mon, 2024-06-10 at 20:09:21 +0500, Andrey Rakhmatullin wrote:
> 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
> >
On Mon, Jun 10, 2024 at 04:06:13PM +0500, Andrey Rakhmatullin 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?
I think that a test rebuild and the MBF are reasonabl
Hello,
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 p
* Helmut Grohne [2024-06-10 18:01]:
> Ideally, we'd not just do a rebuild with the flags, but also do a
> rebuild without and then compare the binary .debs. In the event that we
> misguide configure, we expect the .debs to differ and otherwise to equal
> due to the work of the reproducible builds
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 se
20 matches
Mail list logo
