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
Hi Itanic people,
dietlibc currently FTBFS, and I’d like to fix the issue.
How can I get access to some sort of porterbox?
Thanks,
//mirabilos
PS: non-static klibc has been broken since like forever,
and I don’t understand the VLIW-based assembly, so
please don’t wait for me to tackle
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
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, 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
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
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
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
(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
Finn Thain dixit:
Why is CONFIG_SERIAL_PMACZILOG to be disabled? And why was
See the discussion in the thread before this message.
CONFIG_EARLY_PRINTK disabled?
It was never enabled. And that’s what you get when you let
a BSD guy whose Linux experience dates back to 2.0.3[3-6]
(and some
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
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: 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
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
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
Hi,
I’ve just put some 「write(2, here1\n, 6)」 style debugging
into klibc’s libc_main.c and found out that shared binaries
seem to crash before reaching __libc_main there. And I cannot
debug an ELF interpreter with gdb, or at least I don’t know
how. Would an IA64 expert please look at this? (Note
Even this, while probably needed, doesn’t get us any further:
--- a/usr/klibc/arch/ia64/MCONFIG
+++ b/usr/klibc/arch/ia64/MCONFIG
@@ -9,3 +9,6 @@
KLIBCOPTFLAGS += -Os
KLIBCBITSIZE = 64
+
+# Extra linkflags when building the shared version of the library
+KLIBCSHAREDFLAGS = -Ttext
Matthias Klose dixit:
GCC 4.7 is now the default for x86 architectures for all frontends except the D
frontends, including KFreeBSD and the Hurd.
How are the plans for other architectures?
The m68k status (which obviously can’t influence the release decisions)
is as follows: gcc-4.7 builds,
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
36 matches
Mail list logo
