Summary: | Stabilise dev-scheme/tinyscheme-1.41 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nick White <gentoo> |
Component: | [OLD] Keywording and Stabilization | Assignee: | Scheme Project <scheme> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | Keywords: | STABLEREQ |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 326287, 328967 | ||
Bug Blocks: |
Description
Nick White
2010-06-08 21:33:08 UTC
Marijn, can you please lower the B in your emails alias on the metadata.xml? Bugzie brings a big red message on non-exhaustive matches when the B is upper case. Thanks, Michael I've been using tinyscheme quite a bit recently, and it's still very stable and happy for me. Scheme folks, anything stopping you from proceeding with the stabilisation and adding arches? Thanks. I changed the version in the summary to 1.40, as this is the latest, has still been around in the tree for ages, and contains a few fixes (done depends on this bug). Still no bugs against it, still stable. Hint hint ;-) Seeing the age of this bug report, could we have this fixed? * QA Notice: Missing soname symlink(s): * * usr/lib/libtinyscheme.so.1.40 -> libtinyscheme.so * Not ready *tinyscheme-1.41 (11 Dec 2013) 11 Dec 2013; Panagiotis Christopoulos <pchrist@gentoo.org> +tinyscheme-1.41.ebuild, +files/tinyscheme-1.41-makefile.patch: Bump to 1.41 contains various fixes for bug #334649, bug #455294, bug #455296, bug #455298, bug #455300 and bug #493694, thanks to Agostino Sarubbo (ago at gentoo dot org) for reporting the QA issues. Special thanks to Michael Mair-Keimberger (iamnr3) who made the patches in bug #455296. Prefix (darwin) keywords dropped cause logic inside the ebuild has changed and the ebuild needs rekeywording. I'll ask for stabilization the 1.41 ebuild in a month if we haven't gotten any open bugs. Any problem with 1.41 then? Ok, it's time to give it a try then. @Arch teams, please test and stabilize this one. Should the blockers be dropped from the bug report then or we need to wait for any of them? :/ @pacho: it seems you're using some workflow that makes you (arch teams) not comfortable working on bugs with open blockers, even if the maintainer requested in comment to go for it. I dropped the open blockers but please verify that for me for future reference. The thing is to make your life easier, that's why I'm asking. Ah, ok, no problem. I simply tried to be the safest I can since I wrongly stabilized a package recently with some issue :S x86 stable amd64 stable ppc stable. Closing. |