Re: firefox-esr: no longer using system nspr, nss, sqlite?
Mike Hommey wrote: > Look at the build dependencies in debian/control.in, specifically the > versions, and the versions of the mentioned libraries in jessie and > stretch. Yep, the required versions are not there. Okay, intentional then. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
firefox-esr: no longer using system nspr, nss, sqlite?
Hi, firefox-esr since 52.2.0esr-1 is no longer using the system libs for nspr, nss, sqlite; was that an intentional change? This affects at least sid (where DIST="stretch"): https://buildd.debian.org/status/fetch.php?pkg=firefox-esr=amd64=52.2.0esr-1=1497417448=0 (see "NSPR selection... source-tree", or grep for USE_SYSTEM_ ) and I expect it would affect the backports in jessie-security too (but I don't know how/where to find build logs, to check that). Maybe it should have been ifneq in debian/rules? | ifeq (,$(filter wheezy jessie stretch,$(DIST))) | SYSTEM_LIBS += nspr nss sqlite | endif | #ifeq (,$(filter wheezy jessie,$(DIST))) | SYSTEM_LIBS += vpx | endif Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#856405: unblock: libdebian-installer/0.109 and others
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-b...@lists.debian.org Hi! Attached are proposed debdiffs for anna, cdebootstrap and their dependency libdebian-installer (Bug #856210). Would the release team be willing to grant unblocks for these? (It would also require an ACK from the d-i release manager). In the installer, net-retriever verifies the Release file with SHA256, but anna only validates the .udeb files with MD5, which was surprising. The .udeb files are extracted and then their contents may be executed with full privileges during the install (Bug #856211). netboot images typically fetch .udeb files over unsecured HTTP. Other install media bundles those so they need not be downloaded, but it could still happen if networking is configured during the install and a network mirror has newer versions of any required .udeb files. (Some .udeb files are retrieved later, after installing the base system). If not already considered a grave security flaw, it might be during the lifetime of stretch (-2022?). Even if fixed in a point release, any install media created before then would remain vulnerable. cdebootstrap - not used by the installer, but available in stretch - only verifies Release files using MD5 (Bug #856215), which is an unintended regression since jessie. The changes to libdebian-installer are ABI-compatible, such that only reverse-dependencies that use the md5sum field should be affected (thought to be just anna and cdebootstrap). They would FTBFS until patched, and already-built binaries would report a "md5sum mismatch" if they used this new version of the library at run-time, since the new SHA256 hashes would not match the MD5 hashes they expect. unblock libdebian-installer/0.109 unblock anna/1.58 unblock cdebootstrap/0.7.7 Thanks! -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.1-0-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) diff -Nru libdebian-installer-0.108/debian/changelog libdebian-installer-0.109/debian/changelog --- libdebian-installer-0.108/debian/changelog 2016-08-30 05:45:17.0 +0100 +++ libdebian-installer-0.109/debian/changelog 2017-02-28 16:36:45.0 + @@ -1,3 +1,15 @@ +libdebian-installer (0.109) unstable; urgency=high + + * In structs di_release and di_package, replace md5sum member with a +sha256 member. This is ABI-compatible, but reverse-dependencies +will fail if they still try to verify with MD5 (Closes: #856212). + * Parse SHA256 fields instead of MD5Sum fields in Packages files. + * Parse SHA256 fields instead of MD5Sum fields in Release files. + * No longer try to parse SHA1 field, which is no longer present in +Release files as of stretch. + + -- Steven Chamberlain <stev...@debian.org> Tue, 28 Feb 2017 16:36:45 + + libdebian-installer (0.108) unstable; urgency=medium [ Helmut Grohne ] diff -Nru libdebian-installer-0.108/include/debian-installer/package.h libdebian-installer-0.109/include/debian-installer/package.h --- libdebian-installer-0.108/include/debian-installer/package.h 2011-03-03 02:00:33.0 + +++ libdebian-installer-0.109/include/debian-installer/package.h 2017-02-28 16:33:59.0 + @@ -112,7 +112,7 @@ di_slist depends; /**< Any different dependency types */ char *filename; /**< Filename field */ size_t size; /**< Size field */ - char *md5sum; /**< MD5Sum field */ + char *sha256; /**< SHA256 field */ char *short_description; /**< Description field, first part*/ char *description;/**< Description field, second part */ unsigned int resolver;/**< @internal */ diff -Nru libdebian-installer-0.108/include/debian-installer/package_internal.h libdebian-installer-0.109/include/debian-installer/package_internal.h --- libdebian-installer-0.108/include/debian-installer/package_internal.h 2011-03-03 02:00:33.0 + +++ libdebian-installer-0.109/include/debian-installer/package_internal.h 2017-02-28 16:33:59.0 + @@ -52,7 +52,7 @@ internal_di_package_parser_field_enhances, internal_di_package_parser_field_filename, internal_di_package_parser_field_size, - internal_di_package_parser_field_md5sum, + internal_di_package_parser_field_sha256, internal_di_package_parser_field_description; /** diff -Nru libdebian-installer-0.108/include/debian-installer/release.h libdebian-installer-
Bug#856148: unblock: ntfs-3g/1:2016.2.22AR.1+dfsg.1-0.1
Hello, I ran diffoscope on the generated binary packages. There is some noise in the diff due to embedded build paths and varying build IDs, but otherwise, the only difference is the contents of const unsigned char boot_array[4136] in the .rodata section of sbin/mkntfs i.e.: Jan's proposed upload changes only the thing we expected it to. But this in turn means that filesystems created by mkntfs will have a placeholder instead of the first-stage loader of Windows. László Böszörményi wrote: > Can I ask if you tried to reach its maintainer first, before asking > for unblocking a not even uploaded NMU? Jan is at the Berlin BSP along with several DDs. Normally a fixed version would have been uploaded to DELAYED/10 allowing time for the maintainer to pre-empt with another upload. But - there would be no point uploading something to DELAYED if the release time would not approve an unblock. I think that is why this was filed - intended as a request for comments about a speculative upload to DELAYED/10. You could follow-up with your own debdiff if you plan to make your own upload for this? Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: [Stretch] Status for architecture qualification
Hi, John Paul Adrian Glaubitz wrote: > I have invested lots of time and effort to get sparc64 into a usable state in > Debian. > We are close to 11.000 installed packages. Missing packages include Firefox, > Thunderbird/Icedove, golang and LibreOffice to name the most important ones. Is there some way to define 'core'[0] packages as blockers for testing migration, and arch release qualification; but other packages not? Many of these ports would be useful if just a base system was released, and preferably having stable/security updates for that part (otherwise it is difficult for users to try it, developers to work on it, or DSA to support buildds for it; all of which are limitations on ports' further growth). Trying to have *every* package build and stay built on every port, and supported for the lifetime of stable, is a lot of work without much purpose sometimes. And it's unreasonable for any one port to block testing migration of a package on all arches, unless it is something really essential. This might be done either: * in the official archive, with relaxed rules for testing migration and more frequently de-crufting of out-of-date packages; * creating a mini testing/stable suite based on debian-ports.org? where maybe only the core packages are candidates to migrate. [0]: I'd define core packages as everything needed to install, boot, and then build packages on that arch. The rebootstrap project gives us some idea of what those are; but add to that the kernel and any bootloaders. Being able to rebootstrap, should be part of the arch release qualification anyway IMHO. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#817003: transition: glibc
Emilio Pozuelo Monfort wrote: > On 08/03/16 13:46, Steven Chamberlain wrote: > > Many architectures will be binNMUd against libc6 2.22, but please on > > kfreebsd-* could you binNMU these packages against libc0.1 2.22 instead: > > > > * p11-kit (breaks sid at the moment) > > * libnss-db > > I have hopefully done everything. Yes, thanks. kfreebsd-i386 wasn't able to complete the binNMU until Aurelien uploaded glibc/2.22-2 today. But this transition is finished now on kfreebsd. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Bug#817003: transition: glibc
Hi, Many architectures will be binNMUd against libc6 2.22, but please on kfreebsd-* could you binNMU these packages against libc0.1 2.22 instead: * p11-kit (breaks sid at the moment) * libnss-db hurd-i386 may also need rebuilds against libc0.3 2.22: * (libp11 was binNMUd already) * dante * libbsd * libnss-db The other one is libc6.1 on alpha, but I guess release team is not responsible for that. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB
Norvald H. Ryeng wrote: > >Norvald H. Ryeng wrote: > >>Tell us exactly what you want, in detail. If you don't then I don't > >>think your position is reasonable. > > I don't recognize those words, and it's not in the style I usually express > myself. Are you paraphrasing? Sorry, that was Robie Basak being quoted. Regards, -- Steven Chamberlain ste...@pyro.eu.org
Re: [debian-mysql] [Summary] Request for release team decision on MySQL and MariaDB
I'll try to make this my last intervention in this thread. Because it's not my decision, or area of responsibility, and I likely won't be one of the people having to do the work when a decision is made, but... Clint Byrum wrote: > most of these CVE's would remain fully undisclosed and unfixed in both > MySQL and MariaDB if the MySQL engineering team or customers had not > found them. Sorry, this is not compelling. As long as Oracle sells MySQL to enterprise, it *must* do these things, and release source code to satisfy legal obligations of what is a GPL codebase. It is really only doing the bare minimum in that regard. It was also a condition of Oracle's acquisition of MySQL AB: "As part of the negotiations with the European Commission, Oracle committed that MySQL server will continue until at least 2015 to use the dual-licensing strategy long used by MySQL AB, with proprietary and GPL versions available" according to https://en.wikipedia.org/wiki/MySQL#Legal_disputes_and_acquisitions Oracle may still drop MySQL support like a hat due to market conditions, regardless of whether Debian has already shipped it by then. And apart from sponsoring Debian packaging work, Oracle seems conspicuously missing from: http://debconf16.debconf.org/sponsors.html http://debconf15.debconf.org/ https://www.debian.org/mirror/sponsors https://www.freexian.com/en/services/debian-lts.html Clint Byrum wrote: > [...] if it were written down somewhere as an actual policy. [...] Norvald H. Ryeng wrote: > Tell us exactly what you want, in detail. If you don't then I don't > think your position is reasonable. Robie Basak wrote: > So please: the security team needs to engage directly with Oracle by > responding to Norvald's email and enumerating exactly what is wrong. I don't see that Debian has to do that, at all. Other upstream projects seem to 'just get it', so Oracle management is really expecting special treatment. IMHO I respond to bad dealings with a company by shopping elsewhere, not helping them improve their business practices. This is perhaps more significant than a mere decision over what goes into the next release. I see a really fantastic, rare opportunity for Debian to take a moral stand against Oracle for shameful mistreatment of free software to date. rock on \m/ Niels Thykier wrote: > I appreciate that the release team failed on action item several > months back and have not been very proactive in the communication. > And I am sorry that it has (and probably will) inconvenience you and > MySQL upstream. I do have personal sympathy for Debian contributors who became entwined, by their career choices, with the business preferences of Oracle and Canonical. And the team of MySQL developers who must work under Oracle's non-disclosure policies. But I don't think it should get in the way of doing whatever seems right for Debian's users and by its own principles. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: [Summary] Request for release team decision on MySQL and MariaDB
Hi, As a mere user (systems administrator), I'll share some questions / criticisms from my perspective that might help shed some light on the underlying issues. I was wondering why after the 2016-01-19 announcement, there is still no patched mysql-5.5 in jessie or wheezy; and also why mariadb was only just patched today. Debian is typically much faster than this at getting out patches. Is it to do with complexity, available manpower, or other things? Another concern I have is that when I check Debian's Security Tracker, I although I can see which CVEs apply to my (still unpatched) systems, the only descriptions I have are for example: "[...] allows remote authenticated users to affect integrity via unknown vectors related to encryption" That is definitely not okay in a free, open-source software project. I want to be able to evaluate how/whether my specific configuration is vulnerable and assess the risk for myself, while I wait for patches to come, and decide if I even want to apply them at all. Why is it that way? It reflects badly on Oracle that they don't or can't do better, and it reduces my personal trust in them. (It's in the Debian Social Contract, "we will not hide problems"). In contrast, for something as complex as the Linux kernel, I'm usually pointed to a specific Git commit showing how and where the bug was fixed, and there's often public discussion of the vulnerability in Red Hat's bug tracker or other sources. Assuming MariaDB is affected by the same issues, I may not be in a technically better situation if I switched to using that. (Although, it seems one of the recent CVEs did not affect MariaDB?). But I look at their public bug dashboard as a model of how open I want development to happen, and it makes me _feel_ more comfortable and optimistic in that project already. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: openjdk-7 not migrating?
Hi, Adam D. Barratt wrote: I assume this is due to the presence of openjdk-7-doc | 7u75-2.5.4-3 | unstable | all which appears to be being kept around due to the old kfreebsd-* binary packages. I didn't expect that kfreebsd FTBFS could still affect testing migrations. Is this a (rare, edge-case) bug in britney? We do have a patch to fix the kfreebsd FTBFS however: https://bugs.debian.org/788982 Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
openjdk-7 not migrating?
Hi, May I ask why openjdk-7 does not update from 7u75-2.5.4-2 to 7u79-2.5.5-1 in testing? https://qa.debian.org/excuses.php?package=openjdk-7 | Excuse for openjdk-7 | | 79 days old (needed 2 days) | openjdk-7-doc (amd64, i386, arm64, armel, armhf, mips, mipsel, powerpc, ppc64el, s390x) has new bugs! | Updating openjdk-7-doc introduces new bugs: #781577 | Not considered Bug #781577 is apparently fixed in the version that is trying to migrate. https://bugs.debian.org/781577 | Found in version openjdk-7/7u75-2.5.4-3 | Fixed in version openjdk-7/7u79-2.5.5-1 Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: Bug#782976: debian-installer-netboot-images packages kfreebsd images but kfreebsd is not in jessie.
Hi peter, I think it's been removed today already: https://packages.qa.debian.org/d/debian-installer-netboot-images/news/20150423T215008Z.html Do you agree? And this bug can be closed. It could presumablly be modified to look in an unofficial location Yeah, I guess we'll have a jessie-kfreebsd suite, where we patch this package to do exactly that. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: kFreeBSD CD/DVD builds for Jessie
Hi Steve, Steve McIntyre wrote: I know that the kFreeBSD ports are not being officially released [1]. What plans (if any) have been made for any *un*official releases? I've just removed the BSD builds from the debian-cd architecture lists in preparation for next weekend, but I've not heard anything more... kfreebsd as a whole, I feel has been in a releaseable state for some months (massive improvement over wheezy, and no bugs that are absolutely RC). I'd still like to make a stable release out of it. But since we need to move it to a jessie-kfreebsd suite first, I think we are behind schedule with that. I'm not familiar in that area, but Christoph was speaking with ftpmaster about it. I expect it will require changes in debian-installer (for new repository URLs), and there are other d-i issues I'd quite like to patch if possible, and lots of testing I wanted to do (incl. of CD images). Given how busy I am at the moment, I couldn't do that in time for the official release. Would it be reasonable and practical - even preferable - to postpone release of kfreebsd until at least 1-2 weeks after the official release? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: Digital signature
Re: Hints for d-i jessie RC3, part 2
Ivo De Decker wrote: On Thu, Apr 09, 2015 at 11:09:13PM +0200, Cyril Brulebois wrote: # no objections for d-i (kfreebsd-specific), but please check with BSD # guys (cc'd) before the matching unblock: unblock-udeb kfreebsd-10/10.1~svn274115-4 Added all of these. For kfreebsd, the unblock is still needed. Please feel free to unblock, it has security fixes only. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20150412133415.ga92...@pyro.eu.org
Bug#778734: unblock: bind9/9.9.5.dfsg-9
Cyril Brulebois wrote: No objection on my side, but let's give BSD folks a heads-up since isc-dhcp-client-udeb depends on bind9's udebs. Thanks, the changes seem to only relate to authoritative DNS zones though. No foreseeable impact on ISC DHCP or d-i. Regards -- Steven Chamberlain ste...@pyro.eu.org -- 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/20150226235625.ga5...@squeeze.pyro.eu.org
Bug#778734: unblock: bind9/9.9.5.dfsg-9
Steven Chamberlain wrote: Cyril Brulebois wrote: No objection on my side, but let's give BSD folks a heads-up since isc-dhcp-client-udeb depends on bind9's udebs. Thanks, the changes seem to only relate to authoritative DNS zones though. No foreseeable impact on ISC DHCP or d-i. Actually, the libs in the udebs have identical object code to before, only their BuildID differs. (I think this kind of analysis could be quite useful in the future, and is becoming easier thanks to the ongoing work on reproducible builds.) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20150227001150.gb5...@squeeze.pyro.eu.org
Bug#778366: unblock: kfreebsd-10/10.1~svn274115-2
Hi,
Michael Gilbert wrote:
Please consider unblocking kfreebsd-10. It fixes 2 security issues:
https://security-tracker.debian.org/kfreebsd-10
A debdiff is attached.
The other change is to limit the arch-dep packages to kfreebsd-any
(which was forgotten in the previous upload).
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
diff -Nru kfreebsd-10-10.1~svn274115/debian/changelog
kfreebsd-10-10.1~svn274115/debian/changelog
--- kfreebsd-10-10.1~svn274115/debian/changelog 2014-12-28 11:41:23.0
+
+++ kfreebsd-10-10.1~svn274115/debian/changelog 2015-01-28 01:18:06.0
+
@@ -1,3 +1,16 @@
+kfreebsd-10 (10.1~svn274115-2) unstable; urgency=high
+
+ * Pick SVN r277808 from FreeBSD 10.1-RELEASE to fix:
+- SA-15:02: SCTP SCTP_SS_VALUE kernel memory corruption and
+ disclosure vulnerability (CVE-2014-8612) (Closes: #776415)
+- SA-15:03: SCTP stream reset vulnerability (CVE-2014-8613)
+ (Closes: #776416)
+ * Build kernel images only on kfreebsd-any arches, so that any
+security or other RC-severity kernel bugs will not affect the
+official jessie release
+
+ -- Steven Chamberlain ste...@pyro.eu.org Tue, 27 Jan 2015 20:02:52 +
+
kfreebsd-10 (10.1~svn274115-1) unstable; urgency=medium
[ Steven Chamberlain ]
@@ -6,9 +19,6 @@
(CVE-2014-8476) (Closes: #768108)
* Replace non-DFSG-free ar9300_devid.h with a 3-clause BSD substitute
derived from Linux ath9k driver (Closes: #767583)
- * Build kernel images only on kfreebsd-any arches, so that any
-security or other RC-severity kernel bugs will not affect the
-official jessie release
[ Christoph Egger ]
* Upload to unstable
diff -Nru kfreebsd-10-10.1~svn274115/debian/control
kfreebsd-10-10.1~svn274115/debian/control
--- kfreebsd-10-10.1~svn274115/debian/control 2014-10-20 22:19:28.0
+0100
+++ kfreebsd-10-10.1~svn274115/debian/control 2015-01-27 20:40:49.0
+
@@ -51,7 +51,7 @@
Package: kfreebsd-image-10.1-0-amd64
-Architecture: any-amd64
+Architecture: kfreebsd-amd64
Depends: ${misc:Depends},
freebsd-utils (= 8.1-5) [kfreebsd-any], kldutils (= 7.1) [kfreebsd-any],
devd [kfreebsd-any] | freebsd-utils ( 8.2+ds2-9) [kfreebsd-any],
@@ -79,7 +79,7 @@
This package is compiled for a amd64-class machine.
Package: kfreebsd-image-10-amd64
-Architecture: any-amd64
+Architecture: kfreebsd-amd64
Depends: kfreebsd-image-10.1-0-amd64, ${misc:Depends}
Description: kernel of FreeBSD 10 image (meta-package)
This package depends on the latest binary image for kernel of FreeBSD 10 on
@@ -496,7 +496,7 @@
This package contains zlib modules.
Package: kfreebsd-image-10.1-0-486
-Architecture: any-i386
+Architecture: kfreebsd-i386
Depends: ${misc:Depends},
freebsd-utils (= 8.1-5) [kfreebsd-any], kldutils (= 7.1) [kfreebsd-any],
devd [kfreebsd-any] | freebsd-utils ( 8.2+ds2-9) [kfreebsd-any],
@@ -524,7 +524,7 @@
This package is compiled for a 486-class machine.
Package: kfreebsd-image-10-486
-Architecture: any-i386
+Architecture: kfreebsd-i386
Depends: kfreebsd-image-10.1-0-486, ${misc:Depends}
Description: kernel of FreeBSD 10 image (meta-package)
This package depends on the latest binary image for kernel of FreeBSD 10 on
@@ -549,7 +549,7 @@
486-class machines.
Package: kfreebsd-image-10.1-0-686
-Architecture: any-i386
+Architecture: kfreebsd-i386
Depends: ${misc:Depends},
freebsd-utils (= 8.1-5) [kfreebsd-any], kldutils (= 7.1) [kfreebsd-any],
devd [kfreebsd-any] | freebsd-utils ( 8.2+ds2-9) [kfreebsd-any],
@@ -577,7 +577,7 @@
This package is compiled for a 686-class machine.
Package: kfreebsd-image-10-686
-Architecture: any-i386
+Architecture: kfreebsd-i386
Depends: kfreebsd-image-10.1-0-686, ${misc:Depends}
Description: kernel of FreeBSD 10 image (meta-package)
This package depends on the latest binary image for kernel of FreeBSD 10 on
@@ -602,7 +602,7 @@
686-class machines.
Package: kfreebsd-image-10.1-0-xen
-Architecture: any-i386
+Architecture: kfreebsd-i386
Depends: ${misc:Depends},
freebsd-utils (= 8.1-5) [kfreebsd-any], kldutils (= 7.1) [kfreebsd-any],
devd [kfreebsd-any] | freebsd-utils ( 8.2+ds2-9) [kfreebsd-any],
@@ -630,7 +630,7 @@
This package is compiled for a xen-class machine.
Package: kfreebsd-image-10-xen
-Architecture: any-i386
+Architecture: kfreebsd-i386
Depends: kfreebsd-image-10.1-0-xen, ${misc:Depends}
Description: kernel of FreeBSD 10 image (meta-package)
This package depends on the latest binary image for kernel of FreeBSD 10 on
diff -Nru kfreebsd-10-10.1~svn274115/debian/patches/SA-15_02.kmem.patch
kfreebsd-10-10.1~svn274115/debian/patches/SA-15_02.kmem.patch
--- kfreebsd-10-10.1~svn274115/debian/patches/SA-15_02.kmem.patch
1970-01-01 01:00:00.0 +0100
+++ kfreebsd-10-10.1~svn274115/debian/patches/SA-15_02.kmem.patch
2015-01-27 20:37:34.0 +
@@ -0,0 +1,51 @@
+Description:
+ Fix SCTP SCTP_SS_VALUE kernel memory corruption
Re: Last hints for d-i, upload tomorrow
Hi! On 06/01/15 00:04, Cyril Brulebois wrote: Ivo De Decker iv...@debian.org (2015-01-06): First of all: would you be ok with an unblock-udeb for kfreebsd-10? Provided Steven/BSD people are fine with it (possibly with urgenting), I'm very OK with having it in testing before d-i gets uploaded. I almost asked but decided to try and skip some more back and forth. Let's do that now anyway, then. :) Yes I'm fine with this, thanks. (There's a reason I didn't ask for unblocks sooner but that's a long story and unrelated to d-i). Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#773548: unblock: bind9/1:9.9.5.dfsg-7
Hi, Cyril Brulebois wrote: Non-linux porters may want to double check this new version isn't going to lead to regressions on their architecture(s) though, so letting them know through Cc (patch available below). Thanks for checking with us. Seems like only DNS resolver code was changed, I don't think d-i uses any part of that, and needs only unrelated library functions for ISC dhcpd. Still, with the updated libs d-i still completed successfully (a netboot install involving DNS resolution and using DHCP). This test-run was more than 24 hours after 1:9.9.5.dfsg-7 built on kfreebsd-amd64 so would have been using the new udebs. https://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_kfreebsd/447/ Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20141221152320.ga13...@squeeze.pyro.eu.org
Re: Plan B for kfreebsd
Hi, Peter Palfrader wrote: I think having a jessie kfreebsd release is a prerequisite for keeping the debian.org machine resources (buildds, porterboxes). The buildds and porterboxes serve unstable. Removing it from there would be even more devastating than being dropped from the official release and/or testing. There will be an unofficial release though, and I imagine the buildds would be upgraded to that still? DSA can't maintain rolling releases or testing systems for any length of time. I'm not quite sure what you mean; particularly how those involve DSA. What systems would you need to maintain besides the buildds for sid? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/2014111953.gb14...@squeeze.pyro.eu.org
Re: Plan B for kfreebsd
Lucas Nussbaum wrote: [...] if that's helpful, Debian funds could be allocated to that effect. (Note that, concretely, I don't really see how Debian funds could help here; but you might have more ideas) Thanks Lucas; I think there are places where Debian funds or resources could be useful - like KVM VMs, or public cloud credits - otherwise I may have been looking for sponsors for these things : * somewhere to build and host the install media * somewhere to host repositories: - snapshots.d.o could already be useful as basis for stable - a supplemental repository for stable, which I'm sure we'll need - a repository for an unofficial testing-like suite, possibly * somewhere to build security and stable updates ourselves, if we can't do that on the regular buildds * random/cool stuff: - http.d.n-like redirector, in preference to a mess of APT sources - place to run c-i testing, QA tools - infrequent archive-wide rebuilds Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/2014114117.gc14...@squeeze.pyro.eu.org
Re: Final kfreebsd-10 upload before freeze?
Christoph Egger wrote: Uploading kfreebsd-10 10.1-RC4 in a minute and I guess see for -final Final release has been tagged. After the setlogin security fix, there was only one more change - but it's kind of odd: http://freshbsd.org/commit/freebsd/r274367 To fix a crash bug in a driver module, they've backported a whole new version from 10-STABLE branch. That's really unusual. Since technically, kfreebsd-10 is still part of the official release (it builds also on linux), we should fix the security bug anyway, and still ask for an unblock due to that. This ixl/ixvl driver update seems a bit big to include in such an unblock request. (Although, for our unofficial release, we'd more likely want to include that bugfix). What to do? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/2014135744.gg14...@squeeze.pyro.eu.org
Re: Final kfreebsd-10 upload before freeze?
On 12/11/14 00:14, Christoph Egger wrote: Speaking of which -- people from -release@ already wondered (and I agree there) why we would want to keep building the kfreebsd kernel on linux. We may want to get it removed on linux so we don't have to handle it at two different places for little gain. What do you think? I suppose it's a mere novelty that it does build on Linux; but with linux arches being supported stable, and kfreebsd itself now not, it seems like time to remove it there, yes. This ixl/ixvl driver update seems a bit big to include in such an unblock request. (Although, for our unofficial release, we'd more likely want to include that bugfix). What to do? It is *huge*. Guess if we were still considered for normal stable I would ask for pre-approval based on faith in freebsd release process somehow. As it stands I think -release@ would rightfully reject it. OK I agree, I don't see any point to burden release team with that part. But let's upload the -RC4 snapshot from SVN with the pre-approved bugfixes, fix the security bug, and make it kfreebsd-any, tying off all those loose ends. The driver backport seems like something we'd add into our unofficial stable release later, as it's a crash bug for someone having that particular hardware. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/5462aa2b.80...@pyro.eu.org
Re: Plan B for kfreebsd
Petr Salinger wrote: Jonathan Wiltshire wrote: [...] though we do hope that the porters will be able to make a simultaneous unofficial release. It is unclear, what we have to duplicate. Do we stay in testing ? I'd like to know this as soon as possible as it affects our planning. Thanks. If we don't stay in testing, we'd at least want to archive off the last-built kfreebsd packages before they are deleted... Will be there a repository copy in time of official stable release ? A snapshot would be the basis of any unofficial stable release. To support it as best we can, we might like to update it (either in-situ, or in a separate repository) with stable and security updates applied. Maybe just for the core kfreebsd packages we maintain, but ideally the whole archive depending on resources. The same snapshot could also be cloned as the basis of an unofficial testing release; if we could update it with packages from the official Debian sid (trying to mirror what Britney is doing) what we'd have is a kind of rolling release. We could also hold packages back at older versions if they'd introduce portability issues. In the old days, we used to have unreleased suite on debian-ports, it augmented sid whenever we needed a different version of a package. I'd like to avoid that in sid - so that it still works properly using only official packages. But certainly for unofficial releases, a supplemental repository would be great for us. We can bypass usual freeze policy to fix bugs we think are important, which may not have got an unblock. We can apply kfreebsd patches to some packages, such as in the Xorg Intel graphics driver to make it work better out-of-the-box for users. We can even overrule maintainers' decisions; perhaps make openjdk-7 our default JRE, change APT config to not install recommends, override default shell or MTA ;) So - while I disagree with the release team's decision - being an unofficial release doesn't have to be a bad thing for us. It actually gives us freedom to make improvements as we see fit. And it could be a lot of fun. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20141110220944.ga12...@squeeze.pyro.eu.org
Re: Plan B for kfreebsd
Hi, Andreas Barth wrote: * Steven Chamberlain (ste...@pyro.eu.org) [141110 23:10]: Petr Salinger wrote: It is unclear, what we have to duplicate. Do we stay in testing ? I'd like to know this as soon as possible as it affects our planning. Thanks. If we don't stay in testing, we'd at least want to archive off the last-built kfreebsd packages before they are deleted... That sounds sensible. As you want to do an unofficial release, I think we should coordinate so that this doesn't create unnecessary additional efforts. Thank you, and others who have offered to help as they can; but I'm sad we're having to do this instead of being part of the official release, and thus duplicate a lot of process/infrastructure that was already in place since wheezy. I don't know how the others feel about, when should kbsd be removed from testing? That would give some impression how fast this should be done. Is that a 'no' in answer to Petr's question: kfreebsd actually must be removed from testing? I think removing it anytime in the next 1-3 months would be okay from our point of view. Would you normally delete the packages outright, or archive them off in any place similar to archive.d.o? I guess snapshots.d.o would still have copies of the last packages that were _in_ testing? But won't have the indices _for_ testing. But certainly for unofficial releases, a supplemental repository would be great for us. We can bypass usual freeze policy to fix bugs we think are important, which may not have got an unblock. I'd replace that with that allows to have an freeze policy centered around kbsd. I don't think it's limited to that; in making an unofficial release, we become our own release managers, and can try to apply our own... personal taste here. I'll discuss that on -bsd@ rather than here. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20141110230127.ga13...@squeeze.pyro.eu.org
Re: Plan B for kfreebsd
Christoph Egger wrote: Steven Chamberlain ste...@pyro.eu.org writes: But certainly for unofficial releases, a supplemental repository would be great for us. We can bypass usual freeze policy to fix bugs we think are important, which may not have got an unblock. I guess we need that in some way -- we need to do some uploads that do not concern the normal release process like a last kernel upload. Also, between now and release there is a risk of kfreebsd regressions introduced into testing that we want to hold back / revert. I've had opinions for a while that Debian freeze policy has some flaws, concerning not just kfreebsd but the rest of the distro. An unfortunate consequence of having a fixed freeze date, is that many big changes are rushed in at the last moment. (c.f. http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/mgp5.html) Then during freeze, when most testing happens, we discover the trivial, annoying bugs that accumulate to make user experience less than ideal - but by then we can't fix them, because in the Debian BTS they only qualify as 'important' or lower severity, and likely not eligible for unblocks. You and I probably have made dozens of tiny changes on our own kfreebsd systems to make them work smoothly. For other, especially new users, those could be a total roadblock and I want to avoid that if we can at all. I've seen examples of users get frustrated by already-known issues like that and give up on using kfreebsd, and it's sad to see. I don't think it's limited to that; in making an unofficial release, we become our own release managers, and can try to apply our own... personal taste here. I'll discuss that on -bsd@ rather than here. Which also needs we need to do that. For almost all of debian, the normal release procedures should really work fine for us as well and the more we can get automatically the better IMHO. There may at least be some short-cuts we can take, things we can do to make the unofficial release easier for just a few of us to support. We could declare some packages unsupported perhaps. This is another rant coming, sorry, but I think it's relevant when we're talking about doing an unofficial release: I do feel many Debian procedures take way too much time and involve many people to fix trivial issues. A major usability problem might be fixable with just a one-line config file edit, but often there'd be a bug report, perhaps patch submitted by someone else or picked from upstream where it was fixed already; maintainer commits it to a packaging repo, uploads, it's built and waits for dinstall, and then testing migration. So for users running testing it could be 7-14 days for fixes to reach their machines. Arguably some of that time is meant for QA, but some of it is really just waiting around for some next step to happen. (And there are other good ways to supplement QA besides this). For stable, there might need to be a separate upload prepared, debdiff sent to -release@ and reviewed, approved then uploaded, built, queued for many weeks until next point release. In that case there may have been at least 4 people each do some amount of work for that obvious change, probably one of hundreds in the stable release lifetime. Or it may not meet the criteria and have to wait *2 years* or so for the next release. Imagine this was a problem faced in a corporate IT deployment. It wouldn't be acceptable to have such a workflow; work time is scarce, and the issues could be affecting others' work until fixed. Surely the same constraints or goals apply to a volunteer software distribution? Plus everywhere we diverge from the normal release process we need to stay atop of these deltas for the whole time. That's a good point I will try to bear in mind when I get carried away! In sid, by the way, I'd prefer things to stay totally in keeping with Debian practices so that maintainers can still, if they wish, build and maintain their packages for kfreebsd as they do already. Changes we make should ideally go into sid and not just stay in an unofficial repo. There's also stable updates and security we need to think of. I guess stable updates can be handled without problem manually as it's punctual and not so time critical. Yes, the stable-pu queue has debdiffs, we can somehow build updated packages based on those and update an unofficial stable repo, in sync with point releases. security is actually what worries me most. Guess ideally we can still source from security on wanna-build so builds just happen whenever there's a update. For the kfreebsd core packages (kernel and such) it's actually easier that we don't have to involve the security team and can update those directly in an unofficial repo. For the rest of the archive, we can try and do similar to the above; we might have to wait for updated source packages to become public, due to the embargo around security issues and the private security
Re: Re: Plan B for kfreebsd
Sorry, actually meant to take -release@ out of Cc: for that mail. Please follow up to -bsd@ if you have comments on it. Thanks. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/546171eb.3070...@pyro.eu.org
mips buildds (was: Re: Bits from the Release Team: transitions, architectures, freeze!)
Adam D. Barratt wrote: * mips [3] [3] Current hardware is a concern, but in the process of being dealt Hi, mips had a huge backlog of unbuilt packages which has cleared very quickly in the past 2 days: https://buildd.debian.org/stats/graph2-week-big.png Is that due to having new hardware now? I notice a new mips machine in use I've not seen before: https://db.debian.org/machines.cgi?host=mips-aql-02 could porters explain a little about that? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20141104135219.gd21...@squeeze.pyro.eu.org
Re: mips buildds (was: Re: Bits from the Release Team: transitions, architectures, freeze!)
Aurelien Jarno wrote: It's mostly due to me having started again a temporary build daemon called swarm, after getting the agreement from the release team. It is hosted in my home and not DSAed, so it means manual signing and so on. Oh, thanks for that. I was concerned some packages could miss their migration because of the mips build queue (after the surge in uploads right before freeze). It seems that situation might been averted by this. I notice a new mips machine in use I've not seen before: https://db.debian.org/machines.cgi?host=mips-aql-02 [...] I take the opportunity of this email to thanks all the persons who made that possible: DSA, ImgTec for the hardware, AQL for the hosting and probably a few other persons I have forgotten/I am not aware of. I might add that it sounds like a great piece of hardware if it's what I think it is: EdgeRouter Pro (Cavium Octeon II + 8GiB RAM), a 1U router with many gigabit Ethernet ports, and running a full, free Debian OS? Could be worth mentioning to debian-publicity@, or on planet.d.o especially if there are photos ;) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20141104214522.gd23...@squeeze.pyro.eu.org
Final kfreebsd-10 upload before freeze?
Hi, kfreebsd-10 migrated last night; is there a chance another upload of the kernel could go into sid and be aged in before the freeze starts? +kfreebsd-10 (10.1~svn273874-1) UNRELEASED; urgency=medium + + * Upload to unstable + * New upstream snapshot of 10.1-RC4 FreeBSD.org hasn't published an announcement for RC4 yet, which would explain the changes in more detail, but there were only a few bugfixes applied: - revert a GEOM optimisation that possibly caused data corruption in some environments - fix ATA CF ERASE - something corrected in the HyperV drivers - unspecified bug fixed in Intel EPT and in VMM (from http://www.freshbsd.org/search?project=freebsdq=file.name%3Areleng%2F10.1%2Fsys) and also bring in the following changes, already in experimental: * New upstream snapshot of 10.1-RC3+ - Fix memory leak in sandboxed namei lookup. [SA-14:22] (CVE-2014-3711) (Closes: #766278) * Symlink to drm2.ko as provider of drmn.ko dependency, for *kms modules (Closes: #731182) * NEWS: advise to reboot after upgrading kernel and userland tools from wheezy (Closes: #765588) I think all of these make sense, although none of them were RC bugs which is why I'm asking in advance. A snapshot of RC4 should be exactly what releases with FreeBSD 10.1, which was rescheduled for 10th November 2014. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#767431: jessie-ignore: kfreebsd RC bugs don't affect jessie
Package: release.debian.org Tags: jessie Dear Release Team, Please could you perhaps set jessie-ignore tags for: #748743 kfreebsd-8: triple fault on execve from 64-bit thread to 32-bit process #754237 kfreebsd-9: SCTP kernel memory disclosures (CVE-2014-3953) The UDD bugs search, lists those as RC bugs affecting jessie and sid, though in fact those packages were removed already from those suites. They're only mentioned here because debian-installer-netboot-images references them in the Built-Using field. This is perhaps correct behaviour of UDD, but it is understood that debian-installer-netboot-images will be updated to use only kfreebsd-10 as part of the release process: http://lists.debian.org/20141028133854.gd1...@mraw.org If not for those two bugs, kfreebsd wouldn't have any RC bugs left in jessie, that are not already done (#766430), pending upload (#740509) or having patch (#649038). So it would be nice to clean this up. Thanks! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20141030232813.96498.76102.report...@sid.kfreebsd-amd64.pyro.eu.org
Bug#767431: jessie-ignore: kfreebsd RC bugs don't affect jessie
On 30/10/14 23:39, Julien Cristau wrote: I believe this should be fixed in UDD, and jessie-ignore would be inappropriate for packages that are not in jessie. Okay. I thought it was maybe intentional behaviour of UDD. If some package really is Built-Using something out-of-date and RC-buggy, we'd usually want to know about it. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#766873: release.debian.org: Please reduce age for cfengine3
Hi, Antonio Radici wrote: The latest version (3.6.2-4) is building everywhere and it will be really great if you could reduce its age to 6 days so that we can have it in Jessie, since the existing version is quite old. I think this will already migrate in time for the freeze? The freeze is at 23:59 UTC on 2014-11-05, which is 10 days from now. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20141026200744.gd20...@squeeze.pyro.eu.org
Re: squid3_3.4.8-1 waiting in unstable with security fixes
On 20/10/14 18:38, Emilio Pozuelo Monfort wrote: On 20/10/14 19:20, Luigi Gangitano wrote: Il giorno 20/ott/2014, alle ore 19:14, Adam D. Barratt a...@adam-barratt.org.uk ha scritto: out of date on kfreebsd-amd64: squid-cgi, squid-purge, squid3, squid3-common, squid3-dbg, squidclient (from 3.3.8-1.2) out of date on kfreebsd-i386: squid-cgi, squid-purge, squid3, squid3-common, squid3-dbg, squidclient (from 3.3.8-1.2) That is actually caused by #764897 and should be fixed as soon as the next package is uploaded. You'll need to request a give back on debian-wb-team when that happens, and then your package should migrate when it becomes old enough (which should happen in 7 days). All done. (Bug in kfreebsd-kernel-headers fixed, squid3 given back and built). Perhaps the release team could hint it into testing if the security fixes are urgent? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/5446b011.7090...@pyro.eu.org
Bug#765639: wheezy-pu: openssl new upstream version
Hi, On 16/10/14 21:12, Kurt Roeckx wrote: This would actually make things for me much more simple. I sometimes run into problems because of missing bug fixes that have been done earlier in the branch. And I generaly think that the 1.0.1j version is much better than then 1.0.1e version. AIUI that would enable TLS v1.1, v1.2, and GCM cipher modes not available in the current wheezy version? These are highly desirable in production for me. FWIW the latter is specified by NSA Suite B. The wheezy-pu's of Tor might be some precedent for keeping crypto software up-to-date. OTOH Heartbleed only affected those who'd upgraded already from openssl 0.9.8 - 1.0.x, so one takes a risk either way? Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Uploading kfreebsd-10 (10.1~svn272463-1)
Hi, As I've mentioned before on -boot@ and -release@, we intend to upload a new kfreebsd-10 package with the kernel of FreeBSD 10.1-RC1. This will be accompanied by updated userland packages worked on my Christoph, Petr and myself. (Axel already updated the freebsd-manpages in sid.) Until now they have been staged in experimental, pending the release of d-i Beta 2, because they will update udebs. We will also need to update the minor version in debian-installer Git for daily d-i builds to still work. @KiBi: are we at the point where we can make these changes now? Potentially-affected reverse build-dependencies are limited to the kfreebsd-* architectures. No binNMUs are needed. A test-rebuild of core and toolchain packages only found regressions that actually date back to the 9.2-10.0 userland update already in sid/jessie, so those have been filed/fixed along with other bugs closed by these packages: RC bugs: #751316, #753773, #756786, #762372, #752194, #762199 Important bugs: #754799, #755739, #750836, #756553, #653929 Once it migrates to jessie, we'll be removing kfreebsd-9 from sid/jessie, thus closing RC bugs: #750493, #730004 (issues not affecting stable, or already fixed by wheezy-sec upload) I think that leaves us with only three unpatched RC bugs affecting jessie: #740509, #734451, #761418 Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20141004234937.gd17...@squeeze.pyro.eu.org
Re: Time for Jessie Beta 2?
On 06:02, Cyril Brulebois wrote: I've discovered #763580 though, so I might revert this change for now since I don't want to reintroduce this bug right now, and generate more work for translators because of an errata we could and should have avoided, since that problem was warned against already. We're possibly looking at an upload this wednesday (European) afternoon. Bringing back the bug from d-i Beta 1 (#712907 auto preseed installs get stuck) seems like the lesser evil than (re)introducing #763580. Obviously we can't find a better fix in this short timeframe, but I hope we can try again for Beta 3. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20141001133804.gb5...@squeeze.pyro.eu.org
Re: kFreeBSD port in Jessie
On 25/09/14 22:10, Jonathan Wiltshire wrote: The results of the final architecture qualification will soon be published. In there is reference to a number of concerns about the kFreeBSD port and its place in Jessie. Thanks for this heads-up; I'd seen the release team's mail to d-d-a. We'll probably put out a status update in a few days and reply respond directly, but for now I did mention some release team concerns in this thread: http://lists.debian.org/542b142d.10...@pyro.eu.org Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#763058: nmu: doxygen_1.8.7-3
On 08:36, Julien Cristau wrote: On Mon, Sep 29, 2014 at 02:26:11 +0100, Steven Chamberlain wrote: So AIUI Sylvestre needs to remove that symlink in a new upload, but all reverse-deps must be NMUd to use the new, versioned library name e.g. libclang-3.5.so.1. Except I think the package name needs to be changed in order to do that, so perhaps a soname bump to libclang-3.5.so.2 provided by libclang2-3.5? I don't think the package name and SONAME changes are necessary; libclang-3.5.so.1 is unambiguous, and libclang1-3.5 is not in wheezy. Doxygen in sid/jessie has a dependency on libclang1-3.5 but still looks for libclang.so.1, which was once shipped by that package. That's why I thought the package name must change, to make sure all incidents of this are cleaned up, and any package with dependency on libclang1-3.5 (possibly broken) transitioned to something like libclang2-3.5 (only shipping a libclang-3.5.so.2 and not libclang.so.1). By the way, the doxygen issue was temporarily fixed by the symlink and brltty was able to build; if there is going to be a new upload to try to address this it could perhaps go to experimental first, if that makes it any easier to review and check it? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20140929123718.gb29...@squeeze.pyro.eu.org
Bug#760050: transition: llvm-toolchain-3.5
Hi, On 21:44, Cyril Brulebois wrote: Sylvestre Ledru sylves...@debian.org (2014-08-31): However, I am planning to keep llvm 3.4 in the archive. So, packages not supporting 3.5 won't be deleted. We will just have to force the version 3.4. Moreover, switching toolchain defaults while we're trying to freeze library transitions doesn't look like a good idea; especially since 3.5 packages aren't exactly bug free. FWIW when building kfreebsd (kernel package) we already explicitly depend on clang-3.4, in order to be not impacted by a change of default such as this. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20140928200657.gc26...@squeeze.pyro.eu.org
Bug#763058: nmu: doxygen_1.8.7-3
Hi, [I'm trying to learn to understand this kind of thing, as well try to elaborate on what Julien said, so please correct me if I'm wrong]. On 01:19, Julien Cristau wrote: On Sun, Sep 28, 2014 at 21:25:07 +0200, Andreas Barth wrote: * Andreas Barth (a...@ayous.org) [140928 14:32]: What works in practice, and seems to be ok-ish from a theoretical POV is to create a symlink from libclang-3.5.so.1 to /usr/lib/`dpkg-architecture -qDEB_BUILD_MULTIARCH`/libclang.so.1 during build time (as part of the deb file). This allows doxygen to work again. That seems wrong. If wheezy's libclang1 and jessie's libclang1-3.5 aren't binary-compatible, the latter shouldn't provide a libclang.so.1. Assuming they're not meant to be binary-compatible: It looks like libclang.so.1 has been provided by different versions of the LLVM toolchain since wheezy, and that was wrong. I don't think the LLVM 'default version' transition itself caused this, but merely exposed an existing problem, one that can't be reverted. Already some packages were built with libclang-3.4-dev (e.g. mesa, vim-youcompleteme) or libclang-3.5-dev (e.g. doxygen). So doxygen for example expects libclang.so.1 to be provided by libclang1-3.5. When that file was (rightly) removed from libclang1-3.5 it was left broken. Restoring a symlink from libclang.so.1 may fix it temporarily but is not a correct thing to do; some other package (now, or in the future) may expect libclang.so.1 to come from a different LLVM version and may have been subtly broken for some time already. So AIUI Sylvestre needs to remove that symlink in a new upload, but all reverse-deps must be NMUd to use the new, versioned library name e.g. libclang-3.5.so.1. Except I think the package name needs to be changed in order to do that, so perhaps a soname bump to libclang-3.5.so.2 provided by libclang2-3.5? The existing transition bug and tracker could possibly be repurposed for this? https://release.debian.org/transitions/html/llvm-defaults-3.html Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20140929012610.gh26...@squeeze.pyro.eu.org
Re: Your procps upload 1:3.3.10-1
Hi, On 08:42, Craig Small wrote: I thought that: New package goes into SID = no real problem. That's maybe only true for 'leaf' packages in sid. And anything in experimental. The frozen set of packages come from testing, not Sid, so as long as procps wasn't moved from Sid to testing, then it would not mess up the don't change libraries stage we're in now. But the buildd chroots take packages from sid, so a reverse-dependency of procps could pick up a dependency on procps = 1:3.3.10; then that package then can't migrate unless procps does too. And still, if a reverse-dependency FTBFS because of the procps change, that could delay the transition of some other library. (And yet more packages that were waiting on it to migrate). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20140927225618.gc23...@squeeze.pyro.eu.org
Bug#760114: GNU/kFreeBSD sprint, fast porterbox access
Hi, I'm going to privately rent a VM from BigV.io for approximately one week to do some Debian GNU/kFreeBSD work: * to test jessie d-i, particularly partman-zfs * clang-3.4, #759303: Does not have multiarch include paths on !linux * kfreebsd 10.1, #760114: transition: kfreebsd-kernel-headers * gcc-4.9, #761277: gdc uninstallable on kfreebsd because of missing dep. libphobos-4.9-dev If anyone would find it useful, please send me your SSH public key (via GPG-signed email, please) and you can have access. But remember the machine will be gone in 7 to 10 days from now. If this all goes to plan, there'll be two sid chroots (jails, actually) both accessible via ssh: kfreebsd-amd64 and kfreebsd-i386, but the host kernel will be kfreebsd-amd64 10.1 (from experimental). I'll be tuning it to get the fastest possible disk I/O (using ZFS). Initially it will have only 2 cores + 4GiB memory, increasing later if needed to 3 cores + 8GiB memory or more. The (compressed) filesystem will have 50GB space increasing later if needed. And about 8GiB swap. BigV.io is a public cloud product of Bytemark, a Debian sponsor. They have a full Debian mirror in the same datacentre (York, UK). I wanted to test anyway that GNU/kFreeBSD installs and runs nicely on it (based on KVM, using virtio). I need to do some test rebuilds for #760114 involving big packages with slow testsuites like glibc, gcc-4.9; I'll probably SIGSTOP these while any interactive users are logged in to keep things fast for any porting work. screen and tmux will be available. I'll perform at least two builds of packages maintained by debian-...@lists.debian.org, for the http://wiki.debian.org/ReproducibleBuilds effort. With whatever time is left I'll try to rebuild (only once) all of build-essential and perhaps other things. Have fun! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#760114: transition: kfreebsd-kernel-headers
Hi Emilio, On 10/09/14 20:16, Emilio Pozuelo Monfort wrote: [...] what packages are involved, what packages need rebuilds, and of those, which ones currently fail. The root of this is kfreebsd-source-10.0, from the kfreebsd-10 source package. kfreebsd-kernel-headers [kfreebsd-any] has Build-Depends on that exact version, so it needs a new upload to use kfreebsd-source-10.1. That has been done in experimental. I don't think anything *requires* a rebuild for this, but kfreebsd-kernel-headers is an indirect dependency of build-essential on kfreebsd. I expect you'll want us to check we didn't break anything. But I was hoping for some hints on how far to go with this. If something does break, it would be on kfreebsd only, and something porters then need to fix. A simple 'apt-cache rdepends' points to freebsd-glue, freebsd-libs (both have been rebuilt against new kfreebsd-kernel-headers in experimental), and glibc. Some other packages set an explicit Build-Depends on kfreebsd-kernel-headers, although they don't really need to: freebsd-smbfs freebsd-utils gcc-4.8 gcc-4.9 gnat gnome-mplayer pd-iemambi pmacct sash ufsutils wine zfsutils I haven't test-rebuilt these yet, but would glibc and everything from that list be confidence enough that the 10.0 - 10.1 changes didn't obviously break something? (AFAIK the 9.0 - 9.2 - 10.0 changes in the past year were done without much/any co-ordination at all with the release team, but I'm trying to do the right thing by asking here first). Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/5410b038.7020...@pyro.eu.org
Re: kfreebsd-* release status?
. Thanks! Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#755539: transition: hdf5
block 749395 by 760125 block 749395 by 760162 thanks Hi, shogun did not build on all architectures, please see these two bugs with patches / suggestions. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/540468c6.5030...@pyro.eu.org
Bug#755539: transition: hdf5
# in DELAYED/1 close 760125 3.2.0-7.2 unblock 749395 by 760125 unblock 749395 by 760162 # still an issue in shogun packaging severity 760162 important clone 760162 -1 retitle 760162 shogun: builds docs in binary-arch target # also an issue in graphviz reassign -1 src:graphviz found -1 graphviz/2.38.0-5 retitle -1 graphviz: [kfreebsd] multithreaded dot hangs sometimes affects -1 shogun thanks On 01/09/14 14:08, Gilles Filippini wrote: Hrm... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760120 I didn't see any RC bugs filed against shogun and didn't notice that one... Ah well! Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/540473c5.9070...@pyro.eu.org
Bug#760114: transition: kfreebsd-kernel-headers
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Hi, This is not a mere transition but our ambition to use kFreeBSD 10.1 as our kernel version for jessie. This is primarily driven by the FreeBSD 10.1 release schedule; they have gone into a 'code slush' which resembles Debian's early freeze, with a final freeze date of 5th September, then they begin beta builds. That applies to their entire distribution, not just their kernel. http://www.freebsd.org/releases/10.1R/schedule.html A major consequence of their release schedule is that 10.0 security support will have ended by the time Jessie is released. 10.1 should get long-term security support, which means two years from release. http://www.freebsd.org/security/security.html#sup Within Debian: * packaging of 10.1 snapshots began some 3 weeks ago, it is in experimental and got through the NEW queue already * Christoph has been running it throughout DebConf * it's working fine with d-i: I've been using 10.1 kernels exclusively while working on the bugs reported in d-i beta 1 (even udebs based on 10.0 or older userland) * the snapshots are based on 10-STABLE, so it is not a development trunk; it is viable to use a snapshot of this for Debian even if the final 10.1 release comes too late to reach sid/jessie * we're already using some features that were new/unimplemented in 10.0, such as newcons that Robert backported an early version of, and KMS which should have matured some more in 10.1 * clang-3.3 is being dropped from jessie/sid in favour of clang-3.4 or 3.5: upstream already builds 10.1 with clang-3.4, whereas 10.0 would need some bits backported by us (not too difficult though) The actual 'transition' part will be kfreebsd-kernel-headers from 10.0 to 10.1 (a snapshot is in experimental; we could update it to a newer snapshot in a few days). It already went through a 9.2-10.0 transition earlier this year. Reverse-Depends are mostly our own freebsd-libs, libc0.1-dev, and from there it could affect many more things. Still it doesn't seem like a regular transition, I don't know if a Ben file could be written to describe it. It should not make anything uninstallable by migrating to jessie. amd64/i386 hardware is easy to get a hold of, so we could do some test rebuilds where it seems like a good idea. Thanks! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20140831215501.76522.79850.report...@sid.kfreebsd-amd64.pyro.eu.org
Re: kfreebsd-* release status?
On 19/08/14 00:40, Cyril Brulebois wrote: [ I'm adding -release@ to the loop. I tried to refrain from mentioning my concerns in the Jessie Beta 1 announce, that's why I used a quite neutral wording, but let's be honest: kfreebsd-* is looking bad right now. ] I was drafting a quite long reply to this, but after 15 minutes, I realised whatever precious time we have, needs to be spent fixing the bugs, not discussing this. So I'll reply to each of the bugs individually. In short, yes I think kfreebsd does have high workload right now; we could use more help as the freeze approaches, but I'm not worried. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: Preparing (lib)gnome-keyring for the freeze.
On 15:45, Steven Chamberlain wrote: This did expose an important issue though - mlock() may be not working yet on kFreeBSD, even on a sufficiently recent kernel where we'd expect it to. Actually, with the latest 10.0 kernel package from sid, mlock() by unprivileged user is fully working, and the full libgnome-keyring testsuite passes. I think the kfreebsd buildds are supposed to keep running a stable 9.0 kernel until at least the start of the freeze period. Would it be appropriate in this situation for binNMUs by a DD using kfreebsd-amd64 and kfreebsd-i386 10.0 kernels? (We had a similar issue with some other package requiring a 10.0 kernel feature; I forget now what it was.) Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20140803094718.ga20...@squeeze.pyro.eu.org
Re: Preparing (lib)gnome-keyring for the freeze.
On 08:47, Andreas Henriksson wrote: To sum up the current problem, the versions in unstable are RC-buggy because of FTBFS. The FTBFS is caused by a newly introduced testsuite which basically showed the package never worked on kFreeBSD. I assumed the package would still work; unless I overlooked something, the code contains a fallback to regular malloc in case mlock() is not possible? The failing test has code to check that it actually did use mlock(). Making the testsuite failure cause FTBFS of the package on kfreebsd therefore seems... premature. This did expose an important issue though - mlock() may be not working yet on kFreeBSD, even on a sufficiently recent kernel where we'd expect it to. Time-permitting, we'd surely like to fix it for jessie, and perhaps we will. But I personally don't see it as a release-critical feature since it isn't a regression and is an optional part of POSIX. There may be some new issues during build/testsuite now as mentioned by Bastian. If so, I'd probably look into those first. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20140802144547.ga18...@squeeze.pyro.eu.org
Bug#753781: Heads up: transition: xserver 1.16
On 10/07/14 09:07, Emilio Pozuelo Monfort wrote: That package is not marked as auto-buildable, which means it doesn't build on the Debian buildds and thus it can't be binNMUed. So you'll have to upload it manually, or ask the wanna-build team to make it auto-buildable. In any case xserver-xorg-video-nv 1:2.1.20-3 will need to be uploaded first (from SVN 5427), which adds the XS-Autobuild flag. Only after that is done, can we ask for autobuilding to be set up, according to: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#non-free-buildd Please could a DD among the GNU/kFreeBSD maintainers do an upload of that to unstable? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53c30c29.3000...@pyro.eu.org
Bug#753781: Heads up: transition: xserver 1.16
On 10/07/14 09:07, Emilio Pozuelo Monfort wrote: That package is not marked as auto-buildable, which means it doesn't build on the Debian buildds and thus it can't be binNMUed. So you'll have to upload it manually, or ask the wanna-build team to make it auto-buildable. Strange, I thought someone had previously requested this... the latest build is 1:2.1.20-2+b1 which looks like it was binNMUd once before? Anyway I'll try to request this; it should be a valid candidate because it is freely-licensed, just nobody could understand it... Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53be7b1b.9030...@pyro.eu.org
Bug#753781: Heads up: transition: xserver 1.16
Adam D. Barratt a...@adam-barratt.org.uk (2014-07-10): Not on the buildds: projectb= select distinct u.name from changes c inner join fingerprint fpr on c.fingerprint=fpr.fingerprint inner join uid u on u.id=fpr.uid where changesname like 'xserver-xorg-video-nv%' and version = '1:2.1.20-2+b1'; name --- Robert Millan (1 row) On 10/07/14 13:13, Cyril Brulebois wrote: Mails for upload+accept are on this list, see e.g. https://lists.debian.org/e1wdybw-7l...@franck.debian.org https://lists.debian.org/e1wdyby-7x...@franck.debian.org Thank you both, I didn't know it had been handled that way. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#753781: Heads up: transition: xserver 1.16
Hi Emilio, On 05/07/14 10:55, Emilio Pozuelo Monfort wrote: We're planning on uploading xserver 1.16 to unstable. [...] I haven't tried to rebuild the drivers in non-free. Please check those. Thanks. I've checked that xserver-xorg-video-nv (non-free, meant for kfreebsd systems) still builds OK with xorg-video-abi-18, xserver-xorg-core (= 2:1.15.99.903). I don't have hardware available to test it with unfortunately. Please could you schedule a binNMU for it in any case? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53bdaa87.70...@pyro.eu.org
Bug#708350: transition: java7
Hi, On 24/06/14 16:11, Emilio Pozuelo Monfort wrote: Is there anything left to do here? I presume openjdk-6 removal is the last thing to be done here. ftpmaster can't do that until icedtea-web stops building icedtea-6-plugin I think: https://bugs.debian.org/720911#36 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/53b045ab.4010...@pyro.eu.org
Re: please remove kfreebsd-any from Architecture
Hi Emilio, I'm confused why source packages gdm3 and gnome-shell didn't migrate at the same time as meta-gnome3. I can only see that they wait for each other; is there something else blocking this? Is some additional hint needed to allow removals? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/538c50f9@pyro.eu.org
Re: please remove kfreebsd-any from Architecture
On 15:16, Robert Millan wrote: Indeed. Unless something has changed, only broken (linux-)i386 dependencies prevent migration. Um, a binary package on any release arch stalls migration, I think. Did you say that based on the Britney excuses output as shown on the PTS? Britney tests installability on i386 first, and may short-cut without testing any other arches, so it often doesn't list other arches but they do matter. GNOME maintainers have uploaded a new src:meta-gnome3 today though addressing this (thanks). Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20140531151851.ga31...@squeeze.pyro.eu.org
Re: gnome-terminal: FTBFS on kfreebsd hurd archs
On 15:43, Robert Millan wrote: I find it very strange that a terminal application needs gnome-shell. Stranger still that it is a *build* dependency; here's what happens without it: checking whether to build the gnome-shell search provider... yes checking for /usr/share/dbus-1/interfaces/org.gnome.ShellSearchProvider2.xml... no configure: error: gnome-shell search provider requested but interface definition file not found make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 I can't imagine what feature of gnome-terminal this is used for. Maybe there's some way to split these DBus definitions out into a gnome-shell-dev package or similar, but we should find out if gnome-shell is still needed at run-time. I would imagine some Linux users of other desktops use gnome-terminal; I'd check this on popcon.d.o but it is unavailable today. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20140531154459.gb31...@squeeze.pyro.eu.org
Re: please remove kfreebsd-any from Architecture
Hi Emilio, On 16:01, Emilio Pozuelo Monfort wrote: Just a reminder: there are still various things depending on the removed packages, preventing things from migrating to testing. Do you agree it's just the two metapackages from src:meta-gnome3 that need changes, or is there anything else? http://lists.debian.org/53863f46.2050...@pyro.eu.org Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20140530155724.gb28...@squeeze.pyro.eu.org
Re: lazarus not migrating, why?
Hi, On 26/05/14 19:41, Paul Gevers wrote: Is it because some binaries (arch:all) got renamed and decrufting scripts only pick this up after 10 days? I don't think the decruft is automatic, ftpmaster might possibly notice it in the cruft report, or you could specifically file a request with them to remove lazarus-1.2, lazarus-doc-1.2, lazarus-src-1.2. The Britney output is odd because it seems to implicate those specific architectures where the arch:all packages were uninstallable anyway; but the rename affects *all* arches... Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: preparing for GCC 4.9
Hi, On 08/05/14 16:25, Matthias Klose wrote: I would like to see some partial test rebuilds (like buildd or minimal chroot packages) for other architectures. Any possibility to setup such a test rebuild for some architectures by the porters? Afaics the results for the GCC testsuite look okish for every architecture. I rebuilt 105 source packages on kfreebsd-amd64 comprising minbase and build-essential (except for GCC itself) using GCC 4.9 and did not notice any new build failures introduced by it. I'll continue to check that the binaries compiled by GCC 4.9 are actually okay. The issue with running the GCC testsuite on kfreebsd-amd64 buildds is being fixed by FreeBSD upstream, and on Debian buildds within 1-2 weeks. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/5381122c.3010...@pyro.eu.org
Re: Bits from the Release Team: Architecture health check
On 12/02/14 20:06, Niels Thykier wrote: kFreeBSD is just shy of 90%, whereas most other release architectures are at 96%[1]. Here kFreeBSD has increased in the past quarter from ~89.5% to almost, but not quite 90%. I'm a little puzzled you mention this as a problem because... Here we need you to assess what can you reasonably support. Once we know that we can look at the consequences and how to deal with them. if we decide some packages can't be supported any more, I assume some would become linux-any and thus the number of built packages would fall? So these seem like conflicting goals. I fully agree with the latter point though, I see value in having a plan for what to support, and probably free some packages of an obligation to either build, be installable or functional kfreebsd if it no longer makes sense. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52fd53f5.2090...@pyro.eu.org
Re: Bug#708697: not fixed (udev dependency now causing FTBFS)
Control: forcemerge 708697 736608 Ah, I filed a duplicate bug for this by mistake, and already submitted a patch: http://bugs.debian.org/736608 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52ed4e0d.4040...@pyro.eu.org
Bug#737183: pu: package kfreebsd-8/8.3-6+deb7u1
On 31/01/14 05:42, Adam D. Barratt wrote: Please go ahead, bearing in mind that the window for 7.4 closes this weekend. This should now be in your queue. Many thanks. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52ec3e18@pyro.eu.org
Bug#737183: pu: package kfreebsd-8/8.3-6+deb7u1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: wheezy
X-Debbugs-Cc: debian-...@lists.debian.org
Hi,
Please could we also update kfreebsd-8 in wheezy? This has the same
backported patch to disable hardware RNGs, as well as a backlog of
security fixes, that are already applied to kfreebsd-9 in wheezy.
kfreebsd-8 is removed already from jessie/sid. It was not the default
kernel for wheezy, so issues are handled at a lower priority, and the
security bugs are marked non-DSA.
The debdiff is attached. Thanks!
kfreebsd-8 (8.3-6+deb7u1) wheezy; urgency=medium
[ Robert Millan ]
* Apply upstream SA-13_08.nfsserver patch (CVE-2013-4851).
(Closes: #717959)
[ Steven Chamberlain ]
* Apply upstream SA-13_09.ip_multicast patch (CVE-2013-3077).
(Closes: #720470)
* Apply upstream SA-13_10.sctp patch (CVE-2013-5209).
(Closes: #720476)
* Apply upstream SA-13_12.ifioctl patch (CVE-2013-5691).
(Closes: #737181)
* Apply upstream SA-13_13.nullfs patch (CVE-2013-5710).
(Closes: #737182)
* Disable VIA hardware RNG by default. Use hw.nehemiah_rng_enable
sysctl to re-enable (but read about the security implications
first). (Closes: #735448)
-- Steven Chamberlain ste...@pyro.eu.org Fri, 31 Jan 2014 02:58:14 +
diff -Nru kfreebsd-8-8.3/debian/changelog kfreebsd-8-8.3/debian/changelog
--- kfreebsd-8-8.3/debian/changelog 2012-11-23 22:13:01.0 +
+++ kfreebsd-8-8.3/debian/changelog 2014-01-31 03:35:00.0 +
@@ -1,3 +1,24 @@
+kfreebsd-8 (8.3-6+deb7u1) wheezy; urgency=medium
+
+ [ Robert Millan ]
+ * Apply upstream SA-13_08.nfsserver patch (CVE-2013-4851).
+(Closes: #717959)
+
+ [ Steven Chamberlain ]
+ * Apply upstream SA-13_09.ip_multicast patch (CVE-2013-3077).
+(Closes: #720470)
+ * Apply upstream SA-13_10.sctp patch (CVE-2013-5209).
+(Closes: #720476)
+ * Apply upstream SA-13_12.ifioctl patch (CVE-2013-5691).
+(Closes: #737181)
+ * Apply upstream SA-13_13.nullfs patch (CVE-2013-5710).
+(Closes: #737182)
+ * Disable VIA hardware RNG by default. Use hw.nehemiah_rng_enable
+sysctl to re-enable (but read about the security implications
+first). (Closes: #735448)
+
+ -- Steven Chamberlain ste...@pyro.eu.org Fri, 31 Jan 2014 02:58:14 +
+
kfreebsd-8 (8.3-6) unstable; urgency=medium
* Apply patch for SA-12:08 / CVE-2012-4576:
diff -Nru kfreebsd-8-8.3/debian/patches/disable_via_rng.diff
kfreebsd-8-8.3/debian/patches/disable_via_rng.diff
--- kfreebsd-8-8.3/debian/patches/disable_via_rng.diff 1970-01-01
00:00:00.0 +
+++ kfreebsd-8-8.3/debian/patches/disable_via_rng.diff 2014-01-31
03:15:37.0 +
@@ -0,0 +1,34 @@
+Description:
+ Disable VIA hardware RNG by default due to unsafe usage. Implement a
+ loader tunable allowing to turn it back on.
+ .
+ Minimal patch based on upstream SVN r240950 and r260644
+Origin: backport, commit:240950, commit:260644
+Forwarded: not-needed
+Bug-Debian: http://bugs.debian.org/735448
+
+--- kfreebsd-8-8.3.orig/sys/dev/random/probe.c
kfreebsd-8-8.3/sys/dev/random/probe.c
+@@ -30,6 +30,8 @@
+
+ #include sys/types.h
+ #include sys/param.h
++#include sys/systm.h
++#include sys/kernel.h
+ #include sys/malloc.h
+ #include sys/random.h
+ #include sys/selinfo.h
+@@ -57,7 +59,12 @@
+ /* Then go looking for hardware */
+ #if defined(__i386__) !defined(PC98)
+ if (via_feature_rng VIA_HAS_RNG) {
+- *systat = random_nehemiah;
++ int enable;
++
++ enable = 0;
++ TUNABLE_INT_FETCH(hw.nehemiah_rng_enable, enable);
++ if (enable)
++ *systat = random_nehemiah;
+ }
+ #endif
+ }
diff -Nru kfreebsd-8-8.3/debian/patches/SA-13_08.nfsserver.diff
kfreebsd-8-8.3/debian/patches/SA-13_08.nfsserver.diff
--- kfreebsd-8-8.3/debian/patches/SA-13_08.nfsserver.diff 1970-01-01
00:00:00.0 +
+++ kfreebsd-8-8.3/debian/patches/SA-13_08.nfsserver.diff 2014-01-31
02:26:03.0 +
@@ -0,0 +1,21 @@
+Description:
+ Fix a bug that allows remote client bypass the normal
+ access checks when when -network or -host restrictions
+ are used at the same time with -mapall. [13:08]
+ (CVE-2013-4851)
+Origin: vendor, http://security.FreeBSD.org/patches/SA-13:08/nfsserver.patch
+Bug: http://www.freebsd.org/security/advisories/FreeBSD-SA-13:08.nfsserver.asc
+Bug-Debian: http://bugs.debian.org/717959
+Applied-Upstream: http://svnweb.freebsd.org/base?view=revisionrevision=253694
+
+--- a/sys/kern/vfs_export.c
b/sys/kern/vfs_export.c
+@@ -208,7 +208,7 @@
+ np-netc_anon = crget();
+ np-netc_anon-cr_uid = argp-ex_anon.cr_uid;
+ crsetgroups(np-netc_anon, argp-ex_anon.cr_ngroups,
+- np-netc_anon-cr_groups);
++ argp-ex_anon.cr_groups);
+ np-netc_anon-cr_prison = prison0;
+ prison_hold(np-netc_anon-cr_prison);
+ np-netc_numsecflavors = argp
Re: Bits from the Release Team: Architecture health check
On 29/01/14 22:11, Robert Millan wrote: On 29/01/2014 19:41, Niels Thykier wrote: * kfreebsd-amd64 and kfreebsd-i386 - On one hand, we are unconvinced that kFreeBSD will be able to be on par with other release architectures in terms of supported packages for Jessie. - On the other hand, we believe kFreeBSD could be improved by reducing the scope of the port for Jessie. Could you elaborate? I.e. what is the problem and what solution you have in mind. What exactly does the 'scope of the port' mean? Suites of packages, tasksel tasks, desktop environments? Particular use cases (server, laptop, desktop)? Or something else? I'm grateful we've been given another 2 months to work on this. The init system debate might have come to a conclusion by then, and it could have some bearing on this. If some packages (potentially the whole GNOME desktop environment) get a hard systemd dependency that would somewhat reduce the scope of the port for us I think. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52e97fa1.1070...@pyro.eu.org
Re: Bits from the Release Team: Architecture health check
On 29/01/14 22:50, Russ Allbery wrote: Per Josselin's latest discussion of this, there doesn't appear to be any direct GNOME dependencies on systemd itself that would be blocking for jessie. Sorry, I got completely the opposite impression from this tonight: On 29/01/14 17:41, Josselin Mouette wrote: Le mercredi 29 janvier 2014 à 19:03 +0200, Adrian Bunk a écrit : No, you are not. There are several features in systemd that GNOME uses. One of them is user sessions, for which there will indeed be a fallback in place. But it is not the only one. Can you provide a list of features without a fallback in place? At least logind, timedated, hostnamed, localed, the boot control interfaces. With a very widespread level of failure depending on the unavailable interface. Assuming jessie will support multiple init systems, why would GNOME need a dependency on systemd? Because it needs logind. https://lists.debian.org/debian-ctte/2014/01/msg00360.html So, even having an adequate logind substitute, GNOME is expected to be considerably impaired without systemd? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52e98b51.9050...@pyro.eu.org
Bug#736846: pu: package kfreebsd-9/9.0-10+deb70.6
On 27/01/14 21:41, Robert Millan wrote: It is fixed in kfreebsd-10. As the plan for kfreebsd-9 is to remove it after the transition to -10 is complete, we haven't made a new kfreebsd-9 upload just for this bug. The fix for this in 9.2 (and Intel Ivy Bridge as well) is so simple though, could we maybe do one last upload fixing this? (For the benefit of anyone that decides to keep using kfreebsd 9.2 a little longer, or installs it from snapshots.d.o for some reason in future). http://svnweb.freebsd.org/base/stable/9/sys/dev/random/probe.c?r1=260644r2=260643pathrev=260644 Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52e6d50a.4080...@pyro.eu.org
Bug#736846: pu: package kfreebsd-9/9.0-10+deb70.6
Control: tags -1 - moreinfo On 27/01/14 16:25, Adam D. Barratt wrote: The BTS metadata implies that this bug is unfixed in unstable and applicable to the package there; is that correct? Bug #736198 (ZFS lseek) was already fixed in jessie/sid; I've just corrected the version tagging in the BTS. Bug #735449 (VIA hardware RNG) we've decided to fix in sid with one last upload. kfreebsd-9 is to be removed soon though in favour of kfreebsd-10 (which is unaffected). Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52e72ad5.7010...@pyro.eu.org
Bug#729289: transition: openscenegraph
On 22/01/14 22:23, Rebecca N. Palmer wrote: Given that libopenscenegraph80 is uninstallable (it depends on the no-longer-existing libavcodec53/libavformat53/libavutil51), keeping it around doesn't actually help its reverse dependencies; how should this be dealt with? (request its removal? request that openscenegraph be forced to testing anyway?) Probably file a bug requesting ftp-master remove it; I'm a bit puzzled though how an old libopenscenegraph80 gets in the way of newer src:openscenegraph migrating to testing. Anyway, from https://ftp-master.debian.org/cruft-report-daily.txt : * source package openscenegraph version 3.2.0~rc1-2 no longer builds binary package(s): libopenscenegraph80 on amd64,armel,armhf,i386,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,s390x,sparc - suggested command: dak rm -m [auto-cruft] NBS (no longer built by openscenegraph) -s unstable -a amd64,armel,armhf,i386,kfreebsd-amd64,kfreebsd-i386,mips,mipsel,powerpc,s390x,sparc -p -R -b libopenscenegraph80 Above is exactly what you'd request. I'd say everything possible has been done already to try to get these fixed: - broken Depends: choreonoid: choreonoid [mipsel] choreonoid-plugins-base [mipsel] libcnoid1 [mipsel] fgrun: fgrun flightgear: flightgear [kfreebsd-amd64 kfreebsd-i386 mips] libcitygml: openscenegraph-plugin-citygml-shared openwalnut: libopenwalnut1 openwalnut-modules openwalnut-qt4 simgear: libsimgearscene2.10.0 [mips] simgear2.4.0 [armel armhf kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc] Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52e0667d.4060...@pyro.eu.org
Re: qiime REMOVED from testing
On 21/01/14 20:10, Niels Thykier wrote: On 2014-01-21 19:45, Andreas Tille wrote: I know that qiime has a serious bug (#731190) where I was seeking for help six weeks ago with no real result. So I would have expected to become kicked from testing because of this bug which would be fine. Please, please Cc: debian-...@lists.debian.org for help with something like this. I only noticed that bug today because I happen to read -release@ Now, by the looks of it, this FTBFS has not been filed. For that, I believe you have suffered from the problem mentioned in [2]. On a related note, I suspect a good part of this problem would go away if we had an automated tool to deal with the case where a (sid-only) FTBFS is ignored. It happens sometimes that the maintainer does nothing (or, maybe, does not realise the package FTBFS on arch X) and neither the porters nor the buildd admins filed a bug for it. That would be extremely useful, and even better if it could Cc: porters of that arch and/or apply relevant BTS (user)tags. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52ded6bb.5050...@pyro.eu.org
Re: qiime REMOVED from testing
On 21/01/14 18:45, Andreas Tille wrote:
However, it is kicked because of an old libffi dependency. I realised
that it had in fact
libffi6 (= 3.0.4)
in its dependencies which was included via
${shlibs:Depends} or
${misc:Depends}
but I have no idea, how to prevent this. Would a rebuild be sufficient
to get the new libffi dependency or do I need to do more?
When I rebuilt it just now on kfreebsd-amd64, the .deb picked up these
dependencies:
Depends: libc0.1 (= 2.17-91), libffi6 (= 3.0.4), libgmp10, python (= 2.7),
python ( 2.8), pynast (= 1.2), python-cogent (= 1.5.3), king,
python-biom-format
So presumably that's fine, libffi6/3.0.13-10 in jessie+sid satisfies this.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--
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/52df0617.7030...@pyro.eu.org
Re: Release sprint results - team changes, auto-rm and arch status
On 15/12/13 12:34, Niels Thykier wrote: Uhm I think we both may have misunderstood. Perhaps 'this state' just means 'as technology preview'. I.e. normal QA requirements are no longer waived because of preview status. This is exactly what we meant; we intend to not do technology previews for Jessie. I assumed kFreeBSD no longer carried the 'technology preview' label for the wheezy release, and that it was subject to normal testing migration and release policy already. 'Technology preview' status allowed a more forgiving policy on unblock requests. I don't think that was ever relevant during the wheezy freeze because whatever bugs we had were already inherently RC? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52ade555.4000...@pyro.eu.org
Bug#706798: transition: Libav 9
On 01/12/13 10:46, Julien Cristau wrote: aqualung's dependencies don't match that as far as I can tell. Okay thanks. I'm misinterpreting the PTS: dep: libavcodec52 (= 4:0.5.1-1) [hppa] Libav codec library or libavcodec-extra-52 (= 4:0.5.1-1) Package not available I assumed the libavcodec-extra-52 dependency was the one for [not hppa]. In fact the aqualung binary package has no libav dependency in sid, since choking on the last libav transition. The build system didn't fail on this, and produced a package without libav functionality. So it is really not affected by the latest libav9 transition. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#706798: transition: Libav 9
Hi, The tracker for this transition[0] doesn't show either good or bad status for package aqualung. In fact it still uses the old libav and requires an NMU, but it will FTBFS with the new version. [I plan to prepare an NMU fixing this and another RC bug]. [0]: http://release.debian.org/transitions/html/libav9.html aqualung's dependencies refer to packages matching /lib(avcodec-extra-53|avformat-extra-53|avutil-extra-51)/ is that bad/unexpected? Could other packages have been missed? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/529a5b6d.5020...@pyro.eu.org
Bug#706798: transition: Libav 9
Also,,, package sox doesn't show good/bad status. But it depends on an older libav matching /lib(avcodec52|avformat52|avutil50)/ See http://packages.debian.org/sid/libsox-fmt-ffmpeg Was it missed during a previous soname transition? Could/should the libav9 tracker be updated to match on this as Bad? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/529a5c9c.4040...@pyro.eu.org
Re: Release sprint results - team changes, auto-rm and arch status
On 28/11/13 20:04, Niels Thykier wrote: kFreeBSD was a technology preview, and has not generated enough user interest to bring in sufficient install base to continue in this state. We will review this situation after 28th January 2014. Architectures still causing us concern at that point will join ia64 in no longer being considered for britney migrations and may be dropped from testing after a further period. I'm unclear on what this means, or what should happen by that date to ensure it is considered sufficient to continue in 'this state' (meaning, a release architecture and considered for Britney migration?). An obvious place for a porter assess their own compliance might be to look the release team's policy document on this: [ARCH-POL] http://release.debian.org/jessie/arch_policy.html but the only thing I see relating to the above, is Users: ... at least 50 which is currently true of both kfreebsd-amd64 and kfreebsd-i386. as demonstrated by popcon. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: A new metric for source package importance in ports
Hi josch! On 27/11/13 17:58, Johannes Schauer wrote: http://mister-muffin.de/p/Gid8.txt One can see that now the amount of source packages which is needed to build the rest of the archive is only 383. So, there are 383 packages that share the same, maximum value (in this case 11657) in the second column? Does anybody see enough value in these numbers for source package importance in the light of bootstrapping Debian (either for a new port or for rebuilding the archive from scratch)? I find the list of 383 packages interesting, at least. I think this closure is what I had in mind[0] for regular testing of ports' toolchains and reproducibility of builds. Because each Debian port depends in some indirect way on the authenticity of these packages. And likewise any toolchain bugs are most critical here. I just didn't think there would be so many packages. Does the list vary by architecture? I see many odd things in here such as 'systemd' and 'redhat-cluster' which would be unavailable if trying to bootstrap a non-Linux port, for example. I also find it interesting to see openjdk-7 listed but not gcj; or even gcc-4.8. Was this computed for jessie or sid? [0]: http://lists.debian.org/5266df9d.9040...@pyro.eu.org Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/529688a8.8080...@pyro.eu.org
Re: Replacing openjdk-6 with gcj-jdk as default java for mips{,el}
On 13/11/13 00:29, Aurelien Jarno wrote: I have finally been able to fix openjdk-7 on mips and mipsel. It was a problem of ugly casts done without taking care of alignement issues. See bug #729448 for more details. This patch may also be desirable for openjdk-6; mips(el) is out-of-date at building security updates with the same failure. Not sure if such a change would have to go through s-p-u first, or directly applied in a security upload. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Bug#725951: transition: libgphoto2
On 13/11/13 09:55, Julien Cristau wrote: Does that mean the rest of the rdeps (in debian) can deal with the new API with no source changes? gvfs build-depends on libgphoto2-2-dev, and has some problems building on kfreebsd-* currently: https://buildd.debian.org/status/package.php?p=gvfs But I assume it to be fixable with changes only to libgphoto2 and/or libmtp-dev. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52840506.9010...@pyro.eu.org
Bug#729289: Bug#720816: openscenegraph: FTBFS with libav9: FFmpegDecoder.cpp:282:76: error: 'url_feof' was not declared in this scope
Hi Bas, Am I right in thinking osgearth cannot build against the libopenscenegraph99 currently in sid? So actually you *cannot* fix bug #725383 until a new upload of openscenegraph? You used the word 'uninstallable' before but, AFAIK it is installable (everywhere except mips), but rather anything building against that lib will FTBFS due to libav9 incompatibility? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/5282288a.5040...@pyro.eu.org
Bug#729289: transition: openscenegraph
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Hi, It appears to me that a openscenegraph began a transition. I'm opening this bug as a place to track/discuss this. Version 3.2.0~rc1-1 in unstable dropped libopenscenegraph80 for libopenscenegraph99, but pending in VCS is an eventual bump to libopenscenegraph100. Unfortunately this is tangled already with the libav9 transition. If release team agrees, I think it would be beneficial to have a tracker set up for this in any case: Ben file: title = openscenegraph; is_affected = .build-depends ~ /libopenscenegraph-dev/; is_bad = .depends ~ libopenscenegraph80; is_good = .depends ~ libopenscenegraph100; ===[ Dependency level 0 ]= choreonoid: just needs binNMU? libcitygml: FTBFS #719396 + patch openwalnut: FTBFS #719388 awaiting upstream osgearth: FTBFS #725383 + patch pending, waits for libopenscenegraph100 ossim: just needs binNMU? simgear: just needs binNMU? ===[ Dependency level 1 ]= flightgear: simgear; needs binNMU The most recent simgear upload to sid also broke fgrun: FTBFS #719402 + patch Thanks. -- System Information: Debian Release: 7.1 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/2013130526.87187.88361.report...@kfreebsd-amd64.pyro.eu.org
Bug#729289: transition: openscenegraph
fgrun only indirectly build-depends on libopenscenegraph-dev, via the transitional package simgear-dev I think. I now have this ben file: title = openscenegraph; is_affected = .build-depends ~ /(libopenscenegraph|simgear)-dev/; is_bad = .depends ~ /libopenscenegraph(80|99)/ | .depends ~ /libopenthreads(13|14)/; is_good = .depends ~ /libopenscenegraph100/ | .depends ~ libopenthreads15; And this brings in fgrun as expected: ===[ Dependency level 0 ]= choreonoid: libcitygml: openwalnut: osgearth: ossim: simgear: ===[ Dependency level 1 ]= fgrun: simgear flightgear: simgear Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/2013204201.ga6...@squeeze.pyro.eu.org
Bug#729289: Bug#720816: openscenegraph: FTBFS with libav9: FFmpegDecoder.cpp:282:76: error: 'url_feof' was not declared in this scope
block 729289 by 720816 block 729289 by 725383 thanks Hi, [TL;DR: please refer to question in last paragraph :)] I hoped the transition bug #729289 could be a more relevant place to discuss this and gather details (such as blocking bugs) on what needs to be done to help move this forward. I'm adding it into Cc... On 11/11/13 23:44, Manuel A. Fernandez Montecelo wrote: [...] in principle I don't agree that this needs a official transition and I can't say whether this needed to be co-ordinated or not. For some reason I still don't see a warning in the PTS that openscenegraph would have been involved in the libav9 transition, so I understand if this was unexpected. This is already underway and I don't mean to argue over this now. But the tangle with libav9 and possibly boost1.54 does add more pressure to resolve this quickly. I am not happy that you went ahead in a matter of hours asking the release team for it before having a reply from us, for the following reasons: This was brought up some 5-6 weeks ago in #706798, to debian-release@ and some mails went to Loic as maintainer, but I guess you were not notified yourself, sorry. I already warned to rdepends months ago (before the package being even approved) by email (BTS) to please make modifications to accomodate to the new package, as that page suggests, and offered help to the respective maintainers, [...] Yes you've done well to prepare for this; every issue seems to have a bug already filed and most have patches now. See #718381 for an example to help maintainers of openwalnut. [...] If it was a matter of binNMUs and simple fixes that I could upload, as I expected, this would have been fixed long ago. Yes, unforeseeably that issue turned out to be more complex. (whereas libcitygml and openwalnut have a whopping ~10 of popcon, chorenoid 3). It's not a good solution that these packages block OSG from being updated for long periods. I'm not sure these are really blocking anything. I now see that these packages are 'sid only', so if libopenscenegraph80 were removed, those packages would be uninstallable but everything else could migrate? The current cause of this blockage is actually problems/delays in MIPS toolchain and bad timing. If you mean the delayed build of openscenegraph on mips, happening after libav9 transition started, I'm not sure that makes a difference because it would be stuck until rdepends are ready (and they're still not). libav9 transition started only a few days later so openscenegraph would have failed on *all* arches when binNMUd? 5) So as a summary and in short, having an open transition process is not going to speed-up the transition [...] (libcitygml didn't respond or upload for more than 3 months, for example). Conversely, that's why I suggested having a tracker; having more eyes on the problem and making it easier to see what needs to happen. This may need adjustment but it is a start: http://release.debian.org/transitions/html/osg.html [openthreads and fgrun currently missing from there] I am a bit lost with the changes happened lately, but looking at the rdepends on libopenscenegraph80 in my system, I think that things have been updated and are supposed to work except for: - fgrun [...] already been removed from testing - openwalnut and libcitygml are removed from testing, they will allow migration to testing with libopenscenegraph99 Right. OSG, with the patch for url_eof it should compile and allow libav9 to migrate -- unless some further problems appear when going again through buildds in all arches, which is can easily happen. The tracker can help illustrate this, but ... Since the transition requested already mentions libopenscenegraph100, but 3.2.1 is not released, I think that it's actually more risky (or prone to more delays) if to tie the current transition to these future ones of OSG. ... the tracker will need updating with whatever you decide to aim for (99 or 100). I would think 99 is the quickest and safest resolution to the libav9 tangle. As Rebecca said, it implies another round of binNMUs as soon as 3.2.1 is uploaded. But IMHO that will be much easier and less urgent if nothing else is waiting on it by then. Are you decided that you are aiming for libopenscenegraph99 to migrate first? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52818f83.2070...@pyro.eu.org
Re: Replacing openjdk-6 with gcj-jdk as default java for mips{,el}
On 09/11/13 13:35, Niels Thykier wrote: At the current time, OpenJDK 7 have not been successfully ported on these architectures and it is my understanding that it is unlikely to change in the near future. It did build in the past, but I guess nobody was around to fix it as things changed over time - Bus Error has been happening since 7u7-2.3.2: https://buildd.debian.org/status/logs.php?pkg=openjdk-7arch=mipsel This leaves gcj-jdk as the only viable option for mips and mipsel. The timing of this seems ironic - renewed discussion about dropping Java from the GCC default languages - if it makes any difference: http://gcc.gnu.org/ml/gcc/2013-11/msg00153.html Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/527e9299.3040...@pyro.eu.org
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
Hi, On 05/11/13 18:50, Don Armstrong wrote: On Tue, 05 Nov 2013, Don Armstrong wrote: This sounds like a case where we should turn these usertags into fully fledged tags. [Or alternatively, they should just be made usertags under the debian-po...@lists.debian.org user or similar.] Either of those sounds good. Fully-fledged tags would be the easiest for most reporters to remember to use, but I wonder if this pollutes the tag namespace. [Or multiple pseudopackages.] Something like i386.ports.debian.org or similar would work, with each current port getting a pseudopackage, and the maintainer of the pseudopackage being the ports list. Would that be only for generic issues with a port, not specific to a package? I doubt this would be used much. These bugs might typically be reassigned to kernel packages or eglibc anyway. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/527949c5.8040...@pyro.eu.org
Bug#728698: nmu: nodejs_0.10.21~dfsg1-1~bpo7+1
Hello Mike, On 04/11/13 11:19, Mike Gabriel wrote: unfortuntely, I forgot to provide a build-dependency upload to wheezy-backports when I uploaded nodejs. Now, that all B-Ds for nodejs are in wheezy-backports, I'd be happy if you could re-trigger a second build of nodejs (0.10.21~dfsg1-1~bpo7+1). What about this? nodejs build-depends on missing: - gyp (= 0.1~svn1654) If that becomes available in wheezy-backports, I expect the builds would start automatically. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/527785f1.2030...@pyro.eu.org
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On 03/11/13 10:54, Niels Thykier wrote: Come to think of it; maybe we should have a BTS page for each of the ports (e.g. a pseudo package in the BTS). We've had this on kfreebsd, due it to having been a release goal: http://udd.debian.org/bugs.cgi?release=jessie_or_sidmerged=ignfnewerval=7kfreebsd=1sortby=severitysorto=desccseverity=1ctags=1 It uses usertags, but someone has to set those. Porters usually set them on bugs they file; but quite often FTBFS on kfreebsd bugs are filed without being tagged or Cc'd to our list, so someone has to periodically look for and tag things. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/527665af.2040...@pyro.eu.org
Britney mails missing?
Hi, I notice some packages migrated into testing (kfreebsd-9, cuse4bsd, fuse4bsd) but mails didn't go to the maintainer yet and the PTS hasn't updated. Am I being too impatient, or did Britney fail to send out mails for this? Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20131019133526.ga11...@squeeze.pyro.eu.org
Re: Britney mails missing?
On 15:38, Cyril Brulebois wrote: Steven Chamberlain ste...@pyro.eu.org (2013-10-19): I notice some packages migrated into testing (kfreebsd-9, cuse4bsd, fuse4bsd) but mails didn't go to the maintainer yet and the PTS hasn't updated. Am I being too impatient, or did Britney fail to send out mails for this? Aren't those sent by qa.d.o, which was done for a while? I assumed some mails were sent *to* there, that updates the PTS news box and notifications go out to susbcribers? http://packages.qa.debian.org/c/cuse4bsd/news/20130505T163920Z.html I'm probably wrong about this, but there's also nothing here since Wednesday: http://lists.debian.org/debian-changes/2013/10/threads.html Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20131019134715.gb11...@squeeze.pyro.eu.org
Re: Britney mails missing?
On 15:38, Cyril Brulebois wrote: Steven Chamberlain ste...@pyro.eu.org (2013-10-19): I notice some packages migrated into testing (kfreebsd-9, cuse4bsd, fuse4bsd) but mails didn't go to the maintainer yet and the PTS hasn't updated. Am I being too impatient, or did Britney fail to send out mails for this? Aren't those sent by qa.d.o, which was done for a while? Hmmm nevermind. Maybe the PTS doesn't update until this runs at 16:39 UTC (which is a bit later than I realised). http://release.debian.org/testing-watch/ Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20131019140321.gc11...@squeeze.pyro.eu.org
Re: First autoremovals happen in about 8 days
On 07/10/13 23:04, Bill Allombert wrote: I am concerned that in the event a package is removed from testing, the people most interested with restoring the package will miss the removal, since the package will stay installed on their systems. This, then, cause stable releases to be missing packages that users are depending on, which reduce the value of the distribution. `aptitude search '?obsolete'` is useful after upgrading a system to a new stable release, a trick I learned from: http://raphaelhertzog.com/2011/02/07/debian-cleanup-tip-2-get-rid-of-obsolete-packages/ Not directly related to this: a side effect of running debsecan is that if I see security issues accumulating for some package, I would likely check the PTS to see why it remains unfixed, or decide to remove or replace the package with something else that's still maintained. So if `aptitude search '?obsolete'` was run periodically, like debsecan, it could email the system admin when new items appear on the obsoletes list. I imagine that'd be a good way to notify of the situation being described here? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/52549549.1050...@pyro.eu.org
Re: First autoremovals happen in about 8 days
Hi, On 06/10/13 08:52, Niels Thykier wrote: kfreebsd-8: bugs 720470,717959,720476, flagged for removal in 14.7 days Not sure why that's appearing in this list because: 1. the package was removed from testing over a month ago at the request of the maintainer, and 2. when that happened the bugs listed were closed? Perhaps this is because the script does not notice 1. and therefore despite 2. it still thinks affected versions are in testing? Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/525144dc.6090...@pyro.eu.org
Re: First autoremovals happen in about 8 days
On 06/10/13 08:52, Niels Thykier wrote: Laszlo Boszormenyi (GCS) g...@debian.org vice: bugs 693641, flagged for removal in 8.3 days Bug #693641 is another interesting edge case: Found in version vice/2.3.dfsg-4 (testing, unstable, stable) Fixed in version vice/2.4.dfsg-1 (unstable) Marked as done But it didn't quite build everywhere - kfreebsd-amd64 and s390 still have out-of-date 2.3.dfsg-4 binaries in sid. I'm not sure if this logic was intended, but it actually makes sense: the fixed version cannot migrate to testing and replace the buggy one. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/5251bd46.8070...@pyro.eu.org
Bug#706798: where is OpenSceneGraph 3.2 status?
Hi, [not part of Release Team but hopefully I can answer your question] On 04/10/13 09:32, Rebecca N. Palmer wrote: Is there a tracker for the OpenSceneGraph 3.2 transition (tied to this one by #720816)? Status as far as I can find: It doesn't look to me that a transition was coordinated for openscenegraph? Status of openscenegraph's migration to testing is best shown by: http://packages.qa.debian.org/o/openscenegraph.html http://qa.debian.org/excuses.php?package=openscenegraph http://release.debian.org/migration/testing.pl?package=openscenegraph Blocking issues are #720816 which you already submitted a patch for, a (possibly temporary) build issue on mips, and the fact openscenegraph must be rebuilt anyway as part of the libav9 transition. And then the rest of the libav9 transition needs to complete: http://release.debian.org/transitions/html/libav9.html The 'hurd' column can be ignored, as well as rows marked 'sid only'. AIUI the packages at higher dependency levels (such as openscenegraph at level 3) tend to sometimes need packages at lower levels (higher in the list) to be rebuilt first. AFAIK blockers are dvswitch, opencv, spek [on s390x], yorick-av, and vxl [on ia64]. The BTS entry for #706798 notes these and some other things as blocking bugs. I don't see that #725071 in xine-lib-1.2 really blocks this as the kfreebsd binaries are already built against newer libav9; I submitted a patch for that anyway. * #719402 fgrun (sid only) has patch * #719376 osgearth fixed in 2.4, but this is held in unstable because an unrelated upstream fix makes it non-kFreeBSD (https://github.com/gwaldron/osgearth/commit/a270f5f0e2c3d56f5d528db17873dc37c52a6655 ; SYS_gettid doesn't exist there) That's definitely not portable code, I'll look into that one. * #718381 / #719388 openwalnut badly broken by 3.2, being worked on upstream (latest upstream reported to build but not work properly, http://www.openwalnut.org/issues/298) So these are all broken by openscenegraph going into sid? I don't think that will actually prevent openscenegraph from migrating to testing automatically. But perhaps a transition should have been requested for it and a tracker set up. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/524ea417.4010...@pyro.eu.org
Bug#706798: where is OpenSceneGraph 3.2 status?
On 04/10/13 19:16, Rebecca N. Palmer wrote: spek [on s390x], This build failure looks like a bash crash, not an error in spek itself. Try again?? Still the same on a different buildd, unfortunately: https://buildd.debian.org/status/logs.php?pkg=spekver=0.8.2-3arch=s390x Note that only part of output from the (C++ compiled) test program is shown, before the crash. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/524f2692.9080...@pyro.eu.org
Bug#706798: where is OpenSceneGraph 3.2 status?
block 706798 by 725385 thanks On 04/10/13 21:35, Steven Chamberlain wrote: On 04/10/13 19:16, Rebecca N. Palmer wrote: spek [on s390x], This build failure looks like a bash crash, not an error in spek itself. Try again?? Still the same on a different buildd, unfortunately: https://buildd.debian.org/status/logs.php?pkg=spekver=0.8.2-3arch=s390x That is now bug #725385. Aurelien provided a backtrace possibly implicating libav... On 04/10/13 12:18, Steven Chamberlain wrote: On 04/10/13 09:32, Rebecca N. Palmer wrote: * #719376 osgearth fixed in 2.4, but this is held in unstable because an unrelated upstream fix makes it non-kFreeBSD (https://github.com/gwaldron/osgearth/commit/a270f5f0e2c3d56f5d528db17873dc37c52a6655 ; SYS_gettid doesn't exist there) That's definitely not portable code, I'll look into that one. That is now bug #725383. It is not directly blocking the libav9 transition though. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/524f39bc.1090...@pyro.eu.org
Bug#725304: pu: package kfreebsd-9/9.0-10+deb70.5
On 03/10/13 22:17, Cyril Brulebois wrote: Does this affect unstable? If so, please update the BTS accordingy, get the fix there, and revisit the pu bug afterwards. The change (dropping 101_nullfs_vsock.diff) was already made back in 9.1-1, and so I've updated the BTS accordingly. I agree that detail is missing from the changelog, as it was hard even for me to determine this just now. I wonder if we have an opportunity to fix the non-standard version numbering we have at the moment, perhaps by calling this pu something like 9.0-12+deb7u1 instead (because changes from 9.0-11 and -12 are already incorporated in this)? Or if it is less confusing to stay with what we have? Why this version number? security seems to only have 9.0-10+deb70.3 There is a 9.0-10+deb70.4 upload in Secre^WSecurity Team's queue since 23 days ago but I've no idea the status if this. [rt.debian.org #4671] Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/524dea6b.9060...@pyro.eu.org
