in Message ---
Hi,
On 2023-08-04 21:40, Thorsten Glaser wrote:
> Hi,
>
> some of the buildds still use Linux 4.19 but klibc has started to
> require Linux 5.1-specific features with the latest sid upload.
> This has implications on mksh (for the mksh-static and lksh binaries
Simon McVittie dixit:
>was rather recent at that time, but hopefully we no longer have any
>machines that are running Debian 8 kernels...
The varios MIPS buildds run 4.19 and some even 4.9 kernels
(AFAIHH due to hardware/patch constraints), which has led
to problems (e.g. I had to disable klibc b
Hi Simon,
thanks for testing.
>I'm using Thorsten's regression report in #983423 as my representative
>sample of a package that regressed with schroot 1.6.13-4, because mksh
>builds much more quickly than gcc-14
(You can add mksh-firstbuilt to DEB_BUILD_OPTIONS so it doesn’t build
and test binar
Simon McVittie dixit:
>On Mon, 19 Aug 2024 at 16:27:24 +0000, Thorsten Glaser wrote:
>> mksh actually does things inside script(1) that use the tty
>
>For the purposes of having a test-case for schroot that doesn't require
>mksh, perhaps a good approximation to this would b
Simon McVittie dixit:
>On Sun, 18 Aug 2024 at 23:44:57 +0000, Thorsten Glaser wrote:
>> On three buildds, mksh FTBFS already because the whole
>> /dev/ptmx and /dev/pts stuff is malfunctioning again
>
>Which buildds? Are you referring to -ports builds
>https://buildd.deb
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 li
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 ☹
bye
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
unportab
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 m
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
Ouch
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
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 spec
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, src:openssl
Lennart Sorensen dixit:
>On Tue, Nov 01, 2016 at 01:42:50PM +0900, John Paul Adrian Glaubitz wrote:
>> Since Debian powerpc was recently announced to be removed as a
>> release architecture, I would like to formally request to move the
>> port to Debian Ports as there still seems to be quite some
On Mon, 28 Mar 2016, Christian Seiler wrote:
> (Also, I'd recommend a different mirror, ftp.debian-ports.org is not
I’m using this mirror:
deb http://ftp.de.debian.org/debian-ports unstable main
deb http://ftp.de.debian.org/debian-ports unreleased main
That’s faster and usually lags by only 2 h
On Mon, 28 Mar 2016, John Paul Adrian Glaubitz wrote:
> > Unfortunately, that doesn't help me without a proper rootfs. :(
>
> Here's an image from the AmigaONE people which you can try:
Uh… debootstrap?
bye,
//mirabilos
--
>> Why don't you use JavaScript? I also don't like enabling JavaScript
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,
//mirabilos
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 look
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 unre
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 p
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 n
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 thi
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 re
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 ne
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 (>= ⌦
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
wd
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.
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, upco
(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
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
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.
Thi
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
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 2.4.
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 i
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é
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 debootst
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 ap
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 Wi
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 https://buildd.d
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
massi
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 >> $?"
Fatal error in module deb/debcudf.ml:
Unable to get real vers
Package: edos-distcheck
Version: 1.4.2-13+b1
Severity: normal
tglase@tglase:~ $ = 3.3.2-2~)
1|tglase@tglase:~ $
Architecture: all
Replaces: python3 (<< 3.3.2-4~)
Depends: python3:any (>= 3.3.2-2~)
Breaks: python3 (<< 3.3.2-4~)
Description: Debian helper tools for packaging Python libraries and ap
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 wi
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 mone
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 bui
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++
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 23-Ja
Kyle Moffett dixit:
>Additionally, even FreeScale appears to be abandoning the e500v2
>hardware; all of their new chipset families are e500mc (32-bit) or
>e5500 (64-bit), both of which return to classic PowerPC FPU and can
>run normal "powerpc" Debian.
>
>So if nobody is maintaining it anymore, pe
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, la
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 kee
51 matches
Mail list logo
