Bug#829371: transition: ntl
Hi, On 04/07/2016 14:13, Jonathan Wiltshire wrote: On 2016-07-03 10:30, Jonathan Wiltshire wrote: Control: tag -1 confirmed On 2016-07-02 21:58, Julien Puydt wrote: I checked that these new ntl packages make it possible to build eclib, flint, linbox, singular and flint-arb on an amd64 debian box, so I don't expect any new problem. Please go ahead. Seems to have happened, so rebuilds scheduled. The eclib failure on amd64 is pretty annoying -- I tried on my amd64 box, and got illegal instruction too. Then I compiled libntl27 from apt-get source and installed the obtained libntl27 package, and ran make check again : gone! I don't know what is amiss with the package yet -- and even more worrying: I don't know how I didn't detect the matter when I checked the deps! I'll try to find more about it as soon as possible, Snark on #debian-science
Bug#826568: Bug#826161: Bug#826568: jessie-pu: package sendmail/8.14.4-8+deb8u1
Hi! On Tue, 2016-07-05 at 14:41:26 +0200, Andreas Beckmann wrote: > On 2016-07-05 11:51, Adam D. Barratt wrote: > > On a related note, which has been mentioned before (on dda at least) - > > please don't name your .changes file _amd64.changes if the package > > builds amd64 binaries and they're not included in the upload. dak keeps > > That's dpkg-buildpackage -g in stable. It is fixed in sid. (#826161) > > Guillem, could #826161 be fixed in stable, too? Ah certainly! I didn't mark it as a stable candidate because I was afraid it could cause unintended problems, but if it is already causing problems now I don't see why not. I've added a git-notes to that commit to queue it for the next stable update. Thanks, Guillem
Re: Thinking about a "jessie and a half" release
On Tue, Jul 05, 2016 at 06:11:24PM +, Holger Levsen wrote: >On Mon, Jul 04, 2016 at 04:01:10PM -0400, Nicholas D Steeves wrote: >> I still wonder if a fork of the last linux:src=4.4, updated to bring >> it to linux-4.4.14 would be a lower support burden? I'm still finding >> that there are a fair number of issues reported with 4.5.x and 4.6.x >> on various mailing lists. Does anyone know how Skylake support is >> like for the 4.4.x branch? What is arm64 support like? I've >> corresponded with Ben Hutchings, and he tells me an LTS kernel effort >> is ok to do, but unofficial. Personally, I believe following bpo >> kernel is a bit of a rodeo in comparison to what one expects from >> Debian Stable, which is why I'm looking into this project. > >Steve, *this* is a major open question as I see it, what's you take on >it? > >I assume "forking" the kernel for jessie+½ as done for etch-and-half is >the plan already? (forking as in using a new source package…) God, no - really *not* that way at all. I'm thinking of using the kernel in backports at the time we do a build/test/release cycle. People using this and updating will end up following bpo for a while until the Stretch release. >(Probably related to the remark that jessie+½ might become obsolete by >stretch quite soon after too… related as in: what will be the next >upstream LTS kernel?) > > >-- >cheers, > Holger -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Re: Thinking about a "jessie and a half" release
On Tue, Jul 05, 2016 at 04:15:36PM -0300, Breno Leitao wrote: >Steve, > >On 07/04/2016 10:01 AM, Steve McIntyre wrote: >>A lot of arm64 machine users would benefit from this, and maybe owners >>of very recent amd64 machines too. > >ppc64el port would take benefit from it also, since, there were many new >kernel features that made linux after 3.16. ACK. Just kernel, or any other bits? -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: Thinking about a "jessie and a half" release
On Tue, Jul 05, 2016 at 02:37:06PM +0200, Martin Zobel-Helas wrote: >Hi Steve, > >On Mon Jul 04, 2016 at 14:01:03 +0100, Steve McIntyre wrote: >> A lot of arm64 machine users would benefit from this, and maybe owners >> of very recent amd64 machines too, with better support for things on >> the Skylake platform. Those are the only two architectures I'm >> thinking of supporting at this point. >> >> Is anybody else interested in helping? Thoughts/comments? > >from a cloud image users perspective this sounds like a great idea. >There are several things eg. in the kernel with 10GE network drivers, >where a newer kernel would definitivly help a lot. Also maybe newer >cloud-init and friends would help. > >Please go for it. > >+1 from my side. ACk, thanks for the feedback. -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: Thinking about a "jessie and a half" release
On Mon, Jul 04, 2016 at 07:05:42PM +0200, Ben Hutchings wrote: >On Mon, 2016-07-04 at 14:01 +0100, Steve McIntyre wrote: >> Hey folks, >> >> There's something I've been pondering for a while, along with some >> other folks - it might be useful to do a "jessie and a half" release, >> similarly to what we did in the etch days. > >As I recall, that added extra packages to the etch suite, whereas it >seems like this would take updated packages the jessie-backports suite. Yup, that's what I'm thinking. >> That's *basically* just like a normal jessie release, but with a few >> key updates: >> >> * backports kernel >> * rebuilt d-i to match that kernel >> * X drivers >> * ... (other things that might be needed for consistency) > >For the kernel: firmware-nonfree, kernel-wedge, linux-base, linux- >latest, linux-signed, sbsigntool. All of those are already in jessie- >backports, except the last two which will be needed starting with 4.7. Right. >For user-space graphics: libdrm and mesa, presumably. > >> all rolled up with a small installer image build (netinst, maybe DVD#1). >> >> A lot of arm64 machine users would benefit from this, and maybe owners >> of very recent amd64 machines too, with better support for things on >> the Skylake platform. Those are the only two architectures I'm >> thinking of supporting at this point. >> >> Is anybody else interested in helping? Thoughts/comments? > >When do you anticipate this would be releasable? Would it really be >long enough before stretch, to be worthwhile? I'm thinking late July / early August, which would still give us a number of months lead on Stretch. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: Thinking about a "jessie and a half" release
Steve, On 07/04/2016 10:01 AM, Steve McIntyre wrote: A lot of arm64 machine users would benefit from this, and maybe owners of very recent amd64 machines too. ppc64el port would take benefit from it also, since, there were many new kernel features that made linux after 3.16.
Re: Thinking about a "jessie and a half" release
Holger Levsen (2016-07-05): > On Mon, Jul 04, 2016 at 04:01:10PM -0400, Nicholas D Steeves wrote: > > I still wonder if a fork of the last linux:src=4.4, updated to bring > > it to linux-4.4.14 would be a lower support burden? I'm still finding > > that there are a fair number of issues reported with 4.5.x and 4.6.x > > on various mailing lists. Does anyone know how Skylake support is > > like for the 4.4.x branch? What is arm64 support like? I've > > corresponded with Ben Hutchings, and he tells me an LTS kernel effort > > is ok to do, but unofficial. Personally, I believe following bpo > > kernel is a bit of a rodeo in comparison to what one expects from > > Debian Stable, which is why I'm looking into this project. > > Steve, *this* is a major open question as I see it, what's you take on > it? > > I assume "forking" the kernel for jessie+½ as done for etch-and-half is > the plan already? (forking as in using a new source package…) AFAICT the plan is to use whatever is in backports and confirmed to just work at the time, release, and be happy. KiBi. signature.asc Description: Digital signature
Re: Thinking about a "jessie and a half" release
On Mon, Jul 04, 2016 at 04:01:10PM -0400, Nicholas D Steeves wrote: > I still wonder if a fork of the last linux:src=4.4, updated to bring > it to linux-4.4.14 would be a lower support burden? I'm still finding > that there are a fair number of issues reported with 4.5.x and 4.6.x > on various mailing lists. Does anyone know how Skylake support is > like for the 4.4.x branch? What is arm64 support like? I've > corresponded with Ben Hutchings, and he tells me an LTS kernel effort > is ok to do, but unofficial. Personally, I believe following bpo > kernel is a bit of a rodeo in comparison to what one expects from > Debian Stable, which is why I'm looking into this project. Steve, *this* is a major open question as I see it, what's you take on it? I assume "forking" the kernel for jessie+½ as done for etch-and-half is the plan already? (forking as in using a new source package…) (Probably related to the remark that jessie+½ might become obsolete by stretch quite soon after too… related as in: what will be the next upstream LTS kernel?) -- cheers, Holger signature.asc Description: Digital signature
Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*
On Tue, Jul 05, 2016 at 11:41:15AM +0200, Jonathan Wiltshire wrote: > > I suggest we extend the mysql-defaults source package to provide a > > real default-mysqlclient-dev metapackage, which other packages can > > build depend on, using versions if needed (just as default-jdk does). > > Yes. > > > Current mariadb-10.0 source package does not ship any > > libmariadbclient18 nor libmariadbclient-dev packages at all, as > > previously it was seen as against the policy (but mariadb-5.5 in > > Debian did). I suggest we start producing them now again to make a > > libmysqlclient.so(.18) available from mariadb-10.0. > > > > Having two libmysqlclient.so.18 files from two different packages is a > > controversial topic. They are not identical so it is ugly to use the > > same name. This is however a necessity dictated by the need to provide > > a drop-in-replacement that can be used directly without going into > > every single clienting program and editing the C headers and soname > > calls. > > We discussed this in the release team and concluded that having two > libmysqlclient.so.18 files in two packages is likely to run into problems > later if/when they diverge, so there is no point delaying that pain. > Especially as they are not identical even now. Sorry, I'm not clear on the sense of your statement. By this, are you agreeing to do it now, or saying that we shouldn't do it? > I wonder if pkgconfig can be any help here? That involves a one-time change > to client packages if they don't already use pkgconfig but doesn't have to > be repeated if the default switches. I experimented down another route. In my proposal, I keep the libmysqlclient for MySQL only, and use libmariadbclient for the MariaDB upstream. So: PROPOSAL B pkg:libmysqlclient18 ships libmysqlclient.so.18 pkg:libmysqlclient-dev ships libmysqlclient.so (no change so far). Then: pkg:libmariadbclient18 is created to ship libmariadbclient.so.18 pkg:libmariadbclient-dev is created to ship libmariadbclient.so These are new additions to src:mariadb-10.0. We have to patch a little to switch from MariaDB from building libmysqlclient to use libmariadbclient instead. pkg:libmariadbclient-dev must conflict with pkg:libmysqlclient-dev because they ship the same header files, but this affects builds only, and not (normal) runtime. Then: pkg:libmariadbclient-dev-compat is created to ship a symlink: libmysqlclient.so -> libmariadbclient.so. This must conflict with pkg:libmysqlclient-dev, but again we're affecting builds only, and not normal runtime. pkg:default-libmysqlclient-dev is created to depend on pkg:libmariadbclient-dev-compat. What this gets us: 1) Maintainers can build against whichever one they prefer, and/or the release team is in a position to be able to mandate a default as required. 2) Users can build against either, and continue to use either. There is no system wide choice being forced here. 3) No confusion between MySQL and MariaDB. "libmysqlclient.so.18" is always MySQL and "libmariadbclient.so.18" is always MariaDB. 4) Maintainers need only change their build dependencies. Upstreams that try to link using "-lmysqlclient" will continue to work. END OF PROPOSAL I tested this and it appears to work. https://git.launchpad.net/~racb/ubuntu/+source/mariadb-10.0/log/ is my MariaDB test modification (PoC with amd64 hardcoded). I created a fake "equivs" libmysqlclient-dev that depends only on libmariadbclient-dev-compat, and dropped the necessary conflicts, for testing purposes. cacti-spine (a simple consumer of libmysqlclient) then successfully linked against libmariadbclient.so.18 and depended on pkg:libmariadbclient18 with no further modification. If we want to test more packages, it's sufficient to just rebuild them with my test build dependencies available. Some commentary on my justifications above: 1) I believe this is the core of what the release team requested in terms of MySQL and MariaDB. I appreciate of course that whatever hackery we do to make this happen is something the release team should weigh in on also. 3) I really don't want to go down the route of "libmysqlclient.so.18" actually being MariaDB. It may be ABI-compatible now, but what about the future? MySQL 5.7 already bumps to libmysqlclient.so.20, for example. If and until MariaDB ships an ABI-compatible libmysqlclient.so.20, are we going to ship both, one from each upstream? What if MariaDB's one turns out not to be ABI compatible? I think down this path lies madness. sonames give us a method to avoid this conflict by using different names. We should use this if we can. Feedback on this approach appreciated. Robie
Bug#829735: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2016f
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I've prepared an update for libdatetime-timezone-perl in
jessie+jessie-updates which incorporates today's tzdata 2016f release
as a patch changing only the timezone data files.
One of the changes (Egypt) will be effective in 2 days unfortunately.
Manually stripped down debdiff attached.
Cheers,
gregor
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQJ8BAEBCgBmBQJXe+HaXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGEAcP/0Pumcgoa4jUiaOnCzXxzh8V
2PVYg3agWltvP1JEQxPliBLn1LO/6f6QlVQXMikfHQd/Zl6OuHONECj3SxjMNHww
0W1y3xTQcuZ44GxHEwWdm3KXX7vThwwiyzFRvPAAnZ1BDPybOj/AQ8TfhowyTKuY
crR9Ua9yZiCPlbKayB1+iWPNxipnCZATmylQ91aI3F95mZJRTGrtBpIU6NXPqE1O
FZ1Nlbire496WRyAR5qz/P7UDtvFt90WeFjvUtgCJCwlIQbavfXrLPjpCidoEQ55
iJMusDIv6Zf73tdjyrGruvJKzULek8bkpSnA8grVfncPAAR8Jwxb1n7OaUe5He5Q
ArbzFyj8FYVtHGEcqUUgk79S/Iuakm2O5uoP8sab9HuuO+NiAYpsc2ud2vnto2mP
nvKuQJBD/KrTAFGYHhdcXmzqUZNGfc/OQUOB/MIlahV0quTMBUqZiRqmbxjL+o6P
gVtzTel7Pu4aVVpta55phHXUaHR4DdpsIfXj0HADm9dMF+ImcBvNlnkf3xG3zhUi
IsRNEtYoSFjrgA6isgLdd6i22QlTfOR6F2YQ+mwNfB//yTkmlB1hLlNslFEGDowa
o9iKQKMl76ix3j7ppLnTrlDIYbUVPKMycaVb4xMSD3JpYsvr/LN849SmWBuxyxex
wnRzl9hLgcPfU4+s8LYb
=cuZU
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-1.75/debian/changelog libdatetime-timezone-perl-1.75/debian/changelog
--- libdatetime-timezone-perl-1.75/debian/changelog 2016-06-26 17:53:17.0 +0200
+++ libdatetime-timezone-perl-1.75/debian/changelog 2016-07-05 18:31:17.0 +0200
@@ -1,3 +1,13 @@
+libdatetime-timezone-perl (1:1.75-2+2016f) UNRELEASED; urgency=medium
+
+ * Update to Olson database version 2016f.
+Add patch debian/patches olson-2016f, which updates the timezone *.pm
+files, using upstream's tools/parse_olson script.
+This update contains contemporary changes for Africa/Cairo and
+Asia/Novosibirsk.
+
+ -- gregor herrmann Tue, 05 Jul 2016 18:29:45 +0200
+
libdatetime-timezone-perl (1:1.75-2+2016e) jessie; urgency=medium
* Update to Olson database version 2016e.
diff -Nru libdatetime-timezone-perl-1.75/debian/patches/olson-2016f libdatetime-timezone-perl-1.75/debian/patches/olson-2016f
--- libdatetime-timezone-perl-1.75/debian/patches/olson-2016f 1970-01-01 01:00:00.0 +0100
+++ libdatetime-timezone-perl-1.75/debian/patches/olson-2016f 2016-07-05 18:31:17.0 +0200
@@ -0,0 +1,16705 @@
+Description: update to olson db 2016f
+Origin: vendor
+Author: gregor herrmann
+Last-Update: 2016-07-05
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+
+ #
+-# Generated from debian/tzdata/africa. Olson data version 2016e
++# Generated from debian/tzdata/africa. Olson data version 2016f
+ #
+ # Do not edit this file directly.
+ #
+@@ -39,7 +39,7 @@
+ ],
+ ];
+
+-sub olson_version { '2016e' }
++sub olson_version { '2016f' }
+
+ sub has_dst_changes { 0 }
+
+--- a/lib/DateTime/TimeZone/Africa/Cairo.pm
b/lib/DateTime/TimeZone/Africa/Cairo.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+
+ #
+-# Generated from debian/tzdata/africa. Olson data version 2016e
++# Generated from debian/tzdata/africa. Olson data version 2016f
+ #
+ # Do not edit this file directly.
+ #
+@@ -1164,1093 +1164,26 @@
+ ],
+ [
+ 63547362000, #utc_start 2014-09-25 21:00:00 (Thu)
+-63603612000, # utc_end 2016-07-07 22:00:00 (Thu)
++DateTime::TimeZone::INFINITY, # utc_end
+ 63547369200, # local_start 2014-09-25 23:00:00 (Thu)
+-63603619200, #local_end 2016-07-08 00:00:00 (Fri)
++DateTime::TimeZone::INFINITY, #local_end
+ 7200,
+ 0,
+ 'EET',
+ ],
+-[
+-63603612000, #utc_start 2016-07-07 22:00:00 (Thu)
+-63613285200, # utc_end 2016-10-27 21:00:00 (Thu)
+-63603622800, # local_start 2016-07-08 01:00:00 (Fri)
+-63613296000, #local_end 2016-10-28 00:00:00 (Fri)
+-10800,
+-1,
+-'EEST',
+-],
+-[
+-63613285200, #utc_start 2016-10-27 21:00:00 (Thu)
+-63629013600, # utc_end 2017-04-27 22:00:00 (Thu)
+-63613292400, # local_start 2016-10-27 23:00:00 (Thu)
+-63629020800, #local_end 2017-04-28 00:00:00 (Fri)
+-7200,
+-0,
+-'EET',
+-],
+-[
+-63629013600, #utc_start 2017-04-27 22:00:00 (Thu)
+-63631429200, # utc_end 2017-05-25 21:00:00 (Thu)
+-63629024400, # local_start 2017-04-28 01:00:00 (Fri)
+-6363144, #local_end 2017-05-26 00:00:00 (Fri)
+-10800,
+-1,
+-'EEST',
+-],
+-[
+-63631429200, #utc_start 2017-05-25 21:00:00 (Thu)
+-63634456800, # utc_end 2017-06-29 22:00:00 (Thu)
+-63631436400, # local_start 2017-05-25 23:00:00 (Thu)
+-63634464000, #local_end 2017-06-30 00:00:00 (Fri)
+-7200,
+-0,
+-'EET',
+-],
+-[
+-
Re: Thinking about a "jessie and a half" release
On Tue, 2016-07-05 at 08:25 +0100, Rebecca N. Palmer wrote: > Would it be possible/reasonable (at least for stretch) to have the > installer detect this and ask "your hardware appears to be too new for > this release, would you like to enable -backports?" It might be, but it's going to be hard to tell what's 'too new'. We could check whether there are drivers that match the device IDs for the detected PCI and USB devices. However, we know that device IDs are sometimes added to a driver before the driver has stable support for those devices. That question might also be giving false hope, in that the devices not supported in stable might still be unsupported in stable-backports. > On 04/07/16 23:38, Ben Hutchings wrote: > > As I understand it, xserver-xorg-video-modesetting should be used > > instead of xserver-xorg-video-intel, for chips supported by the i915 > > kernel driver. So the latter should be changed to limit the device IDs > > it claims, then both of them should be backported. > > This appears to be causing at least one actual problem: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828087 [...] Once this is fixed in unstable and then testing, I wonder how to fix this for jessie-backports. The modesetting driver is now part of xserver-xorg-core and that has had a driver ABI bump which would require backporting other driver packages. Ben. -- Ben Hutchings Life is what happens to you while you're busy making other plans. - John Lennon signature.asc Description: This is a digitally signed message part
Bug#829130: jessie-pu: package wget/1.16-1+deb8u1
Hello Salvatore and Stable Release Managers,
Am Dienstag, den 05.07.2016, 15:44 +0200 schrieb Salvatore Bonaccorso:
> > Package: release.debian.org
> > Severity: normal
> > Tags: jessie
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > wget in stable is affected by CVE-2016-4971, an issue where wget
...
> JFTR, if actually Noël Köthe would like to do the
> upload himself, I can happily hand over.
I wasn't aware of this release bugreport (sorry). Thanks for CC:.
DSA informed me that there will be no DSA for this CVE and liked to see
this fixed by a jessie point release.
https://security-tracker.debian.org/tracker/CVE-2016-4971 (at the end
"no DSA").
Attached the minor changed debdiff based on the backported patch from
Salvatore.
I tested the resulting wget 1.16-1+deb8u1 package on a amd64 jessie
machine.
If the Stable Release Manager accept the changes I will upload the
package.
Regards
Noeldiff -Nru wget-1.16/debian/changelog wget-1.16/debian/changelog
--- wget-1.16/debian/changelog 2014-10-27 11:41:18.0 +0100
+++ wget-1.16/debian/changelog 2016-07-05 16:21:21.0 +0200
@@ -1,3 +1,15 @@
+wget (1.16-1+deb8u1) jessie; urgency=medium
+
+ * added patch for CVE-2016-4971. closes: #827003, #829130
+By default, on server redirects to a FTP resource, use the original
+URL to get the local file name. Close CVE-2016-4971. This
+introduces a backward-incompatibility for HTTP->FTP redirects and
+any script that relies on the old behaviour must use
+--trust-server-names.
+ * debian/rules fixed clean target
+
+ -- Noël Köthe Mon, 04 Jul 2016 18:37:47 +0200
+
wget (1.16-1) unstable; urgency=medium
* new upstream release from 2014-10-27
diff -Nru wget-1.16/debian/patches/series wget-1.16/debian/patches/series
--- wget-1.16/debian/patches/series 2014-10-16 11:32:22.0 +0200
+++ wget-1.16/debian/patches/series 2016-06-30 17:21:45.0 +0200
@@ -1,4 +1,5 @@
wget-doc-remove-usr-local-in-sample.wgetrc
wget-doc-remove-usr-local-in-wget.texi
wget-passive_ftp-default
+wget-CVE-2016-4971.patch
diff -Nru wget-1.16/debian/patches/wget-CVE-2016-4971.patch wget-1.16/debian/patches/wget-CVE-2016-4971.patch
--- wget-1.16/debian/patches/wget-CVE-2016-4971.patch 1970-01-01 01:00:00.0 +0100
+++ wget-1.16/debian/patches/wget-CVE-2016-4971.patch 2016-07-05 16:09:10.0 +0200
@@ -0,0 +1,270 @@
+Description: ftp: understand --trust-server-names on a HTTP->FTP redirect
+ If not --trust-server-names is used, FTP will also get the destination
+ file name from the original url specified by the user instead of the
+ redirected url. Closes CVE-2016-4971.
+Origin: backport, http://git.savannah.gnu.org/cgit/wget.git/commit/?id=e996e322ffd42aaa051602da182d03178d0f13e1
+Bug-Debian: https://bugs.debian.org/827003
+Forwarded: not-needed
+Author: Giuseppe Scrivano
+Reviewed-by: Salvatore Bonaccorso
+Last-Update: 2016-06-30
+Applied-Upstream: 1.18
+---
+
+--- a/src/ftp.c
b/src/ftp.c
+@@ -235,14 +235,15 @@ print_length (wgint size, wgint start, b
+ logputs (LOG_VERBOSE, !authoritative ? _(" (unauthoritative)\n") : "\n");
+ }
+
+-static uerr_t ftp_get_listing (struct url *, ccon *, struct fileinfo **);
++static uerr_t ftp_get_listing (struct url *, struct url *, ccon *, struct fileinfo **);
+
+ /* Retrieves a file with denoted parameters through opening an FTP
+connection to the server. It always closes the data connection,
+and closes the control connection in case of error. If warc_tmp
+is non-NULL, the downloaded data will be written there as well. */
+ static uerr_t
+-getftp (struct url *u, wgint passed_expected_bytes, wgint *qtyread,
++getftp (struct url *u, struct url *original_url,
++wgint passed_expected_bytes, wgint *qtyread,
+ wgint restval, ccon *con, int count, wgint *last_expected_bytes,
+ FILE *warc_tmp)
+ {
+@@ -992,7 +993,7 @@ Error in server response, closing contro
+ {
+ bool exists = false;
+ struct fileinfo *f;
+- uerr_t _res = ftp_get_listing (u, con, &f);
++ uerr_t _res = ftp_get_listing (u, original_url, con, &f);
+ /* Set the DO_RETR command flag again, because it gets unset when
+ calling ftp_get_listing() and would otherwise cause an assertion
+ failure earlier on when this function gets repeatedly called
+@@ -1536,7 +1537,8 @@ Error in server response, closing contro
+This loop either gets commands from con, or (if ON_YOUR_OWN is
+set), makes them up to retrieve the file given by the URL. */
+ static uerr_t
+-ftp_loop_internal (struct url *u, struct fileinfo *f, ccon *con, char **local_file)
++ftp_loop_internal (struct url *u, struct url *original_url, struct fileinfo *f,
++ ccon *con, char **local_file)
+ {
+ int count, orig_lp;
+ wgint restval, len = 0, qtyread = 0;
+@@ -1560,7 +1562,7 @@ ftp_loop_internal (struct url *u, struct
+ else
+ {
+ /
Bug#828630: jessie-pu: package libbusiness-creditcard-perl/0.33-1+deb8u1
On Sun, 26 Jun 2016 18:18:55 +0200, gregor herrmann wrote: > > > In practice there are several options to do this update in stable: > > > - What I've prepared (attached as a debdiff) for now is to backport > > > the functional and some documentation changes from 0.34 and 0.35 to > > > 0.33 in 3 logically separate quilt patches, in order to make > > > reviewing easy. In practice this leaves out only some minor changes > > > in metadata and unrelated documentation changes from 0.35. > > > - Ivan (upstream and Debian contributor) originally asked to take > > > the 0.35 release and upload it to stable (presumably as > > > 0.35-0+deb8u1). This had the advantage of shipping a fully tested > > > release but is probably not the release team's typically preferred > > > way. -- Complete diff: > > > > > > https://metacpan.org/diff/file?target=IVAN%2FBusiness-CreditCard-0.35%2F&source=IVAN%2FBusiness-CreditCard-0.33%2F > > > > I'd be okay with either of those options, having looked at the upstream > > diff. > > Thanks, then I think we can proceed with the second option, i.e. > updating to the "full" 0.35 release. > > I'm attaching a new debdiff for the proposed upload. *gentle ping* (As in: "I'd rather be on the cautious side and have an explicit ACK on the last debdiff before uploading.") Cheers, gregor -- .''`. Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
Hi all, Quoting Ralf Treinen (2016-07-05 15:51:58) > One change I also spotted only very recently is that the --latest option now > takes an integer argument. If you used -latest before you should replace it > by "--latest 1" now. from IRC, the error supposedly was: STDERR: Fatal error in module deb/debcudf.ml: Unable to get real version for libusb-1.0-0-dev:kfreebsd-i386 (20826) All Known versions for this package are (libusb-1.0-0-dev,2:1.0.19) Aurélien told me that they will try to get some data for us to reproduce and analyze the issue. > Cheers from debconf in Cape Town -Ralf. cheers to cape town! josch signature.asc Description: signature
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
Hi Aurelien, On Tue, Jul 05, 2016 at 03:12:06PM +0200, Aurelien Jarno wrote: > > Thanks a lot, I have installed it on wuiet. It seems to work fine at a > > first glance. > > Unfortunately I had to revert it to the jessie version has it doesn't > correctly compute the dependencies. It looks like something has changed > in the command line interface, and I have no time to investigate now. One change I also spotted only very recently is that the --latest option now takes an integer argument. If you used -latest before you should replace it by "--latest 1" now. Cheers from debconf in Cape Town -Ralf.
Bug#829130: jessie-pu: package wget/1.16-1+deb8u1
Hi, On Thu, Jun 30, 2016 at 09:42:44PM +0200, Salvatore Bonaccorso wrote: > Package: release.debian.org > Severity: normal > Tags: jessie > User: release.debian@packages.debian.org > Usertags: pu > > Hi stable release managers, > > wget in stable is affected by CVE-2016-4971, an issue where wget does > not correctly handle filenames when beeing redirected from a HTTP to a > FTP URL. We think that this does not necessarly need a DSA, but still > would be good to be fixed in stable. I thus have prepared a debdiff, > attached. Bug in BTS is #827003. > > The debdiff contains an increasing debian/wget.debhelper.log. > > If you allow me to, I can prepare a new debdiff, to clean this up as > well, by using dh_prep instead of dh_clean -k for the build target. > Would that be fine? > > But attached the debdiff without that packaging change. JFTR, if actually Noël Köthe would like to do the upload himself, I can happily hand over. Regards, Salvatore
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
On 2016-07-05 14:36, Aurelien Jarno wrote: > On 2016-07-02 22:03, Anton Gladky wrote: > > Dear all, > > > > I have just uploaded dose3_5.0-1~bpo8+1 into jessie-backports. > > > > Thanks a lot, I have installed it on wuiet. It seems to work fine at a > first glance. Unfortunately I had to revert it to the jessie version has it doesn't correctly compute the dependencies. It looks like something has changed in the command line interface, and I have no time to investigate now. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Processed: tagging 829606
Processing commands for cont...@bugs.debian.org: > # forgot to remove moreinfo on own reply > tags 829606 - moreinfo Bug #829606 [release.debian.org] jessie-pu: package duck/0.7+deb8u1 Removed tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 829606: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829606 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Thinking about a "jessie and a half" release
2016-07-05 7:43 GMT-03:00 Jose R R : > > Why would you call it "Jessie + 1/2"? Wouldn't it be a better idea > Well IBM set a precedent for that: OS/2. > Accordingly, Jessie BP could be called Jessie/2 ;-) Well, that would be a half Jessie, not Jessie and a half, right? We could use 3Jessie/2 or Jessie3/2, or maybe not. Mark Brown > We're getting to the point where there's a fairly pressing need for > arm64 - the more useful hardware is starting to get a wider distribution > and we don't really have anything for people who want to run Debian > that gets them a supported system with an upgrade path. > We have Debian Stretch, which is what i recommend to anybody who wants do install Debian as a desktop. I understand the difference of running Debian Testing and Debian Stable with some backported packages, but is it really worth it? Shouldn't we discuss more the usability of Testing as a solid release, or maybe start doing a stable release and another release kinda like Testing but with more stability guarantees? I'm not really sure, but i think opensuse has a model like that. I use debian for a considerable amount of time now, but just started interacting with the community recently, having installed debian to a lot of new users on installfests over the years, one of the most common problems i found out for novice Debian users is that they don't really know how Debian releases works and thinks using stable in their laptop bought last year is a good idea, then i always end up having a conversation where they're needing help with problems related to using stable, i have to explain things like: why their performance is crap, why they can't see youtube html5 videos on iceweasel version lastversion-4, why they can't install softwares like steam (wheezy was a hard one on this)* and how the testing stability is the same, or better, than of the other distros they used to use. They always end up using Debian Testing, knowing that the main risk comes when the unfreeze happens and that while the freeze is rolling they will have a more stable debian (compared to when unfreezed). *these are just some of the various conversations i've had. Unfortunately i' not attending DebConf, but it is a great opportunity to discuss things like this there, maybe even form a team and work on policies changes for this "new testing" release, if i'm not dreaming too big. Samuel Henrique O. P. [samueloph]
Bug#826568: jessie-pu: package sendmail/8.14.4-8+deb8u1
On 2016-07-05 11:51, Adam D. Barratt wrote: > On a related note, which has been mentioned before (on dda at least) - > please don't name your .changes file _amd64.changes if the package > builds amd64 binaries and they're not included in the upload. dak keeps That's dpkg-buildpackage -g in stable. It is fixed in sid. (#826161) Guillem, could #826161 be fixed in stable, too? Andreas
Re: Thinking about a "jessie and a half" release
Hi Steve, On Mon Jul 04, 2016 at 14:01:03 +0100, Steve McIntyre wrote: > A lot of arm64 machine users would benefit from this, and maybe owners > of very recent amd64 machines too, with better support for things on > the Skylake platform. Those are the only two architectures I'm > thinking of supporting at this point. > > Is anybody else interested in helping? Thoughts/comments? from a cloud image users perspective this sounds like a great idea. There are several things eg. in the kernel with 10GE network drivers, where a newer kernel would definitivly help a lot. Also maybe newer cloud-init and friends would help. Please go for it. +1 from my side. Cheers, Martin -- Martin Zobel-Helas Debian System Administrator Debian & GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
On 2016-07-02 22:03, Anton Gladky wrote: > Dear all, > > I have just uploaded dose3_5.0-1~bpo8+1 into jessie-backports. > Thanks a lot, I have installed it on wuiet. It seems to work fine at a first glance. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#829145: transition: glibc 2.23
On 04/07/16 00:48, Aurelien Jarno wrote: > On 2016-07-01 09:42, Emilio Pozuelo Monfort wrote: >> Control: tags -1 confirmed >> >> On 01/07/16 01:41, Aurelien Jarno wrote: >>> Package: release.debian.org >>> Severity: normal >>> User: release.debian@packages.debian.org >>> Usertags: transition >>> >>> Dear release team, >>> >>> We would like to get a transition slot for glibc 2.23. It is currently >>> available in experimental and has been built successfully on all >>> official architectures except hurd-i386. We have fixed the hurd-i386 >>> failure in out git, and we are working on build failures for alpha, hppa >>> and sparc64. There are due to testsuite issue, mostly in the math parts >>> and do not look very critical. >>> >>> It should be noted that this upload will make a few packages to FTBFS, >>> mostly due to more precise checking in the floating-point classification >>> macros (isnan, isinf, ...). In most of the cases the changes just make >>> existing bugs visible. The list of affected packages is available [1] >>> (thanks to Martin Michlmayr), and the bugs have been opened for more >>> than 3 months. >>> >>> As the glibc is using symbol versioning, there is no soname change. That >>> said a few packages are using libc internal symbols and have to be >>> rebuilt for this transition: >>> - apitrace >>> - bro >>> - dante >>> - libnih >>> - libnss-db >>> - unscd >>> >>> Here is the corresponding ben file: >>> >>> title = "glibc"; >>> is_affected = .depends ~ /libc[0-9.]* \(<>> is_good = .depends ~ /libc[0-9.]* \(<< 2.24\)/; >>> is_bad = .depends ~ /libc[0-9.]* \(<< 2.23\)/; >>> >>> In addition to that, a few new symbols have been added that might >>> prevent a few other packages to transition to testing if they pick up >>> the new symbols, namely the fts64_* and the lgamma* ones. It should not >>> concerns many packages. >> >> Go ahead. > > It has just been accepted by dak. binnmus scheduled. Cheers, Emilio
Bug#829371: transition: ntl
Hi, On 04/07/2016 14:13, Jonathan Wiltshire wrote: On 2016-07-03 10:30, Jonathan Wiltshire wrote: Control: tag -1 confirmed On 2016-07-02 21:58, Julien Puydt wrote: I checked that these new ntl packages make it possible to build eclib, flint, linbox, singular and flint-arb on an amd64 debian box, so I don't expect any new problem. Please go ahead. Seems to have happened, so rebuilds scheduled. I still follow things on the auto-ntl tracker, so I don't see if anything happens with flint-arb : is it ok ? Snark on #debian-science
Re: [debian-mysql] About packages that depend on mysql-* / mariadb / virtual-mysql-*
2016-07-02 17:53 GMT+03:00 Otto Kekäläinen: > This is modeled after how default-jdk or default-mta works. Actually default-jdk is a real metapackage, while default-mta is a pure virtual package. I am not sure which way to pick here now. https://packages.debian.org/jessie/default-mta https://packages.debian.org/jessie/default-jdk It depends on what behaviour you want on dist-upgrade. A real package will stick arround, so if you switch the default then a dist-upgrade will pull in the new default. On the other hand a virtual package is never installed as such, so existing systems will keep their existing implementation.
Re: Thinking about a "jessie and a half" release
On Tue, Jul 5, 2016 at 2:01 AM, Christian Seiler wrote: > > On 07/04/2016 03:01 PM, Steve McIntyre wrote: > > There's something I've been pondering for a while, along with some > > other folks - it might be useful to do a "jessie and a half" release, > > similarly to what we did in the etch days. That's *basically* just > > like a normal jessie release, but with a few key updates: > > > > * backports kernel > > * rebuilt d-i to match that kernel > > * X drivers > > * ... (other things that might be needed for consistency) > > > > all rolled up with a small installer image build (netinst, maybe DVD#1). > > Why would you call it "Jessie + 1/2"? Wouldn't it be a better idea Well IBM set a precedent for that: OS/2. Accordingly, Jessie BP could be called Jessie/2 ;-) > to regularly have a "backports installer" netinst image? So when > 8.6 (or 8.7 if it takes longer) comes around, there'll be an image, > part of the point release, that will contain the backports kernel > that's current at that time, plus the installer will enable backports > automatically, plus it will install a preferences.d file that will > enable pulling kernel + X11 drivers from backports. (But not other > things.) > > This could then be a regular part of the released installer images, > and any new major release (e.g. Stretch 9.0) would enable the > preferences.d file + backports automatically, but would still use > the regular kernel at that point (because there'd be no backports > then). > > That way, you'd have a little more work in the installer in creating > an image that uses a backports kernel, but there'd be no need in > having to support a new release in addition to Jessie, because the > installed system would be equivalent to Jessie + upgrade kernel to > backports + remove old kernel package. Which is already something > that people do _now_. > > Regards, > Christian > Good luck! -- Jose R R http://metztli.it - Try at no charge http://b2evolution.net for http://OpenShift.com PaaS - from our GitHub http://Nepohualtzintzin.com repository. Cloud the easy way! -
Re: About packages that depend on mysql-* / mariadb / virtual-mysql-*
2016-07-05 12:41 GMT+03:00 Jonathan Wiltshire : > I don't think I understand why you would have both virtual-mysql-* and > default-mysql-* packages for dependencies (leaving aside build-deps). If a > package requires one of the variants, it will need an explicit dependency. > If it doesn't care, it should use the default. > > Therefore are the virtual-* packages required? > > As virtual packages provided by >1 package breaks build-dependency > handling, if there is any danger that these might be used in build-depends > they should be meta-packages, not virtual. Maintainers need to have 2 options: 1. depend on a specific one OR 2. depend on the default one but be work with any of them default-mysql-* only points to a single option. If the admin of system has already installed MariaDB, Oracle, Percona, mysql-wsrep or whatever is available from 3rd party repositories, they should be able to continue using that option and not forced into installing what default-mysql-* points to. Using "Depends: mysql-default-server | virtual-mysql-server" allows this flexibility. Also, mysql-virtual-* has been in production since 2013 and is implemented everywhere, we should not break it now. >> > 3. libmysqlclient.so.18 ... > I wonder if pkgconfig can be any help here? That involves a one-time change > to client packages if they don't already use pkgconfig but doesn't have to > be repeated if the default switches. I don't know, I am not faimiliar with it. I'll research.
Bug#826568: jessie-pu: package sendmail/8.14.4-8+deb8u1
On Sun, 2016-07-03 at 17:50 +0200, Adam D. Barratt wrote: > Uploaded and flagged for acceptance. On a related note, which has been mentioned before (on dda at least) - please don't name your .changes file _amd64.changes if the package builds amd64 binaries and they're not included in the upload. dak keeps the changes files in dists/proposed-updates until they're manually cleared out as part of a point release, so the buildd upload on amd64 was rejected due to there already being an _amd64.changes there. I've asked ftp-master to rename and accept the buildd upload, but it makes me a little unhappy every time I have to do so. Regards, Adam
Re: About packages that depend on mysql-* / mariadb / virtual-mysql-*
On Sun, Jul 03, 2016 at 12:46:29PM +0100, Otto Kekäläinen wrote: > On the pkg-mysql-maint team we have discussed providing a new scheme > to complement the existing virtual-mysql-* scheme. We plan to > introduce new purely virtual packages, that are provided only by > MariaDB: > - default-mysql-client > - default-mysql-client-core > - default-mysql-server > - default-mysql-server-core > - default-libmysqlclient > > (the last item on the list is my own addition, see point 3 below) > > Once these are available we would announce them on debian-devel@ and > ask all packagers to update existing "Depends: mysql-*" to "Depends: > default-mysql-*" > > If release team whished to switch defaults, then it is just a matter > on deciding which package shall provide these default-mysql-* virtual > packages. This is how e.g. default-mta works and is provided by > Postfix. I don't think I understand why you would have both virtual-mysql-* and default-mysql-* packages for dependencies (leaving aside build-deps). If a package requires one of the variants, it will need an explicit dependency. If it doesn't care, it should use the default. Therefore are the virtual-* packages required? As virtual packages provided by >1 package breaks build-dependency handling, if there is any danger that these might be used in build-depends they should be meta-packages, not virtual. > > 3. libmysqlclient.so.18 > > Here theres's no concensus yet within the pkg-mysql-maint team on this one. > > I suggest we extend the mysql-defaults source package to provide a > real default-mysqlclient-dev metapackage, which other packages can > build depend on, using versions if needed (just as default-jdk does). Yes. > Current mariadb-10.0 source package does not ship any > libmariadbclient18 nor libmariadbclient-dev packages at all, as > previously it was seen as against the policy (but mariadb-5.5 in > Debian did). I suggest we start producing them now again to make a > libmysqlclient.so(.18) available from mariadb-10.0. > > Having two libmysqlclient.so.18 files from two different packages is a > controversial topic. They are not identical so it is ugly to use the > same name. This is however a necessity dictated by the need to provide > a drop-in-replacement that can be used directly without going into > every single clienting program and editing the C headers and soname > calls. We discussed this in the release team and concluded that having two libmysqlclient.so.18 files in two packages is likely to run into problems later if/when they diverge, so there is no point delaying that pain. Especially as they are not identical even now. I wonder if pkgconfig can be any help here? That involves a one-time change to client packages if they don't already use pkgconfig but doesn't have to be repeated if the default switches. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
Re: Thinking about a "jessie and a half" release
On Tue, Jul 05, 2016 at 10:52:37AM +0200, Ben Hutchings wrote: > On Tue, 2016-07-05 at 10:07 +0200, Mark Brown wrote: > > We're getting to the point where there's a fairly pressing need for > > arm64 - the more useful hardware is starting to get a wider distribution > > and we don't really have anything for people who want to run Debian > > that gets them a supported system with an upgrade path. > I'm not questioning whether it would be good to have this now. But we > don't have it now and won't have it for some time. So long as it's substantially before the next release it shuld still be useful. signature.asc Description: PGP signature
Re: Thinking about a "jessie and a half" release
On 07/04/2016 03:01 PM, Steve McIntyre wrote: > There's something I've been pondering for a while, along with some > other folks - it might be useful to do a "jessie and a half" release, > similarly to what we did in the etch days. That's *basically* just > like a normal jessie release, but with a few key updates: > > * backports kernel > * rebuilt d-i to match that kernel > * X drivers > * ... (other things that might be needed for consistency) > > all rolled up with a small installer image build (netinst, maybe DVD#1). Why would you call it "Jessie + 1/2"? Wouldn't it be a better idea to regularly have a "backports installer" netinst image? So when 8.6 (or 8.7 if it takes longer) comes around, there'll be an image, part of the point release, that will contain the backports kernel that's current at that time, plus the installer will enable backports automatically, plus it will install a preferences.d file that will enable pulling kernel + X11 drivers from backports. (But not other things.) This could then be a regular part of the released installer images, and any new major release (e.g. Stretch 9.0) would enable the preferences.d file + backports automatically, but would still use the regular kernel at that point (because there'd be no backports then). That way, you'd have a little more work in the installer in creating an image that uses a backports kernel, but there'd be no need in having to support a new release in addition to Jessie, because the installed system would be equivalent to Jessie + upgrade kernel to backports + remove old kernel package. Which is already something that people do _now_. Regards, Christian signature.asc Description: OpenPGP digital signature
Re: Thinking about a "jessie and a half" release
On Tue, 2016-07-05 at 10:07 +0200, Mark Brown wrote: > On Mon, Jul 04, 2016 at 07:05:42PM +0200, Ben Hutchings wrote: > > On Mon, 2016-07-04 at 14:01 +0100, Steve McIntyre wrote: > > > > A lot of arm64 machine users would benefit from this, and maybe owners > > > of very recent amd64 machines too, with better support for things on > > > the Skylake platform. Those are the only two architectures I'm > > > thinking of supporting at this point. > > > > Is anybody else interested in helping? Thoughts/comments? > > > When do you anticipate this would be releasable? Would it really be > > long enough before stretch, to be worthwhile? > > We're getting to the point where there's a fairly pressing need for > arm64 - the more useful hardware is starting to get a wider distribution > and we don't really have anything for people who want to run Debian > that gets them a supported system with an upgrade path. I'm not questioning whether it would be good to have this now. But we don't have it now and won't have it for some time. Ben. -- Ben Hutchings Life is what happens to you while you're busy making other plans. - John Lennon signature.asc Description: This is a digitally signed message part
Bug#827160: jessie-pu: package dosfstools/3.0.27-1+deb8u1
[Andreas Bombe] > If you strongly expect it to be accepted as it is, then push it. > > Or wait with tagging until it is accepted. Moving tags and releases > that aren't releases after all is something I'd like to avoid. Right. I believe the changes are sound and suspect the release team agree with me that fixing also minor security issues in Stable is important. Because of this, I've pushed the changes, but not added the tag. I suspect it would help if you the package maintainer believe these changes should go into stable too. Btw, do you know why there is no BTS report about these two CVEs? -- Happy hacking Petter Reinholdtsen
Re: Thinking about a "jessie and a half" release
On Mon, Jul 04, 2016 at 04:01:10PM -0400, Nicholas D Steeves wrote: >>> >>> Is anybody else interested in helping? Thoughts/comments? > >Yes, it's a project I'm already working on ;-) Is this project a >candidate for a new Debian Team? I guess so, yes. :-) >> 2. Does it have to be called "jessie and a half"? (How much is the >> concept understood across users? Wouldn't it be a better idea to >> squeeze the "backports" concept into the name somehow?) > >Maybe something like jessie-fresh-unofficial? I'm definitely *not* thinking of saying this is "unofficial" - I'm wanting this to be blessed as an additional installation option here. >On 4 July 2016 at 13:13, Hideki Yamane wrote: >> >> Just a comment. I don't have any objection for this proposal. >> >> However, not only half but also updates with some point is better >> to deliver value for users, I hope it'll be in Stretch cycle. >> >> Recently I've read "lean software development" and it's quite >> impressive for me. "deliver value to users" is one of the most >> important thing in Debian (it means "do continuous improvement >> for stable"), IMO. > >Agreed! Also, OpenSUSE has been doing this with their post-42.x >release model. Mind you, to the best of my knowledge Debian has >always cherry picked fixes and essential hardware enablement fixes for >the stable packages (eg: intel-microcode). This newly proposed Debian >project seems to be a more aggressive approach...but does it also have >a client machine focus to the exclusion of servers, or should it serve >both? I'm more concerned about easy installation on new "client" x86 machines at this point, and for arm64 machines in general as they've seen massive changes since we released jessie. I don't think x86 server machines are such an issue, but I'm open-minded if somebody wants to argue otherwise. -- Steve McIntyre, Cambridge, UK.st...@einval.com "C++ ate my sanity" -- Jon Rabone
Re: Thinking about a "jessie and a half" release
On Mon, Jul 04, 2016 at 07:05:42PM +0200, Ben Hutchings wrote: > On Mon, 2016-07-04 at 14:01 +0100, Steve McIntyre wrote: > > A lot of arm64 machine users would benefit from this, and maybe owners > > of very recent amd64 machines too, with better support for things on > > the Skylake platform. Those are the only two architectures I'm > > thinking of supporting at this point. > > Is anybody else interested in helping? Thoughts/comments? > When do you anticipate this would be releasable? Would it really be > long enough before stretch, to be worthwhile? We're getting to the point where there's a fairly pressing need for arm64 - the more useful hardware is starting to get a wider distribution and we don't really have anything for people who want to run Debian that gets them a supported system with an upgrade path. signature.asc Description: PGP signature
Re: Thinking about a "jessie and a half" release
On Mon, Jul 04, 2016 at 03:12:34PM +0200, Cyril Brulebois wrote: >Hi, > >Steve McIntyre (2016-07-04): >> There's something I've been pondering for a while, along with some >> other folks - it might be useful to do a "jessie and a half" release, >> similarly to what we did in the etch days. That's *basically* just >> like a normal jessie release, but with a few key updates: >> >> * backports kernel > >That's a given. > >> * rebuilt d-i to match that kernel > >You know there are patches around for that. ACK. :-) >> * X drivers > >I don't see backports for them. I installed a backport Intel xserver driver over the weekend at the installfest, and it helped the user in question. >> * ... (other things that might be needed for consistency) >> >> all rolled up with a small installer image build (netinst, maybe >> DVD#1). > >That'd probably make it easy to decide how to resolve open questions >with my "d-i vs. backported kernel" patches. Cool. >> Is anybody else interested in helping? Thoughts/comments? > >Questions: > 1. Is it going to pick pieces from backports only? (See X question >above.) That's my current plan, unless people have good arguments otherwise. > 2. Does it have to be called "jessie and a half"? (How much is the >concept understood across users? Wouldn't it be a better idea to >squeeze the "backports" concept into the name somehow?) I'm not attached to any particular name. Something like "Jessie Backport August 2016" would work for me too - suggest a better name? > 3. What about security support once the system is installed? (Which >can be answered along with 1., I suppose.) Most of the core packages I'd expect to use in backports are seeing regular updates AFAICS. That's probably enough? -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Re: Thinking about a "jessie and a half" release
On Tue, 2016-07-05 at 08:25 +0100, Rebecca N. Palmer wrote: > Have you reported this bug (with the full warnings)? If not, please > do so. I haven't. If I got a response at all to "My monitor doesn't work" it looks to me it would be: compile latest source with instrumentation turned on and send log. I've tried compiling the Intel drivers before - I could not get patches to apply. Fortunately, others get the same backtrace: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1523088 It probably isn't related to my monitor not displaying, but I won't be able to tell until 4.8, when the patch addressing that report is scheduled to make it to a released kernel. Like I said, progress is slw. My point is really the 4.4 kernel is nothing special for amd64. Laptop's with Intel chipsets that started shipping over 6 months ago don't work 100% with it. Actually from memory the Intel GPU driver opps's on occasion in 4.4. signature.asc Description: This is a digitally signed message part
Re: Thinking about a "jessie and a half" release
Would it be possible/reasonable (at least for stretch) to have the installer detect this and ask "your hardware appears to be too new for this release, would you like to enable -backports?" On 04/07/16 23:38, Ben Hutchings wrote: As I understand it, xserver-xorg-video-modesetting should be used instead of xserver-xorg-video-intel, for chips supported by the i915 kernel driver. So the latter should be changed to limit the device IDs it claims, then both of them should be backported. This appears to be causing at least one actual problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828087 (The other backports-kernel bugs known to me are https://lists.debian.org/debian-backports/2016/06/threads.html#00133 (appears to be fixed in 4.6) and https://lists.debian.org/debian-backports/2016/06/threads.html#00139 (no details yet)). Russell Stuart wrote: Currently 4.6.0 doesn't work with skylake for me when I plug in a 3440x1440 monitor on a Dell XPS 9550, both with and without xserver- xorg-video-intel installed. It never has worked reliably on any kernel version. Currently, the monitor works maybe 20% of the time - so if you persist for 5 boots you've got a reasonable chance of getting lucky. The only noticeable change from 4.5 to 4.6 is in the kernel backtraces produced - they have got fewer, and they are only warnings now. Have you reported this bug (with the full warnings)? If not, please do so.
