Source: graphviz
Version: 2.42.2-9
X-Debbugs-Cc: t...@mirbsd.de, debian-po...@lists.debian.org
librsvg has become extremely unportable, and so only a subset of
architectures have it:
amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x
loong64 powerpc ppc64 sparc64
Please whitelist the
Dixi quod…
>Is there a chance your team could fork the old python-cryptography
>source package (3.4.8-2) and do something like:
Apparently, pyopenssl needs to also be forked as it wraps the above
and, between 21.0.0-1 and 22.1.0-1, it began requiring the rust
version of python-cryptography ☹
Source: fsverity-utils
Version: 1.5-1.1
Severity: important
Justification: RC for Debian-Ports
X-Debbugs-Cc: t...@mirbsd.de, debian-po...@lists.debian.org
Recent versions of fsverity-utils (larger than 1.4-1~exp1 anyway)
have a Build-Depends-Arch on pandoc; however, pandoc is an extremely
Jérémy Lal dixit:
>Anyone had experience with the version 3.3 to 38.0 migration ?
>Maybe the API didn't change that much.
We cannot go past 3.4 because newer versions (starting at 38)
have a hard dependency on rust stuff.
bye,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich
Jérémy Lal dixit:
>While I'm very much concerned about architectures and compatibility,
>it seems that for python-cryptography, it's a sinking boat:
>The end of a very discussion dates from february, 2021 - 3 years ago:
>https://github.com/pyca/cryptography/issues/5771#issuecomment-775990406
Hi,
we have still the situation that the current python-cryptography,
having rather heavy rust ecosystem dependencies, cannot be built
on some debian-ports architectures.
This situation is not likely to go away:
• some ports are unlikely to meet the dependencies soon
• new ports won’t meet them
John Paul Adrian Glaubitz dixit:
>On 3/27/21 8:32 PM, Thorsten Glaser wrote:
>> -
>> https://cdimage.debian.org/cdimage/ports/debian-installer/2021-01-03/alpha/debian-installer-images_20201202+nmu1_alpha.tar.gz
>> is insufficient, it lacks the ISO which contains nic-
FYI
-- Forwarded message --
Message-ID: <161687355375.3666.12906764209603803348.reportbug@alpha>
Date: Sat, 27 Mar 2021 20:32:33 +0100
Subject: Bug#986009: installation-reports: document qemu workarounds and bug in
newer d-i image
Package: installation-reports
Severity:
Guillem Jover dixit:
>> Yes, but they *do* break anything that
>> - acts on the CFLAGS (and LDFLAGS) variables
>> - uses klcc or other compiler wrappers that don't understand -specs
>> - uses clang or pcc or whatever other compilers
>
>The default dpkg build flags have always been tied to the
clone 845193 -1
reassign -1 dpkg
retitle -1 dpkg: please do not add -specs= flags only on some architectures
thanks
Guillem Jover dixit:
>> I cannot build openssl1.0 any longer. Downgrading all binary
>> packages from src:dpkg to 1.18.10 makes the build succeed.
Interestingly enough,
Philipp Kern dixit:
>> Maybe wb could do a “dak ls” and whatever the equivalent for dpo mini-dak is.
>
>Unfortunately it is not being run on the same host as dak either.
Hm, rmadison then. What does packages.d.o/sid/binpkgname use? (On the
other hand, that’s often quite behind…)
bye,
On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:
> I didn't say once per arch. I said once per package, which is worse. I
> normally
> schedule binNMUs for several dozens packages. Multiply that by several
But you need to look the number up anyway? The wanna-build
--binNMU parameter gets the
On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:
> >> Ah, cool – so we have only to patch this tool to automatically
> >> use the highest number per batch on all affected architectures
> >> (or even to use the highest number if all architectures would
> >> be touched, but that’s probably an
On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote:
> I can go back to scheduling binNMUs for release architectures only, or for ANY
> -x32. But I don't have the time to look at every architecture and determine
> which one needs a binNMU and which one has already done it. Anyway if your
OK. In
On Fri, 23 Oct 2015, Adam D. Barratt wrote:
> and testing), so the only way to be certain what binNMU number to use is to
> check manually. In practice what actually happens is that people forget about
Maybe wb could do a “dak ls” and whatever the equivalent for dpo mini-dak is.
I’ll have a
On Fri, 23 Oct 2015, Adam D. Barratt wrote:
> wanna-build does, yes, but at least the Release Team tend to use the "wb"
> wrapper tool which automatically works out the next free number on each
> architecture.
Ah, cool – so we have only to patch this tool to automatically
use the highest number
Hi,
whoever is scheduling binNMUs now should do so with a little
bit more care, please.
Case in point, frameworkintegration – x32 already was rebuilt
against the new Qt API and did not need the additional binNMU.
Case in point, some OCaml binNMUs were done recently (within
the last month), to
Steve McIntyre dixit:
That seems like a bad idea to me, tbh. There will be people who won't
notice that the meaning of debian-ports@ has changed, and who will try
to use it with its old meaning.
favour of the existing behaviour. If anybody does use try to use it
that way in future, the new list
Hi *,
using build profiles breaks debian-ports architectures, all of them:
http://buildd.debian-ports.org/status/package.php?p=x264
│Dependency installability problem for [33]x264 on alpha, hppa, m68k, sh4,
sparc64 and x32:
│
│x264 build-depends on missing:
│- empty-dependency-after-parsing
On Fri, 17 Jul 2015, John Paul Adrian Glaubitz wrote:
On 07/17/2015 09:31 AM, Thorsten Glaser wrote:
using build profiles breaks debian-ports architectures, all of them:
What exactly is a build profile in this context?
Build-Depends: […] libgpac-dev (= ⌦0.5.0+svn4288~),⌫ ▶0.5.0+svn4288
Alexander Wirt dixit:
Could you please (technically) summarize what needs to be done from
listmaster side?
1. Remove whatever debian-ports@l.d.o is right now
2. Create a new debian-ports@l.d.o mailing list which
works just like the other regular lists
3. Announce the new debian-ports@l.d.o
Steven Chamberlain dixit:
On 05/09/14 18:39, Steve McIntyre wrote:
* Remove the confusion: turn debian-ports into a separate *normal*
mailing list, announce it and let people subscribe to it [...]
That sounds perfect IMHO. It could be used for general discussion about
porting, upcoming
(excluding d-release for what they hatingly call “debian-ports spam”)
Matthias Klose dixit:
I would like to see some partial test rebuilds (like buildd or minimal chroot
Haven’t tried yet, but Helmut Grohne does automated rebootstrapping of
some ports using what he can get his hands on, and he
Helge Deller dixit:
Can such a package be uploaded to debian master ftp if I go through
the standard ITP process?
No.
If not, is there a way to make this happen on debian-ports somehow?
Not in unstable, only in unreleased. We have the same problem
on m68k with e.g. bootloader packages.
This
John Paul Adrian Glaubitz dixit:
On 05/02/2014 10:05 PM, Helge Deller wrote:
This needs to be addressed on d-i side; we need better support
for the dpo 'unreleased' suite there.
Sounds not very simple or clean.
How did you solved that on m68k then?
Not yet. I’m not a big friend of d-i
Dixi quod…
Hi $maintainer,
can we still get CONFIG_EARLY_PRINTK=y and
CONFIG_SERIAL_PMACZILOG=n into 3.12 before it hits unstable?
This was, of course, not integrated into src:linux before the
3.12.6-1 upload. (Which by the way autobuilt, meaning we have
build logs ☻ instead of me building it
Michael Banck dixit:
I am not sure which thread you are meaning, and in general, I think
discussing random Linux kernel config options on -ports is off-topic.
Indeed, that wasn’t the intent of this thread. I’ve continued
that particular discussion on debian-68k.
My intent in _this_ thread was
Michael Schmitz dixit:
your finding that packages from both unstable and unreleased are needed is
correct (along with the complication that some may not be availabe at any
given
time).
There’s another problem: even in the main Debian archive, “unstable”
is *not* guaranteed to be
jhcha54008 dixit:
Custom mini-repositories for installation
-
One may download the missing packages from
http://snapshot.debian.org/archive/debian-ports.
Indeed, but – as I said – the regular debian-ports archive is
also weekly snapshotted, and Aurélien
Helge Deller dixit:
We noticed, that when we manually binmnu-upload packages, which are
already in the *same version* on debian-ports, then debian-ports ACCEPT
When you binNMU packages you add a +b1, +b2, … suffix to their
versions. ITYM porter upload?
those packages, but if we then try to
Don Armstrong dixit:
These are the list of ports that I see:
Question is, where do you see them?
avr32
This one got removed even from debian-ports for several
reasons.
sh
I think there's sh4 but not just sh.
Looking at the buildd pages is probably the best idea.
Combining
John Paul Adrian Glaubitz dixit:
On 11/24/2013 12:47 AM, John David Anglin wrote:
It should be going up now.
So, the buildds are already up and running? Shouldn't they be showing
up on buildd.debian-ports.org [1]?
I think I saw buildd uploads for hppa on incoming.d.o this week.
Paul Wise
Niels Thykier dixit:
Then there are more concrete things like ruby's test suite seg. faulting
on ia64 (#593141), ld seg. faulting with --as-needed on ia64
And only statically linked klibc-compiled executables work on IA64,
not dynamically linked ones. I’ve looked into it, but Itanic is so
Package: edos-distcheck
Version: 1.4.2-13+b1
Severity: normal
tglase@tglase:~ $ x edos-debcheck -failures -explain
Completing conflicts...* 100.0%
Conflicts and dependencies... * 100.0%
Solving
Package: dose-distcheck
Version: 3.1.3-5
Severity: normal
Hi,
I get the following error with dose-debcheck in both wheezy and sid:
tglase@tglase:~ $ dose-debcheck --deb-native-arch=m68k --failures --explain x;
echo $?
Fatal error in module deb/debcudf.ml:
Unable to get
Steven Chamberlain dixit:
Come to think of it, it must take a day or more for m68k to rebuild
eglibc. This is a more serious problem than resources needed by
Kernel takes a day now (on the fastest VMs), eglibc 3 days,
gcc 5 days (since gcj got folded into it; add another day or
so once gnat
Matthias Klose dixit:
I’d like to have gcj at 4.6 in gcc-defaults for m68k please,
until the 4.8 one stops FTBFSing.
please send a patch.
For gcc-defaults? I think that one is trivial…
For gcj? I did not take Compiler Design in what two semesters
of Uni I managed until I ran out of money. I
Matthias Klose dixit:
The Java and D frontends now default to 4.8 on all architectures, the Go
frontend stays at 4.7 until 4.8 get the complete Go 1.1 support.
I’d like to have gcj at 4.6 in gcc-defaults for m68k please,
until the 4.8 one stops FTBFSing.
From me nothing against switching C/C++
Steven Chamberlain dixit:
Before that can be changed, I think the gcc-defaults package expects
package version (= 4.8.1-2) whereas m68k still has only the 4.8.0-7 you
uploaded.
Right. That’s because gcj FTBFSes.
You will also first need newer binutils (= 2.23.52) which is still in
the build
Matthias Klose dixit:
Currently java bindings/packages are built for all architectures, however some
architectures still use gcj as the (only available) Java implementation, and
some OpenJDK zero ports are non-functional at this point, and Debian porters
usually don't care about that. So the
Hi,
I’ve just noticed a problem:
Wed, 23 Jan 2013 20:31:38 +
http://debian.advalem.net/debian-ports/dists/unstable/
Index of /debian-ports/dists/unstable
NameLast modified Size Description
Parent Directory-
Contents-all.gz
Michael Cree dixit:
Alpha has not been building the experimental distribution since we were
kicked out of the official Debian repo, so I have done manual builds of
Yes, that’s why I asked. (m68k, which I currently toy around in my spare
time, has similar, but worse, issues so I’m familiar with
Dixi quod…
please schedule manual builds of the following packages on
armhf alpha hppa buildds (or equivalent):
dietlibc (0.33~cvs2008-1) experimental; urgency=low
Please use 0.33~cvs2008-2 (just uploaded) instead,
it should fix hppa. (Please build in a clean chroot,
with sbuild or
Hi,
please schedule manual builds of the following packages on
armhf alpha hppa buildds (or equivalent):
dietlibc (0.33~cvs2008-1) experimental; urgency=low
mksh (40.2-3exp1) experimental; urgency=low
Note that mksh (40.2-3exp1) dep-waits on dietlibc (= 0.33~cvs2008-1)
The reason
Matthias Klose dixit:
At this point, pretty well after the GCC 4.6.0 release, I would like to avoid
switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce
maintenance efforts on the debian-gcc side, even before the multiarch changes
Porters side, too. I’m okay with
45 matches
Mail list logo
