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: Bug#986009: installation-reports: document qemu workarounds and bug in newer d-i image
John Paul Adrian Glaubitz dixit: >On 3/27/21 8:32 PM, Thorsten Glaser wrote: >> - >> https://cdimage.debian.org/cdimage/ports/debian-installer/2021-01-03/alpha/debian-installer-images_20201202+nmu1_alpha.tar.gz >> is insufficient, it lacks the ISO which contains nic-modules > >The debian-installer tarballs are completely untested. We have ISO images >in the snapshots folder which you should use. Yeah, I did that later. The tarball there was the first thing I found, though, and its ISO subdirectory contains only kernel and initrd :/ In contrast to e.g. ppc64el, which ISO to use is hard to figure out. (As I wrote, the latest ISO didn’t work, I had to use an older one.) >If the nic-modules package is missing, it needs to be added to the pkg-list >for d-i for netboot. No, this was the ISO subdirectory, not netboot, I use -net nic -net user and so don’t have netboot set up. This is a throwaway VM for a oneshot. bye, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜ also warum machen die xorg Jungs eigentlich alles kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…
Bug#986009: installation-reports: document qemu workarounds and bug in newer d-i image (fwd)
FYI
-- Forwarded message --
Message-ID: <161687355375.3666.12906764209603803348.reportbug@alpha>
Date: Sat, 27 Mar 2021 20:32:33 +0100
Subject: Bug#986009: installation-reports: document qemu workarounds and bug in
newer d-i image
Package: installation-reports
Severity: normal
Tags: d-i
X-Debbugs-Cc: t...@mirbsd.de
Boot method: CD
Image version:
https://cdimage.debian.org/cdimage/ports/snapshots/2020-10-12/debian-10.0.0-alpha-NETINST-1.iso
Date: 2021-03-26 to 2021-03-27
Machine: qemu-system-alpha on a buster host
Partitions:
root@alpha:~# fdisk -l
|
Disk /dev/sda: 40 GiB, 42949672960 bytes, 83886080 sectors
|
Disk model: QEMU HARDDISK
|
Geometry: 255 heads, 2 sectors/track, 164482 cylinders
|
Units: sectors of 1 * 512 = 512 bytes
|
Sector size (logical/physical): 512 bytes / 512 bytes
|
I/O size (minimum/optimal): 512 bytes / 512 bytes
|
Disklabel type: bsd
|
|
SliceStart End Sectors Size Type Fsize Bsize Cpg
|
a1 1954 1954 977K ext2 0 0 0
|
b 1955 353517 351563 171.7M ext2 0 0 0
|
c 353518 81884768 81531251 38.9G ext2 0 0 0
|
d 81884769 83886078 2001310 977.2M swap 0 0 0
|
root@alpha:~# df -Tl
|
Filesystem Type 1K-blocksUsed Available Use% Mounted on
|
udev devtmpfs 2052568 0 2052568 0% /dev
tmpfs tmpfs 413304 472412832 1% /run
/dev/sda3 ext4 39860300 1123656 36682092 3% /
tmpfs tmpfs 2066512 0 2066512 0% /dev/shm
tmpfs tmpfs 5120 0 5120 0% /run/lock
/dev/sda2 ext2170219 68778 92653 43% /boot
tmpfs tmpfs 413296 0413296 0% /run/user/0
Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Initial boot: [O]
Detect network card:[O]
Configure network: [O]
Detect media: [O]
Load installer modules: [O]
Clock/timezone setup: [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives: [O]
Install base system:[E]
Install tasks: [O]
Install boot loader:[?]
Overall install:[↓]
Comments/Problems:
-
https://cdimage.debian.org/cdimage/ports/debian-installer/2021-01-03/alpha/debian-installer-images_20201202+nmu1_alpha.tar.gz
is insufficient, it lacks the ISO which contains nic-modules
- Tried
https://cdimage.debian.org/cdimage/ports/snapshots/2021-02-01/debian-10.0.0-alpha-NETINST-1.iso
first but it contains errors, e.g. no /var/lib/dpkg/status,
thus used a random older image; turned out to work
- Ran into #985954 so used raw qemu instead of libvirt/virt-manager
- qemu-system-alpha’s SRM firmware ("BIOS") seems to be unable to do
more than set up the bus and echo back REPL commands instead of executing
them, so only direct kernel boot is usable, so I copied out the kernel and
initrd from the ISO and ran:
qemu-system-alpha -cpu ev68-alpha-cpu -m 2048 -drive
format=raw,file=/dev/vg-evolvis-wirt/alpha -drive
format=raw,file=debian-10.0.0-alpha-NETINST-1.iso -nographic -net nic -net user
-kernel vmlinux-alpha -initrd initrd-alpha.gz -append console=ttyS0
Installation using the serial console, including screen, worked fine.
- After install, booting from the HDD failed (see above), so I used
partprobe (kpartx, normally the tool of choice, failed to recognise
the BSD disklabel used by SRM and thus Linux/Alpha) to map the boot
partition onto the host and copied kernel and initrd out and boot with:
qemu-system-alpha -cpu ev68-alpha-cpu -m 4096 -drive
format=raw,file=/dev/vg-evolvis-wirt/alpha -nographic -net nic -net user
-kernel ~/vmlinux-5.10.0-5-alpha-generic -initrd
~/initrd.img-5.10.0-5-alpha-generic -append 'console=ttyS0
root=UUID=6381e09c-4567-4fff-bbe4-608973308f65'
- After install, getting tons of unaligned messages from dbus:
[ 320.117023] dbus-daemon(366): unaligned trap at 02080bf0:
f6857c0e 28 18
⚠ Unfortunately there was no way to disable usrmerge in d-i,
so I’m now left with a system I cannot build on and have
to resort to debootstrapping me a chroot
Please make sure that any installation logs that you think would
be useful are attached to this report. Please compress large
files using gzip.
-- Package-specific info:
==
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-alpha-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-alpha-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-alpha-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: 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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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-alpha-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
klibc breakage on alpha, need porterbox
Hi, is there a DD-accessible porterbox somewhere (slow would be ok, as this is smallish software) with an up-to-date sid (enough to install the recently-built libklibc-dev 2.0~rc5-1 and all other B-D of mksh 40.9.20120518-1, as well as strace and gdb-minimal)? Similarily to http://www.zytor.com/pipermail/klibc/2012-May/003229.html I found klibc-compiled programmes on Alpha to fail (SIGSEGV though, not SIGILL like on sh4) and would take a look myself first and defer to you if I can’t find anything, unless you want to peek first, in which case just say so, and I’ll give a how-to-debug. bye, //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-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1205251759170.20...@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-alpha-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: [armhf alpha hppa] manual experimental build request: dietlibc, then mksh
Michael Cree dixit: >Alpha has not been building the experimental distribution since we were >kicked out of the official Debian repo, so I have done manual builds of Yes, that’s why I asked. (m68k, which I currently toy around in my spare time, has similar, but worse, issues so I’m familiar with it.) >these packages (with the newer version of dietlibc) and both built fine >and are uploaded to experimental. Thanks, that’s good to know. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we 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-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.111059530.3...@herc.mirbsd.org
Re: [armhf alpha hppa] manual experimental build request: dietlibc, then mksh
Dixi quod… >please schedule manual builds of the following packages on >armhf alpha hppa buildds (or equivalent): > > dietlibc (0.33~cvs2008-1) experimental; urgency=low Please use 0.33~cvs2008-2 (just uploaded) instead, it should fix hppa. (Please build in a clean chroot, with sbuild or cowbuilder, not just dpkg-buildpackage.) > mksh (40.2-3exp1) experimental; urgency=low Skip that on ARM until a fixed GCC is uploaded. >Note that mksh (40.2-3exp1) dep-waits on dietlibc (>= 0.33~cvs2008-1) Thanks, //mirabilos -- In traditional syntax ' is ignored, but in c99 everything between two ' is handled as character constant. Therefore you cannot use ' in a preproces- sing file in c99 mode. -- Ragge No faith left in ISO C99, undefined behaviour, etc. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.101853200.31...@herc.mirbsd.org
[armhf alpha hppa] manual experimental build request: dietlibc, then mksh
Hi, please schedule manual builds of the following packages on armhf alpha hppa buildds (or equivalent): dietlibc (0.33~cvs2008-1) experimental; urgency=low mksh (40.2-3exp1) experimental; urgency=low Note that mksh (40.2-3exp1) dep-waits on dietlibc (>= 0.33~cvs2008-1) The reason for this is: I’ve uploaded a dietlibc source package that _hopefully_ fixes the armhf and alpha problems, and which should give us insight into the hppa problem (if it persists, we’ll apply a workaround and ask for another build). I’d like to check that, then upload that fixed dietlibc package to unstable. mksh currently is “the best” dietlibc testsuite I know of (and compiler testsuite ☺) and runs the tests on (native) builds. Thanks, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we 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-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.091032090.30...@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-alpha-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
