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
Re: Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use
Hi Andreas, >>> Jessica Clarke brought out docs saying f8‥f15 must be saved, the >>> other FPU registers not: > >I can confirm this. It is f8-f15 for the z/Architecture (64 bit). thanks! >It is f1, f3, f5, f7 for the ESA >architecture (32 bit) which is still supported by Glibc and GCC. Is this what we know as s390 in Debian? (klibc saves f4 and f6 there currently. If so, this also needs to change.) >>> … GCC chooses to allocate an FPU register for a pointer value. > >GCC will put integer values into vector registers for >auto-vectorization or for spilling. We also use call-clobbered FPRs as >save slots for GPRs in leaf-functions if can get rid of allocating a >stack frame that way. Ah, interesting. Thanks! >The vector registers are call-clobbered - exactly for the reason of >setjmp / longjmp. Only f8-f15 need to be saved. Right. >You can find the latest version of our ABI here: >https://github.com/IBM/s390x-abi/releases/download/v1.5/lzsabi_s390x.pdf > >However, it is still lacking the vector ABI extension. I wrote a >document for that which we use internally and we are working on >integrating it into the publicly available version. OK, thanks for the information! >>> @klibc list: as indicated earlier, I can provide a patch if needed >>> (though it should be obvious). hpa, maks, bwh: any of you taking these two or should I send patches and possibly NMU klibc in Debian? Thanks, //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: Debian #943425: [s390x] setjmp/longjmp do not save/restore all registers in use
Dixi quod… >Jessica Clarke brought out docs saying f8‥f15 must be saved, the >other FPU registers not: This needs to be fixed in klibc. >>• klibc does not really support the FPU anyway > >… GCC chooses to allocate an FPU register for a pointer value. This is a curiosity. >>• the half of v10 that equals f10 just HAPPENS to be saved by >> glibc, but what if the upper half, that is outside of the FPU, >> is used? > >The question here is, does GCC only use the halves of the half >of the vector registers that match the FPU registers? 04:41⎜«jrtc27:#debian-x32» hephaistor: re s390x vector registers, reading the gcc and llvm sources they're ⎜all call-clobbered by default, only the float parts are call-saved 04:41⎜«jrtc27:#debian-x32» so that's why setjmp/longjmp don't need to save/restore them 04:42⎜«jrtc27:#debian-x32» there *is* a vector calling convention, but it's not the default for the ABI, ⎜it's opt-in, and setjmp/longjmp won't be annotated as such So we indeed need to only save the registers glibc does. >@klibc list: as indicated earlier, I can provide a patch if needed >(though it should be obvious). bye, //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.)
Debian #943425: [s390x] setjmp/longjmp do not save/restore all registers in use (was Use of $v10 register (was Re: klibc: [s390x] SIGSEGV in mksh testcase funsub-2))
Dixi quod… >So, setjmp/longjmp in klibc save f1/f3/f5/f7 (as shown on Wikipedia >https://en.wikipedia.org/wiki/Calling_convention#IBM_System/360_and_successors >“the z/Architecture ABI,[11] used in Linux” a page down), while >glibc’s save f8–f15 instead. Jessica Clarke brought out docs saying f8‥f15 must be saved, the other FPU registers not: https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSeries.html#AEN413 This matches what glibc does. Maybe an s390x porter wishes to fix Wikipedia? >https://share.confex.com/share/124/webprogram/Handout/Session16897/SHARE_Seattle_2015_SIMD.pdf >shows that the vector registers overlap and extend the FPU registers. >• is register v10 (vector extension) even supposed to be used? This needs to be answered, I guess, because… >• klibc does not really support the FPU anyway … GCC chooses to allocate an FPU register for a pointer value. >• the half of v10 that equals f10 just HAPPENS to be saved by > glibc, but what if the upper half, that is outside of the FPU, > is used? The question here is, does GCC only use the halves of the half of the vector registers that match the FPU registers? @klibc list: as indicated earlier, I can provide a patch if needed (though it should be obvious). bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Use of $v10 register (was Re: klibc: [s390x] SIGSEGV in mksh testcase funsub-2)
retitle 943425 klibc: [s390x] setjmp/longjmp do not save/restore all registers
in use
# because this affects a release architecture
severity 943425 serious
thanks
Recapping for the benefit of d-s390@l.d.o:
> The code in question (where it crashes) is thus:
>1607 */
>1608 valsub(t, NULL);
>1609 subst_exstat = exstat & 0xFF;
>1610 /* rewind the tempfile and restore regular stdout */
>1611 lseek(shf_fileno(shf), (off_t)0, SEEK_SET);
> The crash occurs in line 1611 because shf (a local variable) is nil.
>
> The really interesting part, though, is in line 1608, a call to valsub():
[…]
>2104 if (!kshsetjmp(e->jbuf))
>2105 execute(t, XXCOM | XERROK, NULL);
[…]
kshsetjmp(x) is sigsetjmp(x,0) (though klibc ignores the 0).
execute() calls siglongjmp().
> - it appears as if the combination of sigsetjmp/siglongjmp does not restore
> all callee-saved variables correctly on s390x; comparing with glibc shows
> that the wrong FPU registers seem to be saved but mksh does not use the
> FPU anyway
>
> Setting breakpoints to lines 1608 (valsub call) and 1609:
[…]
> 1608valsub(t, NULL);
> (gdb) print shf
> $5 = (struct shf *) 0x3fffdfe5de8
> (gdb) print
> Address requested for identifier "shf" which is in register $v10
> (gdb) print $v10
> $6 = {v4_float = {1.43352833e-42, -4.22639375e+37, 0, 0}, v2_double =
> {2.1729070589754877e-311, 0}, v16_int8 = {
> 0, 0, 3, -1, -3, -2, 93, -24, 0, 0, 0, 0, 0, 0, 0, 0}, v8_int16 = {0,
> 1023, -514, 24040, 0, 0, 0, 0},
> v4_int32 = {1023, -33661464, 0, 0}, v2_int64 = {4398012849640, 0}, uint128
> = 81129017470195127308370827018240}
>
> 0x3FFFDFE5DE8 is 4398012849640 which is in v2_int64, found.
[…]
> Breakpoint 2, comsub (fn=14, cp=0x0, xp=) at
> ../../eval.c:1609
> 1609subst_exstat = exstat & 0xFF;
[…]
> (gdb) print $v10
> $7 = {v4_float = {0, 0, 0, 0}, v2_double = {0, 0}, v16_int8 = {0 times>}, v8_int16 = {0, 0, 0, 0,
> 0, 0, 0, 0}, v4_int32 = {0, 0, 0, 0}, v2_int64 = {0, 0}, uint128 = 0}
--
So, setjmp/longjmp in klibc save f1/f3/f5/f7 (as shown on Wikipedia
https://en.wikipedia.org/wiki/Calling_convention#IBM_System/360_and_successors
“the z/Architecture ABI,[11] used in Linux” a page down), while
glibc’s save f8–f15 instead.
https://share.confex.com/share/124/webprogram/Handout/Session16897/SHARE_Seattle_2015_SIMD.pdf
shows that the vector registers overlap and extend the FPU registers.
(gdb) info float
[…]
f102.172907066248134e-311 (raw 0x03fffdfe9768)
(gdb) print shf
$2 = (struct shf *) 0x3fffdfe9768
The real questions here are:
• is register v10 (vector extension) even supposed to be used?
• klibc does not really support the FPU anyway
• the half of v10 that equals f10 just HAPPENS to be saved by
glibc, but what if the upper half, that is outside of the FPU,
is used?
• where *is* the s390x̲ ABI documented anyway? syscall(2) has the
kernel side only
Building with -mno-vx does not seem to help, %f* are still in
the .s files generated by gcc.
So I assume klibc should save registers f8–15 on s390x but what
happened to f1/f3/f5/f7?
Thanks,
//mirabilos
--
[17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker:
veni, vidi, fixi(t) ;-)
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, 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: > 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: > 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-s390-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
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~) !stage1,◀ […] 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-s390-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: 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~) !stage1,◀ […] 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-s390-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
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 -- gcc ncal.c: In function 'parsemonth': warning: comparison between pointer and integer • mirabilos ↑ hab da „in function parselmouth“ gelesen Natureshadow ICH AUCH! • Natureshadow Ich hab gerade gedacht Häh? Wie, hab da parselmouth gelesen ... steht da doch auch :o? -- too much fanfic… -- To UNSUBSCRIBE, email to debian-s390-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 -- theftf Ich gebs zu, jupp ist cool -- theftf zu Natureshadow beim Fixen von Debian -- To UNSUBSCRIBE, email to debian-s390-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?
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 -- igli exceptions: a truly awful implementation of quite a nice idea. igli just about the worst way you could do something like that, afaic. igli it's like anti-design. mirabilos that too… may I quote you on that? igli sure, tho i doubt anyone will listen ;) -- To UNSUBSCRIBE, email to debian-s390-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: 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-s390-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
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 -- diogenese Beware of ritual lest you forget the meaning behind it. igli 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-s390-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: 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-s390-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
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-s390-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: 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) -- mirabilos│ untested Natureshadow │ tut natürlich Natureshadow │ was auch sonst ... mirabilos│ fijn ☺ -- To UNSUBSCRIBE, email to debian-s390-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: 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 -- hecker cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten die nicht noch 3 Jahre warten können? mirabilos bis dahin gibts google nicht mehr hecker 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-s390-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: 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 -- diogenese Beware of ritual lest you forget the meaning behind it. igli 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-s390-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#727550: edos-distcheck: edos-debcheck MUST support :any qualifier ASAP
Package: edos-distcheck Version: 1.4.2-13+b1 Severity: normal tglase@tglase:~ $ x edos-debcheck -failures -explain Completing conflicts...* 100.0% Conflicts and dependencies... * 100.0% Solving* 100.0% dh-python (= 1.20131021-1): FAILED dh-python (= 1.20131021-1) depends on missing: - python3:any (= 3.3.2-2~) 1|tglase@tglase:~ $ x sed s/:any//g | edos-debcheck -failures -explain Completing conflicts...* 100.0% Conflicts and dependencies... * 100.0% Solving* 100.0% tglase@tglase:~ $ cat x Package: dh-python Version: 1.20131021-1 Installed-Size: 305 Maintainer: Piotr Ożarowski pi...@debian.org 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 d...@debian.org 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-s390-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-s390-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) IN, 77 (82) MW, 0 (0) FP) ‣ src:dash (86 (102) bugs: 3 RC, 41 (46) IN, 42 (53) MW, 0 FP) ‣ src:mksh (2 bugs: 0 RC, 0 IN, 2 MW, 0 FP, 1 gift) http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit? -- To UNSUBSCRIBE, email to debian-s390-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
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-s390-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-s390-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
