Re: Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423
Simon McVittie dixit:
>I was not aware of any mips* buildds still on 4.9 (Debian 9 kernel). The
>only mips family architecture listed on buildd.debian.org is mips64el, for
I think 4.9 is some mipsel buildds. Shortly after the discussion,
which I’m attaching as I don’t know where it’s otherwise archived,
mipsel was removed from sid with no fanfare or announcement, so I
think those now only build for the old releases’ security support,
but the porters/buildd admins would know. Also unsure whether any
derivative distro still has mipsel with sid packages (but it then
is their problem to obtain newer kernels).
>If there are unofficial mips* buildds outside the buildd.debian.org
>infrastructure, then I would hope that either they can be upgraded to a
>Debian 10 or later kernel, or they can run a Debian 12 or older user-space
>(in particular, not keeping up with the latest sbuild).
Or that.
>However, if I'm
>reading kernel git history correctly, the patch proposed on #1079124
>should in principle work with any 4.7+ kernel (not tested). This would
>not have been broad enough compatibility in 2017, but seems OK now.
Yes, certainly.
Thanks,
//mirabilos
--
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival--- Begin 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
> and for passing the testsuite) as well.
>
> Could we please get the buildds to run with the stable or at least
> the oldstable kernel?
Unfortunately newer kernels do not work on those buildds:
https://lists.debian.org/debian-mips/2023/07/msg00052.html
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
--- End Message ---
--- Begin Message ---
On Fri, 2023-08-04 at 23:58 +0200, Aurelien Jarno wrote:
> 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
> > and for passing the testsuite) as well.
> >
> > Could we please get the buildds to run with the stable or at least
> > the oldstable kernel?
>
> Unfortunately newer kernels do not work on those buildds:
>
> https://lists.debian.org/debian-mips/2023/07/msg00052.html
I have to wonder why this did not disqualify mips{,64}el as release
architectures for bookworm.
The error messages are coming from of_irq_parse_pci(), which wasn't
called at all in the buster kernel because we didn't enable CONFIG_OF
or CONFIG_OF_IRQ. That changed with:
commit 8a788b0708ba1593f1fd4f3c585b7d5466a29f16
Author: YunQiang Su
Date: Sat May 23 23:17:42 2020 +0800
Enable CONFIG_OF and CONFIG_SERIAL_OF_PLATFORM for Loongson-3
Loongson64, aka loongson-3 switch to devicetree, and the console
cannot accept input anymore due to SERIAL_OF_PLATFORM is
not enabled.
While SERIAL_OF_PLATFORM depends on OF, we need to enable it
at the same time.
These options can only work with 5.7+.
Do you have an FDT for these systems, and is the boot loader passing
it? I'm guessing not, because we currently don't build or package any
FDTs in the kernel. In 6.1 these sources are available:
arch/mips/boot/dts/loongson/loongson64_2core_2k1000.dts
arch/mips/boot/dts/loongson/loongson64c_4core_ls7a.dts
arch/mips/boot/dts/loongson/loongson64c_4core_rs780e.dts *
arch/mips/boot/dts/loongson/loongson64c_8core_rs780e.dts *
arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dts
arch/mips/boot/dts/loongson/loongson64v_4core_virtio.dts
Hopefully one of those marked with an asterisk would be suitable.
Relatedly, I see that eller is also running a 4.19 kernel. What's the
story there?
Ben.
--
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams
signature.asc
Description: This is a digitally signed message part
--- End Message ---
--- Begin Message ---
On Sat, 2023-08-05 at 02:09 +0200, Ben Hutchings wrote:
[...]
> Do you have an FDT for these systems, and is the boot loader passing
> it? I'm guessing not, because we currently don't build or package any
> FDTs in the kernel.
[...]
That has actually been fixed post-bookworm, but should probably be
backported to bookworm:
https://salsa.debian.org/kernel-team/linux/-/commit/7b4954db782
Re: Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423
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 builds of mksh on them because klibc now uses Linux 5.1 features). AIUI this is being worked on, but not yet resolved. >(As far as I can see, the fstab configuration in dsa-puppet is intended to >add some lines to schroot's defaults, rather than forcing specific handling >for /dev/pts, but it forces specific handling for /dev/pts as a side-effect >because it's overwriting the whole file.) Ah, ouch. Those config tools where doing that is easier than doing the actual manipulation… Thanks again for digging into this, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999
Re: Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423
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 binaries for dietlibc/klibc/musl.) >, but I suspect that the same would >apply equally to Adrian's regression report in #856877: the important >factor is probably just "any package that wants to run script(1) >or expect(1)". I think so. >I was not able to reproduce the mksh build failure, so there must be >some relevant difference in setup (other than CPU architecture, which Oh, okay. Adrian? bye, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Re: Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423
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 be asserting that
>tty(1) from coreutils exits successfully and prints the path to a char
>device that exists and is rw?
Unsure. It also requires and accesses /dev/tty, it doesn’t just
do isatty on stdio.
>For a manual smoke-test for this change, having a known-good version
>of mksh build and pass its test suite seems like a better indicator
>that the terminal is indeed working, but I think that's too large and
>involved to make a reasonable autopkgtest for schroot to guard against
>this maybe regressing.
Right.
Looking at the code, it seems we need isatty(0) && isatty(2)
to succeed as well as open("/dev/tty", O_RDWR, 0) to succeed
(and later F_DUPFD and F_SETFD, FD_CLOEXEC fcntl).
Perhaps isolating that as a small C or Perl program to use
for those tests?
>on a pty or tty, or produce some other output if not?
Produce some other output (error messages) if not.
$ echo true | sudo chroot /tmp/a /sh -i; echo
W: /sh: can't find controlling tty: Permission denied
W: /sh: won't have full job control
# #
The two warning lines are absent if the tty is present.
They look different in older versions, though.
bye,
//mirabilos
--
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Re: Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423
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.debian.org/status/fetch.php?pkg=mksh&arch=powerpc&ver=59c-39&stamp=1724031073&raw=0, >https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=ppc64&ver=59c-39&stamp=1724031078&raw=0, >https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=sparc64&ver=59c-39&stamp=1724031447&raw=0 >each of which reported >"script: failed to create pseudo-terminal: Permission denied"? Yes, indeed. >-powerpc, -sparc teams: how are those buildds >(debian-project-be-1.buildd.org, blaauw.buildd.org, sompek.debian.net) >set up? >* host system suite: testing? unstable? other? >* kernel: seems to be 6.9.12 in each case, presumably from testing/unstable >* schroot: 1.6.13-4 or some sort of backport? >* is there any container/chroot/other confinement between the host system > and sbuild+schroot? >* any special schroot or kernel configuration? → cbmuser et al. >Thorsten, I see that >https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=m68k&ver=59c-39&stamp=1724031130&raw=0, >https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=sh4&ver=59c-39&stamp=1724031300&raw=0 >seem to be running script(1) successfully, but failing with an error >that looks different (possibly related to using qemu-user on an amd64 >system). Can I assume that those are out-of-scope here? Right, these are from the failure to set argv[0] again, which is somehow on-again off-again with these hosts, despite qemu having been fixed ages ago. >> have you actually tested that this works? > >I initially provided the patch that was recently applied to schroot back >in 2017, and unfortunately I don't completely remember what I did 7 years Fair. >ago, but I think my usual reproducer for "do pseudo-terminals work?" was >to run something like "script -c 'cat /etc/os-release' /dev/null" inside >a schroot. Is that a good mockup of what mksh needs to do, or is there Half of it: mksh actually does things inside script(1) that use the tty. I cannot test this in that environment currently, but something like… case $(script -c 'echo true | env -i /bin/mksh-static -i' 2>&1) in *[!\ \#\$]*) echo fail ;; esac … or, if you can guarantee running as nōn-root (root ignores PS1 if it does not contain an octothorpe), case $(script -c 'echo true | env -i PS1=X /bin/mksh-static -i' 2>&1) in *[!X]*) echo fail ;; esac could work (i.e. test whether the returned text is just the prompt). The -i after the shell is important. You could also check for the warning message, but their format is not guaranteed to be fixed. Or just inspect this interactively. >I have not been continually testing that patch for 7 years, and I didn't >make the decision to integrate it now, so I can't speak to what testing >was done before the upload that integrated it. tbh I was more addressing the uploader with this, but I was rather tired yesternight when I found this and just wanted to throw the ball to “someone”. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Bug#1067026: graphviz: please build without librsvg except on rust platforms
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 librsvg usage restricting it to these architectures. This is a ports-only change, release architectures are not affected, but it’ll help tremendously.
Re: python-cryptography vs. stainless steel ports
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, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Bug#1066832: fsverity-utils: hard Build-Depends on unportable package pandoc
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 unportable package written in a hard to port language. Please split the package so that the part that requires pandoc is done in an arch:all build. Normally, pandoc is needed only for documentation, which is often easy enough to split off in a -doc binary package, which can then move to B-D-Indep and be built on amd64 or whatever hosts. Thanks, //mirabilos
Re: python-cryptography vs. stainless steel ports
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 meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Re: python-cryptography vs. stainless steel ports
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. cbmuser also has hopes for rustc_codegen_gcc, but I believe that quite a way off for regular use in Debian yet and won’t hold my breath. So, perhaps at least do palliative care for the 3.8-based package in the meantime? Porters can help, but we don’t know the python ecosystem well. bye, //mirabilos -- Gast: „Ein Bier, bitte!“ Wirt: „Geht auch alkoholfrei?“ Gast: „Geht auch Spielgeld?“
python-cryptography vs. stainless steel ports
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 at first even if they may meet them later (riscv64 and loong64 now meet them) For the t64 transition, I *think* I can just binNMU the last version that worked and porter-upload that, but that’s not a workable long-term solution, especially when python transitions come, etc. Is there a chance your team could fork the old python-cryptography source package (3.4.8-2) and do something like: • rename its python3-cryptography binary package to python3-cryptography-rustless or something • let that Provide python3-cryptography in the same version Making python3-cryptography-rustless available on all arches has the benefit that people can test that their code will work on ports arches without having to bother installing one of them. I’m not entirely sure that having python3-cryptography-rustless Provides python3-cryptography, then other packages B-D/Depends python3-cryptography will work; IIRC, there was something about the first alternative must not be virtual and buildds won’t use second+ alternatives. In that case, we’ll instead need the python3-cryptography-rustless source package to build a second binary package python3-cryptography either as arch:all but in a lower version than the python-cryptography’s (if that’s okay), or as arch:any on just the affected architectures (which will end up being an annoying to maintain whitelist) that Depends python3-cryptography-rustless, to keep things installable on the buildds. With this in unstable proper, debian-ports will have a much easier job, and maintainers (both of the python3-cryptography ecosystem/packages and of software using it) can more easily test things work, and your team can apply whatever new policy changes, dh-* helpers, etc. to the 3.4.8-based package, and backport bugfixes, etc. (and perhaps there’s even an upstream fork?). The arches currently split as: • alpha 3.4.8-2 • hppa 3.4.8-2 • hurd-amd643.4.8-2 • hurd-arm64unknown, probably 3.x • hurd-i386 3.4.8-2 • ia64 3.4.8-2 • loong64 41.0.7-5 • m68k 3.4.8-2 • powerpc 41.0.7-3 • ppc64 41.0.7-5 • sh4 3.4.8-2 • sparc64 41.0.7-5 • x32 38.0.4-4 (x32 seems to be lagging in the rust department, too…) Since this exists mostly to help d-ports, it would be fine to open an RC bug against it early to prevent it from showing up in releases, if desired. Thanks for considering, //mirabilos, helping out m68k for the time_t transition again -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
sparc64 sigsetjmp buffer size mismatch?
Hi porters, I just stumbled upon an old bugreport of mine from when I was working with µClibc-ng for sparc64 (which shares the header in question with glibc): https://sourceware.org/bugzilla/show_bug.cgi?id=25093 Looking at glibc 2.30-8 in Debian, the patch still applies. It needs more eyes, as I don’t even know if it’s correct for glibc (probably is). It’s applied in µClibc-ng: https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/sysdeps/linux/sparc64/bits/setjmp.h Can anyone look at it, confirm whether it’s needed or not in glibc and post their findings to the bugtracker and possibly get the patch applied in Debian if it is needed? Might help with some signal stuff. Thanks in advance, //mirabilos -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
Re: Some hardware to give away
This was fast! The m68k and hppa stuff is already grabbed. Remaining: > Accessories: > • assorted PC keyboards and mice > • assorted monitors > Sun: > • Sun Ultra5 > > x86(?): > • 2x Targa PC Series II (some Pentium-based towers) Not much info about these. The picture of the tower on https://www.pcwelt.de/ratgeber/Targa-Powerline-WW-620-MD-ATLO-1800-116977.html is pretty accurate, but apparently, they put anything between Pentium MMX 233 MHz and Athlon XP 1800+ into them. I didn’t have time to look into them when I was in Lippstadt. bye, //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml
Some hardware to give away
Hi everyone, a good friend of mine left behind a couple of old hardware which is currently located in a basement in Lippstadt, Germany; it’s scheduled for being dumped into the trash soon (we’re talking about $smallnum weeks) but it was offered to me. I don’t currently need this, but here’s a list, in case someone decides to rescue them. Feel free to share this around, I don’t know where else to write but chances are someone interested is on these lists ☻ I’ve only listed hardware that passed a first optical inspection; we don’t know whether they have defects, but assume they will work. Accessories: • assorted PC keyboards and mice • assorted Macintosh keyboards and mice • assorted monitors Apple: • Macintosh IIvx • 2x Macintosh LC II • Performa 450 • Performa 630 • PowerMac G2 • PowerMac G3 • not sure if it’s not just a monitor, but could be an iMac G4 HPPA: • HP 712/60 Sun: • Sun Ultra5 x86(?): • 2x Targa PC Series II (some Pentium-based towers) Sorry, no Sun keyboard, I took that for my SPARCstation 20. There’s also a damaged Macintosh of the “monitor with built-in computer” form factor, where the front panel has been taken off, and other stuff, I don’t know. Please respond quickly; if you can’t fetch the hardware and we can’t manage shipping then I can at least request they put it aside or cache it in my basement temporarily. bye and fup2p please, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!
Re: Bug#845193: dpkg: recent -specs PIE changes break 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 specific >language compiler version currently marked as the default (for C that >would currently be gcc-6). Sure, but we do have other compilers and compiler wrappers in the archive, and packages are using them. >As long as gcc enables PIE on a subset, there will be need to inject >some form of specs on either subset of those arches, either on >hardening=+pie or on hardening=-pie, pick yout poison. :( […] >> Either are *much* better than the current way. > >Well you and me both, I'm just adapting the dpkg-buildflags to the >current gcc situation. :/ This sounds to me like we should reassign this to GCC (and remove all the… well, “offending”, no offence intended, code from dpkg). >Having a subset of architectures is a pain for maintainers as they True, so GCC should just enable it on all architectures where it at all works. >Well I think we should be enabling all hardening flags directly in >gcc, but now that we have the specs files I guess it would not be >too bad to enable them just in dpkg, but I agree either would be >preferable. :/ OK, thank you. bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999
Re: Bug#845193: dpkg: recent -specs PIE changes break openssl
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 (1.1) works, so… >So, I think I'll reassign this to openssl1.0, if no other feedback … this is probably legit. But I would *still* like to raise another point. >Those specs files should make it possible to build stuff with PIE 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 Worse, they break *differently* on whether… >Precisely to make the behavior consistent on all architectures, dpkg >enables PIE (conditionally if no other flags marks it as to be >disabled) on all architectures were gcc has not enabled this by >default. … that. And that is just plain wrong. Either dpkg should inject -specs= stuff on all architectures or on none. Differing like this just invites hidden and hard to track down bugs. Please get an agreement with the GCC maintainer on how to proceed from here. Personally, I’d still prefer for GCC to behave as on other systems, i.e. not to enable PIE by default, and to have it done completely within dpkg, but I can *also* live with it being done exclusively in GCC. Either are *much* better than the current way. >if no other feedback is provided showing that this is a problem in >dpkg itself, such as PIE not working at all there, and a request to >disable it for x32 in dpkg as non-functional. This can be done just as well on the GCC side. >Also BTW the gcc maintainer asked that porters >interested could request PIE to be enabled by default in gcc. What difference does it make on whether GCC or dpkg enables PIE? The two last quote sections make it clear that any architecture that currently has PIE enabled in dpkg should have it enabled in GCC in the first place. (Did dpkg enable that on porters’ requests? It does not look like that to me. This smells like overstepping boundaries.) tl;dr: I don’t care as much _which_ of GCC xor dpkg does it, as long as only one does it. FFS, just enable it on all of them unless known to absolutely not work; that’d still be better than the current mess. Thanks, //mirabilos -- [00:02] gecko: benutzt du emacs ? [00:03] nö [00:03] nur n normalen mac [00:04] argl [00:04] ne den editor -- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)
Re: binNMUs: please exercise some care
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 -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Re: binNMUs: please exercise some care
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 at the code, maybe on this weekend. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: binNMUs: please exercise some care
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 unreasonable amount of code > >> change). > > > > Sorry, aren't you saying the same thing in both cases? If not, can you > > rephrase > > or expand that? > This won't help when we have to schedule a binNMU on one or two architectures > and not all of them. That’s why I made the distinction. The change to the tool can be done by taking the highest version number across the _listed_ or _all_ architectures. (The listed ones is probably better.) On Fri, 23 Oct 2015, Adam D. Barratt wrote: > Well, except you only really want to do it for libraries that are ma:same, as > that's the only case where it actually matters and otherwise you're > pointlessly losing versions. Right, but it’s not as if losing versions would have any bad impact. > It's also not quite that simple, even working things out by hand - see #599128 > for example. Hm, I’m still under the impression that the +bN suffix to the Debian version of the package in the archive is the authoritative source for what binNMU version a package currently has, as that’s taking porter uploads into account which is a requirement. If the current code doesn’t do that I consider it a bug which must be fixed (at the same time, or before doing this change), which makes it more tricky, yes. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: binNMUs: please exercise some care
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 per batch on all affected architectures (or even to use the highest number if all architectures would be touched, but that’s probably an unreasonable amount of code change). Where’s the source code to that tool? bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: binNMUs: please exercise some care
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 number to use as argument. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: binNMUs: please exercise some care
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 this case, scheduling them is probably better. > buildds are fast enough that they already rebuilt things, then maybe > rebuilding > them again is not such a big deal... This is probably true for x32, yes, but I was concerned about M-A libraries not being coinstallable. For example, the harfbuzz library currently has one +b more than all others, making trouble for my desktop system (x32+i386 M-A). In that case, it wasn’t even because the rebuild was done twice, but, because another rebuild before the current (shared) one was necessary. How about, scheduling them all at once, but using the same version number across arches when doing it (i.e. the largest)? > That wasn't me. But I'll try to spread the word about --extra-depends, as I > agree it's useful to avoid this. I didn't use it much in the past when I just Okay, thanks a lot! Also, thanks for the response. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
binNMUs: please exercise some care
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 rebuild against the new compiler version, but that version was not yet built on m68k. (You can set extra Build-Depends and use that to version them, to make sure that, while you have the comfort of scheduling them all at once instead of in several batches, they only happen after their prerequisite has been done.) Unfortunately, I have no idea how to find out who was the person scheduling them, so this generic message will have to suffice. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: Time to change the debian-ports "list"?
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 will most likely be the best place >for their mail to go... I agree, the new ports list would probably be the better place; mails and people can still be directed elewhere, but this would take less time from people to whom the message “probably” should not have gone in the first place. (Take my recent message, for example – while the ports multiplicator was not wrong per se, the new list would have been even better. If needed I could have added individual architectures’ lists, but I’d only do that if urgent.) Adrian dixit: >I'm in favor of the old design because I think it's important to havw a >list which can be used to make announcements about important issues >that all porters should be aware of. Even then, the new design is better (active porters will likely subscribe to the new list, users won’t, but they’re getting the “spam” right now), and for archive-wide things, d-devel-announce is the place to go anyway. bye, //mirabilos -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1507222113000.27...@herc.mirbsd.org
Re: using build profiles breaks debian-ports
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~) > > ,◀ […] bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.20.1507171033500.11...@tglase.lan.tarent.de
using build profiles breaks debian-ports
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 wdiff shows: Version: ⌦2:0.146.2538+git121396c-2⌫ ▶2:0.146.2538+git121396c-3◀ Build-Depends: […] libgpac-dev (>= ⌦0.5.0+svn4288~),⌫ ▶0.5.0+svn4288~) ,◀ […] So this means that because someone added the build profiles thing, wanna-build (or something else in the component stack) on dpo can no longer calculate B-D installability for those packages, which sorta defeats the purpose of adding it. bye, //mirabilos -- >> Why don't you use JavaScript? I also don't like enabling JavaScript in > Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.20.1507170928540.11...@tglase.lan.tarent.de
Re: Debian Archive architecture removals
[ 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 > not the latest one or an "unreleased" suite for packages built from > modified source (hence architecture specific). On the contrary its There’s two more bugs that *really* disturb porters’ work in it: • it is possible to do a binary upload of the *same* version of a pak‐ kage that is currently in the archive, which breaks the package until the next bigger upload fixes it: mini-dak serves the checksums from one of the uploads but the .deb files from the other of the uploads (this can happen in case of human errors, or caused by a w-b hiccup, when a package was taken by someone (porter or buildd) and is in Building state, then vanishes from the DB, then comes back) • (much worse) library transition old-version keeping is broken: suppose there is src:isl (= 0.12.2-2) building libisl10 in the archive and built on some architecture; then, someone uploads src:isl (= 0.14-2) which builds libisl13 instead; in dak (on the main archive), the old libisl10 binary packages are kept in the Packages.gz file until there is no dependency on it any more; mini-dak just throws all NBS binary packages away immediately Oh, and the performance. On the other hand, things like the existence of unreleased really *do* help, so, a ｂｉｇ thank-you to Aurélien for running d-ports❣ bye, //mirabilos PS: I’d be happy to discuss things (dpo experience) on debconf, if I manage to make some time for that in the days I’m there; can’t say beforehand, unfortunately -- 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 merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1505061037260.27...@herc.mirbsd.org
Re: Time to change the debian-ports "list"?
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 so that people can subscribe to it; document that there is no longer an address to reach *all* ports but that people should eMail the individual ports’ lists (and cross-post if needed, but only to the amount needed), and that the new debian-ports@l.d.o instead is a mailing list for discussion about a) debian-ports.org infrastructure b) porting Debian in general c) questions related to setting up a Debian port, including wanna-build, buildd, etc. Thanks, //mirabilos -- >> Why don't you use JavaScript? I also don't like enabling JavaScript in > Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1409101858240.4...@herc.mirbsd.org
Re: Time to change the debian-ports "list"?
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 new ports, or any ports that don't quite merit having >their own mailing list yet. Agreed, all that plus the dpo infrastructure, buildd and wanna-build related setup (possibly for both dpo and the main archive), etc. >>"debian-cross-ports" or "debian-architectures" or something. > >I'd prefer not to have it, or have to sign up to it as a porter. It'd >probably get more spam than useful mail. Agree. >I can't think of a reason to mail *all* ports that wouldn't be >appropriate for debian-devel-announce; or if your mail only concerns a >few ports it should be convenient to cross-post to the relevant ports' >lists only. Fully agree. bye, //mirabilos -- ncal.c: In function 'parsemonth': warning: comparison between pointer and integer • ↑ hab da „in function parselmouth“ gelesen ICH AUCH! • Ich hab gerade gedacht "Häh? Wie, hab da parselmouth gelesen ... steht da doch auch :o?" -- too much fanfic… -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1409051936000.7...@herc.mirbsd.org
Re: [m68k] preparing for GCC 4.9
(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 said m68k was the best-(cross)bootstrappable port, and was using gcc-4.9 for it, so there are probably at least no ICEs. If Helmut can publish the *.deb files that fall out of such a (cross) rebootstrap, we could try debootstrapping (natively, in ARAnyM) from them, then boot (a VM) into them, to check basic usage. This sounds pretty few work. Other than that… we’ve built src:gcc-4.9 now, which means that at least the C/C-- part survives the three-stage bootstrap AFAICT. >packages) for other architectures. Any possibility to setup such a test rebuild >for some architectures by the porters? Afaics the results for the GCC testsuite >look okish for every architecture. … that runs it. I have no idea how to set up such a test rebuild setup, but we have somewhat clonable VMs (and a VM base image that “just” needs to be dist-upgraded to latest sid before using it), so “anybody” can do that for m68k (provided they install the aranym package from sid, as it contains FPU emulation bugfixes required by Python 3.5 at least). Also, I’d be interested in a way to run GCC’s testsuite against an installed compiler, i.e. without taking the five days needed for the bootstrap (plus adding dejagnu and removing disabling the testsuite from the package rules) again. bye, //mirabilos -- Ich gebs zu, jupp ist cool -- theftf zu Natureshadow beim Fixen von Debian -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1405081543370.28...@herc.mirbsd.org
Re: How to get d-i udeb packages for hppa-only back into unstable?
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 myself (but recognise its need, of course), so I’ve not done any work in that area. Some debootstrap patches exist, and IIRC Wouter has done/planned something on the d-i side, but he also stopped due to lack of time. >We didn't yet :(. You have to partition the disk manually and copy >a root filesystem onto it. Either that or debootstrap, yes. >I agree with Thorsten, this is a fundamental problem with Debian ports >that needs to be addressed, especially when you look at the stats how ACK. >Maybe this problem gets more attention within the rest of Debian when >sparc, which has recently been dropped from testing, will move to the >ports side. Since there are still many people running Debian on sparc, >there might be an incentive to solve this problem. Absolutely no: everyone who was using sparc post-etch will just change to sparc64, and people using a real sparc (as opposed to sparc64) have… other venues… open to them which are OT on this list ;-) >>The only simple way I see is then to set up an own repository (cloned >>from debian-ports), add the packages there and then instruct the >>installer to load the installation packages from there. This is at >>least how I got it to work sucessfully once. No, you don't need that. You can work with unstable+unreleased, if you just tell it to merge the Packages lists in the proper place, and if the mirror carries both. That being said: it is not, generally, possible to install (using either debootstrap or d-i) from “unstable”, even in Debian proper, due to missing dependencies, library transitions, etc. (which the dpo-minidak bug that doesn’t keep libraries around for as long as they’re used makes only worse). We need some sort of “testing”-lookalike suite, and a way for ports to opt-in to have packages from “unreleased” migrate into it. (This is for ports staying on dpo. Ports bootstrapping on dpo and intending to get into the main archive from there will, of course, need to have zero packages in “unreleased”, and as such, their “testing”-alike (I’d call it a different name though, and ideally one per arch¹) would have only packages from unstable too.) ① if for no other reason that, even when taking only from unstable, (binary) package version will differ, adding the need to track different versions of source packages too bye, //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1405022200020.22...@herc.mirbsd.org
Re: How to get d-i udeb packages for hppa-only back into unstable?
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 needs to be addressed on d-i side; we need better support for the dpo 'unreleased' suite there. Sorry, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;) -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1405021909120.22...@herc.mirbsd.org
Re: maintainer communication
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 to get a discussion among
debian-ports.org users started for best practices of how
to communicate with package maintainers in Debian. Sorry
for being unclear there. I had hoped for hints ☺ since I
know my communication skills lack somewhat.
bye,
//mirabilos
--
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooohhh"). [aus dasr]
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.bsm.4.64l.1312232212380.2...@herc.mirbsd.org
Re: maintainer communication
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.3) do the Debian/m68k Linux kernel config, instead of someone who actually knows about this. I did warn y’all back then. Now we got a config, and we can incrementally improve it. >how it can help when it is downstream of the kernel developers. Eh? Parse error. bye, //mirabilos -- „Also irgendwie hast du IMMER recht. Hier zuckelte gerade ein Triebwagen mit der Aufschrift "Ostdeutsche Eisenbahn" durch Wuppertal. Ich glaubs machmal nicht…“ -- Natureshadow, per SMS „Hilf mir mal grad beim Denken“ -- Natureshadow, IRL, 2x -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312231645470.2...@herc.mirbsd.org
maintainer communication (was Re: Debian kernel regression, was Re: Modernizing a Macintosh LC III)
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 in cowbuilder manually on a – possibly faster – VM.) The request to the GCC maintainer to somehow make autoconf regenerate some more configure scripts, to fix the -fpic/-fPIC problem, was, of course, also not integrated. I think we need to file bugs in the BTS for each of these instances in the future, instead of trying to communicate with the maintainers directly. I hate it, because I like to talk to humans more, and some people on the Debian side hate it too (“because debports is not Debian”), but… *shrug*. Tell me if you have a better idea. Or anything else to comment on this matter. To clarify: this is *not* intended to make package maintainers show in a bad light, rather the contrary, trying to improve things. I can understand that things that are not in the BTS are likely to be forgotten (in fact I forgot a suggestion how to do/fix something too, due to falling ill last week and not writing it down e.g. in the bug). Thanks, //mira“still on antibiotics but recovering”bilos -- Beware of ritual lest you forget the meaning behind it. yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312231011210.24...@herc.mirbsd.org
Re: debootstrap and debian-ports
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 can persist them TTBOMK (like etch-m68k was). I’ve got a manually created mini-repository for m68k, but experience shows acceptance of these is questionable even if done by a DD, *and* you need custom archive keys, so I think it’s best to stick to “more official” ways if these contain all needed packages in unstable (or debootstrap’s patched to handle unreleased). bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312182157360.19...@herc.mirbsd.org
Re: debootstrap and debian-ports
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 debootstrap’able, and has regularily been broken. Good news for m68k though: eglibc, gcc-4.8 and linux are no longer in “unreleased”. In fact: tg@freewrt:~ $ u=/var/lib/apt/lists/ftp.de.debian.org_debian-ports_dists_unreleased_main_binary-m68k_Packages tg@freewrt:~ $ # test idempotency tg@freewrt:~ $ grep-dctrl -r -P . <$u | diff -u - $u | wc 0 0 0 tg@freewrt:~ $ # get me all source packages that have packages in unreleased/m68k tg@freewrt:~ $ grep-dctrl -r -P . -n -s Source:Package <$u | sort -u atari-bootstrap atari-fdisk gcc-4.6 gcj-4.6 glib-networking gnat-4.6 google-gadgets libbluray m68k-vme-tftplilo m68kboot mesa mysql-5.1 vmelilo webkit We can group them by: • architecture-specific packages atari-bootstrap atari-fdisk m68k-vme-tftplilo m68kboot vmelilo • architecture-specific patches, packages going away in sid soon anyway gcc-4.6 gcj-4.6 gnat-4.6 mysql-5.1 (actually already gone) • maintainer refuses integrating our patches libbluray (maybe ping again?) mesa(refusal also upstream) • patches need to be updated against current versions of the packages google-gadgets (waits on webkit/gtk) webkit • “Build without libproxy, for bootstrapping.” glib-networking None of them is, however, strictly needed for debootstrap (although the architecture-specific packages may be needed when d-i’ing a system). I read somewhere that Aurélien regularily creates snapshots of debian-ports – which means that we can install m68k from these, Right Now™. deb http://ftp.debian-ports.org/debian-snapshot/2013-12-12/ unstable main This should work. Maybe Aurélien can “freeze” one of these, if needed? -- Back to debootstrap. Yes, it needs support for multiple versions (already has some, atm) and the unreleased distribution right now. I guess APT’s ordering (from a given package, always use the dpkg-numerically largest version, ignoring all dpkg-numerically smaller versions, period) would work for now, as we don’t have the arch:all/arch:any mix in the minbase, base or buildd set much (except libsemanage-common). Everything else needs a very complicated solver (such as, use an older libsemanage-common that works with the libsemanage1 version in the archive) and is out of scope for the sh-based debootstrap. bye, //mirabilos (short, caught the flu) -- │ untested │ tut natürlich │ was auch sonst ... │ fijn ☺ -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312181709050.19...@herc.mirbsd.org
Re: debian-ports.org getting relatively unstable (hppa)
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 apt-get-update those later on, this leads
>to a "size mismatch" error. I do have the feeling, that this is a
>problem on debian-ports.
I noticed this problem too, when I accidentally built a package
I already had uploaded (and totally forgotten about): basically,
the new *.deb files are accepted but the Packages file still
contains the checksums etc. from the old *.deb file.
Only way to fix this is to reupload the old *.changes file, or
to do a binNMU proper. Or to build a newer version, ofc…
>So, I'm anxious, that if I start the buildd, it will happily build and upload
>packages
>which we already uploaded to debian-ports. If this happens we will get more
>size-mismatch errors.
That’s what you have wanna-build for. Basically, stop doing
manual uploads without wanna-build locking at least six hours
before turning on the first buildd. After that time, when you
want/need to build a package manually, lock it in wanna-build:
either “take” it for building, or mark as N-F-U.
See here for more info on that:
• https://wiki.debian.org/M68k/Porting#binNMU_notes
• http://lists.debian.org/debian-68k/2012/12/msg00124.html
• http://lists.debian.org/debian-68k/2013/10/msg00021.html
If you have packages that buildds should never build, for example
like we had gcc-4.{6,8} for some time, mark them as Not-For-Us;
otherwise, just take them for building.
>deller@leda:~$ wb info hello . hppa
This the same as “wanna-build -A hppa -d unstable --info hello”.
>But on http://ftp.debian-ports.org/debian/pool-hppa/main/h/hello/ you can
>see, that the hello-package is already uploaded at version 2.8-4
Indeed. This is bad, new, another / a different problem, and we
didn’t have this on m68k. (Note that uploads usually take a bit
until they show up on w-b, hence the need for locking.)
>So, if my buildd now uploads the newly created hello package, I'm sure
>we will run again into the size-mismatch problem.
Yes, you will definitely run into that problem when you upload
hello_2.8-4_hppa again.
>My question here on the list would be, if you (other arch-porters) do have an
>idea
>on how I should proceed.
Either…
>Best solution would probably be, if the wanna-build database rescans what's in
>the archive already. Is this possible?
… that (no idea if it’s possible), or make two lists: a list of what
is currently in the archive for hppa, and a list of packages in the
Needs-Build or BD-Uninstallable¹ state. Then, for every package in
the same versions (except +b* sufficēs) in *both* lists, schedule a
binNMU (e.g. to get hello_2.8-4+b1_hppa). Do note whether it already
got a binNMU suffix: e.g. aclock.app_0.2.3-3+b4 would need to be
scheduled for --binNMU=5 to be larger.
You might be able to cheat, e.g. take hello for building, then tell
it that you uploaded it. But I don’t know why w-b doesn’t register
that it’s there in the first place, so a rescan, if possible, should
happen first.
Hm, only 12 packages here:
tg@leda:~$ wanna-build -A hppa -d unstable --list=needs-build | less
But this has more (9043):
tg@leda:~$ wanna-build -A hppa -d unstable --list=bd-uninstallable | less
① You need to include BD-Uninstallable because they will happily
convert to Needs-Build once you upload e.g. perl.
>Or, should I just start the buildd and see what's happening? If we then get
No, get the w-b list consistent first.
According to
http://ftp.debian-ports.org/debian/dists/unstable/main/binary-hppa/Packages.bz2
hello is at version 2.8-4 just fine… hmm. So the apt-ftparchive database
seems to be correct.
This is all quite complicated, so feel free to ask around when we
can help you out again, no need for every arch to go through all
of this by themselves, figure out best practices again, etc.
HTH & HAND,
//mirabilos
--
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.bsm.4.64l.1312151335210.21...@herc.mirbsd.org
Re: Bug#730258: please add arch-specific BTS tags
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 dixit: >are other ports out there not maintained on d-p.o (like the Interix or Huh, the Interix port is not vaporware? Interesting… bye, //mirabilos -- cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten die nicht noch 3 Jahre warten können? bis dahin gibts google nicht mehr ja, könnte man meinen. wahrscheinlich ist der angekündigte welt- untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum müssen die die doodles vorher noch raushauen -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1311240019570.12...@herc.mirbsd.org
Re: Bug#730258: please add arch-specific BTS tags
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.debian.org/status/package.php?p=mksh and http://buildd.debian-ports.org/status/package.php?p=mksh (and ignoring s390 removal) gives us this list: alpha amd64 arm64 armel armhf hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc powerpcspe ppc64 s390x sh4 sparc sparc64 x32 This keeps hppa, which I’ve seen have some activity recently. >has another; I'd like to reference a canonical location for ports >(perhaps maintained by debian-ports or similar) so I don't have to Even the list on debian-ports is out of date wrt. debian-ports architectures – it misses x32 and arm64, for example. Sorry about that. There seems to be nobody keeping this list up to date so looking at the buildds seems best. Another option is of course to look at what dpkg supports, unearthing things like armeb, arm, avr32, sh3, etc. bye, //mirabilos -- „Also irgendwie hast du IMMER recht. Hier zuckelte gerade ein Triebwagen mit der Aufschrift "Ostdeutsche Eisenbahn" durch Wuppertal. Ich glaubs machmal nicht…“ -- Natureshadow, per SMS „Hilf mir mal grad beim Denken“ -- Natureshadow, IRL, 2x -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1311232243030.12...@herc.mirbsd.org
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
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 massively foreign I didn’t manage to find out anything except that the problem appears to happen before main. >Until we have a clear definition of "actively maintained ports", I would >recommend porters to err on the side of being verbose over being silent. I’ve held off on the m68k side because I think the role call was only for architectures in the main archive, right? >[1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be >acceptable as a default for Jessie. Didn't Doko say he’d want 4.8? We (on the m68k side) are putting effort into that one, since 4.7 appears to only be used by eglibc right now. And 4.6 for GNAT, but gnat-4.8 is new, and the ICE may be fixed as there’s active upstream on the GCC/m68k side. bye, //mirabilos -- Beware of ritual lest you forget the meaning behind it. yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1311031444380.31...@herc.mirbsd.org
Bug#727642: dose-distcheck: fails on input that works with edos-debcheck and is "correct"
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 version for unscd All Known versions for this package are (libc6,2.17),(locales,2.17),(locales-all,2.17),(nscd,2.17) report: - package: m68k:unscd version: 0.48-2+b1 architecture: m68k essential: false source: unscd (= 0.48-2) status: broken reasons: - conflict: pkg1: package: m68k:libc6 version: 2.17-92 architecture: m68k essential: false source: eglibc (= 2.17-92) unsat-conflict: >>> 64 The file 'x' is attached. edos-debcheck on wheezy handles this just fine: tg@freewrt:~/DP $ edos-debcheck -failures -explain >> $?" Completing conflicts...* 100.0% Conflicts and dependencies... * 100.0% Solving* 100.0% >>> 0 Please cross-reference #727550 in which Ralf Treinen suggested to use this as replacement. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Versions of packages dose-distcheck depends on: ii libbz2-1.0 1.0.6-5 ii libc6 2.17-93 ii libpcre31:8.31-2 ii librpm3 4.11.1-3 ii librpmio3 4.11.1-3 ii zlib1g 1:1.2.8.dfsg-1 dose-distcheck recommends no packages. dose-distcheck suggests no packages. -- no debconf information Package: libc6 Source: eglibc Version: 2.17-92 Architecture: m68k Maintainer: GNU Libc Maintainers Installed-Size: 8557 Suggests: glibc-doc, debconf | debconf-2.0, locales Conflicts: prelink (<= 0.0.20090311-1), tzdata (<< 2007k-1), tzdata-etch Breaks: locales (<< 2.17), locales-all (<< 2.17), nscd (<< 2.17) Provides: glibc-2.17-1 Filename: dists/sid/main/0_Essential/eglibc/libc6_2.17-92_m68k.deb Size: 2047460 MD5sum: ac5cd6a7fee0621ce747a2baf20c6a7c SHA1: 842393ab17ccf0f8c0f1bca5db873035e0c13ad4 SHA256: f2c09d9af2b2c56236af965ce0d301442c75f70448b53134da60e3de8a90b6ea Section: libs Priority: required Multi-Arch: same Homepage: http://www.eglibc.org Description: Embedded GNU C Library: Shared libraries Contains the standard libraries that are used by nearly all programs on the system. This package includes shared versions of the standard C library and the standard math library, as well as many others. Package: unscd Source: unscd (0.48-2) Version: 0.48-2+b1 Architecture: m68k Maintainer: Don Armstrong Installed-Size: 74 Depends: libc6 (>> 2.17), libc6 (<< 2.18) Conflicts: nscd Replaces: nscd Provides: nscd Filename: dists/sid/main/8_Nice/unscd/unscd_0.48-2+b1_m68k.deb Size: 19016 MD5sum: 4a617bd9b133ac3ab9859c90e75498c8 SHA1: e476ab3e1e09d42b6d035498f58fa80dc1a7b8f7 SHA256: 11dc8c377d6d45b3b759576ae37e31ba6a21b584f26f959f9d5b1f7eb361eeeb Section: admin Priority: extra Homepage: http://busybox.net/~vda/unscd/ Description: Micro Name Service Caching Daemon A daemon which handles passwd, group and host lookups for running programs and caches the results for the next query. You only need this package if you are using slow Name Services like LDAP, NIS or NIS+. . This particular NSCD is a complete rewrite of the GNU glibc nscd which is a single threaded server process which offloads all NSS lookups to worker children; cache hits are handled by the parent, and only cache misses start worker children, making the parent immune to resource leaks, hangs, and crashes in NSS libraries. . It should mostly be a drop-in replacement for existing installs using nscd.
Bug#727550: edos-distcheck: edos-debcheck MUST support :any qualifier ASAP
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 applications Description-md5: 9f24690d2f6e9b70048dc4079a2dfca7 Section: python Priority: optional Filename: pool/main/d/dh-python/dh-python_1.20131021-1_all.deb Size: 51304 MD5sum: 5790257e34d861016fea18b20e3d0294 SHA1: 3a5eaf99f97f7dbf93976ba480ef4a00068131a3 SHA256: e2f8706c54e2852c2f9537f87208059bfee6c66baef2c662801b9cf1094e13ec Package: python3 Source: python3-defaults Version: 3.3.2-17 Installed-Size: 99 Maintainer: Matthias Klose Architecture: i386 Description: interactive high-level object-oriented language (default python3 version) Description-md5: 81733bd73a4c1fc634a99143ddb31ea1 Multi-Arch: allowed Homepage: http://www.python.org/ Tag: devel::interpreter, devel::lang:python, devel::library, implemented-in::c, implemented-in::python, role::devel-lib, role::program, role::shared-lib Section: python Priority: optional Filename: pool/main/p/python3-defaults/python3_3.3.2-17_i386.deb Size: 20618 MD5sum: 7c310b77541682c434c0882f3852ad0f SHA1: 6072efeb030d51e309c6d71699006023368e37be SHA256: 293057a81fbf839516e70a315e6fea0cd75e9c24506ea0e0ec30f2576ad5d360 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Versions of packages edos-distcheck depends on: ii libbz2-1.0 1.0.6-5 ii libc6 2.17-93 ii libgdbm3 1.8.3-12 ii libpcre3 1:8.31-2 ii libpopt0 1.16-7 ii librpm34.11.1-3 ii librpmio3 4.11.1-3 ii perl 5.18.1-4 ii python 2.7.5-5 ii python-debian 0.1.21+nmu2 ii zlib1g 1:1.2.8.dfsg-1 edos-distcheck recommends no packages. edos-distcheck suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131024081712.12852.56726.report...@tglase.lan.tarent.de
Re: Bits from the Release Team (Jessie freeze info)
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 will also be folded). >Jenkins. We can't ask them to rebuild their entire toolchain each night! No OpenJDK either (can probably be fixed, but zero is sloow). Additionally, with only, say, 256 or 768 MiB physmem, running additional software on the buildds is something you do not want, considering how much RAM building some stuff takes (I had to use about 5 GiB of swap to link Webkit, and imagine just how much paging that involves, also in terms of time). Building GCC isn’t exactly resource-saving. (Even running apt/dpkg isn’t due to the sheer size of the archive, though Guillem kindly reduced memory usage in the upcoming dpkg upload.) I think with my “better SCC proposal” we could have a sliding scale for this, but I’d oppose using something OpenJDK-based for that (think of mipsel, too). Especially as simple mksh scripts would take care of the job too (including CGI for web export ;). bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1310231242320.29...@herc.mirbsd.org
Re: Current and upcoming toolchain changes for jessie
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 will, however, forward #711558 to upstream. I can’t do everything, but I don’t think anyone can accuse me of not trying either… >> From me nothing against switching C/C++ to 4.8 for m68k at >> this point, but I’d like to hear at least Wouter’s opinion >> on that, and possibly Mikael since he’s not just doing work >> upstream on gcc but also using it (for ColdFire) heavily. > >same as well, please send a patch. Wouter, Mikael: input on switching C/C++ to 4.8? [ Ada ] >try it and send a patch please. Would be useful to get it compiled first, for which #711558 is currently the blocker AFAICT. But I guess I’ll try eventually. Note to myself: do not “temporarily help out” in any more Debian projects, you’ll never leave them… bye, //mirabilos, sponsoring for a week of Linuxhotel would be nice… (I’m seriously short of hacking time, in general, recently, and could use some switching of paper hangings for a while) -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (259 (278) bugs: 0 RC, 182 (196) I&N, 77 (82) M&W, 0 (0) F&P) ‣ src:dash (86 (102) bugs: 3 RC, 41 (46) I&N, 42 (53) M&W, 0 F&P) ‣ src:mksh (2 bugs: 0 RC, 0 I&N, 2 M&W, 0 F&P, 1 gift) http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit? -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1306141907290.27...@herc.mirbsd.org
Re: Current and upcoming toolchain changes for jessie
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 queue. True; that’s new, but it’ll be done eventually, no hurries there ☺ bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (259 (278) bugs: 0 RC, 182 (196) I&N, 77 (82) M&W, 0 (0) F&P) ‣ src:dash (86 (102) bugs: 3 RC, 41 (46) I&N, 42 (53) M&W, 0 F&P) ‣ src:mksh (2 bugs: 0 RC, 0 I&N, 2 M&W, 0 F&P, 1 gift) http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit? -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1306132021420.22...@herc.mirbsd.org
Re: Current and upcoming toolchain changes for jessie
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++ to 4.8 for m68k at this point, but I’d like to hear at least Wouter’s opinion on that, and possibly Mikael since he’s not just doing work upstream on gcc but also using it (for ColdFire) heavily. For Ada, I’d like to see a successful build of gnat-4.8 (from src:gcc-4.8, if I understand the recent changes right) first; gnat-4.6 mostly works at the moment, but I’m not sure about the upstream situation wrt. patches from Mikael. bye, //mirabilos -- 17:08⎜«Vutral» früher gabs keine packenden smartphones und so 17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig 17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch 17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1306131944240.22...@herc.mirbsd.org
Re: changing the java default to java7, and dropping java support for some architectures
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 architectures to drop java support >would be Yeah, sorry, I really should contact the Zero developers about why it doesn’t work on m68k. On the other hand, judging from the talk at FOSDEM, their focus seems to be on Shark these days, and Zero isn’t worked much on upstream either… but “us porters” should definitely get at least Zero working. (No LLVM for m68k in sight. There’s a project, but everything interesting is stubbed out. I don’t do C++.) bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1305061920550.7...@herc.mirbsd.org
debian.advalem.net mirror seems to not be using the proper method
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-Jan-2013 20:36 17M Contents-alpha.gz 23-Jan-2013 20:58 23M Contents-hppa.gz23-Jan-2013 20:59 21M Contents-m68k.gz23-Jan-2013 20:59 21M Contents-powerpcspe.gz 23-Jan-2013 21:00 21M Contents-ppc64.gz 23-Jan-2013 21:00 22M Contents-sh4.gz 23-Jan-2013 21:01 22M Contents-sparc64.gz 23-Jan-2013 21:01 22M Contents-x32.gz 23-Jan-2013 21:02 18M InRelease 23-Jan-2013 21:03 22K Release 23-Jan-2013 14:46 20K Release.gpg 23-Jan-2013 14:46 1.5K main/ 25-Dec-2012 13:54 - This looks to me as if the mirror uses something like rsync with exclusion but doesn’t exclude the Contents and the new InRelease file in the first run. It should use the ftpsync script, or at least the minimum mirror requirements. See: http://rgeissert.blogspot.de/2012/11/better-routing-less-bad-apples.html Cc’ing the ports lists for ports that use Debian-Ports, so they are informed of this possible problem. bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (256 (275) bugs: 0 RC, 178 (192) I&N, 78 (83) M&W, 0 (0) F&P) ‣ src:dash (82 (96) bugs: 4 RC, 36 (40) I&N, 42 (52) M&W, 0 F&P) ‣ src:mksh (1 bug: 0 RC, 0 I&N, 1 M&W, 0 F&P) http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit? -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1301232033370.14...@herc.mirbsd.org
Re: GCC 4.7 is now the default for x86 architectures
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, last time I looked gcj-4.7 didn’t but it is currently building again (so let’s see whether it does this time); gcc-4.6 and gnat-4.6 are getting development and bugfixes (I’ve queued up some patches, but am not entirely ready with all of them, plus some for binutils and gdb), and I’ve asked for help re. the gcj-4.4/gcj-4.6 recent problems. But nothing has tested gcj-4.7, and I fear of new and old bugs… so I’d rather not switch default compiler to it anytime soon. As for gcc-4.7 in general: a friend (authoring an ObjC framework _and_ runtime) told me that it dropped support for an old method of doing things while not fulfilling the promise to get the new method of doing it (don’t exactly remember what it was, /msg js on freenode for details) fixed, with the effect that gobjc-4.7 is virtually useless/broken. This is hearsay, but ask him for details, and check them against reality. bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1205071730550.28...@herc.mirbsd.org
Re: failed sparc build of mksh 40.2-3
Hi sparc (and sparc64, same issue) porters! >Debian buildds dixit: > >> * Source package: mksh >> * Version: 40.2-3 >> * Architecture: sparc >> * State: failed >> * Suite: sid >> * Builder: lebrun.debian.org >> * Build log: >> https://buildd.debian.org/fetch.cgi?pkg=mksh&arch=sparc&ver=40.2-3&stamp=1319590758&file=log The problem being: >+ gcc -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat >-Wformat-security -Werror=format-security -Wall -Wextra -fno-strict-aliasing >-fstack-protector-all -fwrapv -flto=jobserver -std=gnu99 -fPIE -pie >-Wl,-z,relro -Wl,-z,now -fuse-linker-plugin -o mksh lalloc.o edit.o eval.o >exec.o expr.o funcs.o histrap.o jobs.o lex.o main.o misc.o shf.o syn.o tree.o >var.o strlcpy.o printf.o >edit.o (symbol from plugin): warning: memset used with constant zero length >parameter; this could be due to transposed parameters >`__sparc_get_pc_thunk.l7' referenced in section `.text' of >/tmp/ccwb0C7i.ltrans12.ltrans.o: defined in discarded section >`.text.__sparc_get_pc_thunk.l7.2988[__sparc_get_pc_thunk.l7.2988]' of >/tmp/ccwb0C7i.ltrans12.ltrans.o >`__sparc_get_pc_thunk.l7' referenced in section `.text' of >/tmp/ccwb0C7i.ltrans26.ltrans.o: defined in discarded section >`.text.__sparc_get_pc_thunk.l7.2613[__sparc_get_pc_thunk.l7.2613]' of >/tmp/ccwb0C7i.ltrans26.ltrans.o >collect2: ld returned 1 exit status This looks like a toolchain (binutils?) issue to me, probably from either +pie or +bindnow hardening flags being introduced into the package. I’ve asked doko whether he’s seen something like this already, but maybe one of you’s got an idea too, before I try to investigate this on a porterbox. Now that I see it… might also be a GCC issue, recalling http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625 but that was years ago, and COMDAT support shouldn’t have become missing… anyway if it’s a known issue I’d like to know. Thanks, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1110262010020.5...@herc.mirbsd.org
Re: Need a hand to test fdutils
Matteo Cypriani dixit: >the bugs with a recent version of fdutils (the last one if possible, which is >5.5-20060227-5). While I don’t have the hardware, I’ll compile and upload that version of fdutils now. I hope one of the porters can then try it out and come back to you. bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (254 (273) bugs: 1 RC, 175 (190) I&N, 78 (82) M&W, 0 F&P) ‣ src:dash (82 (90) bugs: 3 RC, 44 (47) I&N, 35 (40) M&W, 0 F&P) ‣ src:mksh (2 bugs: 0 RC, 0 I&N, 2 M&W, 0 F&P) -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1108101835140.16...@herc.mirbsd.org
Re: GCC-4.5 as the default for (at least some) architectures
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 keeping gcc-4.4 for a while (kernel?) and switching to gcc-4.6 directly for m68k. I know I’ll probably have to invest some work into the latter, but considering the kernel problem is almost solved, chances are good. (I do want to bring out a new base emulator image first, though, but then…) bye, //mirabilos -- 13:47⎜ if i were omnipotent, i would divide by zero all day long ;) (thinking about http://lobacevski.tumblr.com/post/3260866481 by waga) -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1104261853560.28...@herc.mirbsd.org
