On Sun, 11 Sep 2022, Samuel Thibault wrote:
> The problem is that apparently debootstrap doesn't handle Replaces, and
Apparently, it also doesn’t handle Provides (which would fix this).
Sad.
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http
On Wed, 6 Dec 2023, Chris Hofstaedtler wrote:
>I have zero knowledge about hurd, but it looks like[1] hwclock is built
>with CMOS support on hurd. So maybe it could work?
Maybe it just needs a different config?
>Given this I'd imagine nobody has ever used the hwclock initscripts
>on hurd before
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
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
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
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
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: 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
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
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
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
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
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
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
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
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
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é
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
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.
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
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
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
(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
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
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.
[ with my m68k buildd maintainer and (ex-?) porter hat ]
Aurelien Jarno dixit:
>- debian-ports uses mini-dak instead of dak. It uses less resources and
> brings some features that are useful for new architectures like
> accepting binary uploads when it "improves" the version even if it is
> no
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
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 (>= ⌦
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
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
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
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, 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:
> >> 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:
> 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
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
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
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
On Sun, 14 Oct 2018, Andreas Henriksson wrote:
> Please note that sysvinit dependencies still have open RC bugs which
> noone is caring for.
Oof. How do I find them out? The BTS shows no RC bugs, not even
ones tagged as affects src:sysvinit, and the QA page
https://packages.qa.debian.org/s/sysvin
bly not very normal, though…
Adam Borowski wrote:
>On Mon, Oct 15, 2018 at 08:46:31AM +0200, Laurent Bigonville wrote:
>> Thorsten Glaser wrote:
>> > On Sun, 14 Oct 2018, Andreas Henriksson wrote:
>> >
>> > > Please note that sysvinit dependencies still have o
On Mon, 15 Oct 2018, Petter Reinholdtsen wrote:
> Note, I can with authority, as the person introducing dependency based
> boot and shutdown ordering in Debian, report that insserv were not
> introduced for parallell boot, nor for boot speed. It was introduced to
> correct broken boot and shutdow
On Tue, 16 Oct 2018, Adam Borowski wrote:
> > > With only two modified binary packages (policykit-1 and udisks2) I’ve
> 1. You need to recompile these packages, this is not something an average
> user or even sysadmin knows how to do.
I publish .deb packages for them (although not for all arches
Hi,
performous currently FTBFS on Hurd (and my are you people fast at
figuring out the right line from the build log and letting it show
up on buildd.d.o), I already fixed one issue and pushed it upstream
but now there’s an OS-dependent question.
It basically does this (I’m ignoring the boring st
Hi,
src:mksh just FTBFS on hurd-i386 (the failure reason given by
the buildd admin is incorrect, though). The problem is:
:>a
sleep 1
:>b
sleep 1
:>a
test a -nt b; a=$?
test b -nt a; b=$?
test a -ot b; c=$?
test b -ot a; d=$?
echo d $a $b $c $d .
This is supposed to give:
d 0 1 1 0 .
On the bu
Package: hurd
Version: 1:0.9.git20191228-1
Severity: normal
I first reported this on the mailing list:
https://lists.debian.org/debian-hurd/2020/03/msg00023.html
Now I logged in on the porterbox (exodar.debian.net) to try and
reproduce, and voilà, I can:
tg@exodar:~$ rm a b
tg@exodar:~$ :>a
tg@e
Hi,
I’ve just updated two plugins for libpurple and fixed an
FTBFS on the non-Linux ports in one. On hurd-i386 it cannot
currently build because, deep in the dependency stack,
libgupnp-igd-1.0-4 depends on a removed (transition) library
and has not rebuilt.
The build job of libgupnp-igd-1.0-4 (sr
Hi Samuel,
>It was stuck again. Looking at the logs, 0.2.5-3 succeed probably only
ouch. Time for a bugreport, I guess?
Should I or would you prefer to do it?
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
ebian. (Closes: #493839)
+ * debian/rules: Replace 「dpkg --print-gnu-build-architecture」 with
+「dpkg-architecture -qDEB_BUILD_ARCH_CPU」 to unbreak build.
+ * debian/rules: Use -Wno-unused to clean up build messages.
+
+ -- Thorsten Glaser Sat, 24 Oct 2009 21:01:40 +
+
pmake (1.111-1) un
Guillem Jover dixit:
>Here, even w/o having looked at the rules file, I think you mean
>DEB_HOST_ARCH_CPU, the *_BUILD_* variables are most of the time the
>wrong ones, mostly relevant only when cross-building.
Hm. I need the one of the system the produced binary will
eventually run on. (All this
nd to
+really fix this issue is not worth the effort. No activity in
+more than four years speaks for itself.
+ * mk/sys.mk: We do not run NetBSD® but Debian. (Closes: #493839)
+ * debian/rules: Replace 「dpkg --print-gnu-build-architecture」 with
+「dpkg-architecture -qDEB_HOST_ARCH_CPU」
Hi again,
after this long a waiting period, do you think I can have this NMU’d?
How would I go for it, as I’m not yet a DD, any sponsors?
Thanks,
//mirabilos
--
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we m
Guillem Jover dixit:
>A bit of background info. For GNU/kFreeBSD the kernel images are named
>'kfreebsd-image-*', for GNU/Hurd they are named 'gnumach'. (I should
>probably rename gnumach to match the current kernel naming convention.)
I wonder if there will ever be packages like kmidnightbsd-ima
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
Hi,
I just read on Planet Debian that you might need a DHCP
client that works first.
OpenBSD has taken ISC’s DHCP client and server, split them and
then stripped down and fixed each part independently. Maybe the
stand-alone client would be an easier target to work on, until
ISC’s carries all nece
Samuel Thibault dixit:
>Well, we don't lack working DHCP software, we do have one on
>debian-ports. What we lack is integration of our patch into the main
>archive.
Ah okay. Good luck, then.
bye,
//mirabilos
--
"Using Lynx is like wearing a really good pair of shades: cuts out
the glare a
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
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
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
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 bui
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
61 matches
Mail list logo
