Bug#1068326: bookworm-pu: package mksh/59c-28+deb12u1
Jonathan Wiltshire dixit: >Please go ahead. Thanks. Do you need a blurb for the point release notes or something? bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1068326: bookworm-pu: package mksh/59c-28+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm X-Debbugs-Cc: m...@packages.debian.org, t...@mirbsd.de Control: affects -1 + src:mksh User: release.debian@packages.debian.org Usertags: pu I would like to ask for pre-approval to uploading a proposed stable update for mksh. [ Reason ] There was a discussion on d-devel that ended in suggesting that the /etc/shells file should have both aliased paths for shells, not just the canonical paths, since users could have $SHELL set to either, and some software checks that $SHELL is in shells(5) for security reasons. This change landed in sid and is included here. I’ve also fixed the path wildcards for musl on ARM EABI. I’ve also taken liberty to cherry-pick a few upstream bugfixes and their relevant tests and to include two tiny FAQ updates regarding POSIX compliance and future compatibility/directions. [ Impact ] Users of mksh can run into problems with privilege elevation tools if they are on a usrmerge’d system if this is not applied, and shell scripts can fail or even segfault. [ Tests ] The backported fixes have tests covering them, which all pass when I build this in a nōn-usrmerged bookworm cowbuilder chroot (mirroring the buildd setup). I tested the maintainer script changes by installing the resulting .deb in a copy of both the nōn-usrmerged bookworm chroot and a usrmerged sid chroot. [ Risks ] The patches are small and easy to review and have been in use in sid for a while, except the three-line postinst change, which I manually tested (and inspected both dash and bash to ensure that test -ef does the right thing), so the risk is low. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] (see Reason above) [ Other info ] I’ve split the fixes into easier to review individual patches for this upload, as git is “patches-applied” here, but I also verified the resulting trees are identical. While the test if the system is merged could possibly be removed, I decided to leave it in as it’s easier to backport this way. (When merging later, either the next upgrade or dpkg-reconfigure of mksh fixes up /etc/shells next, or the usrmerge utility does so.) diff -Nru mksh-59c/debian/changelog mksh-59c/debian/changelog --- mksh-59c/debian/changelog 2023-04-28 23:34:20.0 +0200 +++ mksh-59c/debian/changelog 2024-04-03 14:19:25.0 +0200 @@ -1,3 +1,15 @@ +mksh (59c-28+deb12u1) bookworm; urgency=low + + * d/p/typeset-p-fix.diff, d/p/dot-args-fix.diff, +d/p/crash-nest-bashism.diff: cherry-pick upstream bugfixes + * d/p/metadata-update.diff: cherry-pick relevant documentation +changes and adjust user-visible version to indicate the +above fixes were applied + * fix paths missing wildcards in lintian overrides, postinst, prerm + * cherry-pick usrmerge /etc/shells change (Closes: #1063905) + + -- Thorsten Glaser Wed, 03 Apr 2024 14:19:25 +0200 + mksh (59c-28) unstable; urgency=medium * Revert 59c-27 changes as mksh is, surprisingly, still a key diff -Nru mksh-59c/debian/mksh.lintian-overrides mksh-59c/debian/mksh.lintian-overrides --- mksh-59c/debian/mksh.lintian-overrides 2023-04-28 23:00:04.0 +0200 +++ mksh-59c/debian/mksh.lintian-overrides 2024-04-03 13:25:50.0 +0200 @@ -17,8 +17,8 @@ # correct placement mksh: executable-in-usr-lib [usr/lib/diet/bin/mksh] mksh: executable-in-usr-lib [usr/lib/klibc/bin/mksh] -mksh: executable-in-usr-lib [usr/lib/*-linux-musl/bin/mksh] +mksh: executable-in-usr-lib [usr/lib/*-linux-musl*/bin/mksh] # these are to clean old add-shell(8) damage, not actually dereferenced -mksh: bin-sbin-mismatch usr/bin/mksh -> bin/mksh [postinst] -mksh: bin-sbin-mismatch usr/bin/mksh -> bin/mksh [prerm] +mksh: bin-sbin-mismatch usr/bin/mksh* -> bin/mksh* [postinst] +mksh: bin-sbin-mismatch usr/bin/mksh* -> bin/mksh* [prerm] diff -Nru mksh-59c/debian/mksh.postinst mksh-59c/debian/mksh.postinst --- mksh-59c/debian/mksh.postinst 2023-04-28 23:00:04.0 +0200 +++ mksh-59c/debian/mksh.postinst 2024-04-03 13:27:52.0 +0200 @@ -151,14 +151,18 @@ test -e /usr/bin/ksh || test -h /usr/bin/ksh || \ ln -s /bin/ksh /usr/bin/ksh + # determine usrmerge status + um=+ + test /usr/bin/mksh -ef /bin/mksh || um=- + # add us to /etc/shells and clean up old add-shell-caused damage # shellcheck disable=SC2046 mogrifyshells + /bin/mksh /bin/mksh-static \ - - /usr/bin/mksh /usr/bin/mksh-static \ - $(for x in \ + $um /usr/bin/mksh /usr/bin/mksh-static \ + - $(for x in \ /usr/lib/klibc/bin \ /usr/lib/diet/bin \ - /usr/lib/*-linux-musl/bin \ + /usr/lib/*-linux-musl*/bin \ ; do echo "$x/mksh"
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
Wookey dixit: >And it worked beatifully. Thanks. Nice! >I'll try doing openjdk-20 next. You’ll want 21 as 20 has not got the t64 treatment. gl hf, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
Hi Wookey, >OK, got those. but that's just binaries. It was the source changes I >was looking for (or did I misunderstand and you didn't actually make >any of those?), Yes, I did not make any source changes. These were the last binaries from before the t64 transition (I downloaded the .deb files unchanged) with just control.tar.xz/control changed to allow installation given the relevant libraries were already rebuilt for t64. > but actually having an openjdk binaries is very useful >too to satisfy the self-dependency without more faff. Yes, that was their purpose. >I'm no java expert so if anything breaks or it gets more complicated >than 'get the right build-deps in (with care for t64-libs) somehow' I >will indeed be asking questions :-) Right. I’m no expert either, though :/ >> What was the actual problem with uploading the images you built? Just >> not having any corresponding source? Or something more complicated? > >Answering my own question: There have been a couple of new openjdk-17 >uploads (latest is: 17_17.0.11~7ea-1) so Thorsten's bootstrap build >(17.0.10+7-1) is out of date. Yes, exactly: dak lacked the 17.0.10+7.orig.tar.* because sid already moved to 17.0.11~7ea.orig.tar.* >So I now have all the pieces (on armhf, not checked armel yet but >hopefully it matches) Depends, but 'apt install /tmp/*.deb' will tell you ;-) >The build failed: > >An exception has occurred in the compiler (17.0.10). Please file a bug against >the Java compiler via the Java bug reporting page (https://bugreport.java.com) >after checking the Bug Database (https://bugs.java.com) for duplicates. >Include your program, the following diagnostic, and the parameters passed to >the Java compiler in your report. Thank you. >java.io.UncheckedIOException: java.nio.file.FileSystemException: .: Value too >large for defined data type > >Don't worry about this. It's a an issue to do with building for 32 bit >inside qemu on a 64-bit machine. I'll stop doing that and use real >hardware :-/ Ouch. I was just wondering which filesystem you used, but yes, there’s that known combined qemu/kernel/libc issue which cbmuser is also constantly running into. I think switching to… sgixfs I think? also makes it work, but I’m not sure. https://sourceware.org/bugzilla/show_bug.cgi?id=23960#c73 sgixfs and btrfs, yeah, ext4 is problematic. But apparently, LFS should fix this but Java is again special in that it’s still problematic there. Were you using qemu-user? qemu-system has its own kernel and “should” be fine, modulo the usual qemu issues. Real hardware is better (for many architectures even necessary). Good luck, //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#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On Wed, 27 Mar 2024, Wookey wrote: >I looked at this last week, but got stuck because openjdk-17's >build-deps included graphviz Build-Depends-Indep: graphviz, pandoc You don’t need that. Use dpkg-checkbuilddeps -B, or manual inspection of the .dsc (packages.d.o does show the difference between adep and idep but not the profiles, unfortunately, and these can be key in ordering decisions). >another blocked chain with ghostscript,cups and libgtk2 conflicting >about their t64 status. You do need the t64 versions of all that, and the latest openjdk-17 fixed the issue with libcups2 (Ubuntu initially forgot to move that to t64 while Debian did that early, and openjdk-?? followed the former). > apt : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed You should get that rebuilt, yes. On the other hand, if everything else is falling into place, it’s not a problem for apt to uninstall itself just in that one build chroot ☻ > libasound2t64 : Breaks: libasound2 (< 1.2.11-1) but 1.2.10-3 is to be > installed > libcups2t64 : Breaks: libcups2 (< 2.4.7-1.2) but 2.4.7-1+b1 is to be installed > libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2 is to be > installed These are fine. > libcups2 : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed Force that away; nothing from this is actually used during the openjdk build in a way sufficient to impact the build. >But dose now says there is a solution, unlike last week. Oh, dose… right… here I was checking all of them manually ^^ (which did give me a better impression of where to break the cycles and what to upload earlier). >> openjdk-21 is in a similar situation, build-depending on itself, while >> openjdk-22 and openjdk-23 build-depend on -21 and -22 respectively. >I presume the same, but don't actually know how old a java you can use >to bootstrap each newer java. Is it always just one version? AIUI it’s always just one version; I know it was so until 17, but I don’t think this has loosened (I asked in IRC, but got no answer until I went to sleep). >> Presumably once we have a single OpenJDK version that is installable, >> it would be possible to step through 18,19,20,21 building each version >> with the previous one. You’d have to patch them to both address the t64 issues and make it imply nocheck (or quinn-diff doesn’t pick it up as installable). It’s best to get at least 17 and 21 (which AIUI is the one we’ll want for trixie?) built this way. I think, unless users complain, we can these days go without 8 and probably even without 11. (You’d be surprised at the amount of users wanting 8, so I now provide those in a private repo of mine, but so far amd64/i386-only has sufficed for those. For the purposes for which 8 is still in sid, dropping armel and armhf will _most likely_ also suffice; ELTS still wants them, but rebuilt in jessie and stretch chroots so there is no re‐ bootstrapping to be done.)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On Tue, 26 Mar 2024, Jeffrey Walton wrote: >Nothing beats a native compile in your basement. Yes, definitely. >> Do they run stock Debian armhf? > >So the CubieTruck is embarrassingly down level: Oofff… >The Wandboard is doing better: Right, close enough anyway. >I don't mind shipping to Europe if you don't mind paying the VAT. I >think you will be the fourth or fifth Debian maintainer I've sent >hardware to. So sending from outside the eurozone, that can get tricky fast (depending on the value, they also want import duties on top), I think that might just be overkill for a oneshot helping out. Let’s see if I can get an account on a project box first, or work with someone who has. (I’m not intending to add going into ARM development on top of what I already try to balance… right now, I’m mostly helping m68k through t64, so Adrian does not burn out, he’s also got sh4 and powerpc to do, and the whole rest of d-ports with the mini-dak trouble of keeping old binary packages around.) But I do thank you for that offer. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
Hi Jeffrey, I’m answering back from the $dayjob address because Googlemail cannot communicate with normal mailservers. >I can send you two dev boards, if you want them. The first is >Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second is >CubieTruck 5 (Cortex-A7, ARMv7 with NEON and VFPv4). Both work, but I >don't use them much anymore. I've mostly moved on to Aarch64. That is certainly an option, if you don’t want them any more and want to ship them to .de, although it’ll likely take longer than just getting access on a suitable project machine. RAM is tight on them, but with swap the compiling should work. Both seem to have serial console, good. Do they run stock Debian armhf? Thanks, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Hi,
>In the -ports world, hppa doesn't have Java anyway, while m68k, powerpc
>and sh4 seem to have had a re-bootstrap at some point; so I think it's
>only the release architectures armel and armhf that have a problem here.
I hacked that, and I tried to do armel and armhf as well but
dak stopped me, whereas mini-dak was not as strict.
I did the observation that doko changed their source packages
to have the binaries Recommend instead of Depend on the libraries
in question. (Unfortunately neither before the transition started
nor coordinated with the openjdk-8 maintainer (me).)
I downloaded the latest binary packages of openjdk-{8,11,17,21},
changed all references to the libraries in question to refer to
their t64 counterparts, bumped the version number, repacked the
.deb files and updated the .changes files as if to do a binNMU.
After uploading, I used wanna-build to set the priority high so
they get rebuilt before someone considers using them.
mini-dak accepted these, but dak requires that the archive has
the corresponding source available, and since new versions (the
part before the Debian hyphen-minus) had already been uploaded,
it did not have them at hand any more either.
The rebuild process succeeded, as openjdk building itself does
indeed not use the libraries in question (or at least those
parts of their interface that are time_t-relevant).
I don’t have access to a fast armel machine (only an RPi 1) and
to no armhf machine, so I’m not in the situation of throwing the
.debs from above into a chroot to rebuild the current sources.
I *was* considering writing to whereever the t64 transition was
coordinated for ARM, we’re using #debian-ports on OFTC for the
d-ports architectures and I couldn’t find out where to write to
for arm{el,hf}, so this mail of yours comes at a good time ;-)
The options for the armel/armhf porters are to either get the
.debs from me, install them in a chroot, and then the other B-D,
and rebuild the packages, or to use dpkg --force-depends to
install the dependencies (which makes it hard to use apt to
install the other ones unless you also edit /var/lib/dpkg/status
by hand first, something I was already used to from my reviving
m68k back in 2012–2015) into the chroot then rebuild there.
I will gladly help if it’s made possible for me to help. This
cannot be done on a porterbox because it’s still impossible to
either install arbitrary .debs into a chroot there or to obtain
root in the chroot to be able to force installation in the absence
of some Depends.
So if you have a fast armhf box or two, ideally with chroots
already made for sid, which you don’t mind temporarily giving
me root on, I’m in, otherwise I’ll answer questions from these
doing that work if needed.
I *think* 8/11/17/21 are the only versions we need to handle.
This does save us from having to rebootstrap this.
bye,
//mirabilos
- --
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (MirBSD)
Comment: ☃ ЦΤℱ—８ ☕☂☄
iQIcBAEBCQAGBQJmA0vXAAoJEHa1NLLpkAfg0ZQQAI7P7qoVfADQrrsuNHAShvTB
lRvuK1br7bHRmqUx89dDwjOG1k0Xji3X3OURZldlhPCk99SJxQP3DLoCX5cmCzIA
IDyq+GoxREjJ/uyb4b6/qTAgSh7ZdRqxEfbVLsukL1i+wRs6dNw2Wg64i/R538jE
+yncg7zMyrWSA+3815i7BRfdMZBEk9E1qgW3hlnhueVfgANuyBLzzJchSstjunqE
0OcIukVQ30HaWaALmAfGcl7lcfM0sUFXL+EVpA8aBsVWNzZHtMIPnmI+yx8X4NOo
BOkfcYbPI928VZ/91meibSb9FXk8ShnO+zv+gU6dX74RlVoqOIeg6UQ/r2Cy+Up9
ssnksqTWTSkw1/n9bRNNiU8/O4kI5xV6FCUk2CaOsk+diQfXpoga50TR6DRM52tp
mjtBetkI1qK9vA0Y1VS+KoPp/FDYwFBKXiU3Jax9L7koaT5wGCurILqNTbDGVe19
2nmnphBUeIFniPByiItSEv7jH9GgxZyrwRvonYYpDXNeXFa0ymTNzKzrIG2ZqMrz
LcELgtIb6OD+WDYajUMOlTRBj2N9rFodruKyMcdUfc4so3OoFnS3cOdBvWBk/NdX
sFRgES39Ak5xgA3f4hP2ba03KZOFH2iIT3M8ZtZhH7eOIdhErKIUG0t6hxpWFdiV
ntE5WUlefRxovhbTOXKa
=KoS1
-END PGP SIGNATURE-
Re: openjdk-8 vs. nvidia-openjdk-8-jre
Moritz Muehlenhoff dixit: >No, we have enough OpenJDK releases to look after already. OK, it was just a thought. 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.)
openjdk-8 vs. nvidia-openjdk-8-jre
Hi,
TIL about the existence of nvidia-openjdk-8-jre.
Would it not be better to drop that and remove the bug deliberately
blocking openjdk-8 from entering testing/stable? We only added it so
there does not have to be formal security support for more than one
release.
And I’ve been building openjdk-8 for buster/bullseye/bookworm for a
while already, privately (for i386 and amd64), anyway, as people are
still using it, and *buntu also ships it and updates it in all LTS
releases. Freexian ELTS is also supporting it in jessie and stretch,
for the architectures these support.
The other side would be nvidia-openjdk-8-jre is in non-free and only
available for two architectures, so less people would install it, and
it’s JRE-only, AFAICT. If worry about people installing openjdk-8 is
a factor, I can understand the split, but from a technical PoV I don’t
see the duplication as a good solution.
Options are probably: keep things as is, drop nvidia-openjdk-8-jre in
favour of openjdk-8 in trixie/sid, or drop it everywhere and build
openjdk-8 for {,{,old}old}stable as well. I don’t mind any, I just
wondered and wanted to provide an impulse to think about this.
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1039047: bookworm-pu: package cvs/2:1.12.13+real-28+deb12u1
Jonathan Wiltshire dixit: >Please go ahead. Thanks, uploaded. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1039047: bookworm-pu: package cvs/2:1.12.13+real-28+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: c...@packages.debian.org, t...@mirbsd.de Control: affects -1 + src:cvs Pre-approval with debdiff. [ Reason ] CVS was always compiled with --with-rsh=ssh but the configure script ignored that and used rsh because it could not find an ssh binary in the PATH at compile time. This used to be not a problem because ssh was aliased to rsh but in bookworm it no longer is. [ Impact ] Users are unable to cvs update or cvs commit or anything else unless they manually export CVS_RSH=ssh or change their access method from :ext: to :extssh: (which is a relatively new thing and may not be universally known, e.g. to frontends). If this is rejected, I’d suggest the $CVS_RSH workaround be added to the release notes, if they can be changed at this point in time. [ Tests ] The change switches the cpp macro RSH_DFLT, which is used in only two places to set the default rsh. I have tested this as part of the larger changes in tonight’s sid upload, and code inspection shows this has no effect on unrelated code. [ Risks ] See above, this is a no-risk change. [ Checklist ] [✓] *all* changes are documented in the d/changelog [✓] I reviewed all changes and I approve them [✓] attach debdiff against the package in (old)stable [✓] the issue is verified as fixed in unstable [ Changes ] Pass the full path to ssh(1) to configure so it’s actually used. diff -u cvs-1.12.13+real/debian/changelog cvs-1.12.13+real/debian/changelog --- cvs-1.12.13+real/debian/changelog +++ cvs-1.12.13+real/debian/changelog @@ -1,3 +1,9 @@ +cvs (2:1.12.13+real-28+deb12u1) bookworm; urgency=high + + * configure-time hardcode full path for ssh(1) (Closes: #1038926) + + -- Thorsten Glaser Sat, 24 Jun 2023 19:48:48 +0200 + cvs (2:1.12.13+real-28) unstable; urgency=medium [ Helmut Grohne ] diff -u cvs-1.12.13+real/debian/rules cvs-1.12.13+real/debian/rules --- cvs-1.12.13+real/debian/rules +++ cvs-1.12.13+real/debian/rules @@ -66,7 +66,7 @@ --without-krb4 \ --with-gssapi \ --with-external-zlib \ - --with-rsh=ssh \ + --with-rsh=/usr/bin/ssh \ --with-editor=/usr/bin/editor \ --with-tmpdir=/var/tmp \ --with-umask=002 \
Bug#1036175: unblock: mksh/59c-28
substitution and fix the other place it was not reentrant
+ as well (by moving function-static storage to stack/heap);
+ crash discovered by Riccardo Felici, USI Lugano
+ * Revert RCS ID changes, but assign individual version datestamp
+
+ -- Thorsten Glaser Fri, 28 Apr 2023 23:34:20 +0200
+
mksh (59c-26) unstable; urgency=medium
* Fixup more update-shells breakage also found by piuparts
diff -pruN mksh-59c-26/mbsdint.h mksh-59c-28/mbsdint.h
--- mksh-59c-26/mbsdint.h 2023-05-16 19:13:21.0 +0200
+++ mksh-59c-28/mbsdint.h 2023-05-16 19:13:32.0 +0200
@@ -675,7 +675,7 @@ mbiCTAS(mbsdint_h) {
#define mbiK_sr(ut,n,vl,vr,vz) mbiK_SR(ut, mbiTYPE_UBITS(ut), n, vl, vr, vz)
#define mbiMK_sr(ut,FM,n,l,r,z)mbiMM(ut, (FM), mbiK_SR(ut,
mbiMASK_BITS(FM), \
n, mbiMM(ut, (FM), (l)), (r), (z)))
-#define mbiK_SR(ut,b,n,l,r,vz) mbiK_RS(ut, b, n, l, mbiUI(r) & (b - 1U), (vz))
+#define mbiK_SR(ut,b,n,l,r,vz) mbiK_RS(ut, b, n, l, mbiUI(r) % mbiUI(b), (vz))
#define mbiK_RS(ut,b,n,v,cl,zx)mbiOT(ut, cl, n(ut, v, cl, b - (cl),
zx), v)
#define mbiK_shl(ut,ax,cl,CL,z)mbiOshl(ut, ax, cl)
#define mbiK_shr(ut,ax,cl,CL,z)mbiOshr(ut, ax, cl)
diff -pruN mksh-59c-26/sh.h mksh-59c-28/sh.h
--- mksh-59c-26/sh.h2023-05-16 19:13:21.0 +0200
+++ mksh-59c-28/sh.h2023-05-16 19:13:32.0 +0200
@@ -235,7 +235,7 @@
#define __SCCSID(x)__IDSTRING(sccsid,x)
#endif
-#define MKSH_VERSION "R59 2023/01/31"
+#define MKSH_VERSION "R59 2023/04/28"
/* shell types */
typedef unsigned char kby; /* byte */
@@ -2150,6 +2150,7 @@ struct ioword {
#define IOBASH BIT(10) /* &> etc. */
#define IOHERESTR BIT(11) /* <<< (here string) */
#define IONDELIM BIT(12) /* null delimiter (<<) */
+#define IOSYNIONEXTBIT(13) /* already fully configured */
/* execute/exchild flags */
#define XEXEC BIT(0) /* execute without forking */
diff -pruN mksh-59c-26/shf.c mksh-59c-28/shf.c
--- mksh-59c-26/shf.c 2023-05-16 19:13:21.0 +0200
+++ mksh-59c-28/shf.c 2023-05-16 19:13:32.0 +0200
@@ -837,20 +837,15 @@ shf_smprintf(const char *fmt, ...)
char *
kslfmt(ksl number, kui flags, char *numbuf)
{
+ /* easy for positive number */
+ if (number >= 0)
+ return (kulfmt((kul)number, flags, numbuf));
+ /* negative signed quantity */
if (!IS(flags, FM_TYPE, FL_SGN)) {
- /* uh-oh, unsigned? what? be bitwise faithful here */
- union {
- /*XXX hopefully not UB… */
- ksl s;
- kul u;
- } v;
-
- v.s = number;
- return (kulfmt(v.u, flags, numbuf));
+ /* uh-oh, output a signed quantity unsignedly */
+ return (kulfmt(KSL2UL(number), flags, numbuf));
}
- if (number < 0)
- flags |= FL_NEG;
- return (kulfmt(KSL2NEGUL(number), flags, numbuf));
+ return (kulfmt(KSL2NEGUL(number), flags | FL_NEG, numbuf));
}
/* pre-initio() */
@@ -892,13 +887,13 @@ kulfmt(kul number, kui flags, char *numb
number /= 10UL;
} while (number);
- if (!IS(flags, FM_TYPE, FL_DEC)) {
+ if (IS(flags, FM_TYPE, FL_SGN)) {
if (HAS(flags, FL_NEG))
*--cp = '-';
else if (HAS(flags, FL_PLUS))
*--cp = '+';
else if (HAS(flags, FL_BLANK))
- *--cp = '-';
+ *--cp = ' ';
}
break;
}
diff -pruN mksh-59c-26/syn.c mksh-59c-28/syn.c
--- mksh-59c-26/syn.c 2023-05-16 19:13:21.0 +0200
+++ mksh-59c-28/syn.c 2023-05-16 19:13:32.0 +0200
@@ -191,19 +191,16 @@ static struct ioword *
synio(int cf)
{
struct ioword *iop;
- static struct ioword *nextiop;
Wahr ishere;
- if (nextiop != NULL) {
- iop = nextiop;
- nextiop = NULL;
- return (iop);
- }
-
if (tpeek(cf) != REDIR)
return (NULL);
ACCEPT;
iop = yylval.iop;
+ if (iop->ioflag & IOSYNIONEXT) {
+ iop->ioflag &= ~IOSYNIONEXT;
+ return (iop);
+ }
ishere = (iop->ioflag & IOTYPE) == IOHERE;
if (iop->ioflag & IOHERESTR) {
musthave(LWORD, 0);
@@ -228,17 +225,21 @@ synio(int cf)
if (iop->ioflag & IOBASH) {
char *cp;
- nextiop = alloc(sizeof(*iop), ATEMP);
- nextiop->ioname = cp = alloc(3, ATEMP);
+ iop->ioflag &= ~IOBASH;
+
+ cp = alloc(sizeof(struct io
Bug#1032993: release.debian.org: key packages: mksh should not be a key package
Package: release.debian.org Severity: normal X-Debbugs-Cc: t...@mirbsd.de I already mentioned this as an aside in #986431 but here’s it as a separate bugreport. mksh is only a key package because shunit2 build-depends on it. (Would be nice if the key package status is shown in tracker or so… I was surprised by its presence in the list.) However, shunit2 only uses it at build time to run its tests against and its testsuite runner only fails if the last shell, which is zsh, fails.
Bug#1006452: RM: minify-maven-plugin/1.7.4-1.1 -- RoM: old and not useful
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: t...@mirbsd.de Please consider removing minify-maven-plugin from both buster and bullseye: minify-maven-plugin is currently only in Debian to satisfy a Build-Depends of guacamole-client on libminify-maven-plugin-java (its binary package). However, guacamole-client is in bad shape and has last worked in stretch; newer guacamole-client versions will require minify-maven-plugin 2.0.1 anyway, so this version is not necessary to carry around. I’ve also filed an RC bug against the package to keep it out of bookworm unless both updated and guacamole-client attempts to make the release.
Bug#1006450: RM: angular-maven-plugin/0.3.4-3
Thorsten Glaser dixit: >As explained in #111 it’s only an r-bd for an old version of Oops, sent too early… #1006449 this should be. bye, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"...
Bug#1006450: RM: angular-maven-plugin/0.3.4-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: t...@mirbsd.de Please remove angular-maven-plugin/0.3.4-3 from both buster and bullseye. As explained in #111 it’s only an r-bd for an old version of guacamole-client, and the latter is present only in stretch anyway, so this plugin isn’t useful in Debian. It is bound to the unsupported major version 1 of AngularJS.
Bug#1006447: RM: evenement/3.0.1-2.1, php-cocur-slugify/4.0.0-2, php-defuse-php-encryption/2.2.1-1.1, php-dflydev-fig-cookies/2.0.0-1.1, php-embed/3.3.9-1.1, php-fabiang-sasl/1.0.1-1, php-markdown/1.8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: t...@mirbsd.de Hi, these are otherwise unused r-deps for movim, which did not make the release. They were also just removed from unstable, since the movim packaging project was abandoned (I asked the other team maintainers and there’s no interest in continuing it), cf. #1006401 These packages were usable in buster but not usable in or updated for bullseye, so I suggest also removing them from bullseye, or at least clearly marked as unsupported. (I orphaned those that *are* used and informed the respective sole r-dependency remaining.)
Bug#1006417: buster-pu: package php-illuminate-database/5.7.27-1+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@mirbsd.de
[ Reason ]
These are two security-related backports by the new maintainer
of these binary packages for bullseye and up. I’ve been asked
to do this via the upcoming point release by the security team.
[ Impact ]
Two pending security fixes of SQL injection type not applied.
[ Tests ]
The new maintainer, who backported these fixes, has tested them
with upstream’s testsuite and provided tests for the issues
themselves.
[ Risks ]
These are backports of the patches for later versions, so
the risk is low, I guess. I’m not sufficiently familiar with
the codebase to judge myself, but they look plausible at a
quick glance.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Apply two patches prepared by the new maintainer and change
the Maintainer field to them.
diff -Nru php-illuminate-database-5.7.27/debian/changelog
php-illuminate-database-5.7.27/debian/changelog
--- php-illuminate-database-5.7.27/debian/changelog 2019-02-22
20:06:21.0 +0100
+++ php-illuminate-database-5.7.27/debian/changelog 2022-02-25
00:53:26.0 +0100
@@ -1,3 +1,15 @@
+php-illuminate-database (5.7.27-1+deb10u1) buster; urgency=medium
+
+ [ Robin Gustafsson ]
+ * Security fix: Query Binding Exploitation (Closes: #980899)
+Fixes CVE-2021-21263
+ * Security fix: SQL injection with Microsoft SQL Server (Closes: #987848)
+
+ [ Thorsten Glaser ]
+ * Update Maintainer, upload to oldstable as security fixpack
+
+ -- Thorsten Glaser Fri, 25 Feb 2022 00:53:26 +0100
+
php-illuminate-database (5.7.27-1) unstable; urgency=medium
* New upstream version.
diff -Nru php-illuminate-database-5.7.27/debian/control
php-illuminate-database-5.7.27/debian/control
--- php-illuminate-database-5.7.27/debian/control 2019-02-22
20:06:21.0 +0100
+++ php-illuminate-database-5.7.27/debian/control 2022-02-25
00:53:26.0 +0100
@@ -1,7 +1,7 @@
Source: php-illuminate-database
Section: php
Priority: optional
-Maintainer: Teckids Debian Task Force
+Maintainer: Robin Gustafsson
Uploaders: Thorsten Glaser , Dominik George
Build-Depends: debhelper (>= 11~), pkg-php-tools (>= 1.7~)
Standards-Version: 4.3.0
diff -Nru
php-illuminate-database-5.7.27/debian/patches/0001-6.x-Limit-expected-bindings-35865.patch
php-illuminate-database-5.7.27/debian/patches/0001-6.x-Limit-expected-bindings-35865.patch
---
php-illuminate-database-5.7.27/debian/patches/0001-6.x-Limit-expected-bindings-35865.patch
1970-01-01 01:00:00.0 +0100
+++
php-illuminate-database-5.7.27/debian/patches/0001-6.x-Limit-expected-bindings-35865.patch
2022-02-25 00:51:21.0 +0100
@@ -0,0 +1,96 @@
+From: Taylor Otwell
+Date: Wed, 13 Jan 2021 07:35:45 -0600
+Subject: [6.x] Limit expected bindings (#35865)
+
+* limit expected bindings
+
+* limit more bindings
+
+Origin:
https://github.com/laravel/framework/commit/d0954f4574f315f0c2e9e65e92cc74b80eadcac1
+---
+ Query/Builder.php | 18 ++
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+--- a/Query/Builder.php
b/Query/Builder.php
+@@ -654,7 +654,7 @@ class Builder
+ );
+
+ if (! $value instanceof Expression) {
+-$this->addBinding($value, 'where');
++$this->addBinding(is_array($value) ? head($value) : $value,
'where');
+ }
+
+ return $this;
+@@ -1051,7 +1051,7 @@ class Builder
+
+ $this->wheres[] = compact('type', 'column', 'values', 'boolean',
'not');
+
+-$this->addBinding($this->cleanBindings($values), 'where');
++$this->addBinding(array_slice($this->cleanBindings($values), 0, 2),
'where');
+
+ return $this;
+ }
+@@ -1119,6 +1119,8 @@ class Builder
+ $value, $operator, func_num_args() === 2
+ );
+
++$value = is_array($value) ? head($value) : $value;
++
+ if ($value instanceof DateTimeInterface) {
+ $value = $value->format('Y-m-d');
+ }
+@@ -1158,6 +1160,8 @@ class Builder
+ $value, $operator, func_num_args() === 2
+ );
+
++$value = is_array($value) ? head($value) : $value;
++
+ if ($value instanceof DateTimeInterface) {
+ $value = $value->format('H:i:s');
+ }
+@@ -1197,6 +1201,8 @@ class Builder
+ $value, $operator, func_num_args() === 2
+ );
+
++$value = is_array($value) ? head($value) : $value;
++
+ if ($value instanceof DateTimeInterface) {
+ $value = $value->format('d');
+ }
+@@ -1236,6 +1242,8 @@ class Builder
+ $value, $operator, func_num_args() === 2
+ );
+
++$value = is_a
Re: #975016 - OpenJDK 17 support state for Bullseye
Hi Holger, > and filed against src:debian-security-support, as openjdk-17 seems to be > supported and src:debian-security-support's purpose is to documented what's no, 11 is supported, 17 is just for users to run third-party stuff on (IIUC). bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Bug#990973: unblock: mksh/59c-9
ded, there is no public archive any more, unfortunately
(note: several freemail providers have issues with the list;
use GMane (NNTP or web interface) to post in those cases)
diff -pruN mksh-59c-8/debian/changelog mksh-59c-9/debian/changelog
--- mksh-59c-8/debian/changelog 2021-05-31 02:42:55.0 +0200
+++ mksh-59c-9/debian/changelog 2021-07-10 22:08:30.0 +0200
@@ -1,3 +1,21 @@
+mksh (59c-9) unstable; urgency=medium
+
+ * Cherry-pick bugfixes from CVS HEAD:
+- stop referring to dead IRC network
+- check lower bounds of input line array when backspacing
+- protect against hi-bit7 (stty) EOF character
+- show error message and exit nōn-zero on stdout write failure
+ for builtin calls (Closes: #990265) + display correct errno
+- show error message in echo/print builtin on output write failure
+ (it exits 1 already in that case)
+- ensure macro calls don’t have side effects in arguments
+- properly flush stderr and unwind for direct builtin calls
+ (“ln -s /bin/mksh echo; ./echo …”)
+- fix truncation behaviour for internal snprintf equivalent
+ * Update upstream contact info accordingly
+
+ -- Thorsten Glaser Sat, 10 Jul 2021 22:08:30 +0200
+
mksh (59c-8) unstable; urgency=medium
* Fix a -Wpointer-sign in escaping code
‣ Update upstream contact info accordingly
diff -pruN mksh-59c-8/debian/upstream/metadata
mksh-59c-9/debian/upstream/metadata
--- mksh-59c-8/debian/upstream/metadata 2021-05-31 02:40:08.0 +0200
+++ mksh-59c-9/debian/upstream/metadata 2021-07-10 21:36:32.0 +0200
@@ -4,7 +4,7 @@
"Bug-Submit": "mailto:miros-m...@mirbsd.org;,
"Changelog": "http://www.mirbsd.org/mksh.htm#clog;,
"Cite-As": "The MirBSD Korn Shell (http://www.mirbsd.org/mksh.htm\;>mksh)",
- "Contact": "irc://irc.freenode.net/!%2Fbin%2Fmksh",
+ "Contact": "irc://irc.oftc.net/!%2Fbin%2Fmksh",
"Documentation": "http://www.mirbsd.org/MirOS/dist/mir/mksh/mksh.pdf;,
"Donation": "http://www.mirbsd.org/danke.htm;,
"FAQ": "http://www.mirbsd.org/mksh-faq.htm;,
‣ Hunk 1, 2: check lower bounds of input line array when backspacing
‣ Hunk 3: protect against hi-bit7 (stty) EOF character
diff -pruN mksh-59c-8/edit.c mksh-59c-9/edit.c
--- mksh-59c-8/edit.c 2021-07-12 16:13:08.0 +0200
+++ mksh-59c-9/edit.c 2021-07-12 16:12:43.0 +0200
@@ -1677,7 +1677,7 @@ static char *
x_bs0(char *cp, char *lower_bound)
{
if (UTFMODE)
- while ((!lower_bound || (cp > lower_bound)) &&
+ while ((cp > lower_bound) &&
((rtt2asc(*cp) & 0xC0) == 0x80))
--cp;
return (cp);
@@ -1688,7 +1688,7 @@ x_bs3(char **p)
{
int i;
- *p = x_bs0((*p) - 1, NULL);
+ *p = x_bs0((*p) - 1, xbuf);
i = x_size2(*p, NULL);
while (i--)
x_e_putc2('\b');
@@ -1843,10 +1843,11 @@ x_newline(int c MKSH_A_UNUSED)
static int
x_end_of_text(int c MKSH_A_UNUSED)
{
- unsigned char tmp[1], *cp = tmp;
+ unsigned char tmp[2], *cp = tmp;
*tmp = isedchar(edchars.eof) ? (unsigned char)edchars.eof :
(unsigned char)CTRL_D;
+ tmp[1] = '\0';
x_zotc3((char **));
x_putc('\r');
x_putc('\n');
‣ show error message and exit nōn-zero on stdout write failure
for builtin calls (Closes: #990265)
diff -pruN mksh-59c-8/exec.c mksh-59c-9/exec.c
--- mksh-59c-8/exec.c 2021-07-12 16:13:08.0 +0200
+++ mksh-59c-9/exec.c 2021-07-12 16:12:43.0 +0200
@@ -1397,7 +1397,11 @@ call_builtin(struct tbl *tp, const char
shl_stdout_ok = true;
ksh_getopt_reset(_opt, GF_ERROR);
rv = (*tp->val.f)(wp);
- shf_flush(shl_stdout);
+ if (shf_flush(shl_stdout) < 0) {
+ bi_errorf(Tf_sD_s, Twrite, cstrerror(errno));
+ if (rv == 0)
+ rv = 1;
+ }
shl_stdout_ok = false;
builtin_argv0 = NULL;
builtin_spec = false;
‣ Hunk 1: show error message in echo/print builtin on output write failure
‣ Hunk 2: ensure macro calls don’t have side effects in arguments
diff -pruN mksh-59c-8/funcs.c mksh-59c-9/funcs.c
--- mksh-59c-8/funcs.c 2021-07-12 16:13:08.0 +0200
+++ mksh-59c-9/funcs.c 2021-07-12 16:12:43.0 +0200
@@ -554,6 +554,7 @@ c_print(const char **wp)
po.copipe = block_pipe();
continue;
}
+ bi_errorf(Tf_sD_s, Twrite, cstrerror(errno));
c = 1;
break;
}
@@ -1134,7 +1135,8 @@ c_kill(const char **wp)
n = 1;
Bug#990973: unblock: mksh/59c-9
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: t...@mirbsd.de, Vincent Lefèvre Please unblock package mksh [ Reason ] This update is comprised of: • documentation update from upstream CVS HEAD, mostly related to the death of a certain IRC network (one FAQ entry related to changes that are already in 59c-8 also got in) • some more reliability checks (although I’m afraid the full C1 control character escaping changes won’t make bullseye, they’re still under development and rather invasive, so I only picked the small independent fixes): – check lower bounds of input line array when backspacing – protect against hi-bit7 (stty) EOF character – ensure macro calls don’t have side effects in arguments • properly flush stderr and unwind for direct builtin calls (“ln -s /bin/mksh echo; ./echo …”) so they behave the same as if called from within the shell (“/bin/mksh -c 'echo …'”) • fix truncation behaviour for internal snprintf equivalent (a sequence of putc+puts+putc could, before, drop the puts but allow the putc to succeed); this becomes important with the next change • show error message and exit nōn-zero on stdout write failure for builtin calls (Closes: #990265) ‣ there was quite a discussion around what parts are actually buggy-as-in-not-POSIX on the Austin Group (POSIX) mailing list, as there was no consensus between shell implementors, packagers and users; this implements (for all known cases) what the official response requires • display correct errno when doing so (before, one codepath could lose errno as it did another libc call in between) • show error message in echo/print builtin on output write failure (basically the same as the generic one except echo/print don’t write buffered to stdout, they write to any fd, and already exited 1 on write error but didn’t issue a diagnostic message in that case which the POSIX people seem to prefer) [ Impact ] The references to the dead IRC network stay in. Scenarios in which output is redirected to files on a full filesystem can’t be handled by shell scripts. Direct builtin calls can lose stderr messages. (The other fixes are for bugs I’ve not seen in production but aren’t untrue either.) [ Tests ] The stdout/error change has new tests in the regression test suite and has also been tested by the requestor and the concept was ACK’d on the Austin Group mailing list. All changes have been tested in MirBSD for a while (including rebuilding the full OS with them in play) and not triggered any problems. The changes (except documentation where I cp’d for some files) are all individual cherry-picks of the relevant commits, individually reviewed. I also tested the truncation one by temporarily adding debugging code during development, and all error handling-related ones also on Debian with /dev/full (which doesn’t exist on MirBSD). [ Risks ] As mentioned in the last unblock, mksh is effectively not key. These changes only affect specific things (the ones under “some more reliability checks” only the interactive line editor, for example) and thus are rather localised, mistakes easily spotted. Therefore I believe these are low risk (I specifically didn’t cherry-pick a few fixes that are of higher risk because of their interwovenness and intrusivity level; users will have to wait for the next release for these). I expect this to be the last upload before the release. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach diff against the package in testing [ Other info ] I’ve again attached a diff of the unpacked package instead of a debdiff because I use single-debian-patch and develop in VCS. I’ve commented the diff, so it’s easier to map the hunks to the changes listed. unblock mksh/59c-9
Bug#990968: unblock: apache2/2.4.48-3.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: t...@mirbsd.de Please unblock package apache2 [ Reason ] Fixes #990580 which is a regression caused by the changes from #979813. [ Impact ] Sysadmins will get hundreds of eMails each night, become angry and storm Debian HQ with torches and putforks and… erm well insert your favourite upraising scenatio. [ Tests ] The updated package fixes the issue for me, and the cause was identified by kilobyte, so it’s seen two eyepairs at least. [ Risks ] Trivial fix to a logrotate script. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] unblock apache2/2.4.48-3.1 diff -Nru apache2-2.4.48/debian/apache2.logrotate apache2-2.4.48/debian/apache2.logrotate --- apache2-2.4.48/debian/apache2.logrotate 2021-06-20 13:55:24.0 +0200 +++ apache2-2.4.48/debian/apache2.logrotate 2021-07-10 23:31:24.0 +0200 @@ -14,7 +14,7 @@ endscript postrotate if pgrep -f ^/usr/sbin/apache2 > /dev/null; then - invoke-rc.d apache2 reload + invoke-rc.d apache2 reload 2>&1 | logger -t apache2.logrotate fi endscript } diff -Nru apache2-2.4.48/debian/changelog apache2-2.4.48/debian/changelog --- apache2-2.4.48/debian/changelog 2021-06-20 16:39:33.0 +0200 +++ apache2-2.4.48/debian/changelog 2021-07-10 23:31:28.0 +0200 @@ -1,3 +1,11 @@ +apache2 (2.4.48-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Direct init script reload output from logrotate to syslog, to +avoid mail-spamming the local admin (Closes: #990580) + + -- Thorsten Glaser Sat, 10 Jul 2021 23:31:28 +0200 + apache2 (2.4.48-3) unstable; urgency=medium * Fix debian/changelog
Bug#990580: apache2: [regression] daily cron mails from logrotate: Reloading Apache httpd web server: apache2.
Package: apache2 Version: 2.4.48-3 Severity: important X-Debbugs-Cc: t...@mirbsd.de, debian-release@lists.debian.org Having just upgraded machines from 2.4.46-4 to 2.4.48-3 I now get daily¹ cron mails: | From: Anacron | Message-ID: <20210702075325.946f340...@ci-busyapps.lan.tarent.de> | To: r...@ci-busyapps.lan.tarent.de | Date: Fri, 2 Jul 2021 07:53:25 + (UTC) | Subject: Anacron job 'cron.daily' on ci-busyapps.lan.tarent.de | | /etc/cron.daily/logrotate: | Reloading Apache httpd web server: apache2. This is a regression that’s going to severely annoy admins and ought to be fixed, including for bullseye. ① I know they are daily because I have been getting them on another system for some time already but didn’t know if it was that system or something in the package; as multiple other systems are now affected identically, I know it’s a bug in the package. -- Package-specific info: -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages apache2 depends on: ii apache2-bin 2.4.48-3 ii apache2-data 2.4.48-3 ii apache2-utils2.4.48-3 ii dpkg 1.20.9 ii init-system-helpers 1.60 ii lsb-base 11.1.0 ii mime-support 3.66 ii perl 5.32.1-4 ii procps 2:3.3.17-5 Versions of packages apache2 recommends: ii ssl-cert 1.1.0+nmu1 Versions of packages apache2 suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom ii lynx [www-browser] 2.9.0dev.6-2 Versions of packages apache2-bin depends on: ii libapr11.7.0-6 ii libaprutil11.6.1-5 ii libaprutil1-dbd-pgsql 1.6.1-5 ii libaprutil1-ldap 1.6.1-5 ii libbrotli1 1.0.9-2+b2 ii libc6 2.31-12 ii libcrypt1 1:4.4.18-4 ii libcurl4 7.74.0-1.3 ii libjansson42.13.1-1.1 ii libldap-2.4-2 2.4.57+dfsg-3 ii liblua5.3-05.3.3-1.1+b1 ii libnghttp2-14 1.43.0-1 ii libpcre3 2:8.39-13 ii libssl1.1 1.1.1k-1 ii libxml22.9.10+dfsg-6.7 ii perl 5.32.1-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages apache2-bin suggests: pn apache2-doc pn apache2-suexec-pristine | apache2-suexec-custom ii lynx [www-browser] 2.9.0dev.6-2 Versions of packages apache2 is related to: ii apache2 2.4.48-3 ii apache2-bin 2.4.48-3 -- Configuration Files: /etc/apache2/mods-available/ssl.conf changed [not included] /etc/apache2/sites-available/000-default.conf changed [not included] /etc/apache2/sites-available/default-ssl.conf changed [not included] -- no debconf information
Bug#989780: unblock: musescore2/2.3.2+dfsg4-15 and musescore3/3.2.3+dfsg2-11
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@mirbsd.de
Please unblock package musescore2 and musescore3
[ Reason ]
In #985129 a soundfont-dependent crash was reported. Upon further
debugging and inspection of the code as well as discussion with
upstream, multiple failures in the handling of soundfonts was found
which I fixed, adapting the code to honour the SoundFont specification
in the ways I found possible. Some of the issues had been known, but
not fixed yet. (Mostly the mismatch between end and end-1.)
Further discussion with the developers of FluidSynth, an old version
of which the MuseScore built-in synthesiser “fluid” is based on, and
with the developer of MuseScore’s principal soundfont resulted in
further refining the handling of bad {,loop}{start,end} values, as
to better match Fluid’s playback capabilities as well as real-existing
soundfonts.
There were also places where unsigned integers need to be used as
soundfonts can be up to 4 GiB in size. (One place uses size_t instead,
this is a backport of an upstream change; size_t is neither less nor
more correct here.)
This is a patch that applies to both source packages identically
(with very slight changes in the context of some lines only).
[ Impact ]
Rare arbitrary unreproducible crashes, and incorrect playback of some
real-existing but not spec-compliant soundfonts.
[ Tests ]
I’ve tested the patched versions myself for a bit and had developers
of both upstream and FluidSynth look at it. An upstream developer was
also testing it but had mixed feedback because of a bug he himself had
accidentally introduced in his tree, but other than that the feedback
was good.
[ Risks ]
The diff looks complex but in actuality simplifies the code in question
and makes it more easy to read (modulo upstream’s weird indentation
style). The code is duplicated, because SF3 soundfonts handle the checks
at a different point in the application lifecycle than SF2 ones due to
compression coming into play, but I ensured it’s a text editor block copy,
indent level increase, and the addition of p-> everywhere *only*.
These are leaf packages.
The PR has not yet been merged upstream, but I consider it low risk for
Debian nevertheless.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
unblock musescore2/2.3.2+dfsg4-15
unblock musescore3/3.2.3+dfsg2-11
diff -Nru musescore2-2.3.2+dfsg4/debian/changelog
musescore2-2.3.2+dfsg4/debian/changelog
--- musescore2-2.3.2+dfsg4/debian/changelog 2021-03-05 17:57:30.0
+0100
+++ musescore2-2.3.2+dfsg4/debian/changelog 2021-06-05 18:04:54.0
+0200
@@ -1,3 +1,9 @@
+musescore2 (2.3.2+dfsg4-15) unstable; urgency=medium
+
+ * Fix soundfont-related crashes or audible artefacts (Closes: #985129)
+
+ -- Thorsten Glaser Sat, 05 Jun 2021 18:04:54 +0200
+
musescore2 (2.3.2+dfsg4-14) unstable; urgency=medium
* Fix possible error cause in m-common.prerm (Closes: #984592)
diff -Nru
musescore2-2.3.2+dfsg4/debian/patches/experiments/valid-soundfont.diff
musescore2-2.3.2+dfsg4/debian/patches/experiments/valid-soundfont.diff
--- musescore2-2.3.2+dfsg4/debian/patches/experiments/valid-soundfont.diff
1970-01-01 01:00:00.0 +0100
+++ musescore2-2.3.2+dfsg4/debian/patches/experiments/valid-soundfont.diff
2021-06-05 18:04:54.0 +0200
@@ -0,0 +1,430 @@
+Description: Fix multiple possible causes of crashes or audible artefacts
+ - Track sample name so we can issue proper warning messages, show filename
+ - On read errors, issue an error message and mark sample as invalid
+ - Mark sample as invalid if Ogg Vorbis decompression (SF3) fails
+ - Do all sanity checks on {,loop}{start,end} with SF2 semantics for end;
+ only switch end to point to the last sample afterwards in only one place
+ - Adapt sanity checks and corrections to current FluidSynth, which matches
+ real-existing soundfonts better
+ - Add sanity check provided by the SoundFont spec as extra diagnostic
+ - Do not crash if there is no data[]
+ - Issue diagnostics if disabling a sample
+ - Swap two members to improve structure packing/alignment while there
+ - Use unsigned integers for SoundFont element sizes properly
+Author: mirabilos
+Bug: https://musescore.org/en/node/89216 (and probably others)
+Bug-Debian: https://bugs.debian.org/985129
+Forwarded: https://github.com/musescore/MuseScore/pull/7728
+
+--- a/fluid/sfont.cpp
b/fluid/sfont.cpp
+@@ -589,6 +589,7 @@ Sample::Sample(SFont* s)
+ data= 0;
+ amplitude_that_reaches_noise_floor_is_valid = false;
+ amplitude_that_reaches_noise_floor = 0.0;
++ name[0] = 0;
+ }
+
+ //-
+@@ -625,11 +626,12 @@ void Sample::load()
+ #ifdef SOUNDFONT3
+ char* p =
Bug#989779: unblock: polyphone/2.2.0.20210109+dfsg1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: t...@mirbsd.de Please unblock package polyphone [ Reason ] The current release contains a regression where large soundfont sample offsets are not correctly encoded. [ Impact ] Silently produces bad output for large sample offsets. This kind of corruption is hard to manually test for. [ Tests ] The submitter of the patch tested the package, although not the precise binary but a recompilation from the same sources in my PPA. [ Risks ] Low, leaf package, merely reverts part of an upstream commit. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] unblock polyphone/2.2.0.20210109+dfsg1-2 diff -Nru polyphone-2.2.0.20210109+dfsg1/debian/changelog polyphone-2.2.0.20210109+dfsg1/debian/changelog --- polyphone-2.2.0.20210109+dfsg1/debian/changelog 2021-01-19 23:14:12.0 +0100 +++ polyphone-2.2.0.20210109+dfsg1/debian/changelog 2021-06-06 15:22:08.0 +0200 @@ -1,3 +1,9 @@ +polyphone (2.2.0.20210109+dfsg1-2) unstable; urgency=medium + + * Add patch to fix large soundfonts/samples’ offsets + + -- Thorsten Glaser Sun, 06 Jun 2021 15:22:08 +0200 + polyphone (2.2.0.20210109+dfsg1-1) unstable; urgency=medium * Improve compiler flags handling, via MuseScore packaging diff -Nru polyphone-2.2.0.20210109+dfsg1/debian/patches/142.patch polyphone-2.2.0.20210109+dfsg1/debian/patches/142.patch --- polyphone-2.2.0.20210109+dfsg1/debian/patches/142.patch 1970-01-01 01:00:00.0 +0100 +++ polyphone-2.2.0.20210109+dfsg1/debian/patches/142.patch 2021-06-06 15:21:55.0 +0200 @@ -0,0 +1,24 @@ +Description: allow offset values greater than 16-bit signed integer + A fix for issue #141, which was broken by commit + f80fc38b406ad094a1d3d2563da5d8124818e2e3. This fix reverts to the + use of qRound when storing offset values for sample and loop start/end. +From: "S. Christian Collins" +Origin: https://github.com/davy7125/polyphone/pull/142 +Bug: https://github.com/davy7125/polyphone/issues/141 + +--- a/sources/core/types/attribute.cpp b/sources/core/types/attribute.cpp +@@ -181,11 +181,11 @@ AttributeValue Attribute::fromRealValue( + break; + case champ_startloopAddrsCoarseOffset: case champ_endloopAddrsCoarseOffset: + case champ_startAddrsCoarseOffset: case champ_endAddrsCoarseOffset: +-storedValue.shValue = Utils::round16(realValue) / 32768; ++storedValue.shValue = static_cast(qRound(realValue) / 32768); + break; + case champ_startloopAddrsOffset: case champ_startAddrsOffset: + case champ_endloopAddrsOffset: case champ_endAddrsOffset: +-storedValue.shValue = static_cast(Utils::round16(realValue) % 32768); ++storedValue.shValue = static_cast(qRound(realValue) % 32768); + break; + case champ_keyRange: case champ_velRange: + storedValue.rValue.byHi = static_cast(0.001 * realValue); diff -Nru polyphone-2.2.0.20210109+dfsg1/debian/patches/series polyphone-2.2.0.20210109+dfsg1/debian/patches/series --- polyphone-2.2.0.20210109+dfsg1/debian/patches/series2021-01-19 23:12:32.0 +0100 +++ polyphone-2.2.0.20210109+dfsg1/debian/patches/series2021-06-06 15:16:36.0 +0200 @@ -2,3 +2,4 @@ branding.diff fix-build.diff reproducible.diff +142.patch
Bug#989532: unblock: mc/3:4.8.26-1.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@mirbsd.de, only...@debian.org, y...@shurup.com,
ti...@debian.org, deb...@denis-briand.fr
Please unblock package mc
[ Reason ]
This fixes #987446 which basically made any file that isn’t called
.zip but is a PKZIP container (including both things that are ZIP-like
archives, like *.jar, and those which aren’t, like office documents)
unusable with mc.
[ Impact ]
Quite a regression and limiting use.
[ Tests ]
I’ve manually tested this. It’s a backport of an upstream fix,
so I guess they also tested it, and it’ll be part of the next
upstream release.
[ Risks ]
This changes a conffile only, in a somewhat-leaf (only pulled
in by tasks-like packages) package. If anything should need to
be fixed up later, it can if necessary be done by the end user
changing the file in /etc.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
unblock mc/3:4.8.26-1.1
diff -Nru mc-4.8.26/debian/changelog mc-4.8.26/debian/changelog
--- mc-4.8.26/debian/changelog 2021-02-01 02:44:43.0 +0100
+++ mc-4.8.26/debian/changelog 2021-06-01 15:26:23.0 +0200
@@ -1,3 +1,10 @@
+mc (3:4.8.26-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix PKZIP archive handling, patch backported from upstream
+
+ -- Thorsten Glaser Tue, 01 Jun 2021 15:26:23 +0200
+
mc (3:4.8.26-1) unstable; urgency=medium
* New upstream release.
diff -Nru mc-4.8.26/debian/patches/fix-987446.patch
mc-4.8.26/debian/patches/fix-987446.patch
--- mc-4.8.26/debian/patches/fix-987446.patch 1970-01-01 01:00:00.0
+0100
+++ mc-4.8.26/debian/patches/fix-987446.patch 2021-06-01 15:24:55.0
+0200
@@ -0,0 +1,263 @@
+Origin: upstream, commit:fa2cbd2a2c7e38ee56d1756eac5899b57f7f4262
+From: Andrew Borodin
+Description: Ticket #4180: reorgzanize mc.ext.
+ $ file -L image.zip
+ image.zip: Zip archive data, at least v2.0 to extract
+ $ file -L -z image.zip
+ image.zip: JPEG image data, JFIF standard 1.01, resolution (DPI),
+ density 96x96, segment length 16, baseline, precision 8, 1024x768,
+ frames 3 (Zip archive data, at least v2.0 to extract)
+ .
+ Since in mc.ext
+ .
+ type/^JPEG
+ .
+ is evaluated before
+ .
+ type/\(Zip archive
+ .
+ mc assume image.zip is a image not an archive.
+ .
+ To solve this, since we use "file -z", match file name at first
+ (regex/ and shell/), then type/.
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987446
+
+--- a/misc/mc.ext.in
b/misc/mc.ext.in
+@@ -107,6 +107,7 @@
+ ### Changes ###
+ #
+ # Reorganization: 2012-03-07 Slava Zanko
++# 2021-03-28 Andrew Borodin
+
+
+ ### GIT Repo ###
+@@ -117,6 +118,7 @@ regex/^\[git\]
+
+
+ ### Archives ###
++# Since we use "file -z", we should use regex/ and shell/ at first, then
type/.
+
+ # .tgz, .tpz, .tar.gz, .tar.z, .tar.Z, .ipk, .gem
+ regex/\.t([gp]?z|ar\.g?[zZ])$|\.ipk$|\.gem$
+@@ -171,16 +173,6 @@ shell/i/.tar
+ Open=%cd %p/utar://
+ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view tar
+
+-# lha
+-type/^LHa\ .*archive
+- Open=%cd %p/ulha://
+- View=%view{ascii} @EXTHELPERSDIR@/archive.sh view lha
+-
+-# PAK
+-type/^PAK\ .*archive
+- Open=%cd %p/unar://
+- View=%view{ascii} @EXTHELPERSDIR@/archive.sh view pak
+-
+ # arj
+ regex/i/\.a(rj|[0-9][0-9])$
+ Open=%cd %p/uarj://
+@@ -300,7 +292,6 @@ shell/i/.iso
+ Open=%cd %p/iso9660://
+ View=%view{ascii} @EXTHELPERSDIR@/misc.sh view iso9660
+
+-
+ regex/\.(diff|patch)$
+ Open=%cd %p/patchfs://
+ View=%view{ascii} @EXTHELPERSDIR@/misc.sh view cat
+@@ -316,6 +307,102 @@ shell/i/.lib
+ Open=%cd %p/ulib://
+ View=%view{ascii} @EXTHELPERSDIR@/misc.sh view lib
+
++# ace
++shell/i/.ace
++ Open=%cd %p/uace://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view ace
++ Extract=unace x %f
++
++# arc
++shell/i/.arc
++ Open=%cd %p/uarc://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view arc
++ Extract=arc x %f '*'
++ Extract (with flags)=I=%{Enter any Arc flags:}; if test -n "$I"; then
arc x $I %f; fi
++
++# zip
++shell/i/.zip
++ Open=%cd %p/uzip://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view zip
++
++# zoo
++shell/i/.zoo
++ Open=%cd %p/uzoo://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view zoo
++
++# lz4
++regex/\.lz4$
++ Open=@EXTHELPERSDIR@/archive.sh view lz4 %var{PAGER:more}
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view lz4
++
++# WIM
++shell/i/\.wim
++ Open=%cd %p/uwim://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view wim
++
++# gzip
++type/\(gzip compressed
++ Open=@EXTHELPERSDIR@/archive.sh view gz %var{PAGER:more}
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view gz
++
++# b
Bug#989509: buster-pu: package klibc/2.0.6-1+deb10u1
Ben Hutchings dixit: >Thorsten Glaser tested the s390x fix in unstable. It has not (yet) >been manually tested in this version. Unfortunately we don’t have a baseline, as the only test I had that triggered this doesn’t trigger in buster (probably because only a newer GCC scheduled things to use these registers in the first place). bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#989314: unblock: mksh/59c-8
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@mirbsd.de
Control: block -1 by 989279
Please unblock package mksh
[ Reason ]
This upload addresses the following issues:
• Work around #988027 in klibc (which is a POSIX violation but
apparently deliberate by upstream) by using {set,long}jmp
instead of sig{set,long}jmp when not saving/restoring signals
(cherry-pick from upstream)
• Rebuild against klibc with #943425 ({set,long}jmp on s390x use
wrong registers) fixed
• Cherry-pick another two upstream memory leak fixes
• Backport just enough (for Debian) of upstream patch fixing the
way control characters are escaped when showing variable contents
(for reentrancy or when deliberately escaping with ${varname@Q});
specifically, escape C1 control characters dependent on whether
utf8-mode is on (UTF8-encoded) or off (bytewise), catching some
situations in which they were not escaped properly, make the
escaped output match the UTF-8 mode better, and add a shell option
“asis” to allow \x80‥\x9F unescaped outside(!) of UTF-8 mode only
for when the user uses a codepage that has them as printable, not
control, characters
(There’s also a one-line d-ports-only change of no relevance to
the release architectures.)
[ Impact ]
• Potential (but minor; except on s390x, the testsuite didn’t catch
anything) misbehaviour of the klibc-built binaries; outdated
Built-Using for klibc once 2.0.8-6.1 migrates
• Minor memory leaks
• Attempting to display a variable escaped (“typeset -p varname”,
“set | grep ^varname”) may send control sequences to the terminal,
including sequences that cause xterm to, for example, dump the
current terminal contents to files
[ Tests ]
The testsuite is very throughout (it did catch the s390x/klibc issue
and switched the mksh-static and lksh binary to musl for that); it
also proves the klibc change works. I’ve manually verified the escaping-
related changes. I’ve not verified the memory leaks separately, but
the codepaths are like this that, if they were wrong (e.g. use-after-
free), the testsuite (especially on MirBSD with malloc hardening)
would’ve caught it crashing.
I’ve run a number of scripts comparing output with the previous and
the binaries from this upload installed.
[ Risks ]
As I wrote in earlier unblock requests (#987975, #986431) mksh is
effectively leaf in Debian, and changes like these are low risk.
I’ve reduced the upstream commits related to escaping to include
only the necessary parts to make reviewing easier. This carries
some, but very low, risk. The tests would have caught mistakes
during that (incidentally, they did, when I removed a hunk which
I at first thought not necessary).
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
I’m attaching a diff of the unpacked trees instead of debdiff(1)
output again because I use single-debian-patch here and that’d
be a nightmare to review. I’ve commented in the diff which hunks
match which issue.
I’m also attaching a “diff -w” of the file misc.c to make review
easier; a huge part of the escaping code lost one level of indent.
I’ll be uploading another escaping-related fix revision, similar
issues (C0/C1 control characters and DEL) but in the command line
editor and tab completion code, but I have yet to find the time
to actually fix these issues first and think that including what
we’ve already got in sid into testing right now is a good thing.
unblock mksh/59c-8
diff -pruN mksh_59c-6/debian/changelog mksh_59c-8/debian/changelog
--- mksh_59c-6/debian/changelog 2021-05-03 03:26:28.0 +0200
+++ mksh_59c-8/debian/changelog 2021-05-31 02:42:55.0 +0200
@@ -1,3 +1,26 @@
+mksh (59c-8) unstable; urgency=medium
+
+ * Fix a -Wpointer-sign in escaping code
+ * Shrink escape diff (algorithm unchanged) for easier review
+
+ -- Thorsten Glaser Mon, 31 May 2021 02:42:55 +0200
+
+mksh (59c-7) unstable; urgency=medium
+
+ * Do not use sigsetjmp(â¦, 0) with klibc (cf. #988027)
+ * Cherry-pick upstream memory leak fixes
+ * Apply just enough upstream changes to address more escaping
+issues: for ${var@Q} and âtypeset -pâ, take UTF-8 mode (on/off)
+into account; donât issue \u escapes outside of UTF-8 mode,
+donât escape nÅn-ASCII printable, that is, nÅn-control characters;
+always escape C0 controls and DEL; escape C1 controls by default,
+but add an option âasisâ to disable that (e.g. for DOS codepages)
+in nÅn-UTF8 modeââânote this will need fixing for tab completion,
+command line editing (in a subsequent upload)â¦
+ * Work around hppa buildd issue (same as m68k, sh4)
+
+ -- Thorsten Glaser Sun, 30 May 2021 23:57:59 +0200
+
mksh (59c-6) unstable; urgency=medium
* Clear âtaintâ on most actions mutating a variable
Bug#989279: unblock: klibc/2.0.8-6.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@mirbsd.de
Please unblock package klibc
[ Reason ]
The NMU contains a fix for #943425 (save/restore correct set of
registers across *{set,long}jmp) which is RC on s390x, which is
a release architecture.
[ Impact ]
klibc-built binaries on s390x can malfunction.
[ Tests ]
The mksh testsuite catches this. Today’s mksh upload’s buildd log
on s390x shows that the fix works. An S/390 expert provided the
correct set of registers to save/restore. I’ve compared it to the
glibc implementation afterwards, and it matches, so I believe it
to be correct.
[ Risks ]
klibc is rather critical; it’s part of booting and installing (so
this also needs an udeb unblock). The patch affects s390x only,
as far as I can tell, but I believe it necessary there.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
This will need an udeb unblock; what do I need to do for this?
unblock klibc/2.0.8-6.1
diff -Nru klibc-2.0.8/debian/changelog klibc-2.0.8/debian/changelog
--- klibc-2.0.8/debian/changelog2021-04-30 03:05:23.0 +0200
+++ klibc-2.0.8/debian/changelog2021-05-27 00:12:10.0 +0200
@@ -1,3 +1,11 @@
+klibc (2.0.8-6.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * {set,long}jmp [s390x]: save/restore the correct FPU registers
+(f8‥f15 not f1/f3/f5/f7) (Closes: #943425)
+
+ -- Thorsten Glaser Thu, 27 May 2021 00:12:10 +0200
+
klibc (2.0.8-6) unstable; urgency=medium
* Upload to unstable
diff -Nru
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
---
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
1970-01-01 01:00:00.0 +0100
+++
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
2021-05-27 00:11:57.0 +0200
@@ -0,0 +1,57 @@
+Description: {set,long}jmp [s390x]: save/restore the correct registers
+ The s390x ABI actually has FPU registers f8‥f15, not f1/f3/f5/f7,
+ to be saved. (Closes: Debian #943425)
+Author: mirabilos
+Forwarded: https://lists.zytor.com/archives/klibc/2021-May/004620.html
+
+--- a/usr/include/arch/s390/klibc/archsetjmp.h
b/usr/include/arch/s390/klibc/archsetjmp.h
+@@ -16,7 +16,7 @@ struct __jmp_buf {
+
+ struct __jmp_buf {
+ uint64_t __gregs[10]; /* general registers r6-r15 */
+- uint64_t __fpregs[4]; /* fp registers f1, f3, f5, f7 */
++ uint64_t __fpregs[8]; /* fp registers f8-f15 */
+ };
+
+ #endif /* __s390x__ */
+--- a/usr/klibc/arch/s390/setjmp.S
b/usr/klibc/arch/s390/setjmp.S
+@@ -38,10 +38,14 @@ longjmp:
+
+ setjmp:
+ stmg%r6,%r15,0(%r2) # save all general registers
+- std %f1,80(%r2) # save fp registers f4 and f6
+- std %f3,88(%r2)
+- std %f5,96(%r2)
+- std %f7,104(%r2)
++ std %f8,80(%r2) # save fp registers f8 to f15
++ std %f9,88(%r2)
++ std %f10,96(%r2)
++ std %f11,104(%r2)
++ std %f12,112(%r2)
++ std %f13,120(%r2)
++ std %f14,128(%r2)
++ std %f15,136(%r2)
+ lghi%r2,0 # return 0
+ br %r14
+
+@@ -54,10 +58,14 @@ setjmp:
+ longjmp:
+ lgr %r1,%r2 # jmp_buf
+ lgr %r2,%r3 # return value
+- ld %f7,104(%r1)# restore all saved registers
+- ld %f5,96(%r1)
+- ld %f3,88(%r1)
+- ld %f1,80(%r1)
++ ld %f15,136(%r1) # restore all saved registers
++ ld %f14,128(%r1)
++ ld %f13,120(%r1)
++ ld %f12,112(%r1)
++ ld %f11,104(%r1)
++ ld %f10,96(%r1)
++ ld %f9,88(%r1)
++ ld %f8,80(%r1)
+ lmg %r6,%r15,0(%r1)
+ br %r14# return to restored address
+
diff -Nru klibc-2.0.8/debian/patches/series klibc-2.0.8/debian/patches/series
--- klibc-2.0.8/debian/patches/series 2021-04-30 02:38:31.0 +0200
+++ klibc-2.0.8/debian/patches/series 2021-05-27 00:09:21.0 +0200
@@ -10,3 +10,4 @@
0037-klibc-calloc-Fail-if-multiplication-overflows.patch
0039-klibc-cpio-Fix-possible-integer-overflow-on-32-bit-s.patch
0040-klibc-cpio-Fix-possible-crash-on-64-bit-systems.patch
+0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
Bug#987975: unblock: mksh/59c-6
backslashes that are safe (extra
backslashes in those cases can’t hurt anyway, eg. = is already
almost needlessly escaped)
- the memory leaks are low-risk as “obvious”
- same for the lexer change
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
(let it simmer in sid for a few days first)
unblock mksh/59c-6
diff -Nru mksh-59c/debian/changelog mksh-59c/debian/changelog
--- mksh-59c/debian/changelog 2021-03-13 19:09:48.0 +0100
+++ mksh-59c/debian/changelog 2021-05-03 03:26:28.0 +0200
@@ -1,3 +1,28 @@
+mksh (59c-6) unstable; urgency=medium
+
+ * Clear “taint” on most actions mutating a variable
+
+ -- Thorsten Glaser Mon, 03 May 2021 03:26:28 +0200
+
+mksh (59c-5) unstable; urgency=medium
+
+ * Apply targeted fixes, intended for bullseye:
+- [tg] Plug some memory leaks
+- [tg] Harden conversion of imported variables to integer, like
+ Perl “taint”: imported variables will now lose the value when
+ converting to integer but they are not purely numeric
+ (CVE-2019-14868 was a similar issue in AT ksh); honour
+ -o posix for leading-zero as octal, though (but continue not
+ when importing array indicēs)
+- [tg] Fix lexer token state corruption when reading new input;
+ makes evaluate-region editing command actually useful
+- [tg] Fix proper escaping/quoting and tab completion for tilde,
+ curly braces and \x02, either escaped or not
+Note: patches are reduced to minimum change for bullseye
+ * Rebuild for outdated Built-Using
+
+ -- Thorsten Glaser Sun, 02 May 2021 23:52:52 +0200
+
mksh (59c-4) unstable; urgency=low
* Update to upstream CVS HEAD
diff -pruN mksh_59c-4/check.t mksh_59c-6/check.t
--- mksh_59c-4/check.t 2021-05-03 00:29:50.0 +0200
+++ mksh_59c-6/check.t 2021-05-03 03:57:57.0 +0200
@@ -31,7 +31,7 @@
# (2013/12/02 20:39:44)
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/regress/bin/ksh/?sortby=date
expected-stdout:
- KSH R59 2021/03/13
+ KSH R59 2021/05/03
description:
Check base version of full shell
stdin:
@@ -13230,6 +13230,41 @@ expected-stdout:
2=\x7Cfoo-e \x4B
3=\x7Cfoo-e \x4B
---
+name: env-intvars
+description:
+ Check that importing integers fails except for numbers
+stdin:
+ unset foo bar
+ print 1 $foo , $(typeset -p bar) .
+ print 2 $(foo=123 "$__progname" -c 'integer foo; print -- $foo' 2>&1) ,
\
+ $(env 'bar[123]=baz' "$__progname" -c 'typeset -p bar') .
+ print 3 $(foo='abc[$(echo >&2 fowled)0]' "$__progname" -c 'integer foo;
print -- $foo' 2>&1) , \
+ $(env 'bar[$(echo >&2 fowled)0]=baz' "$__progname" -c 'typeset -p
bar') .
+ print 4 $(foo=0123 "$__progname" +o posix -c 'integer foo; print --
$foo' 2>&1) , \
+ $(env 'bar[0123]=baz' "$__progname" +o posix -c 'typeset -p bar') .
+ # ksh93 does not do this:
+ print 5 $(foo=0123 "$__progname" -o posix -c 'integer foo; print --
$foo' 2>&1) .
+ # at import time FPOSIX is not yet set
+ print 6 $(foo=0x123 "$__progname" -c 'integer foo; print -- $foo' 2>&1)
, \
+ $(env 'bar[0x123]=baz' "$__progname" -c 'typeset -p bar') .
+ print 7 $(foo=12#123 "$__progname" -c 'integer foo; print -- $foo'
2>&1) , \
+ $(env 'bar[12#123]=baz' "$__progname" -c 'typeset -p bar') .
+ print 8 $(foo=1+1 "$__progname" -c 'integer foo; print -- $foo' 2>&1) ,
\
+ $(env 'bar[1+1]=baz' "$__progname" -c 'typeset -p bar') .
+ print 9 $(a=1 b=2 c=a "$__progname" -c 'typeset -p c; c=b; typeset -p
c; integer c; typeset -p c') .
+ print 0 $(a=1 b=2 c=a "$__progname" -c 'typeset -p c; typeset -p
c; integer c; typeset -p c') .
+expected-stdout:
+ 1 , .
+ 2 123 , set -A bar typeset -x bar[123]=baz .
+ 3 0 , .
+ 4 123 , set -A bar typeset -x bar[123]=baz .
+ 5 8#123 .
+ 6 16#123 , .
+ 7 12#123 , .
+ 8 0 , .
+ 9 typeset -x c=a typeset -x c=b typeset -i -x c=2 .
+ 0 typeset -x c=a typeset -x c=a typeset -i -x c=0 .
+---
name: utilities-getopts-1
description:
getopts sets OPTIND correctly for unparsed option
diff -pruN mksh_59c-4/edit.c mksh_59c-6/edit.c
--- mksh_59c-4/edit.c 2021-05-03 00:29:50.0 +0200
+++ mksh_59c-6/edit.c 2021-05-03 03:57:57.0 +0200
@@ -74,6 +74,7 @@ static struct {
#define XCF_COMMAND_FILE (XCF_COMMAND | XCF_FILE)
#define XCF_IS_COMMAND BIT(3) /* return flag: is command */
#define XCF_IS_NOSPACE BIT(4) /* return flag: do not append a space */
+#define XCF_IS_HOMEDIR BIT(5) /* return flag: tilde needs slash */
static cha
Re: Tentative summary of the AMD/ATI/NVidia issue
Cyril Brulebois dixit: >Lucas Nussbaum (2021-04-24): >> C) Do nothing and document this in the release notes > >As said above, I strongly recommend against this. Right… what about, add another Plan C… C) When X won’t work, fail gracefully, show a console login … and dump the above to Plan D? (Perhaps doing this is a good idea in general, for when a similar issue pops up in the future?) bye, //mirabilos -- 22:59⎜ glaub ich termkit is kompliziert | glabe nicht das man damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil zuviel bilder │ wie ein spiel | 23:00⎜ die meisten raffen auch nicht mehr von windows | 23:01⎜ bilderbücher sind ja auch nich wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus?
Re: Bug#985634: git (1:2.31.0-1): no longer runs addons from /usr/lib/git-core breaking lots of 3rdpty stuff
Hi again, >I imagine *many* other third-party addons do the same. Please >make git search the old location after the new one (preferred) >or revert this change at least until past the bullseye release >(not preferred, as libexec is actually correct). ping?
Bug#987167: unblock: jamulus/3.6.2+dfsg1-3
l servers are operated by the Jamulus project; there is
+a central server for each genre, which is how public servers are
+categorised into genres.
+.Sh SEE ALSO
+.Xr qjackctl 1
+.Bl -tag -width Ds
+.It Pa https://jamulus.io/wiki/Software\-Manual
+online handbook
+.It Pa https://jamulus.io/wiki/Choosing\-a\-Server\-Type
+more details on the individual server types
+.It Pa https://jamulus.io/wiki/Running\-a\-Server
+documentation on server configuration
+.It Pa https://jamulus.io/wiki/Central\-Servers
+current list of central servers operated by the Jamulus project,
+controlling the
+.Dq genre
+.It Pa https://jamulus.io/wiki/Tips\-Tricks\-More
+verbose
+.Fl \-ctrlmidich
+documentation and other more or less useful information
+.El
+.Sh AUTHORS
+.An -nosplit
+.An mirabilos Aq t...@debian.org
+wrote this manual page for the Debian project,
+but it may be used elsewhere as well.
+.Sh BUGS
+This manual page was derived from the source code and summarises
+some of the information from the website, but it could be more helpful.
+.Pp
+Some of the networking code seems to assume Legacy IP
+.Pq IPv4 .
diff -Nru jamulus-3.6.2+dfsg1/debian/changelog
jamulus-3.6.2+dfsg1/debian/changelog
--- jamulus-3.6.2+dfsg1/debian/changelog2021-01-26 00:03:00.0
+0100
+++ jamulus-3.6.2+dfsg1/debian/changelog2021-04-11 16:04:40.0
+0200
@@ -1,3 +1,21 @@
+jamulus (3.6.2+dfsg1-3) unstable; urgency=low
+
+ * Update GitHub URLs
+- the repository moved to a{n, new} organisation
+- GitHub’s tags and releases pages changed tarball links
+ * Mark diff as applied upstream
+ * Run jdupes on the installed documentation as lintian demands
+ * Ship a manpage (Debian-specific for now)
+ * Merge updated list of central (genre) servers offered by upstream
+ * Also apply upstream fix for memory leaks
+ * Add patch to correctly escape messages received from clients
+ * Backport code around --serverpublicip to support running servers
+behind IPv4 NAT; also a prerequisite of the following patch
+ * Privacy fix: cease sending a packet to Cloudflare to determine
+the (nōn-NAT) external interface / IP address
+
+ -- Thorsten Glaser Sun, 11 Apr 2021 16:04:40 +0200
+
jamulus (3.6.2+dfsg1-2) unstable; urgency=low
* Upload to unstable
diff -Nru jamulus-3.6.2+dfsg1/debian/control jamulus-3.6.2+dfsg1/debian/control
--- jamulus-3.6.2+dfsg1/debian/control 2020-12-29 20:28:29.0 +0100
+++ jamulus-3.6.2+dfsg1/debian/control 2021-04-11 15:44:40.0 +0200
@@ -4,6 +4,7 @@
Maintainer: Thorsten Glaser
Homepage: https://jamulus.io/
Build-Depends: debhelper-compat (= 13),
+ jdupes,
libjack-jackd2-dev,
qtbase5-dev,
qtdeclarative5-dev,
diff -Nru jamulus-3.6.2+dfsg1/debian/copyright
jamulus-3.6.2+dfsg1/debian/copyright
--- jamulus-3.6.2+dfsg1/debian/copyright2020-12-29 21:57:20.0
+0100
+++ jamulus-3.6.2+dfsg1/debian/copyright2021-04-11 15:44:40.0
+0200
@@ -1,7 +1,7 @@
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: Jamulus
Upstream-Contact: https://sourceforge.net/p/llcon/discussion/
-Source: https://github.com/corrados/jamulus
+Source: https://github.com/jamulussoftware/jamulus
# Removed embedded convenience code copies and binaries
Removed embedded binaries (libs blocked by #686777)
Copyright: 2004–2020 Volker Fischer and others
diff -Nru jamulus-3.6.2+dfsg1/debian/jamulus.lintian-overrides
jamulus-3.6.2+dfsg1/debian/jamulus.lintian-overrides
--- jamulus-3.6.2+dfsg1/debian/jamulus.lintian-overrides2020-12-29
20:28:29.0 +0100
+++ jamulus-3.6.2+dfsg1/debian/jamulus.lintian-overrides2021-04-11
15:44:40.0 +0200
@@ -1,15 +1,2 @@
-# I promise to write one for the second upload
-# (the first upload goes to experimental and
-# has to pass ftpmaster NEW; the second one
-# will promote it to unstable) documenting the
-# then-current state of command line options,
-# as they can change…
-jamulus: no-manual-page usr/bin/Jamulus
-
# false positive; I checked all invocations of gcc and g++ in the build log
jamulus: hardening-no-fortify-functions usr/bin/Jamulus
-
-# for now, ignore them; it’s 4 small files, and the next (upstream) version
-# will most likely not ship them at all; otherwise I’ll tackle it in the
-# (second) upload (like above)
-jamulus: duplicate-files usr/share/doc/jamulus/homepage/*
diff -Nru jamulus-3.6.2+dfsg1/debian/jamulus.manpages
jamulus-3.6.2+dfsg1/debian/jamulus.manpages
--- jamulus-3.6.2+dfsg1/debian/jamulus.manpages 1970-01-01 01:00:00.0
+0100
+++ jamulus-3.6.2+dfsg1/debian/jamulus.manpages 2021-04-11 15:57:31.0
+0200
@@ -0,0 +1 @@
+debian/Jamulus.1
diff -Nru jamulus-3.6.2+dfsg1/debian/patches/1073.diff
jamulus-3.6.2+dfsg1/debian/patches/1073.diff
--- jamulus-3.6.2+dfsg1/debian/patches/1073.diff1970-01-01
01:00:00.0 +0100
+++ jamulus-3.6.2+dfsg1/debian/patches/1073.diff
Bug#986431: unblock: mksh/59c-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: t...@mirbsd.de Please unblock package mksh [ Reason ] This change was made under the impression that it would migrate thanks to autopkgtests… I was taken by surprise that mksh is a key package. I debugged that and found that debhelper B-D on shunit2 which B-D on mksh, which causes it to be a key package. Now shunit2 only B-D on mksh because it uses mksh at build time to run its tests, but shunit2’s build only fails if the last (shell, test) tuple fails, which is zsh. The change (asides from updating the documentation, especially wrt. future compatibility guarantees) brings mksh closer to the other shells in that it implements a form of POSIX locale trak‐ king to enable/disable UTF-8 mode (instead of mostly defaulting to C). Furthermore, a few Emacs input editing mode commands are extended to be able to operate on bigwords (like in Vi mode), not only words. [ Impact ] The user who requested the Emacs mode extension will be sad and have to wait for another release (unless I backport mksh, which I may do or may not do later). The shell will behave more closely to the previous releases’ mksh and less like a future mksh and most other shells wrt. handling the POSIX locale. I would consider that unfortunate. [ Tests ] mksh has an extensive regression test suite which exercises a good portion of the code (and the compiler, toolchain and libc/kernel). The testsuite was updated to match the expectations of locale trak‐ king as implemented (minor) and the changes were reviewed. I’ve run the shell, even as /bin/sh (supported but only as manual step in Debian), for more than three weeks now, extensively using it, and found no problems. I’ve verified the interactive mode change as well. [ Risks ] As stated above, the risk is minimal, considering what shunit2 does and when it was changed last, incidentally. mksh is used as direct dependency by not many packages, and while it’s installed on 2454 systems, few would install it as /bin/sh, and those people know what they’re doing. A standard Debian installation will not have mksh even installed. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [↓] attach debdiff against the package in testing I’ve changed the debdiff to change the diff-to-a-patch into a diff between the patched files (the packaging uses single-debian-patch as I normally work on a fully patched tree with git and every new upstream release will have the Debian-local changes go down to 0) to make it more readable. The last time I did that it was accepted. [ Other info ] In a clean bullseye chroot, the autopkgtests pass. unblock mksh/59c-4 diff -Nru mksh-59c/debian/changelog mksh-59c/debian/changelog --- mksh-59c/debian/changelog 2021-02-07 02:57:12.0 +0100 +++ mksh-59c/debian/changelog 2021-03-13 19:09:48.0 +0100 @@ -1,3 +1,27 @@ +mksh (59c-4) unstable; urgency=low + + * Update to upstream CVS HEAD +- [tg] Make "C" the implementation-specified default locale for + early-locale-tracking (note full locale tracking will have to + use whatever the underlying OS’ is, if no setlocale(3) it’ll + be just "C" again) and document possibly removing turning on + POSIX mode disabling and presence of a BOM enabling UTF-8 mode + with full locale tracking +- [tg] Document OPTU-16 (U+EF80‥U+EFFF) mapping for raw octets will not + be present once mksh will have switched to full 21-bit UCS / UTF-8 +- [tg] Add several bigword-based editing commands to Emacs mode +- [tg] Improve documentation wrt. $ENV + * Bring locale tracking code somewhat closer to what will eventually be +in upstream code (once I manage to do the related changes around MirBSD +base and its scripts, which needs some more time and tuits): +- drop BOM enabling UTF-8 mode code +- no longer deactivate UTF-8 mode on entering POSIX mode + (rationale: the POSIX locale parameters will be the only deciding + factor; even if, nominally, only the POSIX locale is compliant) + * Apply locale tracking to nōn-interactive shells as well + + -- Thorsten Glaser Sat, 13 Mar 2021 19:09:48 +0100 + mksh (59c-3) unstable; urgency=medium * Update to upstream CVS HEAD diff --git mksh_59c-3/check.t mksh_59c-4/check.t index e8f96af..7c601fb 100644 --- mksh_59c-3/check.t +++ mksh_59c-4/check.t @@ -31,7 +31,7 @@ # (2013/12/02 20:39:44) http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/regress/bin/ksh/?sortby=date expected-stdout: - KSH R59 2021/02/07 + KSH R59 2021/03/13 description: Check base version of full shell stdin: @@ -8890,7 +8890,7 @@ expected-stderr-pattern: --- name: utf8opt-1 description: - Check that the utf8-mode flag is not set at non-interactive startup + Check that the utf8-mode flag *is* set at non-interactive star
Bug#982669: buster-pu: package portaudio19/19.6.0-1
Adam D. Barratt dixit: >Please go ahead. Thanks, I’ve done so. bye, //mirabilos
Bug#985229: unblock: musescore2/2.3.2+dfsg4-14, musescore3/3.2.3+dfsg2-10, musescore-general-soundfont/0.2-3, timgm6mb-soundfont/1.3-5
Dixi quod… >[ Other info ] >I have another set of uploads for musescore2 and musescore3 fixing >crash bugs coming up (not uploading them today, I want upstream to >have a go at reviewing the change first). How should this be handled? >Should I first wait until the current set of packages is unblocked >and has migrated to testing? Otherwise, if I upload now musescore2 >would get AUTORM’d which is suboptimal. Waiting so long will however >delay availability of the fix even to sid users. On second thought, this fix (involving crashes caused by soundfonts) needs to go some rounds through affected parties (MuseScore upstream, soundfont author, even input from FluidSynth upstream) so I’d prefer for all four to be unblocked as-is with the #984592 fix only and will handle the other fix once it’s there and tested. Thanks, //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
Bug#985229: unblock: musescore2/2.3.2+dfsg4-14, musescore3/3.2.3+dfsg2-10, musescore-general-soundfont/0.2-3, timgm6mb-soundfont/1.3-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@mirbsd.de
Please unblock package musescore2, musescore3,
musescore-general-soundfont and timgm6mb-soundfont
(all packages related to #984592)
[ Reason ]
In rare conditions, “rmdir --ignore-fail-on-non-empty” as used in
the prerm of some packages can fail because dpkg already removed
one of the directories in question; this was found as #984592 by
piuparts. To ensure uninstalling without errors, we mkdir -p the
directories first (other errors will still cause aborting).
[ Impact ]
#984592 is considered an RC bug, so it would lead to removing a
package from the release, which is very suboptimal. In very rare
cases, not fixing this may cause package uninstallation to fail.
[ Tests ]
None; the code is trivial.
[ Risks ]
No risk, this is trivial.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
I have another set of uploads for musescore2 and musescore3 fixing
crash bugs coming up (not uploading them today, I want upstream to
have a go at reviewing the change first). How should this be handled?
Should I first wait until the current set of packages is unblocked
and has migrated to testing? Otherwise, if I upload now musescore2
would get AUTORM’d which is suboptimal. Waiting so long will however
delay availability of the fix even to sid users.
unblock musescore2/2.3.2+dfsg4-14
unblock musescore3/3.2.3+dfsg2-10
unblock musescore-general-soundfont/0.2-3
unblock timgm6mb-soundfont/1.3-5
diff -Nru musescore-general-soundfont-0.2/debian/changelog
musescore-general-soundfont-0.2/debian/changelog
--- musescore-general-soundfont-0.2/debian/changelog2020-07-12
17:02:25.0 +0200
+++ musescore-general-soundfont-0.2/debian/changelog2021-03-12
20:58:58.0 +0100
@@ -1,3 +1,12 @@
+musescore-general-soundfont (0.2-3) unstable; urgency=medium
+
+ * Bump Policy (no relevant changes)
+ * Avoid rare error in prerm (Closes: #984592)
+ * Update from maintainer script template
+ * Do latest lintian tag rename churn
+
+ -- Thorsten Glaser Fri, 12 Mar 2021 20:58:58 +0100
+
musescore-general-soundfont (0.2-2) unstable; urgency=high
* Merge musescore-general-soundfont-small (0.2-2) changes
diff -Nru musescore-general-soundfont-0.2/debian/control
musescore-general-soundfont-0.2/debian/control
--- musescore-general-soundfont-0.2/debian/control 2020-05-28
23:19:04.0 +0200
+++ musescore-general-soundfont-0.2/debian/control 2021-03-12
20:34:13.0 +0100
@@ -5,7 +5,7 @@
Homepage: https://musescore.org/en/node/269869
Build-Depends: debhelper-compat (= 13),
python3-minimal, sf3convert
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
Rules-Requires-Root: no
VCS-git: https://evolvis.org/anonscm/git/alioth/soundfonts.git -b
musescore-general-soundfont
VCS-Browser:
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/soundfonts.git;a=shortlog;h=refs/heads/musescore-general-soundfont
diff -Nru
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.postinst
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.postinst
---
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.postinst
2020-05-28 23:00:17.0 +0200
+++
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.postinst
2021-03-12 20:45:47.0 +0100
@@ -21,9 +21,12 @@
#
# * postinst "triggered" "${triggers[*]}"
# For trigger-only calls, i.e. if "configure" is not called.
+#
+# * new-postinst "reconfigure" [$most_recently_configured_version](?)
+# Treat this as just like "configure" for a future extension by debconf.
case $1 in
-configure)
+(configure|reconfigure)
# need the directories existing before update-alternatives
mkdir -p /usr/share/sounds/sf2 /usr/share/sounds/sf3
# see #929185 for the history behind this
@@ -39,13 +42,13 @@
/usr/share/sounds/sf2/MuseScore_General_Full.sf2 55
;;
-abort-upgrade|abort-remove|abort-deconfigure)
+(abort-upgrade|abort-remove|abort-deconfigure)
;;
-triggered)
+(triggered)
;;
-*)
+(*)
echo >&2 "E: postinst called with unknown subcommand '$1'"
exit 1
;;
diff -Nru
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.prerm
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.prerm
---
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.prerm
2020-05-28 23:00:17.0 +0200
+++
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.prerm
2021-03-12 20:46:28.0 +0100
@@ -19,7 +19,7 @@
# other constraints the sam
Bug#982669: buster-pu: package portaudio19/19.6.0-1
Dixi quod… >built. Without the crash fix backporting polyphone makes >no sense I must correct myself here: polyphone is usable without it *if* the user manually starts jackd first. (It will still crash upon terminating, but that’s after saving all data. I’m documenting this.) >[ Tests ] >No automated tests but without it applied, polyphone >crashes after a bit, maybe a minute or two, of using. I’m uploading the backport so this can be tested more easily. To test, start Polyphone, open a soundfont and click around a bit (maybe try to play back one of the samples). Soundfonts in Debian are installed under /usr/share/sounds/sf2/ and timgm6mb-soundfont is the smallest package with one to test with. bye, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"...
Bug#982669: buster-pu: package portaudio19/19.6.0-1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@mirbsd.de
I would like to upload the contents of portaudio19 19.6.0-1.1
to buster.
[ Reason ]
The current library makes applications crash. Please see
Debian #944509 for the bugreport, but this is also seen
e.g. when testing a polyphone backport which I’ve just
built. Without the crash fix backporting polyphone makes
no sense, and since it is a rather important fix entering
via stable-updates seems sensible (instead of via bpo).
[ Impact ]
Applications using portaudio randomly crash.
[ Tests ]
No automated tests but without it applied, polyphone
crashes after a bit, maybe a minute or two, of using.
[ Risks ]
The patch is rather small and “obvious enough”, so I
consider this zero risk. It has been tested in unstable
and testing for 7 months now.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
Apply a patch from the upstream mailing list to fix the crash.
[ Other info ]
The resulting package is, except for the changelog difference
and being recompiled in buster, identical to the one in
bullseye/sid.
diff -Nru portaudio19-19.6.0/debian/changelog
portaudio19-19.6.0/debian/changelog
--- portaudio19-19.6.0/debian/changelog 2016-12-25 22:08:34.0 +0100
+++ portaudio19-19.6.0/debian/changelog 2021-02-13 07:42:27.0 +0100
@@ -1,3 +1,9 @@
+portaudio19 (19.6.0-1+deb10u1) buster; urgency=medium
+
+ * Apply crash fix patch (Closes: #944509)
+
+ -- Thorsten Glaser Sat, 13 Feb 2021 07:42:27 +0100
+
portaudio19 (19.6.0-1) unstable; urgency=medium
* New upstream release v190600_20161030
diff -Nru portaudio19-19.6.0/debian/patches/944509-crash.patch
portaudio19-19.6.0/debian/patches/944509-crash.patch
--- portaudio19-19.6.0/debian/patches/944509-crash.patch1970-01-01
01:00:00.0 +0100
+++ portaudio19-19.6.0/debian/patches/944509-crash.patch2020-07-30
16:26:55.0 +0200
@@ -0,0 +1,59 @@
+Description: handle EPIPE from alsa_snd_pcm_poll_descriptors
+ was: pa_linux_alsa.c:3636 Assertion failed
+Origin: https://lists.columbia.edu/pipermail/portaudio/2019-July/001888.html
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944509
+Forwarded: not-needed
+Justification: taken from upstream dev mailing list post
+Author: Sam Mason
+Reviewed-by: Norbert Preining
+Applied-Upstream: no
+
+--- a/src/hostapi/alsa/pa_linux_alsa.c
b/src/hostapi/alsa/pa_linux_alsa.c
+@@ -3633,12 +3633,18 @@ error:
+
+ /** Fill in pollfd objects.
+ */
+-static PaError PaAlsaStreamComponent_BeginPolling( PaAlsaStreamComponent*
self, struct pollfd* pfds )
++static PaError PaAlsaStreamComponent_BeginPolling( PaAlsaStreamComponent*
self, struct pollfd* pfds, int *xrunOccurred )
+ {
+ PaError result = paNoError;
+ int ret = alsa_snd_pcm_poll_descriptors( self->pcm, pfds, self->nfds );
+-(void)ret; /* Prevent unused variable warning if asserts are turned off
*/
+-assert( ret == self->nfds );
++if( -EPIPE == ret )
++{
++ *xrunOccurred = 1;
++}
++else
++{
++ assert( ret == self->nfds );
++}
+
+ self->ready = 0;
+
+@@ -3799,17 +3805,22 @@ static PaError PaAlsaStream_WaitForFrame
+ if( pollCapture )
+ {
+ capturePfds = self->pfds;
+-PA_ENSURE( PaAlsaStreamComponent_BeginPolling( >capture,
capturePfds ) );
++PA_ENSURE( PaAlsaStreamComponent_BeginPolling( >capture,
capturePfds, ) );
+ totalFds += self->capture.nfds;
+ }
+ if( pollPlayback )
+ {
+ /* self->pfds is in effect an array of fds; if necessary, index
past the capture fds */
+ playbackPfds = self->pfds + (pollCapture ? self->capture.nfds :
0);
+-PA_ENSURE( PaAlsaStreamComponent_BeginPolling( >playback,
playbackPfds ) );
++PA_ENSURE( PaAlsaStreamComponent_BeginPolling( >playback,
playbackPfds, ) );
+ totalFds += self->playback.nfds;
+ }
+
++if ( xrun )
++{
++ break;
++}
++
+ #ifdef PTHREAD_CANCELED
+ if( self->callbackMode )
+ {
diff -Nru portaudio19-19.6.0/debian/patches/series
portaudio19-19.6.0/debian/patches/series
--- portaudio19-19.6.0/debian/patches/series2016-12-25 21:37:53.0
+0100
+++ portaudio19-19.6.0/debian/patches/series2021-02-13 07:42:08.0
+0100
@@ -1 +1,2 @@
audacity-portmixer.patch
+944509-crash.patch
Re: OpenJDK 17 for bullseye-backports
On Sat, 6 Feb 2021, Emmanuel Bourg wrote:
> If openjdk-17 can't be shipped in bullseyes even with prominent warnings
> that it's unsupported
Users will probably ignore that and use it anyway. It would have been
good if it could be included and kept up to date, but that’s doubling
of efforts, not worth the hassle, plus it would mean people would ex‐
pect Java packages shipped with bullseye to work with 17, which isn’t
the case (plus shipping only one makes it easier/clearer).
>, then this sounds like a good idea.
FWIW there is some discussion around this near
https://lists.debian.org/debian-java/2020/11/threads.html#00025
and we sincerely hope that a one-time copying of the binary packages
from sid to bullseye-backports, followed by either binNMUing or a
regular upload, can be done.
The situation is currently like this:
$ rmadison openjdk-1{1,2,3,4,5,6,7,8}
openjdk-11 | 11.0.4+11-1~bpo9+1 | stretch-backports | source
openjdk-11 | 11.0.4+11-1~deb10u1 | stable| source
openjdk-11 | 11.0.4+11-1 | unstable | source
openjdk-11 | 11.0.6+10-1~bpo9+1 | stretch-backports | source
openjdk-11 | 11.0.9.1+1-1~deb10u2 | stable| source
openjdk-11 | 11.0.10+9-1 | testing | source
openjdk-11 | 11.0.10+9-1 | unstable | source
openjdk-15 | 15.0.2+7-1 | unstable | source
openjdk-16 | 16~34-1 | testing | source
openjdk-16 | 16~35-1 | buildd-unstable | source
openjdk-16 | 16~35-1 | unstable | source
openjdk-17 | 17~7-1 | testing | source
openjdk-17 | 17~8-1 | buildd-unstable | source
openjdk-17 | 17~8-1 | unstable | source
The idea here is to drop all but openjdk-11 from testing (→ bullseye)
while waiting for the official release of 17 in sid and backporting
that one it has migrated to testing/bookworm.
Adrian’s suggestion to use bpo version numbers in sid for this…
>>Slightly less bending of the rules and only marginally more effort would
>>be to build ~bpo11+1 binaries for all bullseye release architectures
>>in unstable before the release of bullseye.
… sounds interesting, this keeps users’ expectations for backports
and is easily fixed in sid by uploading, once the copying is done.
(And, if needed, doing a ~bpo11+1b1 or ~bpo11+2 in backports.)
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
*
Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.
Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.
*
Bug#976811: transition: php8.0
block 976811 by 980567 thanks On Sat, 12 Dec 2020, Ondřej Surý wrote: > And let me restate that it’s not my intent to make anyone’s life hell and > I am willing to help with any package (as usual). I am just trying to do > the most sane thing to do security and maintainer wise. You probably should have communicated this with maintainers of PHP packages. I was taken completely by surprise (via #980567) that PHP 8 is even available in Debian now, and back when I asked you to provide a release candidate via experimental, so that we could test software with it before the release, some months ago, you denied that, so colour me surprised to get a bugreport from it now. As things are, I won’t upgrade php-react-promise now. If I find the time I may backport the two commits mentioned to fix the one issue reported, but… it’s already tight. (Upgrading is completely out of the picture, as this involves multiple packages, and there is a dependency chain reaching as far as composer. By the way, if the composer maintainers with to take over the reactphp packages, that could be arranged.) I also had to actively search for this, wondering which PHP version we’d be having with bullseye then… and this was not obvious to find. bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general
Bug#975874: buster-pu: package openjdk-11/11.0.9.1+1-1~deb10u1
On Thu, 3 Dec 2020, tony mancill wrote: > Given that the JVM bug can affect any application seems to tilt the > scale towards proceeding with the JDK update, so the release of an > upgrade path for Jenkins is a relief. How about versioning it differently? Make it 11.0.9-2 for a while? Convince upstream to re-release it as 11.0.10 and stop using so many periods in a version number (IMHO one is enough and two is already questionable)? 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 * Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in Form von Beratung, Trainings sowie Workshops in den Bereichen Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung sowie Agile Organisation. Besuchen Sie uns auf https://www.tarent.de/consulting . Wir freuen uns auf Ihren Kontakt. *
Re: Bug#975016: OpenJDK 15 support state for Bullseye
On Wed, 18 Nov 2020, Matthias Klose wrote: > On 11/18/20 8:03 PM, Adrian Bunk wrote: > > New OpenJDK versions tend to cause both buildtime and runtime breakages > > in reverse dependencies, some of them hard to resolve and requiring > > updates to new upstream versions which in turn require new dependencies > > that might not even be in Debian. > > New upstream versions likely do that, that's not an attribute of OpenJDK. Which is why new upstream versions _generally_ don’t end up in stable. > What's your point? I think the point is about packages with the JDK in Build-Depends. The JDK has two use cases, one is people using it as JRE or JDK to independently develop software, the other is using it in B-D to build Debian packages (usually via default-jdk-headless). Making 17 available as the latter is certainly a no-go. Maybe that was what Adrian’s point was. I think your point is about making it available as the former, and so that people can test their things with it already, and to allow backporting packages that actually do need it. I think that is a good thing but perhaps bullseye-backports is indeed the better place for it (especially if the copying of binary packages into the suite to bootstrap is possible). I think nobody wants to switch default-jdk to 17 or even not ship 11 at all any more or stop supporting it during bullseye’s lifetime. Maybe that also was too implicit? 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 * Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in Form von Beratung, Trainings sowie Workshops in den Bereichen Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung sowie Agile Organisation. Besuchen Sie uns auf https://www.tarent.de/consulting . Wir freuen uns auf Ihren Kontakt. *
Bug#968503: nmu: mutter, muffin on 32-bit architectures (and gtk+3.0 on m68k)
Simon McVittie dixit: >To -ports people (cc'd): for the -ports architectures, mutter and >muffin should be rebuilt as above on all the 32-bit ports, with the >same dep-wait. Additionally, some differences in build order mean that >gtk+3.0 needs a rebuild on m68k (but not on release architectures or >other 32-bit ports). I’ll schedule this for x32 and m68k (don’t have rights for the others). Thanks, //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
Bug#953735: nmu: unscd_0.53-1+b2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu unscd_0.53-1+b2 . ANY . unstable . -m "Rebuild against glibc 2.30" As usual with new glibc major versions, please binNMU unscd quickly, not having it prevents the installation of the new libc. An extra versioned B-D, so that architectures where glibc 2.30 FTBFS (ia64, kfreebsd-amd64, kfreebsd-i386, sparc64) wait with the binNMU until it’s fixed, would be appreciated. -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init)
Bug#951769: buster-pu: package sssd/1.16.3-3.1
Hi Adam, >+sssd (1.16.3-3.2) buster; urgency=medium > >1.16.3-3.1+deb10u1 would be more conventional, please. Yes, indeed (although there has been precedence for this, considering the version numbers are only so they don’t confluct with later uploads in $distro+1). I admit I had not consciously done that, though. >With that note, please go ahead. OK, will do that later once my “meeting marathon” at $dayjob finished. Do you prefer the binaries I built earlier and which Nik is testing, or should I rebuild with changed version? 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
Bug#951769: buster-pu: package sssd/1.16.3-3.1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi,
we’d like to fix #946847 in buster (which is where we found it in
production and tested a fix locally, which was later discovered to
be identical to a recent upstream fix) because it’s a denial of
service kind of bug (bad network causes sssd to hang causes no
logins and lots of other stuff not working on the machine).
I’ve built a proposed update for stable in stable, and Dominik will
test the precise build on a stable machine. I uploaded the same fix
to unstable, and the next upstream releases will also contain it.
I’m attaching the debdiff.
Please advice how to proceed.
-- System Information:
Debian Release: bullseye/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'),
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64
Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
diff -u sssd-1.16.3/debian/changelog sssd-1.16.3/debian/changelog
--- sssd-1.16.3/debian/changelog
+++ sssd-1.16.3/debian/changelog
@@ -1,3 +1,11 @@
+sssd (1.16.3-3.2) buster; urgency=medium
+
+ * Non-maintainer upload with maintainer permission.
+ * Fix sssd_be busy-looping when LDAP connection flickers.
+(Closes: #946847)
+
+ -- Thorsten Glaser Fri, 21 Feb 2020 14:31:19 +0100
+
sssd (1.16.3-3.1) unstable; urgency=high
* Non-maintainer upload.
diff -u sssd-1.16.3/debian/patches/series sssd-1.16.3/debian/patches/series
--- sssd-1.16.3/debian/patches/series
+++ sssd-1.16.3/debian/patches/series
@@ -3,0 +4 @@
+fix-946847.diff
only in patch2:
unchanged:
--- sssd-1.16.3.orig/debian/patches/fix-946847.diff
+++ sssd-1.16.3/debian/patches/fix-946847.diff
@@ -0,0 +1,36 @@
+Description: fix busy loop caused by watchdog SIGTERM not processed
+Origin: https://pagure.io/SSSD/sssd/c/2c13d8b
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946847
+Bug: https://pagure.io/SSSD/sssd/issue/4132
+Bug: https://pagure.io/SSSD/sssd/issue/4089
+Forwarded: not-needed
+Author: Alexey Tikhonov
+Reviewed-by: Sumit Bose
+Reviewed-by: mirabilos
+Applied-Upstream: 2.2.4, commit:2c13d8b
+Applied-Upstream: 1.16.5, commit:0c62066
+
+--- a/src/util/util_watchdog.c
b/src/util/util_watchdog.c
+@@ -54,9 +54,8 @@ static void watchdog_detect_timeshift(vo
+ if (write(watchdog_ctx.pipefd[1], "1", 1) != 1) {
+ if (getpid() == getpgrp()) {
+ kill(-getpgrp(), SIGTERM);
+-} else {
+-_exit(1);
+ }
++_exit(1);
+ }
+ }
+ }
+@@ -75,9 +74,8 @@ static void watchdog_handler(int sig)
+ if (__sync_add_and_fetch(_ctx.ticks, 1) > WATCHDOG_MAX_TICKS) {
+ if (getpid() == getpgrp()) {
+ kill(-getpgrp(), SIGTERM);
+-} else {
+-_exit(1);
+ }
++_exit(1);
+ }
+ }
+
Bug#931358: release.debian.org: buster-pu (pre-approval): musescore/2.3.2+dfsg2-7? -7~deb10+1?
Adam D. Barratt dixit: >Please go ahead; sorry for the delay. Done, thanks! bye, //mirabilos -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Bug#931358: release.debian.org: buster-pu (pre-approval): musescore/2.3.2+dfsg2-7~deb10u1
Hi again, sorry for bothering, but… … in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931040#10 it was indicated this should go into the first point release, and https://lists.debian.org/debian-devel-announce/2019/07/msg2.html indicates that that will be done in little more than a weel, so… >On Wed, 2019-07-03 at 06:43 +0100, Adam D. Barratt wrote: > >> and target would indeed be "buster". Please attach a debdiff of the >> proposed upload to this report (but do not upload it at this stage). > >Is it OK to upload now? TIA, //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
Bug#931358: release.debian.org: buster-pu (pre-approval): musescore/2.3.2+dfsg2-7~deb10u1
On Wed, 2019-07-03 at 06:43 +0100, Adam D. Barratt wrote: > and target would indeed be "buster". Please attach a debdiff of the > proposed upload to this report (but do not upload it at this stage). Is it OK to upload now? Thanks, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#931358: release.debian.org: buster-pu (pre-approval): musescore/2.3.2+dfsg2-7? -7~deb10+1?
retitle 931358 buster-pu (pre-approval): musescore/2.3.2+dfsg2-7~deb10u1
thanks
Hi again,
now, with sensible amounts of coffee input, the debdiff as
prepared in git and of an actual .dsc/.changes ready for
uploading, attached.
Thanks,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)diff -Nru musescore-2.3.2+dfsg2/debian/changelog
musescore-2.3.2+dfsg2/debian/changelog
--- musescore-2.3.2+dfsg2/debian/changelog 2019-04-19 21:02:11.0
+0200
+++ musescore-2.3.2+dfsg2/debian/changelog 2019-07-03 14:22:57.0
+0200
@@ -1,3 +1,15 @@
+musescore (2.3.2+dfsg2-7~deb10u1) buster; urgency=high
+
+ * Rebuild 2.3.2+dfsg2-7 for buster-updates (cf. #931040)
+
+ -- Thorsten Glaser Wed, 03 Jul 2019 14:22:57 +0200
+
+musescore (2.3.2+dfsg2-7) unstable; urgency=high
+
+ * Disable webkit functionality (Closes: #931021)
+
+ -- Thorsten Glaser Mon, 24 Jun 2019 18:07:46 +0200
+
musescore (2.3.2+dfsg2-6) unstable; urgency=medium
* Workaround for DEP 5 syntax in a complex case
diff -Nru musescore-2.3.2+dfsg2/debian/control
musescore-2.3.2+dfsg2/debian/control
--- musescore-2.3.2+dfsg2/debian/control2019-04-18 15:56:57.0
+0200
+++ musescore-2.3.2+dfsg2/debian/control2019-07-03 14:22:23.0
+0200
@@ -28,7 +28,6 @@
libpulse-dev,
libqt5opengl5-dev,
libqt5svg5-dev,
- libqt5webkit5-dev,
libqt5xmlpatterns5-dev,
libsndfile1-dev (>= 1.0.25),
portaudio19-dev,
diff -Nru musescore-2.3.2+dfsg2/debian/rules musescore-2.3.2+dfsg2/debian/rules
--- musescore-2.3.2+dfsg2/debian/rules 2019-04-18 14:35:38.0 +0200
+++ musescore-2.3.2+dfsg2/debian/rules 2019-07-03 14:22:23.0 +0200
@@ -37,6 +37,9 @@
CMAKE_DEFS+= -DBUILD_PORTMIDI=OFF
endif
+# disable phoning home
+CMAKE_DEFS+= -DBUILD_WEBKIT=OFF
+
override_dh_auto_configure:
dh_auto_configure -- ${CMAKE_DEFS}
Bug#931358: release.debian.org: buster-pu (pre-approval): musescore/2.3.2+dfsg2-7? -7~deb10+1?
Hi, >> It would need to be a new upload, indeed. The version seems sensible, >> and target would indeed be "buster". Please attach a debdiff of the >> proposed upload to this report (but do not upload it at this stage). thanks, will do. >Actually, as Salvatore pointed out on IRC, that should be -7~deb10u1, >to follow the usual convention. I should not try and be useful pre- >coffee... Oh, indeed... same about coffee here ;) and I'm doing lots of backports and few stable updates. 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
Bug#931358: release.debian.org: buster-pu (pre-approval): musescore/2.3.2+dfsg2-7? -7~deb10+1?
Package: release.debian.org Severity: normal In #931040 I was indicated to postpone the fix for #931021 to past the initial buster release, so it can get some more testing in unstable in the meantime. (That being said I hope to get MuseScore 3.x into unstable as opposed to experimental rather quickly as well… which incidentally had the web part disabled already, since 3.x uses a library not portable to all arches…) I’d like to get the same change I posted to #931040 (which is rather tiny) into buster, somehow; I assume I’d have to upload with “buster” in the first line of the changelog; versioning is the question (I would suggest 2.3.2+dfsg2-7~deb10+1) if you cannot simply migrate the -7 package from sid to buster-p-u. Please indicate how we can go forward (but take your time to cut the release first, it’ll rock). Thanks in advance! -- System Information: Debian Release: 10.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init)
Bug#931040: unblock: musescore/2.3.2+dfsg2-7
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package musescore
I’ve found out, from Sunday’s dev chat discussion, that MuseScore
connects to upstream’s webserver on startup (#931021), and we
generally don’t like applications to phone home without explicit
permission.
I’ve tested this with systrace and verified both the fix and the
affected versions. Please unblock if you agree this is RC.
(including a git diff, but I confirmed it’s identical to debdiff)
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+musescore (2.3.2+dfsg2-7) unstable; urgency=high
+
+ * Disable webkit functionality (Closes: #931021)
+
+ -- Thorsten Glaser Mon, 24 Jun 2019 18:07:46 +0200
+
musescore (2.3.2+dfsg2-6) unstable; urgency=medium
* Workaround for DEP 5 syntax in a complex case
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,6 @@ Build-Depends: cmake,
libpulse-dev,
libqt5opengl5-dev,
libqt5svg5-dev,
- libqt5webkit5-dev,
libqt5xmlpatterns5-dev,
libsndfile1-dev (>= 1.0.25),
portaudio19-dev,
--- a/debian/rules
+++ b/debian/rules
@@ -37,6 +37,9 @@ ifneq (linux,${DEB_HOST_ARCH_OS})
CMAKE_DEFS+= -DBUILD_PORTMIDI=OFF
endif
+# disable phoning home
+CMAKE_DEFS+= -DBUILD_WEBKIT=OFF
+
override_dh_auto_configure:
dh_auto_configure -- ${CMAKE_DEFS}
unblock musescore/2.3.2+dfsg2-7
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
Bug#928185: Bug#926009: openjdk-11 breaks libreoffice autopkgtests
On Tue, 2 Apr 2019, Rene Engelhard wrote: > We as distros can patch it for LibreOffice, but this change breaks > LibreOffice out there unless > patched, and I doubt they will (or will be happy) to add extra stanzas for > "Debian", "Ubuntu" or > whatever else. > > I really believe this should be reverted. Yes, this is really weird, and… > > On Mon, 1 Apr 2019, Matthias Klose wrote: > > > > IMHO correctly so, some of the changes are so far away from the > > > > freeze policy.. > > > > > > pointy comments won't help, because you will see these changes at least > > > in the > > > first buster security update, so maybe some backports for libreoffice are … I fail to see how this qualifies for a security update. Perhaps you’ll wish to revert this change when building for anything older than bullseye/sid. Sometimes, lies need to be introduced when backporting (for either stable-security or bpo) to keep the stability guarantee. 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 ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Bug#927296: unblock: musescore/2.3.2+dfsg2-5
> I’ve also found another wrong copyright year, while reviewing the
I found some more. For ease of review, the complete diff follows,
and I’ll upload (the -6) when I get the ACK. The diff, while still
trivial, is now a bit longer because it adds the CC-BY 3.0 legal
code, the need for which was apparently discovered in the experimental
branch only, but also applies to master:
diff --git a/debian/changelog b/debian/changelog
index 457793dd..69f1fb82 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,27 @@
+musescore (2.3.2+dfsg2-6) UNRELEASED; urgency=medium
+
+ * Workaround for DEP 5 syntax in a complex case
+ * Fix share/plugins/notenames.qml and general copyright years
+ * Correct copyright info for the demos
+
+ -- Thorsten Glaser Thu, 18 Apr 2019 14:01:18 +0200
+
+musescore (2.3.2+dfsg2-5) unstable; urgency=medium
+
+ * debian/patches/experiments/new-manpage.diff:
+- mark as applied upstream
+- synchronise with the actually applied patch: fixes a wrong
+ document save directory (missing XDG_DOCUMENTS_DIR)
+ * debian/copyright: incorporate fixes from Debian ftptrainees:
+- aeolus/global.h: also © Hans Fugal
+- effects/freeverb/freeverb.{cpp,h} is a bit more complicated:
+ they were originally PD “Written by Jezar at Dreampoint”,
+ but modified by Werner who, as EU citizen, cannot relinquish
+ copyright, so they are, effectively, published under the same
+ terms as the rest of MuseScore (GPLv2); document that
+
+ -- Thorsten Glaser Tue, 16 Apr 2019 15:34:28 +0200
+
musescore (2.3.2+dfsg2-4) unstable; urgency=low
* Mark some patches as applied upstream
diff --git a/debian/copyright b/debian/copyright
index 776215b5..da1e90d9 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -2,7 +2,7 @@ Format:
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: MuseScore
Upstream-Contact: https://musescore.org/
Source: https://github.com/musescore/MuseScore/
-Copyright: 2018, Werner Schweer and others
+Copyright: 2002-2018, Werner Schweer and others
License: GPL-2 with Font exception (MuseScore)
Files-Excluded: *.pdf
share/sound
@@ -52,7 +52,6 @@ Files: aeolus/addsynth.cpp
aeolus/division.cpp
aeolus/division.h
aeolus/exp2ap.cpp
- aeolus/global.h
aeolus/messages.h
aeolus/model.cpp
aeolus/model.h
@@ -69,6 +68,11 @@ Files: aeolus/addsynth.cpp
Copyright: 2003-2010, Fons Adriaensen
License: GPL-2+
+Files: aeolus/global.h
+Copyright: 2003-2010, Fons Adriaensen
+ 2008, Hans Fugal
+License: GPL-2+
+
Files: awl/fastlog.h
Copyright: Laurent de Soras
License: WTFPL-2
@@ -90,6 +94,24 @@ Files: build/travis/job_macos/extract-qt-installer
Copyright: QT-CI Project <https://github.com/benlau/qtci>
License: Apache-2.0
+Files: demos/All_Dudes.mscz
+ demos/Triumph.mscz
+Copyright: 2011, Outside Shore Music
+License: GPL-2
+
+Files: demos/Reunion.mscz
+Copyright: 2012, Marc Sabatella
+License: CC-BY-3.0
+
+Files: effects/freeverb/freeverb.cpp
+ effects/freeverb/freeverb.h
+Copyright: 2009, Werner Schweer
+License: Freeverb-PD and GPL-2 with Font exception (MuseScore)
+
+License: Freeverb-PD
+ Written by Jezar at Dreampoint, June 2000
+ “This code is public domain” (well, it originally was)
+
Files: fluid/chan.cpp
fluid/conv.cpp
fluid/conv.h
@@ -310,7 +332,7 @@ License: GPL-2
Files: share/plugins/notenames.qml
Copyright: 2012, Werner Schweer
- 2013-2014, Joachim Schmitz
+ 2013-2017, Joachim Schmitz
2014, Jörn Eichler
License: GPL-2
@@ -880,6 +902,324 @@ License: WTFPL-2
.
0. You just DO WHAT THE FUCK YOU WANT TO.
+License: CC-BY-3.0
+ Attribution 3.0 Unported
+ .
+ CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
+ LEGAL SERVICES. DISTRIBUTION OF THIS LICENSE DOES NOT CREATE AN
+ ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
+ INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
+ REGARDING THE INFORMATION PROVIDED, AND DISCLAIMS LIABILITY FOR
+ DAMAGES RESULTING FROM ITS USE.
+ .
+ License
+ .
+ THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE
+ COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY
+ COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS
+ AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.
+ .
+ BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE
+ TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY
+ BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS
+ CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND
+ CONDITIONS.
+ .
+ 1. Definitions
+ .
+ a. "Adaptation" means a work based upon the Work, or upon the Work and
+ other pre-existing works, such as a translatio
Bug#927296: unblock: musescore/2.3.2+dfsg2-5
On Wed, 17 Apr 2019, Thorsten Glaser wrote: > it should sit in sid for a bit longer, that’s no problem either. Oops, I apparently fsck’d up (but why this didn’t show up in lintian for -5 but does show up for the upload in the experimental branch I’m currently doing, I’ll never know) in DEP 5 syntax. I’ve also found another wrong copyright year, while reviewing the git diff between upstream versions for the newest 3.1beta version (also for experimental) and found it is also wrong in buster/sid, so: diff --git a/debian/changelog b/debian/changelog index d8e0e9d8..028febb2 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +musescore (2.3.2+dfsg2-6) UNRELEASED; urgency=medium + + * Workaround for DEP 5 syntax in a complex case + * Fix share/plugins/notenames.qml copyright years + + -- Thorsten Glaser Wed, 17 Apr 2019 23:30:09 +0200 + musescore (2.3.2+dfsg2-5) unstable; urgency=medium * debian/patches/experiments/new-manpage.diff: diff --git a/debian/copyright b/debian/copyright index c6f793d6..9103af9f 100644 --- a/debian/copyright +++ b/debian/copyright @@ -97,7 +97,9 @@ License: Apache-2.0 Files: effects/freeverb/freeverb.cpp effects/freeverb/freeverb.h Copyright: 2009, Werner Schweer -License: Public Domain (Freeverb) and GPL-2 with Font exception (MuseScore) +License: Freeverb-PD and GPL-2 with Font exception (MuseScore) + +License: Freeverb-PD Written by Jezar at Dreampoint, June 2000 “This code is public domain” (well, it originally was) @@ -321,7 +323,7 @@ License: GPL-2 Files: share/plugins/notenames.qml Copyright: 2012, Werner Schweer - 2013-2014, Joachim Schmitz + 2013-2017, Joachim Schmitz 2014, Jörn Eichler License: GPL-2 If you are agreeable to unblocking this, I’ll upload -6 quickly. Thanks, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"...
Bug#927296: unblock: musescore/2.3.2+dfsg2-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package musescore
This upload addresses two issues which, while minor, I would
appreciate having fixed before stable:
* The recent ftpmaster re-review in experimental found missing
authorship attributions in d/copyright which (inherited from
the previous maintainers) affect the version in testing/sid,
which I fixed there.
* The patch debian/patches/experiments/new-manpage.diff was
since accepted upstream, although upstream review has found
a mistake (XDG_DOCUMENTS_DIR was missing from the path in
which the user-generated documents are stored, potentially
misleading users, which is why I ask for inclusion); the
change also records the merging in the DEP 3 headers and
makes it otherwise identical to the version that was actually
merged upstream (copyright year/date changed to encompass
2019 as well; the “cd” to the directory in the script, which
is not called during the build (only for developers) and so
does not change anything) for consistence.
I have “sat” on these changes for a while though, until it became
clear that my current git hosting platform is not affected by the
dreaded “Article 13” and so I do not have to change VCS-* _again_
(otherwise I’d have included this here, too). I hope that’s okay.
This was uploaded yesterday, and I’ve tested it (on x32), but if
it should sit in sid for a bit longer, that’s no problem either.
Extra benefit: the packages are now rebuilt against latest Qt,
which had uploads recently. (Should not change anything, though.)
The full debdiff is really trivial and follows:
diff -Nru musescore-2.3.2+dfsg2/debian/changelog
musescore-2.3.2+dfsg2/debian/changelog
--- musescore-2.3.2+dfsg2/debian/changelog 2019-02-27 17:11:13.0
+0100
+++ musescore-2.3.2+dfsg2/debian/changelog 2019-04-16 15:34:28.0
+0200
@@ -1,3 +1,19 @@
+musescore (2.3.2+dfsg2-5) unstable; urgency=medium
+
+ * debian/patches/experiments/new-manpage.diff:
+- mark as applied upstream
+- synchronise with the actually applied patch: fixes a wrong
+ document save directory (missing XDG_DOCUMENTS_DIR)
+ * debian/copyright: incorporate fixes from Debian ftptrainees:
+- aeolus/global.h: also © Hans Fugal
+- effects/freeverb/freeverb.{cpp,h} is a bit more complicated:
+ they were originally PD “Written by Jezar at Dreampoint”,
+ but modified by Werner who, as EU citizen, cannot relinquish
+ copyright, so they are, effectively, published under the same
+ terms as the rest of MuseScore (GPLv2); document that
+
+ -- Thorsten Glaser Tue, 16 Apr 2019 15:34:28 +0200
+
musescore (2.3.2+dfsg2-4) unstable; urgency=low
* Mark some patches as applied upstream
diff -Nru musescore-2.3.2+dfsg2/debian/copyright
musescore-2.3.2+dfsg2/debian/copyright
--- musescore-2.3.2+dfsg2/debian/copyright 2019-02-27 17:11:13.0
+0100
+++ musescore-2.3.2+dfsg2/debian/copyright 2019-04-16 15:33:48.0
+0200
@@ -52,7 +52,6 @@
aeolus/division.cpp
aeolus/division.h
aeolus/exp2ap.cpp
- aeolus/global.h
aeolus/messages.h
aeolus/model.cpp
aeolus/model.h
@@ -69,6 +68,11 @@
Copyright: 2003-2010, Fons Adriaensen
License: GPL-2+
+Files: aeolus/global.h
+Copyright: 2003-2010, Fons Adriaensen
+ 2008, Hans Fugal
+License: GPL-2+
+
Files: awl/fastlog.h
Copyright: Laurent de Soras
License: WTFPL-2
@@ -90,6 +94,13 @@
Copyright: QT-CI Project <https://github.com/benlau/qtci>
License: Apache-2.0
+Files: effects/freeverb/freeverb.cpp
+ effects/freeverb/freeverb.h
+Copyright: 2009, Werner Schweer
+License: Public Domain (Freeverb) and GPL-2 with Font exception (MuseScore)
+ Written by Jezar at Dreampoint, June 2000
+ “This code is public domain” (well, it originally was)
+
Files: fluid/chan.cpp
fluid/conv.cpp
fluid/conv.h
diff -Nru musescore-2.3.2+dfsg2/debian/patches/experiments/new-manpage.diff
musescore-2.3.2+dfsg2/debian/patches/experiments/new-manpage.diff
--- musescore-2.3.2+dfsg2/debian/patches/experiments/new-manpage.diff
2019-02-27 17:11:13.0 +0100
+++ musescore-2.3.2+dfsg2/debian/patches/experiments/new-manpage.diff
2019-04-16 15:20:21.0 +0200
@@ -3,10 +3,11 @@
Author: mirabilos
Bug: https://musescore.org/en/node/277903
Forwarded: https://github.com/musescore/MuseScore/pull/4265
+Applied-Upstream: master, commit:e292cfb527
--- a/build/Linux+BSD/mscore.1.in
+++ b/build/Linux+BSD/mscore.1.in
-@@ -1,244 +1,505 @@
+@@ -1,244 +1,510 @@
-.\" Hey, EMACS: -*- nroff -*-
-.\" To preview the page formatting without installing use "man -l mscore.1"
-.\" First parameter, NAME, should be all caps
@@ -95,11 +96,11 @@
-@MAN_PORTABLE@.TP
-@MAN_PORTABLE@.B man, manual, manpage
+.\" New manual page for Muse
Re: Fixing Linux getrandom() in stable
Theodore Y. Ts'o dixit: >that problems helps most of our users, and we shouldn't let the >perfect be the enemy of the good. Agreed. Start small, then enhance one bootloader at a time. Or boot protocol, I assume. >Also note that the bootloader has depend on userspace to refresh the >seed entropy, both in early boot (in case the syscrashes), and at >shutdown (so the entropy captured while the system is running can be Definitely! >saved as seed entropy). And this is trickier in Linux because the >bootloader lives in a different source tree, and is maintained by >different people from the systemd and/or initscripts people, and for Yes, unfortunately. >that matter the bootloader doesn't know which distribution it is But in this case, the distribution can tell the bootloader the path to the file to load. >the *BSD's has its advantages. And this is where perhaps Debian as a >distribution can solve this problem by coordinating action across >multiple Debian packages.) Of course. >The *point* is that we can't really make a turn-key solution which >will work for everyone. For as much we have the desire for a >"Universal OS", something that works for all hardware, all users, and >all workloads, is probably just not attainable here. As Debian, we can try to come close, but, as you said, don’t let the perfect be the enemy of the good. Perhaps there are multiple somethings that, together (or having the local admin choose) can help more people than one simple solution, even if the latter may help a majority. (I’m a fan of minorities, in case you couldn’t tell. I run an x32 system, after all, and helped out m68k a bit…) >(It never was a complete solution, BTW; even before the patches to >address CVE-2018-1108, there were already hardware systems where you >couldn't count on the RNG being initialized in time and getrandom(2) Another question is what it means that the RNG is initialised. It all depends on what in the end boils down to guesswork, although I tip my hat because that RNG code of yours, both the Linux and the BSD version, are pretty impressive. But the point here is that, even if the RNG thinks it’s fully initialised, it may not be “good” yet, depending on circumstances. (Again, it should not stop us from trying.) 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: Fixing Linux getrandom() in stable
Adrian Bunk dixit: >As an example, what happens if I debootstrap and deploy the resulting >filesytem to a large number of identical embedded systems without >entropy sources? Just get into a habit of not doing so, for example by modifying the image during each writing process. Having the bootloader inject entropy into the kernel would of course help (something OpenBSD actually did, which I’d dreamt of only until). Reuse is only problematic then if the system actually booted, i.e. an early userspace thing reading and immediately writing to a file will stave off the remaining issues. >As far as I can see, any solution above would either give me boot hangs >or might result in nasty security issues due to the same (known) entropy >being fed to /dev/random on many machines. > >Similar problems for cases like live CDs and installers. And CPUs, and architectures, without usable boot entropy. For the “CD image” case, though, adding stuff like the MAC addresses of the onboard NICs and the current time would at least shuffle the existing (albeit known) entropy around enough for it to begin to differ. A web service for getting random bits sounds like an idea, until you get to the privacy implications of that (as well as reliability). But if it’s inhouse, it’s doable. >I wonder whether the current issue is just the tip of the iceberg, >and usage of /dev/urandom is a gazillion CVEs waiting to be reported. Did you see the fallback code for Linux in OpenBSD’s code for libbsd? It’s… like trying to find randomly-looking things on an 1990s Unix. This is best fixed in the kernel and earlier, plus an extra read/write in early userspace. Of course, embedding some entropy into the kernel image itself will make the reproducible-builds people entirely unhappy… (this one *is* implemented in MirBSD, complete with a tool to update it). >Due to the gdm bugs mentioned above we know that there are real-life >situations where gdm currently uses "random" data that might be >predictable. The question is which uses actually need entropy estimated good enough? >>b. Tolerate a longer wait for getrandom() to return > >I suspect there might be no guaranteed upper bound for the waiting time. On a discless system with no hardware sources (possibly no network) and no keyboard interaction? Infinite. Of course, if early userspace could reliably update a file, then the file’s content could be estimated as good enough and be credited to the RNG, at least for non-identical/readonly-/shared-media systems. >never block but might return predictable data in some cases. “What level of predictability?” >It would then be up to the application to decide whether predictable >data is acceptable, and what to do in entropy-starved situations. I guess most application authors have no answer for you here. It’s also no solution for the arc4random API… seems like a cultural clash (BSD expectations vs. what Linux can actually deliver). bye, //mirabilos -- “Having a smoking section in a restaurant is like having a peeing section in a swimming pool.” -- Edward Burr
Bug#860022: Bug#859935: Bug#860022: unblock: bsd-mailx/8.1.2-0.20160123cvs-3.1 (pre-approval)
On Fri, 14 Apr 2017, Robert Luberda wrote: > The patch looks OK. The addition of -D_GNU_SOURCE flag causes warnings > during compilation of files that already #define _GNU_SOURCE, but this > is easy to fix by using #define in main.c. Hm ok… as long as the definition is before *any* inclusion. But since you seem to have thrown away asprintf() calls, it’s no longer needed either. bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general
Bug#860025: unblock: bsdmainutils/9.0.12+nmu1 (pre-approval)
retitle 860025 unblock: bsdmainutils/9.0.12+nmu1 tags 860025 - moreinfo thanks Niels Thykier dixit: >Please go ahead and remove the moreinfo tag once the NMU has reached >unstable + have been built on all relevant architectures. According to https://buildd.debian.org/status/package.php?p=bsdmainutils it’s now Installed everywhere except hurd-i386 (Built) and powerpcspe (Needs-Build), which I believe qualifies ;-) Thanks! bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!
Bug#860022: unblock: bsd-mailx/8.1.2-0.20160123cvs-3.1 (pre-approval)
On Wed, 12 Apr 2017, Niels Thykier wrote: > If the maintainer agrees with you on it, I am happy to accept that patch > for stretch. OK, thanks. > Mind you, I am also open to reviewing his proposal of > adding those headers even with -a (letting -a override the > auto-generated ones when there is a conflict). OK. Robert, Niels, what do you think about the attached patch? Thanks, //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
Bug#860025: unblock: bsdmainutils/9.0.12+nmu1 (pre-approval)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I would like to request another pre-approval for a one-line fix to bsdmainutils to fix a bad patch. The Debian bug is #859933. In jessie (and on BSD), calling 'calendar' would output: root@evolvis:~ # calendar Apr 10 Commodore Matthew Calbraith Perry born, 1794 Apr 10 William Booth born, 1829, founder of the Salvation Army […] On stretch/sid, it looks thus: tglase@tglase:~ $ calendar Apr 10 Commodore Matthew Calbraith Perry born, 1794 Apr 10 William Booth born, 1829, founder of the Salvation Army […] The patch is trivial: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=859933;filename=bsdmainutils_9.0.12%2Bnmu0teckids1.debdiff;msg=5 (of course as 9.0.12+nmu1) -- System Information: Debian Release: 9.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 4.9.0-2-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 Init: sysvinit (via /sbin/init)
Bug#860022: unblock: bsd-mailx/8.1.2-0.20160123cvs-3.1 (pre-approval)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock I would like to request a pre-approval before uploading a fixed package. The bug in question is #859935 (bsd-mailx sends 8bit messages without MIME headers). I consider this release-critical as it’s a regression for the “mailx” command/interface: in jessie, one could just use U-A to select heirloom-mailx for mailx, which handled this correctly. I wish to ask for inclusion of this to stretch because bsd-mailx is now the only “mailx” provider, and this is relatively easy to fix. The patch is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=859935;filename=bsd-mailx_8.1.2-0.20160123cvs-3.0teckids1.debdiff;msg=5 (would of course be uploaded as -3.1) The impact of the patch is: If the user does not specify any additional header (with the ‘-a’ option), then and only then does it add MIME-Version, Content-Type (text/plain; charset=) and Content-Transfer-Encoding (8bit) headers. Otherwise, nothing is changed compared to before the patch. -- System Information: Debian Release: 9.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 4.9.0-2-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 Init: sysvinit (via /sbin/init)
Bug#859014: unblock: cvs/2:1.12.13+real-22
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package cvs
This package addresses the bug #858769 which was reported
as potentially security-relevant. Debdiff:
diff -u cvs-1.12.13+real/configure.in cvs-1.12.13+real/configure.in
--- cvs-1.12.13+real/configure.in
+++ cvs-1.12.13+real/configure.in
@@ -17,7 +17,7 @@
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.])
-AC_INIT([Concurrent Versions System (CVS)],[1.12.13-MirDebian-21],
+AC_INIT([Concurrent Versions System (CVS)],[1.12.13-MirDebian-22],
[bug-...@nongnu.org],[cvs])
AC_CONFIG_SRCDIR(src/cvs.h)
AC_CONFIG_AUX_DIR(build-aux)
diff -u cvs-1.12.13+real/debian/NEWS cvs-1.12.13+real/debian/NEWS
--- cvs-1.12.13+real/debian/NEWS
+++ cvs-1.12.13+real/debian/NEWS
@@ -1,3 +1,34 @@
+cvs (2:1.12.13+real-22) unstable; urgency=low
+
+ Newly created repositories (from “cvs init”) now rely on
+ CVSUMASK for the permissions of the “history” and “val-tags”
+ files instead of creating them as world-writable.
+
+ Newly created repositories contain a LogHistory configuration
+ setting to only record write operations in the “history” file.
+
+ If you are used to the previous behaviour, you can restore it
+ by altering (or removing, in which case the (commented-out)
+ default of logging everything will be used) the LogHistory
+ configuration setting and changing the permissions on the
+ “history” and “val-tags” files so that every user can write
+ into them.
+
+ If you did not deliberately open your repository to all users
+ on your system, you might wish to change all existing repos
+ to this behaviour. To do this, check out the CVSROOT module,
+ edit the “config” file adding “LogHistory=TMAR”, check that
+ change in, release the CVSROOT module, and chmod the “history”
+ and “val-tags” files to either 0664 (if all users in the same
+ group should be able to commit) or 0644 (if only you wish to
+ commit), possibly 0660 or 0600 is non-committers should also
+ be denied reading.
+
+ Contact me (mirabilos) in #cvs on irc.freenode.net if you have
+ any questions about this change or require further support.
+
+ -- Thorsten Glaser <t...@mirbsd.de> Tue, 28 Mar 2017 19:54:01 +0200
+
cvs (2:1.12.13+real-7) unstable; urgency=high
rcs2log no longer lives in the PATH, the contributed script
diff -u cvs-1.12.13+real/debian/changelog cvs-1.12.13+real/debian/changelog
--- cvs-1.12.13+real/debian/changelog
+++ cvs-1.12.13+real/debian/changelog
@@ -1,3 +1,14 @@
+cvs (2:1.12.13+real-22) unstable; urgency=low
+
+ * cvs init: Change default history logging configuration
+to only log write operations by adding “LogHistory=TMAR”
+ * Testsuite: Alter to cope with this explicit option
+ * cvs init: Rely on CVSUMASK for history and val-tags files
+in newly created repositories (Closes: #858769)
+ * Add a NEWS.Debian entry verbosely documenting this change
+
+ -- Thorsten Glaser <t...@mirbsd.de> Tue, 28 Mar 2017 20:01:39 +0200
+
cvs (2:1.12.13+real-21) unstable; urgency=medium
[ Sylvain Beucler ]
diff -u cvs-1.12.13+real/debian/copyright cvs-1.12.13+real/debian/copyright
--- cvs-1.12.13+real/debian/copyright
+++ cvs-1.12.13+real/debian/copyright
@@ -61,7 +61,7 @@
Parts and the packaging are covered by the following GPL-compatible licence:
-# Copyright © 2005, 2008, 2011
+# Copyright © 2005, 2008, 2011, 2017
# mirabilos <m...@mirbsd.org>
#
# Provided that these terms and disclaimer and all copyright notices
diff -u cvs-1.12.13+real/doc/cvs.texinfo cvs-1.12.13+real/doc/cvs.texinfo
--- cvs-1.12.13+real/doc/cvs.texinfo
+++ cvs-1.12.13+real/doc/cvs.texinfo
@@ -1989,6 +1989,18 @@
@code{cvs init} will enable history logging; if you
don't want that, remove the history file after running
@code{cvs init}. @xref{history file}.
+Since MirBSD CVS 1.12.13-MirOS-0AB7.8, MirPorts-19 or
+Debian cvs 2:1.12.13+real-22, only write operations
+will be logged by default; to change this, make the
+history file world-writable (but beware of the associated
+security risk) and remove the stock @samp{LogHistory}
+line in the @file{CVSROOT/config} file (@pxref{config})
+to use the (commented-out) default or put your own there.
+Note that these versions also create the @file{val-tags}
+file writable (@pxref{CVSUMASK}), not world-writable like
+prior versions, so users who wish to commit must, with a
+default @code{CVSUMASK} of 002, be in the same group as
+the repository.
@node Backing up
@section Backing up a repository
@@ -14901,7 +14913,9 @@
Default of @samp{TOEFWUPCGMAR} (or simply @samp{all}) will log
all transactions. Any subset of the default is
legal. (For example, to only log transactions that modify the
-@file{*,v} files, use @samp{LogHistory=TMAR}.) To disable history logging
+@file{*,v} files, use @samp{LogHistory=TMAR} which is nowadays
+set by @code{cvs init} by default.)
+
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, 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
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, 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
Bug#779997: unblock: (pre-approval) mksh/50d-4
retitle 779997 unblock: mksh/50d-5 tags 779997 - moreinfo thanks Axel Beckert dixit: I've just made a pbuilder build whose debdiff only differs from the debdiff posted here as follows, i.e. only in dates and version numbers: Thanks, this looks as expected. bye, //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-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1503151929540.26...@herc.mirbsd.org
Bug#779997: unblock: (pre-approval) mksh/50d-4
Niels Thykier dixit: I see the upload has happened, but the diff seems to be very unlike the one you included in the bug. A diffstat of what I see is: […] I.e. a patch is being dropped and no other changes. Your original debdiff suggested there ought to be changes to said patch instead. Indeed. Huh. This seems to be a mistake on the sponsor’s side, as this most certainly does not match what I asked them to pull from collab-maint/mksh.git and upload. I’ll retry; sorry. bye, //mirabilos -- [16:04:33] bkix: veni vidi violini [16:04:45] bkix: ich kam, sah und vergeigte... -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1503131422020.6...@herc.mirbsd.org
Bug#779997: unblock: (pre-approval) mksh/50d-4
tags 779997 - moreinfo thanks Niels Thykier dixit: Ack, seems reasonable. Please have it uploaded to unstable and remove the moreinfo tag once it is accepted. ok, done bye, //mirabilos -- This space for rent. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1503122135430.25...@herc.mirbsd.org
Bug#779997: unblock: (pre-approval) mksh/50d-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package mksh
With upstream hat, I found and fixed a security-relevant
(privacy related) bug in mksh and would kindly like to
request its inclusion into jessie.
The bug is: when HISTFILE has been set to a filename,
persistent history writing (logging of commands) is
enabled. Running “unset HISTFILE” is a no-op, instead
of, like with the other shells, disabling file logging
again. (Running “HISTFILE=” sort-of works, as it tries
to call open(2) with an empty string as argument, fails
and then leaves logging disabled.)
The fix is a straight backport of the upstream fix, in
two portions: the histrap.c part makes a NULL and empty
string argument ① do the same, and ② disable history
without relying on “open(, …)” to fail; the var.c
part calls the routine in the “unset” case. The other
patches (check.t and sh.h) adjust the shell version to
note that this is a vendor-patched version; it’s something
I (as upstream) request (though not absolutely require)
from distributions to do when they deviate from upstream
sources.
The full debdiff is attached. I plan to upload using a
sponsor (I have several at hand) if I get the approval,
but have no problem against an RT or Security Team member
uploading the package instead either. The package builds
cleanly in jessie and sid (i386 cowbuilder), passes its
testsuite and is lintian-clean.
The package is kept in collab-maint/mksh.git using the
“single-debian-patch” style packaging, which means that
debian/patches/debian-changes accumulates those patches.
Feel free to inspect the git repository for the actual
commit to the upstream sources instead. The package builds
without any non-standard helpers (e.g. gbp), by just invoking
dpkg-buildpackage after placing the .orig.tar.gz into
the parent directory.
unblock mksh/50d-4
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
diff -Nru mksh-50d/debian/changelog mksh-50d/debian/changelog
--- mksh-50d/debian/changelog 2014-10-23 11:20:27.0 +0200
+++ mksh-50d/debian/changelog 2015-03-07 22:17:11.0 +0100
@@ -1,3 +1,12 @@
+mksh (50d-4) unstable; urgency=medium
+
+ * QA upload.
+ * Backport upstream fix:
+- [tg] SECURITY: make unset HISTFILE actually work
+ * Adjust shell version accordingly
+
+ -- Thorsten Glaser t...@mirbsd.de Sat, 07 Mar 2015 22:16:53 +0100
+
mksh (50d-3) unstable; urgency=high
* QA upload.
diff -Nru mksh-50d/debian/patches/debian-changes mksh-50d/debian/patches/debian-changes
--- mksh-50d/debian/patches/debian-changes 2014-10-23 11:24:49.0 +0200
+++ mksh-50d/debian/patches/debian-changes 2015-03-07 22:19:12.0 +0100
@@ -18,7 +18,7 @@
expected-stdout:
- @(#)MIRBSD KSH R50 2014/10/07
-+ @(#)MIRBSD KSH R50 2014/10/19
++ @(#)MIRBSD KSH R50 2014/10/19 Debian-4
description:
Check version of shell.
stdin:
@@ -27,7 +27,7 @@
---
expected-stdout:
- @(#)LEGACY KSH R50 2014/10/07
-+ @(#)LEGACY KSH R50 2014/10/19
++ @(#)LEGACY KSH R50 2014/10/19 Debian-4
description:
Check version of legacy shell.
stdin:
@@ -531,6 +531,39 @@
/* set $# and $* */
if (setargs) {
wp += argi - 1;
+--- mksh-50d.orig/histrap.c
mksh-50d/histrap.c
+@@ -563,7 +563,7 @@ sethistfile(const char *name)
+ return;
+
+ /* if the name is the same as the name we have */
+- if (hname strcmp(hname, name) == 0)
++ if (hname name !strcmp(hname, name))
+ return;
+
+ /*
+@@ -581,7 +581,8 @@ sethistfile(const char *name)
+ hist_source-line = 0;
+ }
+
+- hist_init(hist_source);
++ if (name)
++ hist_init(hist_source);
+ }
+ #endif
+
+@@ -713,8 +714,10 @@ hist_init(Source *s)
+ hist_source = s;
+
+ #if HAVE_PERSISTENT_HISTORY
+- if ((hname = str_val(global(HISTFILE))) == NULL)
++ if (((hname = str_val(global(HISTFILE))) == NULL) || !*hname) {
++ hname = NULL;
+ return;
++ }
+ strdupx(hname, hname, APERM);
+ hs = hist_init_first;
+
--- mksh-50d.orig/main.c
+++ mksh-50d/main.c
@@ -34,7 +34,7 @@
@@ -561,7 +594,7 @@
+__RCSID($MirOS: src/bin/mksh/sh.h,v 1.701 2014/10/19 21:53:08 tg Exp $);
#endif
-#define MKSH_VERSION R50 2014/10/07
-+#define MKSH_VERSION R50 2014/10/19
++#define MKSH_VERSION R50 2014/10/19 Debian-4
/* arithmetic types: C implementation */
#if !HAVE_CAN_INTTYPES
@@ -585,3 +618,17 @@
#define X_EXTRA 20 /* this many extra bytes in X string */
+--- mksh-50d.orig/var.c
mksh-50d/var.c
+@@ -1351,6 +1351,11 @@ unsetspec(struct tbl *vp)
+ */
+
+ switch (special(vp-name)) {
++#if HAVE_PERSISTENT_HISTORY
++ case V_HISTFILE:
++ sethistfile(NULL);
++ return;
++#endif
+ case V_IFS:
+ setctypes(TC_IFSWS, C_IFS);
+ ifs0 = ' ';
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-release-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
Re: Issue in Bad regexp for ruby1.8-removal transition
On Mon, 2 Sep 2013, Jérémy Bobbio wrote: On the page described the transition to get rid of Ruby 1.8 [1], How is this supposed to work, anyway? • I don’t see either a bts entry or an explanation linked anywhere. • ruby1.9.1 Build-Depends ruby1.8 bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die! -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.10.1309051613280.12...@tglase.lan.tarent.de
Bug#708146: nmu: unscd_0.48-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu unscd_0.48-2 . ALL . -m Rebuild against eglibc major version 2.17 Hi, for FusionForge I’m using unscd instead of nscd, which makes much less trouble. It needs to be binNMU’d against every new eglibc major version. I’ve just done so with the version in sid locally and tested that it still works, to avoid repeating the problem from: https://bugs.launchpad.net/ubuntu/+source/unscd/+bug/958305 Right now, unscd is uninstallable, and a dist-upgrade would remove FusionForge from the system, which is kinda not what I want ;-) as I’m currently preparing it to work with PHP 5.5 (looks like actually no change needed). -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh-static -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130513142100.15643.35280.report...@tglase.lan.tarent.de
Re: tiff 4.x (libtiff5) transition
Jay Berkenbilt qjb at debian.org writes: hoping Jessie will ship with only one version of the tiff library: […] I'd obviously like to get on this as soon as possible, but I understand Agreed, but tiff depends on jpeg, and there are people who want to switch jpeg to “jpeg-turbo” (still being unclear whether it implements all jpeg functions or just these deemed “needed”) or, if not, jpeg might want a soname bump too. So it might make sense to wait for completion of that, or do them in one go (no idea what’s easier for Debian). You might want to talk to the jpeg maintainer for this. Just an outsider 2¢, //mirabilos -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130507t134844-...@post.gmane.org
Bug#705535: unblock: mediawiki/1:1.19.5-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package mediawiki
Please consider allowing the new security bugfix release of
mediawiki’s long-term support branch into wheezy. The upload
to sid also contains a documentation and a code change both
related to correcting the installation/setup process.
The Debian changes, except patch-context-linenumber changes,
are as follows:
--- debian/changelog(revision 430)
+++ debian/changelog(working copy)
@@ -1,3 +1,21 @@
+mediawiki (1:1.19.5-1) unstable; urgency=high
+
+ [ Platonides ]
+ * Update config URL in README.Debian (Closes: #703804)
+
+ [ Thorsten Glaser ]
+ * Re-add LocalSettings creation snippet for support of the
+mediawiki-extensions Debian packaging (Closes: #703852)
+ * New upstream security-only release:
+- (bug 47251) SECURITY: Disable external entities in Import
+- (bug 46859) SECURITY: Disable external entities in XMLReader
+- (bug 46084) SECURITY: Sanitize $limitReport before outputting
+- (bug 43594) Fix notices displayed on PHP 5.4
+- (bug 40585) Don't drop 'step=any' in HTML input fields.
+ * Refresh patches against new upstream code
+
+ -- Thorsten Glaser t...@mirbsd.de Tue, 16 Apr 2013 11:04:05 +0200
+
mediawiki (1:1.19.4-1) unstable; urgency=high
* Urgency high for security fix
--- debian/patches/debian_specific_config.patch (revision 0)
+++ debian/patches/debian_specific_config.patch (revision 434)
@@ -0,0 +1,18 @@
+$Id$
+
+Support mediawiki-extensions Debian packaging (see #703852).
+
+--- a/includes/installer/LocalSettingsGenerator.php
b/includes/installer/LocalSettingsGenerator.php
+@@ -333,6 +333,11 @@ if ( !defined( 'MEDIAWIKI' ) ) {
+ # Path to the GNU diff3 utility. Used for conflict resolution.
+ \$wgDiff3 = \{$this-values['wgDiff3']}\;
+
++# debian-specific include:
++if (is_file(\/etc/mediawiki-extensions/extensions.php\)) {
++ include(\/etc/mediawiki-extensions/extensions.php\);
++}
++
+ # Query string length limit for ResourceLoader. You should only set this if
+ # your web server has a query string length limit (then set it to that limit),
+ # or if you have suhosin.get.max_value_length set in php.ini (then set it to
--- debian/patches/series (revision 430)
+++ debian/patches/series (working copy)
@@ -6,3 +6,4 @@
bz29635.patch
bz40889.patch
bz39635.patch
+debian_specific_config.patch
--- debian/README.Debian(revision 430)
+++ debian/README.Debian(working copy)
@@ -14,14 +14,14 @@
Configuration:
The configuration uses an easy web-based system ; just go to this URL :
- http://www.myserver.org/mediawiki/config/index.php
+ http://www.myserver.org/mediawiki/mw-config/index.php
(replace by your own servername)
You may of course configure your webserver to serve this URL. A
default
configuration can be found in /etc/mediawiki/. Apache and cherokee
users
may have linked this in their configuration automatically if they
asked
the installer to do so.
Then just copy the generated config to the real system location :
- mv /var/lib/mediawiki/config/LocalSettings.php \
+ mv /var/lib/mediawiki/mw-config/LocalSettings.php \
/etc/mediawiki
You should change file permissions for LocalSettings.php as required to
prevent other users on the server from reading passwords and
The upstream changes are as follows:
--- mediawiki-1.19.4/RELEASE-NOTES-1.19 2013-03-04 19:11:51.0 +0100
+++ mediawiki-1.19.5/RELEASE-NOTES-1.19 2013-04-15 18:23:52.0 +0200
@@ -3,6 +3,17 @@
Security reminder: MediaWiki does not require PHP's register_globals
setting since version 1.2.0. If you have it on, turn it '''off''' if you can.
+== MediaWiki 1.19.5 ==
+
+This is a security and maintenance release of the MediaWiki 1.19 branch
+
+=== Changes since 1.19.4 ===
+* (bug 47251) SECURITY: Disable external entities in Import
+* (bug 46859) SECURITY: Disable external entities in XMLReader
+* (bug 46084) SECURITY: Sanitize $limitReport before outputting
+* (bug 43594) Fix notices displayed on PHP 5.4
+* (bug 40585) Don't drop 'step=any' in HTML input fields.
+
== MediaWiki 1.19.4 ==
This is a maintenance release of the MediaWiki 1.19 branch
--- mediawiki-1.19.4/includes/DefaultSettings.php 2013-03-04
19:11:51.0 +0100
+++ mediawiki-1.19.5/includes/DefaultSettings.php 2013-04-15
18:23:52.0 +0200
@@ -33,7 +33,7 @@ $wgConf = new SiteConfiguration;
/** @endcond */
/** MediaWiki version number */
-$wgVersion = '1.19.4';
+$wgVersion = '1.19.5';
/** Name of the site. It must be changed in LocalSettings.php */
$wgSitename = 'MediaWiki';
--- mediawiki-1.19.4/includes/GlobalFunctions.php 2013-03-04
19:11:51.0 +0100
+++ mediawiki-1.19.5/includes/GlobalFunctions.php 2013-04-15
18:23
Bug#702348: unblock: mksh/40.9.20120630-7
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package mksh
unblock mksh/40.9.20120630-7
(Thanks to Lisandro for his posting on Planet Debian!)
Dear Release Team,
please unblock mksh (40.9.20120630-7) for wheezy.
The debdiff between the two source packages (40.9.20120630-4 currently
in testing and 40.9.20120630-7 currently in sid) follows, except the
diff between the debian/patches/debian-changes file was replaced by an
interdiff between them for better legibility (see #689193 for the
reason), and I removed changes to the RCS IDs, i.e. lines only changing
the “$MirOS$” strings, and changes to the copyright years, to get it
more legible. Then, I sorted changes logically and let each block be
followed by the explanation for the change.
Please just ask back if you need any clarification. I am aware that
a Unix shell is complex code; I tried to select only patches to back‐
port for this that I really think the wheezy release will benefit from.
The upload will not change the shell language or behaviour, except
that $? in/after eval is now correct and that the ERR and EXIT traps
are run at all, once only, and in the correct order, and that set -e
aborts correctly when a function returned nonzero; all of these are
regressions against versions of mksh several years old and had been
introduced by earlier bugfixes, so the interface does not change.
--- mksh-40.9.20120630/debian/changelog 2012-10-13 14:57:14.0 +
+++ mksh-40.9.20120630/debian/changelog 2013-02-15 19:01:25.0 +
@@ -1,3 +1,34 @@
+mksh (40.9.20120630-7) unstable; urgency=low
+
+ * The “customer service” upload
+ * Correct the fix for LP#1104543 (Closes: #700526)
+ * Fix uninitialised memory access (Closes: #700604)
+
+ -- Thorsten Glaser t...@mirbsd.de Fri, 15 Feb 2013 19:00:40 +
+
+mksh (40.9.20120630-6) unstable; urgency=low
+
+ * Revert the fix for LP#1104543 as it causes Debian #700526
+(not closing as it’s not a proper fix)
+
+ -- Thorsten Glaser t...@mirbsd.de Fri, 15 Feb 2013 17:44:20 +
+
+mksh (40.9.20120630-5) unstable; urgency=low
+
+ * Bump versioned B-D on libklibc-dev [armhf] to known-fixed
+ * Fix input command line editing display redrawing issue
+ * Backport fixes to the regression testsuite and some new tests
+ * Add bugfixes for error handling related issues:
+- behaviour of $? in eval (RedHat BZ#865121)
+- running the EXIT and ERR traps (Closes: #696823)
+- set -e vs. use of /|| in a function (LP#1104543)
+ * Add appropriate regression tests for these fixes
+ * Update the mailing list address in lksh.1 manpage
+ * In /etc/skel/.mkshrc handle /etc/debian_chroot like bashrc does
+ * Update copyright year
+
+ -- Thorsten Glaser t...@mirbsd.de Mon, 11 Feb 2013 14:14:37 +0100
+
mksh (40.9.20120630-4) unstable; urgency=low
* The “Cookie” upload
This is the changelog, with reference to the bug numbers of the bugs
fixed by the changes below also. The change in -6 just reverted one of
the changes in -5 and was immediately followed up by the correct fix
in -7 once I had it working.
--- mksh-40.9.20120630/debian/.mkshrc 2011-11-26 00:04:53.0 +
+++ mksh-40.9.20120630/debian/.mkshrc 2013-02-11 13:18:28.0 +
@@ -19,6 +19,8 @@
else
p=$'\001'
fi
+[[ -z ${debian_chroot:-} -r /etc/debian_chroot ]] \
+debian_chroot=$(/etc/debian_chroot)
PS1=$p$'\r${debian_chroot:+'$p$'\e[0;1m'$p'($debian_chroot)'$p$'\e[0m'$p'}'$PS1
unset p
This change aligns the standard mkshrc file with what bash’s initiali‐
sation files do wrt. behaviour in chroots (dchroot/schroot, cowbuilder
--login).
--- mksh-40.9.20120630/debian/control 2012-09-30 14:50:32.0 +
+++ mksh-40.9.20120630/debian/control 2012-10-06 13:05:08.0 +
@@ -19,7 +19,8 @@
Build-Depends: bsdmainutils, ed,
# # try klibc on any architectures it has ever been built; this aids people
# # trying to debug klibc itself (hppa, powerpcspe, sh4)
- libklibc-dev [alpha amd64 armel armhf hppa i386 ia64 m68k mips mipsel
powerpc powerpcspe ppc64 s390 s390x sh4 sparc sparc64],
+ libklibc-dev (= 2.0.1-2~) [armhf],
+ libklibc-dev [alpha amd64 armel hppa i386 ia64 m68k mips mipsel powerpc
powerpcspe ppc64 s390 s390x sh4 sparc sparc64],
# # same for dietlibc; the hppa one is optional for now
dietlibc-dev (= 0.33~cvs20120325-4~) [armhf],
dietlibc-dev (= 0.33~cvs2008-5~) [hppa] | dietlibc-doc [hppa],
This change merely introduces a versioning to the klibc dependency
for armhf as it got usable only late in the release process. I’ve
had this in for a while already, even said so on the mailing list,
but I think it went unseen in the flood of messages.
Omitted change for debian/copyright: only the year 2013 was added.
--- mksh-40.9.20120630/debian/lksh.12012-07-20 23:34:00.0 +
+++ mksh-40.9.20120630/debian/lksh.12013-02-11 13:18:30.0 +
@@ -258,7 +258,7 @@
Talk
Re: [Pkg-mediawiki-devel] Bug#700595: mediawiki: Upstream bug: Bug 39635 - PostgreSQL LOCK IN SHARE MODE option is a syntax error
On Wed, 27 Feb 2013, Adam D. Barratt wrote: As a side note, the changelog didn't really need: + * Note: these changes were part of this upload, even though +they were not detailed in this changelog entry when uploading: which will look a little odd to those perusing the changelog in future rather than diffing it, I suspect. Ah well. Hm, do you have a better wording for changelog entries that were supposed to accompany the changes of a past upload but had been forgotten? I thought adding them “after the fact” to the older version but marking them specially would be somewhat clearer than adding them to the newer version, since the changes themselves slipped in with the older one. But then, I’m not an English native speaker… 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-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.02.1302281024570.23...@tglase.lan.tarent.de
Re: [Pkg-mediawiki-devel] Bug#700595: mediawiki: Upstream bug: Bug 39635 - PostgreSQL LOCK IN SHARE MODE option is a syntax error
On Thu, 28 Feb 2013, Adam D. Barratt wrote: I'd just have included them in the older changelog stanza as is and noted in the current version that I'd added them; there's no particular need to know in future versions that they were added after the fact. ymmv. OK, thanks, will do that next time. 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-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.02.1302281412130.23...@tglase.lan.tarent.de
Re: Bug#689578: sysklogd modifies /etc/syslog.conf with helper script
Andres Salomon dixit: Hm. Rather than simply remove it, can we actually provide an upgrade path to rsyslog? I'd be happy to NMU a version of ksyslogd that does this in unstable (for consideration in wheezy), as long as rsyslog is truly a drop-in replacement. No, I veto that, I’m happily using sysklogd in sid. Do *not* break that. It seems that new squeeze installs default to using rsyslog. However, Lenny started with that beast, actually. bye, //mirabilos -- „nein: BerliOS und Sourceforge sind Plattformen für Projekte, github ist eine Plattform für Einzelkämpfer“ -- dieses Zitat ist ein Beweis dafür, daß auch ein blindes Huhn mal ein Korn findet, bzw. – in diesem Fall – Recht haben kann -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1301211352001.10...@herc.mirbsd.org
Bug#696999: [a...@adam-barratt.org.uk: Re: Bug#696999: unblock: mediawiki-extensions/2.11]
Jonathan Wiltshire dixit:
Any idea what the comment in
++ array('a', /* does not work */ 'img')));
is about?
The MediaWiki HTML sanitiser accepts an array of tags to also
accept in the output. I’ve tried whitelisting 'a' and 'img',
but the latter does not currently work. I hope this will be
addressed in a future version of MediaWiki (actually, I could
probably cook up a patch), and right now, its presence there
is a nop.
bye,
//mirabilos
--
I want one of these. They cost 720 € though… good they don’t have the HD hole,
which indicates 3½″ floppies with double capacity… still. A tad too much, atm.
‣ http://www.floppytable.com/floppytable-images-1.html
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.bsm.4.64l.1212301632050.18...@herc.mirbsd.org
Bug#695904: mea culpa (was Re: [Pkg-mediawiki-devel] Bug#695904: Bug#695904: unblock: mediawiki/1:1.19.3-1 (fwd))
On Sat, 15 Dec 2012, Adam D. Barratt wrote: The first patch was *not* in the 1.19.2 package: Indeed, I totally fucked up this one. Apparently, there was a “wheezy” branch in svn which I was supposed to use but did not. The changes that sled in were: • the “| php5-mysqlnd” dependency (#689758) • bz29635.patch (fixes cases where database upgrades fail) ‣ https://bugzilla.wikimedia.org/show_bug.cgi?id=29635 • two hunks of fix_invalid_xhtml.patch (ensures 2 out of 3 places that need the change have all img/ tags always have an alt=… attribute; the third one was not yet committed: https://bugzilla.wikimedia.org/show_bug.cgi?id=40889 has a link to an upstream commit for that) Apparently, because the latter was WIP/incomplete, I had not added debian/changelog entries, which led to my later oversight. I should have used svn log. If there is demand, I will upload a -2 reverting all of these changes, although I consider the bz29635.patch important enough for inclusion for PostgreSQL users. If that is requested, please say so. (Apparently, the -1 upload made it into testing in the meantime.) I learned from this to never assume debian/changelog is up to date in a “trunk” and will try to not repeat this mistake. Sorry. 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-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.02.1212171047240.15...@tglase.lan.tarent.de
Re: Question on proposed integration of MediaWiki 1.19.3 in wheezy
On Wed, 12 Dec 2012, Niels Thykier wrote: On 2012-12-12 10:58, Dominik George wrote: Dear release managers, today, I chose to fix RC bug #694998. It is a security issue with To be exact, I asked Dominik whether he can have a look at it and review it (and ask the Release Team) because I currently lack time to do that in-depth and he’s eager to help RC bug fixing… MediaWiki 1.19.2 currently in testing, and there are two ways of fixing this issue. The easiest would be to get the new upstream version 1.19.3 into testing. From the pkg-mw side this would of course be preferred because it would make later fixes easier, and the MW upstream sort of agreed to support 1.19 longer for us, when we in turn keep MW in good shape in Debian ;-) I created the new package and a debdiff [2]. This diff is quite large because the update also incorporates tons of translation updates. I suggested to use diff -wup and exclude the translations; I’ve already done that for 1.19.2. If 1.19.3 is just the security fix + translations, I'd be willing to allow the translations as well. OK, thanks. Let’s hope it’ll be just fixes. Thanks Dominik for having a look. 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-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.02.1212121130150.2...@tglase.lan.tarent.de
Re: Question on proposed integration of MediaWiki 1.19.3 in wheezy
On Wed, 12 Dec 2012, Niels Thykier wrote: The filtered diff looks reasonable, feel free to upload 1.19.3-0.1 to unstable. Please file an unblock bug for it after it has been in unstable for some time. Thanks Niels. Dominik, please commit the changes needed, version as 1:1.19.3-1 and mark as “* Team upload”, then Jonathan or I can build and upload it, now that you’re in the Alioth team. I’ll even squeeze in some testing in a fusionforge setting ;-) 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-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.02.1212121347000.2...@tglase.lan.tarent.de
seeking pre-upload approval for mksh 40.9.20120630-5 targetting wheezy
Hi,
I would like to put the following patch, which took me 3¼ hours to
find, into mksh in wheezy. It reverts a flag which I mistakenly
converted to bool back to int, as it’s used as a counter. The effect
is that, when you have non-ASCII characters on the command line and
then insert something in the middle, sometimes, the entire display
or parts of it is trashed.
--- edit.c 3 Sep 2012 19:29:14 - 1.8
+++ edit.c 26 Nov 2012 22:40:58 -
@@ -900,7 +900,7 @@ static bool x_adj_ok;
* we use x_adj_done so that functions can tell
* whether x_adjust() has been called while they are active.
*/
-static bool x_adj_done;
+static int x_adj_done;
static int x_col;
static int x_displen;
@@ -1166,7 +1166,7 @@ x_init_prompt(void)
if (x_col = xx_cols)
x_col %= xx_cols;
x_displen = xx_cols - 2 - x_col;
- x_adj_done = false;
+ x_adj_done = 0;
pprompt(prompt, 0);
if (x_displen 1) {
@@ -1339,7 +1339,7 @@ static int
x_ins(const char *s)
{
char *cp = xcp;
- bool adj = x_adj_done;
+ int adj = x_adj_done;
if (x_do_ins(s, strlen(s)) 0)
return (-1);
@@ -1616,7 +1616,7 @@ x_size2(char *cp, char **dcp)
static void
x_zots(char *str)
{
- bool adj = x_adj_done;
+ int adj = x_adj_done;
x_lastcp();
while (*str str xlp adj == x_adj_done)
@@ -2847,7 +2847,7 @@ static void
x_adjust(void)
{
/* flag the fact that we were called. */
- x_adj_done = true;
+ x_adj_done++;
/*
* we had a problem if the prompt length xx_cols / 2
*/
@@ -2969,7 +2969,7 @@ x_e_putc3(const char **cp)
static void
x_e_puts(const char *s)
{
- bool adj = x_adj_done;
+ int adj = x_adj_done;
while (*s adj == x_adj_done)
x_e_putc3(s);
This reverts everything dealing with x_adj_done to the state
it was in mksh 40.5.
I’ve got another diff queued for wheezy, bumping the versioned
B-D for klibc on armhf to the first version known to actually
work there, but I think this is trivial:
--- debian/control 30 Sep 2012 14:50:07 - 1.82
+++ debian/control 6 Oct 2012 13:04:43 - 1.83
@@ -19,7 +19,8 @@ Homepage: http://mirbsd.de/mksh
Build-Depends: bsdmainutils, ed,
# # try klibc on any architectures it has ever been built; this aids people
# # trying to debug klibc itself (hppa, powerpcspe, sh4)
- libklibc-dev [alpha amd64 armel armhf hppa i386 ia64 m68k mips mipsel
powerpc powerpcspe ppc64 s390 s390x sh4 sparc sparc64],
+ libklibc-dev (= 2.0.1-2~) [armhf],
+ libklibc-dev [alpha amd64 armel hppa i386 ia64 m68k mips mipsel powerpc
powerpcspe ppc64 s390 s390x sh4 sparc sparc64],
# # same for dietlibc; the hppa one is optional for now
dietlibc-dev (= 0.33~cvs20120325-4~) [armhf],
dietlibc-dev (= 0.33~cvs2008-5~) [hppa] | dietlibc-doc [hppa],
Thanks in advance,
//mirabilos
--
Darwinism never[…]applied to wizardkind. There's a more than fair amount of[…]
stupidity in its gene-pool[…]never eradicated[…]magic evens the odds that way.
It's[…]harder to die for us than[…]muggles[…]wonder if, as technology[…]better
[…]same will[…]happen there too. Dursleys' continued existence indicates so.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.bsm.4.64l.1211262241200.23...@herc.mirbsd.org
Bug#689153: ping mksh-related release items
Hi, I’d like to do a ping for mksh unblocking and the release notes entry, just so they don’t accidentally forgotten. In case someone already has these on their radar, please sorry for the noise. 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-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1211251719020.30...@herc.mirbsd.org
Re: [Pkg-mediawiki-devel] Candidates for removal from testing (2012-11-14)
On Wed, 14 Nov 2012, Niels Thykier wrote: * The package had at least one RC bug without activity for the past 14 days. Jonathan Wiltshire j...@debian.org mediawiki-math (U) Mediawiki Maintenance Team pkg-mediawiki-de...@lists.alioth.debian.org mediawiki-math Hey Jonathan, will you take care of this? Otherwise I’ll have to see that I take some time for it… 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-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.02.1211150925530.5...@tglase.lan.tarent.de
Re: Bug#689578: sysklogd modifies /etc/syslog.conf with helper script
Michael Biebl dixit: A better approach imho would be to simply remove sysklogd from the archive. Please no! //mirabilos (still ill) -- Natureshadow Dann mach ich git annex copy --to shore und fertig ist das Natureshadow das ist ja viel cooler als ownCloud ... mirabilos sag ich doch Natureshadow ja wieso stimmt das denn immer was du sagst ... -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1210131304320.4...@herc.mirbsd.org
Bug#689153: unblock: mksh/40.9.20120630-4
retitle 689153 unblock: mksh/40.9.20120630-4 thanks Hi, sorry for the trouble, but please wait for the -4 upload, as recent changes in gcc will let mksh ftbfs, and doko said he'll want to propose these versions for wheezy; I've made the same hotfix in Ubuntu already. bye, //mirabilos -- Natureshadow Dann mach ich git annex copy --to shore und fertig ist das Natureshadow das ist ja viel cooler als ownCloud ... mirabilos sag ich doch Natureshadow ja wieso stimmt das denn immer was du sagst ... -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1210121407250.17...@herc.mirbsd.org
Bug#689157: unblock: mediawiki-extensions/2.9, mediawiki/1:1.19.2-2
Dear Release Team,
please extend the courtesy to unblock the MediaWiki packages
to today’s uploads: mediawiki-extensions/2.9, mediawiki/1:1.19.2-2
The reason behind this is the removal of the FCKeditor extension
which works only up to and including MediaWiki 1.17 and has been
deprecated by the Wikimedia Foundation in favour of another, not
yet packaged, extension (see #689375 for the full details). We
would like to have this, now non-working, extension removed from
src:mediawiki-extensions and broken by mediawiki, in wheezy too,
and have added appropriate NEWS entries.
Furthermore, there’s a small fix for the Collection extension
regarding downloading the generated PDFs from the PDF Export
link and for Wikibooks in PDF format, which was broken depending
on the version or configuration of the render server (affecting
one of two possible codepaths). This basically inlines a bit of
code from two “convenience wrapper” functions in order to access
the HTTP Response headers.
The debdiffs (attached) are relatively short (I have represented
file removals as comment in the top instead of including their
full diff):
mediawiki:
- add NEWS entry, break any version of mediawiki-extensions-fckeditor
- adjust debian/watch file for DDPO vs. uscan behaviour difference:
patch (dversionmangle) away the epoch, which DDPO doesn’t like,
as done for src:cvs
mediawiki-extensions:
- remove all files related to the FCKeditor extension
- add NEWS entry
- remove debian/{control{,.in},copyright,patches/series,rules}
entries related to the FCKeditor extension
- debian/patches/fix_collection.patch: add fix for downloading
generated PDFs
- remove svn-revisions entries related to the FCKeditor extension
Thanks in advance,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-314
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Boris Esser, Sebastian Manckedeleted:
- mediawiki-extensions-2.8/debian/mediawiki-extensions-fckeditor.links
- mediawiki-extensions-2.8/debian/patches/fix_fckeditor.patch
- mediawiki-extensions-2.8/dist/mediawiki-extensions-fckeditor/
--- mediawiki-extensions-2.8/debian/NEWS1970-01-01 01:00:00.0
+0100
+++ mediawiki-extensions-2.9/debian/NEWS2012-10-02 14:09:51.0
+0200
@@ -0,0 +1,11 @@
+mediawiki-extensions (2.9) unstable; urgency=low
+
+ The mediawiki-extensions-fckeditor package has been
+ deprecated by the Wikimedia foundation and is thus
+ no longer included in the packaging, so if your wikis
+ have been using this extension, please remove it from
+ their configuration to avoid breakage. This can be
+ done using sudo mwdisext FCKeditor.php if installed
+ from Debian packaging.
+
+ -- Thorsten Glaser t...@mirbsd.de Tue, 02 Oct 2012 14:09:42 +0200
--- mediawiki-extensions-2.8/debian/changelog 2012-09-20 13:45:26.0
+0200
+++ mediawiki-extensions-2.9/debian/changelog 2012-10-02 14:09:51.0
+0200
@@ -1,3 +1,10 @@
+mediawiki-extensions (2.9) unstable; urgency=low
+
+ * Collection: fix downloading generated PDFs from the render server
+ * FCKeditor: remove, no longer works with MW 1.19 (Closes: #689375)
+
+ -- Thorsten Glaser t...@mirbsd.de Tue, 02 Oct 2012 14:09:42 +0200
+
mediawiki-extensions (2.8) unstable; urgency=low
* Remove dependency of mw-ext-collection on various ECMAscript
--- mediawiki-extensions-2.8/debian/control 2012-09-20 13:45:26.0
+0200
+++ mediawiki-extensions-2.9/debian/control 2012-10-02 12:13:31.0
+0200
@@ -91,17 +91,6 @@
This extension is set for the Debian mediawiki
package, but it may also be used separately.
-Package: mediawiki-extensions-fckeditor
-Architecture: all
-Depends: ${misc:Depends}, mediawiki-extensions-base,
- fckeditor
-Description: Extensions for MediaWiki -- FCKeditor extension
- This package provides the mediawiki extensions for
- FCKeditor wysiwyg editor.
- .
- This extension is set for the Debian mediawiki
- package, but it may also be used separately.
-
Package: mediawiki-extensions-collection
Architecture: all
Depends: ${misc:Depends}, mediawiki-extensions-base, php5-curl
@@ -130,7 +119,6 @@
mediawiki-extensions-ldapauth,
mediawiki-extensions-openid,
mediawiki-extensions-confirmedit,
- mediawiki-extensions-fckeditor,
mediawiki-extensions-collection,
mediawiki-extensions-graphviz,
${misc:Depends}
--- mediawiki-extensions-2.8/debian/control.in 2012-09-20 13:45:26.0
+0200
+++ mediawiki-extensions-2.9/debian/control.in 2012-10-02 12:13:31.0
+0200
@@ -91,17 +91,6 @@
This extension is set for the Debian mediawiki
package, but it may also be used separately.
-Package: mediawiki-extensions-fckeditor
-Architecture: all
-Depends: ${misc:Depends}, mediawiki-extensions-base,
- fckeditor
-Description: Extensions for MediaWiki -- FCKeditor extension
- This package provides the mediawiki extensions for
- FCKeditor wysiwyg editor
Bug#689354: nmu: mksh_40.9.20120630-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu mksh_40.9.20120630-3 . armhf . -m Rebuild against fixed klibc maximilian attems dixit: On Sun, 30 Sep 2012, Thorsten Glaser wrote: […] and without busybox, and rebuilding mksh on armhf with it would also show success (in fact, once you uploaded, I’ll ask for a binNMU of mksh on armhf anyway). klibc built fine on all archs, go ahead!! :D Sure, thanks. I guess I’ll file the request now, but it might be best to wait a day or two, until all armhf buildds are sure to have the new libklibc-dev package available. Therefore, please binNMU src:mksh on armhf, so mksh-static gets built against the new klibc package after fixing its RC bug. Thanks! -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 m68k Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/mksh -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121001211350.9375.66864.report...@zigo.mirbsd.org
Bug#689153: unblock: mksh/40.9.20120630-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package mksh
The upload 40.9.20120630-3 was specifically made to target wheezy;
the changes have been tested for a while now, and the diff, split
by the kind of change done, follows.
The package fixes two problems, first, the following script did not
work (regression against mksh 39) and now works again:
echo $(
echo \{
tr u x -'EOF'
price is u denar
EOF
echo }
)
This is LP#1030581.
The part of the debdiff pertaining to that is one half of the diff
to debian/patches/debian-changes (as I do that kind of stuff in CVS)
and follows here as diff against the patched source instead, for
easier review; changes to CVS keywords and the version number reported
have also been omitted:
--- mksh-40.9.20120630-2/tree.c 2012-06-28 22:18:27.0 +0200
+++ mksh-40.9.20120630-3/tree.c 2012-09-29 17:00:22.0 +0200
@@ -53,6 +53,25 @@ ptree(struct op *t, int indent, struct s
return;
switch (t-type) {
case TCOM:
+ prevent_semicolon = false;
+ /*
+* special-case 'var=EOF' (rough; see
+* exec.c:execute() for full code)
+*/
+ if (
+ /* we have zero arguments, i.e. no programme to run */
+ t-args[0] == NULL
+ /* we have exactly one variable assignment */
+ t-vars[0] != NULL t-vars[1] == NULL
+ /* we have exactly one I/O redirection */
+ t-ioact != NULL t-ioact[0] != NULL
+ t-ioact[1] == NULL
+ /* of type here document (or here string) */
+ (t-ioact[0]-flag IOTYPE) == IOHERE) {
+ fptreef(shf, indent, %S, t-vars[0]);
+ break;
+ }
+
if (t-vars) {
w = (const char **)t-vars;
while (*w)
@@ -65,7 +84,6 @@ ptree(struct op *t, int indent, struct s
fptreef(shf, indent, %S , *w++);
} else
shf_puts(#no-args# , shf);
- prevent_semicolon = false;
break;
case TEXEC:
t = t-left;
@@ -216,8 +234,10 @@ ptree(struct op *t, int indent, struct s
* often leads to an extra blank line, but it's not
* worth worrying about)
*/
- if (need_nl)
+ if (need_nl) {
shf_putc('\n', shf);
+ prevent_semicolon = true;
+ }
}
}
@@ -258,8 +278,8 @@ pioact(struct shf *shf, int indent, stru
/* name/delim are NULL when printing syntax errors */
if (type == IOHERE) {
if (iop-delim)
- fptreef(shf, indent, %S , iop-delim);
- else
+ wdvarput(shf, iop-delim, 0, WDS_TPUTS);
+ if (iop-flag IOHERESTR)
shf_putc(' ', shf);
} else if (iop-name)
fptreef(shf, indent, (iop-flag IONAMEXP) ? %s : %S ,
This part also touches the testsuite (most of it remove a space
at the end of the line):
--- mksh-40.9.20120630-2/check.t2012-09-29 17:00:14.0 +0200
+++ mksh-40.9.20120630-3/check.t2012-09-29 17:00:22.0 +0200
@@ -2268,7 +2268,13 @@ stdin:
=c $x \x40=
EOF
}
- typeset -f foo
+ fnd=$(typeset -f foo)
+ print -r -- $fnd
+ function foo {
+ echo blub
+ }
+ foo
+ eval $fnd
foo
# rather nonsensical, but…
vd==d $x \x40=
@@ -2278,11 +2284,12 @@ stdin:
print -r -- | va={$va} vb={$vb} vc={$vc} vd={$vd} ve={$ve} vf={$vf} |
expected-stdout:
function foo {
- vc= -EOF
+ vc=-EOF
=c $x \x40=
EOF
}
+ blub
| va={=a u \x40=
} vb={=b $x \x40=
} vc={=c u \x40=
@@ -2310,20 +2317,27 @@ stdin:
=d $x \x40=
}
- typeset -f foo
+ fnd=$(typeset -f foo)
+ print -r -- $fnd
+ function foo {
+ echo blub
+ }
+ foo
+ eval $fnd
foo
print -r -- | va={$va} vb={$vb} vc={$vc} vd={$vd} |
expected-stdout:
function foo {
- vc= -
+ vc=-
=c $x \x40=
- vd= -
+ vd=-
=d $x \x40=
}
+ blub
| va={=a u \x40=
} vb={=b $x \x40=
} vc={=c u \x40=
@@ -8837,7 +8851,7 @@ expected-stdout:
EOFN
}
inline_IOWRITE_IOCLOB_IOHERE_noIOSKIP() {
- cat |bar EOFN
+ cat
Bug#689156: unblock: mediawiki/1:1.19.2-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package mediawiki
This upload follows on both the threads for better MW 1.19 support
http://article.gmane.org/gmane.linux.debian.devel.release/56559
and the multiple security issues (Debian #686330) part:
http://thread.gmane.org/gmane.linux.debian.devel.secure-testing.general/5325
The changes can be split into multiple parts. The security issues
were fixed by the new upstream version, which I’ll detail below.
First are the changes inside debian/ which I’ll show as diffs
between the _patched_ sources again (like with mksh) because
diffs between 3.0 (quilt) diffs are harder to read, except:
The file debian/patches/texvc_location.patch was removed, but it
was already not used in 1.19.1-1. The following patches were added
and have been attached to this message and removed from the diff:
fix_invalid_xhtml.patch, fix_warnings.patch
First, the packaging changes: add myself to Uploaders; do not
replace the jquery-tablesorter shipped with MW by the one in
Debian again because the MW one is a different/patched codebase
(fixes #687519); update Breaks wrt. the isochronal uploads of
src:fusionforge and src:mediawiki-exensions (for which I’ll also
file an unblock request); and Jonathan had added two Recommends.
I added a few “chmod +x” to quieten lintian and removed a COPYING
file from the .deb file after verifying its contents were already
in debian/copyright (which they were).
--- mediawiki-1.19.2-0/debian/changelog 2012-06-18 17:17:26.0 +0200
+++ mediawiki-1.19.2-1/debian/changelog 2012-09-20 13:45:26.0 +0200
@@ -1,3 +1,26 @@
+mediawiki (1:1.19.2-1) unstable; urgency=low
+
+ [ Thorsten Glaser ]
+ * New upstream: security fixes for CVE-2012-4377, CVE-2012-4378,
+CVE-2012-4379, CVE-2012-4380, CVE-2012-4381, CVE-2012-4382
+(Closes: #686330)
+ * Prevent table/table without any tr / inside, globally
+ * Fix more cases of not checking $wgHtml5
+ * MW’s ID (XML) sanitiser is there for a reason, use it!
+ * Prevent ul/ul without any li / inside in MonoBook
+ * Fix invalid XHTML caused by code not honouring $wgHtml5
+ * Quell some PHP warnings from sloppy code
+ * Do the wfSuppressWarnings patch used with FusionForge right
+ * Add myself to Uploaders and quieten lintian a bit
+ * Do not replace patched jquery-tablesorter with unpatched one;
+unbreaks sortable tables (Closes: #687519)
+ * Update versioned Breaks against fusionforge and mw-extensions
+
+ [ Jonathan Wiltshire ]
+ * Add Recommends on mediawiki-extensions-base and php-wikidiff2
+
+ -- Thorsten Glaser t...@mirbsd.de Thu, 20 Sep 2012 13:40:12 +0200
+
mediawiki (1:1.19.1-1) unstable; urgency=low
* New upstream bug fix release
--- mediawiki-1.19.2-0/debian/control 2012-06-18 16:31:31.0 +0200
+++ mediawiki-1.19.2-1/debian/control 2012-09-20 13:45:26.0 +0200
@@ -2,7 +2,7 @@ Source: mediawiki
Section: web
Priority: optional
Maintainer: Mediawiki Maintenance Team
pkg-mediawiki-de...@lists.alioth.debian.org
-Uploaders: Romain Beauxis to...@rastageeks.org, Jonathan Wiltshire
j...@debian.org
+Uploaders: Romain Beauxis to...@rastageeks.org, Jonathan Wiltshire
j...@debian.org, Thorsten Glaser t...@mirbsd.de
Build-Depends: debhelper (= 9),
dh-buildinfo,
ocaml-nox | ocaml, xsltproc, docbook-xml, docbook-xsl, po-debconf
@@ -13,10 +13,19 @@ Vcs-Browser: http://svn.debian.org/views
Package: mediawiki
Architecture: all
-Depends: apache2 | httpd, php5, php5-mysql | php5-pgsql | php5-sqlite,
mime-support, libjs-jquery, libjs-jquery-tipsy, libjs-jquery-cookie,
libjs-jquery-form, libjs-jquery-tablesorter, ${misc:Depends}
-Recommends: mysql-server | postgresql-contrib, php5-cli, python
+Depends: apache2 | httpd, php5, php5-mysql | php5-pgsql | php5-sqlite,
mime-support, libjs-jquery, libjs-jquery-tipsy, libjs-jquery-cookie,
libjs-jquery-form, ${misc:Depends}
+Recommends: mysql-server | postgresql-contrib, php5-cli, python,
php-wikidiff2, mediawiki-extensions-base
Suggests: imagemagick | php5-gd, mediawiki-math, memcached, clamav
-Breaks: fusionforge-plugin-mediawiki ( 5.2~rc1-4~)
+Breaks: fusionforge-plugin-mediawiki ( 5.2~rc1+1~),
+ mediawiki-extensions-base ( 2.8~),
+ mediawiki-extensions-geshi ( 2.8~),
+ mediawiki-extensions-ldapauth ( 2.8~),
+ mediawiki-extensions-openid ( 2.8~),
+ mediawiki-extensions-confirmedit ( 2.8~),
+ mediawiki-extensions-fckeditor ( 2.8~),
+ mediawiki-extensions-collection ( 2.8~),
+ mediawiki-extensions-graphviz ( 2.8~),
+ mediawiki-extensions ( 2.8~)
Description: website engine for collaborative work
MediaWiki is a wiki engine (a program for creating a collaboratively
edited website). It is designed to handle heavy websites containing
--- mediawiki-1.19.2-0/debian/rules 2012-06-18 16:51:36.0 +0200
+++ mediawiki-1.19.2-1/debian/rules 2012-09-20 13:45:26.0 +0200
@@ -6,9 +6,14 @@ DEB_UPSTREAM_VERSION ?= $(shell
Bug#689157: unblock: mediawiki-extensions/2.8
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package mediawiki-extensions
This unblock request also comes as a follow-up to the thread at
http://article.gmane.org/gmane.linux.debian.devel.release/56559
as discusses earlier.
As for diffs: mediawiki-extensions/2.7 was the first version to
properly work with MediaWiki 1.19, 2.6 and below were for 1.15,
and, despite some trickery leading to 2.6+wheezy1, are not at
all suitable for it (I said in #686190 that it was just the be‐
ginning, and #687641 being filed proved me right).
Furthermore, mediawiki-extensions/2.7 was waiting for migration
to testing for more than 60 (sixty) days already, depending in‐
directly on nodejs due to ECMAscript compression and one of the
affected libraries being a dependency¹, and the JS packagers as
well as I were under the impression, all the time, that we could
have this fixed for wheezy, until being told, IMO much too late,
that this would not be accepted. So I respectfully ask that the
Release Team consider mediawiki-extensions/2.7 already accepted
and just not transitioned due to misinformation.
① As it turns out, that dependency was not even needed in the
end; the 2.8 upload removes it. But I was left in good faith
that 2.7 would transition as-is, and we could fix all follow-
up problems later.
Therefore I consider the upgrade to MW-Extensions 2.8 critical
to the release (as otherwise, peoples’ wikis will either not
work at all and/or show weird error messages, or, if the media‐
wiki/1:1.19.2-1 upload is accepted, their extensions will find
themselves deinstalled, which will make them unhappy, and pos‐
sibly also break their installations).
As for the fixes happening between 2.7 and 2.8, they occurred
during preparing the integration of FusionForge and MW 1.19 in
a semi-production environment. The RSS_Reader extension was
fully broken, PageCSS produced spurious text in wiki pages,
and Collection and InputBox produced invalid XHTML. The diff,
again with quilt patches applied instead of showing a diff
between unidiffs, follows:
--- mediawiki-extensions-2.7/debian/changelog 2012-06-29 17:55:21.0
+0200
+++ mediawiki-extensions-2.8/debian/changelog 2012-09-20 13:45:26.0
+0200
@@ -1,3 +1,15 @@
+mediawiki-extensions (2.8) unstable; urgency=low
+
+ * Remove dependency of mw-ext-collection on various ECMAscript
+libraries that apparently are available from MW core already
+(as log message for r87847 suggests); enables testing transition
+ * Fix paths in RSS_Reader extension
+ * Quell those UNIQ‥QINU texts by fixing PageCSS to honour the API
+ * Fix content-less ul element in Collection extension
+ * Fix invalid XHTML in InputBox extension
+
+ -- Thorsten Glaser t...@mirbsd.de Thu, 20 Sep 2012 13:40:12 +0200
+
mediawiki-extensions (2.7) unstable; urgency=low
* Target MediaWiki 1.19
--- mediawiki-extensions-2.7/debian/control 2012-06-29 17:55:21.0
+0200
+++ mediawiki-extensions-2.8/debian/control 2012-09-20 13:45:26.0
+0200
@@ -104,8 +104,7 @@ Description: Extensions for MediaWiki --
Package: mediawiki-extensions-collection
Architecture: all
-Depends: ${misc:Depends}, mediawiki-extensions-base,
- libjs-jquery, libjs-jquery-ui, libjs-json, php5-curl
+Depends: ${misc:Depends}, mediawiki-extensions-base, php5-curl
Description: Extensions for MediaWiki -- Collection extension
This package provides the mediawiki extensions for
creating books using collections of pages.
--- mediawiki-extensions-2.7/debian/control.in 2012-06-29 17:50:22.0
+0200
+++ mediawiki-extensions-2.8/debian/control.in 2012-09-20 13:45:26.0
+0200
@@ -104,8 +104,7 @@ Description: Extensions for MediaWiki --
Package: mediawiki-extensions-collection
Architecture: all
-Depends: ${misc:Depends}, mediawiki-extensions-base,
- libjs-jquery, libjs-jquery-ui, libjs-json, php5-curl
+Depends: ${misc:Depends}, mediawiki-extensions-base, php5-curl
Description: Extensions for MediaWiki -- Collection extension
This package provides the mediawiki extensions for
creating books using collections of pages.
--- mediawiki-extensions-2.7/debian/mediawiki-extensions-collection.links
2012-06-29 16:16:17.0 +0200
+++ mediawiki-extensions-2.8/debian/mediawiki-extensions-collection.links
2012-09-20 13:45:26.0 +0200
@@ -1,5 +1,2 @@
usr/share/mediawiki-extensions/collection
var/lib/mediawiki/extensions/Collection
usr/share/mediawiki-extensions/collection/Collection.php
etc/mediawiki-extensions/extensions-available/Collection.php
-usr/share/javascript/jquery-ui/jquery-ui.js
usr/share/mediawiki-extensions/collection/collection/jquery.ui.js
-usr/share/javascript/jquery/jquery.js
usr/share/mediawiki-extensions/collection/collection/jquery.js
-usr/share/javascript/json/json2.min.js
usr/share/mediawiki-extensions/collection/collection/json2.js
---
mediawiki-extensions-2.7
