Re: Bug#885563: vte: Do not release with Buster
On Sun, Sep 30, 2018 at 09:03:47AM -0400, Jeremy Bicha wrote: > On Sun, Sep 30, 2018 at 2:57 AM Niels Thykier wrote: > > AFAICT, the cdebconf-gtk-terminal bug (#887649) has not been updated in > > the past 8 months. Is it still realistic to remove vte before the > > transition freeze (2019-01-12)? > I agree that I don't see anyone working on that bug now. I think > porting to gtk3 and getting rid of the unmaintained vte version is an > important goal for Debian. I'd like to leave this bug as RC for Buster > until the Transition Freeze. Unfortunately it doesn't look like there was progress on #887649 this cycle either. So I fear that we'll end up needing to tag both #887649 and #885563 bookworm-ignore. :( Kind regards Philipp Kern
Re: Bug#1012166: ITP: haskell-tzdata -- Haskell package that distributes the standard time zone database
Hi, On 31.05.22 10:14, Robert Greener wrote: The goal of this package is to distribute the standard Time Zone Database in a cabal package, so that it can be used in Haskell programs uniformly on all platforms. This package currently ships the 2022a version of the time zone database. The version of the time zone database shipped is always reflected in the version of this package: x.y.MMDD.z, then MMDD is the official release date of time zone database. I'm not sure further proliferation of this data that needs updating frequently is helpful. Is there any way this data could instead be read from disk - i.e. the from the existing tzdata package? This would add up to the load of all the various packages of various languages that already need updating with every tzdata release. Kind regards Philipp Kern
Re: Bug#985556: flatpak/1.2.5-0+deb10u4 FTBFS on i386
On 20.03.21 13:32, Simon McVittie wrote: > On Sat, 20 Mar 2021 at 09:16:45 +0100, Salvatore Bonaccorso wrote: >> On Sat, Mar 20, 2021 at 12:12:39AM +, Simon McVittie wrote: >>> Could x86-conova-01.debian.org be an IPv6-only buildd? > ... >>> Or, if not that, could it be the case that this buildd is firewalled or >>> otherwise restricted such that connections from the build to a test >>> server listening on an arbitrary high port number on the loopback >>> interface will fail? >> >> JFTR, this might indeed be the case. I gave it back a couple of times >> and building on x86-conova-01.debian.org failed. The last one got >> picked on buildd-x86-grnet-01 which now seems to have built. > > If we now have buildds that are more restrictive or limited than > the buildds that were used at the time stable was frozen, then > it would probably be good if it was possible to arrange for only > testing/unstable/experimental packages to be built on those buildds, > with stable updates built on buildds that more closely resemble the ones > they were originally tested on - otherwise we'll get random build > regressions. The buildd is IPv6-only. I'm somewhat torn given that we have enough buildd coverage that a give-back would likely solve the problem. At the same time you can't avoid a particular buildd either. So I concur, as much as it hurts me in this day and age, that we should at least temporarily disable stable/oldstable builds on the IPv6-only buildds. I have commented out stretch and buster (and their corresponding security and backports suites) on x86-conova-01 for now. I'll definitely leave bullseye on, though. Not sure if there's another IPv6-only buildd lingering around. Kind regards and thanks Philipp Kern
Bug#968548: buster-pu: package s390-tools/2.3.0-2~deb10u1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
Severity: important
X-Debbugs-Cc: debian-s...@lists.debian.org
debootstrap fails to install Debian buster on s390x because of a
multi-arch "perl:any" dependency it fails to parse (bug #960265). This
update to s390-tools hardcodes the dependency on "perl" without that,
which should make the installation possible again. I already validated
that this fixed the issue on unstable and I could successfully install
it using debian-installer.
The fix is this one-liner. Debdiff attached. This should be fixed in the
package rather than debootstrap for now as debootstrap fixes are harder
to distribute.
> diff -Nru s390-tools-2.3.0/debian/control s390-tools-2.3.0/debian/control
> --- s390-tools-2.3.0/debian/control 2018-02-04 19:29:22.0 +0100
> +++ s390-tools-2.3.0/debian/control 2020-08-16 16:35:52.0 +0200
> @@ -9,7 +9,7 @@
>
> Package: s390-tools
> Architecture: s390x
> -Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends}, gawk
> +Depends: ${shlibs:Depends}, ${misc:Depends}, perl, gawk
> Recommends: sg3-utils
> Description: Set of fundamental utilities for Linux on S/390
> The package contains:
My assumption is that this is not fixable through -updates but requires
a point release to be properly fixed.
Kind regards and thanks
Philipp Kern
diff -Nru s390-tools-2.3.0/debian/changelog s390-tools-2.3.0/debian/changelog
--- s390-tools-2.3.0/debian/changelog 2018-02-04 19:29:22.0 +0100
+++ s390-tools-2.3.0/debian/changelog 2020-08-17 10:04:45.0 +0200
@@ -1,3 +1,17 @@
+s390-tools (2.3.0-2~deb10u1) buster; urgency=medium
+
+ * Upload debootstrap fix to Debian stable.
+
+ -- Philipp Kern Mon, 17 Aug 2020 10:04:45 +0200
+
+s390-tools (2.3.0-2) unstable; urgency=medium
+
+ * Hardcode perl dependency instead of using ${perl:Depends}.
+The latter introduces a multi-arch dependency (perl:any) that the
+ base installation environment cannot cope with.
+
+ -- Philipp Kern Sun, 16 Aug 2020 10:36:02 -0400
+
s390-tools (2.3.0-1) unstable; urgency=medium
* New upstream release.
diff -Nru s390-tools-2.3.0/debian/control s390-tools-2.3.0/debian/control
--- s390-tools-2.3.0/debian/control 2018-02-04 19:29:22.0 +0100
+++ s390-tools-2.3.0/debian/control 2020-08-16 16:35:52.0 +0200
@@ -9,7 +9,7 @@
Package: s390-tools
Architecture: s390x
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends}, gawk
+Depends: ${shlibs:Depends}, ${misc:Depends}, perl, gawk
Recommends: sg3-utils
Description: Set of fundamental utilities for Linux on S/390
The package contains:
signature.asc
Description: OpenPGP digital signature
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
Hey, On 08.07.20 21:21, Paul Gevers wrote: > As part of the interim architecture qualification for bullseye, we > request that DSA, the security team, Wanna build, and the toolchain > maintainers review and update their list of known concerns for bullseye > release architectures. I'd also suggest to do a roll call of porters and have them reconfirm their involvement and what is expected from them. I don't think any such thing happened in years now. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Re: Haskell binnmus is there a problem?
On 9/2/2019 9:06 PM, Clint Adams wrote:
> On Mon, Sep 02, 2019 at 06:40:24PM +0200, Philipp Kern wrote:
>> I would prefer JSON as an input format, looking roughly like this:
>>
>> [{"pkg": "haskell-active", "ver": "0.2.0.13-6", "archs": ["mipsel",
>> "mips64el"], "suite": "sid", "reason": "semigroupoids changed from 5.2.2 to
>> 5.3.2"}]
>
> Something like https://people.debian.org/~clint/binNMUs-haskell.json ?
Yup, that passes my parser. But it doesn't answer the question I tried
to ask: How would I signal success/failure properly? And, even more
crucially, how would I signal partial success?
I could settle for two different blobs to return: One text blob in case
something in authz/validation went wrong and one JSON blob in case the
script successfully validated the input and then return "result":
"success"/"failure" (say, maybe with some more data from wannna-build)
on every single entry. I suppose in the first case it'd be an inline
response and in the second a file attachment. But then again you'd need
to actually parse the JSON you get back to see if everything went
according to plan...
Kind regards
Philipp Kern
Re: Haskell binnmus is there a problem?
On 2019-09-02 11:03, Joachim Breitner wrote:
Am Montag, den 02.09.2019, 10:57 +0200 schrieb Philipp Kern:
FWIW, I started working on this. Unfortunately we do not really have
transactions available to schedule all or nothing. If someone has a
creative idea on how to best signal back partial success, let me know.
:)
(My current best guess is a JSON file served as an attachment to the
API
call with success/failure states...)
The JSON is for the response status, and the request will be the
existing format as seen in
https://people.debian.org/~nomeata/binNMUs-haskell.txt
right?
Right now my guide rail is https://buildd.debian.org/auth/giveback.cgi
(documented in [1]) which spews out a bunch of validation notices and
then performs the action.
I would prefer JSON as an input format, looking roughly like this:
[{"pkg": "haskell-active", "ver": "0.2.0.13-6", "archs": ["mipsel",
"mips64el"], "suite": "sid", "reason": "semigroupoids changed from 5.2.2
to 5.3.2"}]
The rationale for this is that it is way easier for me to validate the
input if presented this way. As we know the output of your script above
is piped into wb, which is a glorified wrapper around wanna-build doing
some of the lifting required. Rather than trying to make sense of a line
that is an input to another script (which also supports different
actions), it seems better to constrain us down in a way where every
field is explicitly presented. Especially as ultimately everything needs
to be passed to another binary through command-line options.
The output is then yet another question to solve...
Kind regards
Philipp Kern
[1]
https://debblog.philkern.de/2019/08/alpha-self-service-buildd-givebacks.html
Re: Haskell binnmus is there a problem?
On 2019-09-02 10:33, Emilio Pozuelo Monfort wrote: On 29/08/2019 12:08, Philipp Kern wrote: On 2019-08-29 11:46, Emilio Pozuelo Monfort wrote: On 29/08/2019 11:17, Philipp Kern wrote: On 2019-08-29 11:14, Emilio Pozuelo Monfort wrote: Why don't you let the interested teams run the scripts and generate the required binNMUs (like they do now), and then you pull that from a cronjob in wuiet and schedule the binNMUs? You would just need to define the format and do some sanity checks. What would those sanity checks be? You fetch the list from a known debian host (like several other services already do, including ftp-master or release). If you define the format to be e.g. yaml or json, with an array of binNMUs to schedule, each one with - a source package - a version - a list of architectures - a reason You can just then call 'wb nmu' with the right arguments and the right quoting. The sanity checks would be to make sure the arguments have the right format. So that together with the other mail of not making it automatic: Would we just want to have an endpoint you can call as a member of an approved team(?) that ingests a list of work items, processes it and archives it? Assuming that Release Team has no block in place? Can we require a manual action by a team member rather than it being run continuously? So that we could then track down who initiated it? The reason why I asked the Release Team specifically was if we need to constrain the set of packages to act upon (e.g. golang-%). If you do not see a reason, assuming that we can always tell the team in question to fix their automation, that's fine with me too. On the one hand, adding such a constraint would ensure that the teams don't schedule binNMUs outside their realms. OTOH it would reduce the effectiveness of this solution when they need to schedule them on packages that don't fit whichever criteria we chose (e.g. for apps rather than modules). So I'd start with no constrain and we can add it later if we find out it's preferred. FWIW, I started working on this. Unfortunately we do not really have transactions available to schedule all or nothing. If someone has a creative idea on how to best signal back partial success, let me know. :) (My current best guess is a JSON file served as an attachment to the API call with success/failure states...) Kind regards Philipp Kern
Re: Haskell binnmus is there a problem?
On 2019-08-29 11:46, Emilio Pozuelo Monfort wrote: On 29/08/2019 11:17, Philipp Kern wrote: On 2019-08-29 11:14, Emilio Pozuelo Monfort wrote: Why don't you let the interested teams run the scripts and generate the required binNMUs (like they do now), and then you pull that from a cronjob in wuiet and schedule the binNMUs? You would just need to define the format and do some sanity checks. What would those sanity checks be? You fetch the list from a known debian host (like several other services already do, including ftp-master or release). If you define the format to be e.g. yaml or json, with an array of binNMUs to schedule, each one with - a source package - a version - a list of architectures - a reason You can just then call 'wb nmu' with the right arguments and the right quoting. The sanity checks would be to make sure the arguments have the right format. So that together with the other mail of not making it automatic: Would we just want to have an endpoint you can call as a member of an approved team(?) that ingests a list of work items, processes it and archives it? Assuming that Release Team has no block in place? Can we require a manual action by a team member rather than it being run continuously? So that we could then track down who initiated it? The reason why I asked the Release Team specifically was if we need to constrain the set of packages to act upon (e.g. golang-%). If you do not see a reason, assuming that we can always tell the team in question to fix their automation, that's fine with me too. Kind regards Philipp Kern
Re: Haskell binnmus is there a problem?
On 2019-08-29 11:14, Emilio Pozuelo Monfort wrote: Why don't you let the interested teams run the scripts and generate the required binNMUs (like they do now), and then you pull that from a cronjob in wuiet and schedule the binNMUs? You would just need to define the format and do some sanity checks. What would those sanity checks be? Kind regards Philipp Kern
Re: Haskell binnmus is there a problem?
On 8/27/2019 7:39 PM, Adam D. Barratt wrote: > On Tue, 2019-08-27 at 19:40 +0300, Ilias Tsitsimpis wrote: >> So, how can we move forward? Is the release team willing to give more >> members of our team access to the wanna-build infrastructure, or >> should we try to automate this and how? > That's not the Release Team's decision, but the wanna-build > maintainers. Nor do we have the ability to grant access, beyond any > points where team membership might overlap. Do you have an opinion if this should actually be automated? I.e. automatically be fed into wb on a regular basis? I think the Release Team would also be the first team who would want to have a lever to stop that kind of automation from happening. Unfortunately I don't know how often those binNMUs would interfere with your day to day work. But I'd rather we run this centrally. And yes, I realize that this is a little tricky because of policy questions on what code to run. But dak already solved this AFAIK and as long as we have DD signatures on the code it should also be fine to import from, say, Salsa. That said, there are still awkward questions on how to build the binaries used for this as the Haskell binNMU thing is obviously written in Haskell rather than being a script. Kind regards Philipp Kern
Re: Dropping Release and Release.gpg support from APT
On 2019-07-10 10:04, Julian Andres Klode wrote:
On Wed, Jul 10, 2019 at 10:35:25AM +0800, Paul Wise wrote:
On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:
> Timeline suggestion
> ---
> now add a warning to apt 1.9.x for repositories w/o InRelease, but
Release{,.gpg}
> Aug/Sep turn the warning into an error, overridable with an option (?)
> Q1 2020 remove the code
[...]
We do need them to ship InRelease files. I just filed an issue for OBS
to do that. Given how long we had InRelease file, and how confusing it
is to not provide InRelease files (not to mention that it doubles the
traffic for no-change cases), I'm surprised they aren't using InRelease
files yet.
Given the timeline, shouldn't we also get oldstable to ship an InRelease
file?
Kind regards
Philipp Kern
Bug#930238: unblock: zfs-linux/0.7.12-2+deb10u1 [t-p-u]
On 2019-06-15 11:04, Paul Gevers wrote: On 14-06-2019 12:50, Aron Xu wrote: I have tested the package in a virtual machine on amd64 for linux/4.19.37-3 (buster) and a locally built updated linux kernel that breaks zfs-linux/0.7.12-2. The dkms package builds fine with both of the versions and zpool create/export/import works fine. Therefore, please unblock the t-p-u update for buster, thanks. I am probably asking a very stupid question, but ... The changes in the patch are in the source code. Do these dkms package work is such a way that the binaries are compiled every time that a kernel gets updated? I.e. a change in the source that checks for the kernel version actually results in a binary that works for that source? The whole point of dkms is to make sure that kernel modules available as source are made available to all installed kernels. So as long as the ABI version of the kernel changes (in Ubuntu with every upload, for us much more rarely) the module is recompiled. The corollary here is that it is not recompiled if the ABI version did not change because the module is assumed to still be compatible. (Our kernel maintainers also regularly ignore certain ABI changes they do not consider to actually be part of the ABI they support.) Kind regards Philipp Kern
Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)
On 3/26/2019 3:20 PM, Christoph Berg wrote: > We were thinking about doing something like that, but that doesn't > work for the general case - most libc upgrades do not break > everything, and reindexing would be overkill. It might help for the > 2.28 upgrade, but getting this to work consistently would require lots > of scripting with lots of cornercases to cover. I don't think it is > possible to get this working reliably now, especially as we would need > to push that "fix" into stretch-proposed-updates as well. (Because > libc6 will likely be upgraded first, before the new postgresql-common > version could take action.) Technically the latter could be solved by libc6 in testing adding a breaks on postgresql-common. As neither postgresql-common nor postgresql-client-common seem to depend on libc6 at all, it doesn't immediately seem crazy to me to do that. But I don't dispute that the complexity could be high to do this properly. It's unfortunate that this came up that late, given that it was already a problem for users of testing. Kind regards Philipp Kern
Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)
On 3/26/2019 9:45 AM, Christoph Berg wrote: > Unfortunately not. PostgreSQL supports ICU, but not as the global > locale for clusters/databases, which is still libc only. And even if > it was supported, it's not the default, and we are still breaking all > installations. I suspect this is why MySQL keeps a whole zoo of collations internally that never change. >>> I've been thinking about this for some time, and the best I could come >>> up so far is "raise a debconf note that people need to invoke REINDEX >>> DATABASE". The open question about this plan is, how should this note >>> be triggered. >> >> That might not work for unique indices because locale data changes >> could cause strings to sort the same that were distinct before the >> update. > > Well, that's not an argument for silently doing nothing. And I doubt > that this case even exists, for any two distinct strings, the > collation should output a consistent "less than" or "greater than" > answer. > > I forgot to mention Plan 3: Mention this in the release notes. > That should be done anyway, the question being if that is enough. > My suspicion is that few people actually read the release notes, so > some notification from inside the system would be needed as well. > Be it a debconf note, and/or a NEWS.Debian entry somewhere. Is there a way upon next (re)start to have a startup script check for this case and reindex automatically then - at the expense of a hugely enlarged downtime? Say, with a flag file that keeps the glibc major version at last restart time around - for the first iteration on this? That's at least better than silent data corruption, even if still disruptive. On the other hand I guess you'd need to start the cluster for serving anyway for reindex to work and would then serve broken data in the meantime, too? Kind regards Philipp Kern
Re: Re-evaluating architecture inclusion in unstable/experimental
On 03.10.2018 18:01, John Paul Adrian Glaubitz wrote: >> For s390x I can say that the port was driven without any commercial >> interest on both Aurelien's and my side > The question is though: Is there quantifiable amount of users that is > running Debian on such big iron instead of one of the Linux enterprise > distributions on the market? If the argument is about maintenance burden, > then does it justify to support Debian on s390x when the number of users > is small? And, if yes, why does that not apply to ppc64, for example? > (I would mention sparc64 here as well, but there is actually a valid > blocker which is the lack of supply of new hardware for DSA). I cannot speak to ppc64. ppc64el is useful as I'm told POWER can be competitive to Intel/AMD-based services. But I don't know how many users would run Debian. For s390x, IBM does not publicly admit that there are people running Debian, but there are a few. Almost all of them turn popcon off - most of the VMs can't talk to the internet. Of course I don't know if the availability of Ubuntu significantly changed that. They were able to invest much more time into polishing the port and most people just want some kind of Debian derivative. Historically the base system has been very well maintained by IBM, though. So the effort to keep it running has been relatively small. This recently changed somewhat, given that the primary focus is on enterprise distributions, in that stuff like Javascript interpreters don't work well. Essentially it boils down to server workloads that companies need to run, so as Docker and Go became popular, IBM implemented support for it. The same happened for v8 as used by Node. OpenJDK 9 finally comes with a JIT, so you don't have to use IBM Java anymore. And to IBM's credit, they even contributed some bits back to d-i. Although some of those still await testing and merging. The Ubuntu changes did not flow back / were not mergable as-is into Debian. It's always a tradeoff between how much work is necessary to keep the port alive and how many people use it. As long as the port keeps itself working, that's sort of fine in my experience. Once you need to sheperd a lot of things that all break (like the MIPSens historically had to, even working around broken CPUs) or need to deal with 2 GB virtual address space or don't have modern languages like Go or Rust around, it quickly approaches the point where it's not worth it anymore. Kind regards Philipp Kern
Re: Re-evaluating architecture inclusion in unstable/experimental
On 29.09.2018 00:30, John Paul Adrian Glaubitz wrote: > On 9/28/18 11:26 PM, Adam D. Barratt wrote: >> On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote: >>> So, it's not always a purely technical decision whether a port >>> remains a release architecture. It's also often highly political and >>> somehow also influenced by commercial entities. >> Please don't make implications like that unless you can back them up. > Well, I cannot prove it. But when I see that we have ports as release > architectures with hardware where atomics in hardware don't even work > correctly and the virtual address space is limited to 2 GiB per process > while on the other hand perfectly healthy and maintained ports like > powerpc and ppc64 which have actually a measurable userbase and interest > in the community are axed or barred from being a release architecture, > then I have my doubts that those decisions aren't also driven by > commercial interests or politics. Please excuse my ignorance, but which architecture do we still have with 2 GiB address space? The main point of removing s390 was that this was unsustainable. > I have seen IBM people on multiple occasions in various upstream > projects trying to remove code for older POWER targets because > they insisted anything below POWER8 is not supported anymore. In > some cases like Golang with success [1]. Yeah, IBM behavior has been incredibly frustrating here on the System z side, too. Essentially they end up actively removing support for anything they don't support anymore. To some degree I understand this behavior: It's a real relieve to not need to support something old and crufty when you're the engineer on the other side having to do that. Even when such support is contributed, someone needs to keep it working and they won't keep old hardware around for that. But it has very awkward implications on the people that still have that hardware for one reason or another and don't actually rely on a support contract. For s390x I can say that the port was driven without any commercial interest on both Aurelien's and my side. Kind regards Philipp Kern
Re: stretch-ignore for invalid maintainer address ?
On 6/10/18 11:40 AM, Andreas Beckmann wrote: > can we tag > "Invalid maintainer address pkg-foo...@lists.alioth.debian.org" > bugs as stretch-ignore? As we need a way to reach people, I suppose that'd only make sense if the metadata has been fixed in unstable, no? Kind regards Philipp kern
Re: Workflow for handling security issues in testing
On 6/1/18 9:17 PM, Adrian Bunk wrote: > On Thu, May 31, 2018 at 10:36:27PM -0700, Jonathan Nieder wrote: >> ... >> I don't think most users of testing realize that >> they also need to include stable-backports in sources.list to get >> security fixes. >> ... > > No, this wouldn't get them all security fixes. > > It would only make a difference when the package with the security > fix is backported at all *and* the backport is done before the > package migrated to testing. Which is unfortunately against the rules of backports, as well. Packages are supposed to enter testing before they are backported. [...] > testing (and even unstable) often get security fixes after stable, > and we should be honest about the fact that the security-supported > part of Debian is a subset of stable[1] without backports. I still wonder if there's some way we can make this better for testing users without resorting to a fatalistic attitude, though. ;-) In theory we know which unstable uploads contain security fixes because the security tracker says so. That'd allow us to flag them and potentially give them a higher priority to migrate. But it still doesn't help when manual work is required because they are stuck behind a transition. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Re: Fixing Linux getrandom() in stable
On 5/10/18 7:30 PM, Michael Biebl wrote: > So we'd shift the waiting for randomness-to-be-available from one > service to another? I don't quite see yet, where the benefit is in that. > What's better if a wait-for-rng-ready binary blocks on getrandom() > instead of the krb5-kdc binary itself? We wouldn't shorten the time we > have to wait this way. Unless the services properly signal readiness (which admittedly they should), you'd at least end up with a situation where you don't start things prematurely. Like if, say, something on the machine depends on krb5-kdc being up, it might be better to wait instead of trying to contact a hanging kdc. But then the time is still better spent to implement sd_notify(READY=1)... (But maybe not in stable?) Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Re: wanna-build access for binNMUs
On 02/10/2018 09:26 AM, Julien Cristau wrote: > On Tue, Jan 30, 2018 at 20:45:44 +0100, Emilio Pozuelo Monfort wrote: > >> On 30/01/18 08:54, Michael Stapelberg wrote: >>> This would also be very helpful for fixing security issue #888777. >> >> You need to talk to the wanna-build team if you want to be able to schedule >> binNMUs for your language rebuilds, just like the ocaml and haskell teams do. >> > FWIW I disagree, I think this is something the wanna-build team has > essentially delegated to release, so getting people on board is a shared > thing between those two teams rather than solely a w-b thing. It > happens once every few years though so there isn't really a process to > vet people. So can we have an opinion on the current proposal, which is a single DD (stapelberg)? As far as I know DSA's ticket is currently blocked on this. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Re: wanna-build access to schedule binNMUs for Go packages
On 01.02.2018 06:45, Salvatore Bonaccorso wrote: > On Wed, Jan 31, 2018 at 09:04:09PM +0100, Michael Stapelberg wrote: >> binNMUs for unstable. > > Why, if that is for unstable, permissions for embargoed > queues/security would be needed? Is that due to implementtation on > accessing wanna-build? > > Access to information about embargoed information would not be ok. This is nothing new. It has always been that way. As soon as you have write access to wanna-build, you can inspect all suites. Yes, that's somewhat sad, but at the same time it shouldn't give you access to the actual source packages. The granularity that is still implemented but only used for ports are per-arch access. wb_security implies access to all arches (wb_all) and generally everyone who should be able to schedule binNMUs across architectures needs to be in wb_all. Precedent here was set by nomeata (at least), who schedules binNMUs for OCaml and Haskell in unstable and hence required access across all architectures. As long as we add persons relatively sparingly (the request is for nother single person), I think we should be fine? Kind regards and thanks Philipp Kern
Bug#886294: transition: nodejs
On 2018-01-25 11:36, Aurelien Jarno wrote: Bumping the baseline to z196 looks like the easiest way and as you said, it would also fix go, rustc and maybe more software. However we discussed raising the ISA to z10 about one year and a half ago, and the conclusion was that we still have users with older machines. I'll try to restart the discussion again. What's the venue to have this discussion in? :) Kind regards and thanks Philipp Kern
Bug#867461: should ca-certificates certdata.txt synchronize across all suites?
On 2017-07-21 15:51, Antoine Beaupré wrote: On 2017-07-20 18:15:00, Philipp Kern wrote: On 07/17/2017 09:41 PM, Antoine Beaupré wrote: Let's not jump the gun here. We're not shipping NSS in ca-certificates, just a tiny part of it: one text file, more or less. Yeah, and the consensus of the world external to Debian seems to be that this might not be the smartest choice. I'm not sure I understand what you are proposing as an alternative here. Should we stop shipping ca-certificates? Or make it a binary package of the NSS source package? I don't think anyone has a good answer to this right now as the additional restrictions on CAs to implement distrust are generally not machine-readable these days and especially not supported cross-library. Also, what Mozilla enforced in NSS, we enforced in ca-certificates in other ways, through the use of a blacklist.txt file. So we can definitely fix #858539 without syncing all of NSS to wheezy. That is incorrect. nss/lib/certhigh/certvfy.c contains code specific to the StartCom/WoSign mitigation. Now the time has come for full distrust, we can sync dropping the certs entirely by adding them to blacklist.txt, sure. (Although they will continue to live on in the NSS source additionally.) I don't understand this: how is it incorrect? #858539 applies only to ca-certificates, and can be fixed without patching NSS. Now to update the NSS package itself is another question, again. So that was a mismatch of expectations. You said "what Mozilla enforced in NSS" and you meant the full distrust. I meant the partial one. I now see [0], which is for the full one, which is fine (which is also what I said). But my point stands that in the next round of distrust (say, uh, Symantec), we might actually need to push code changes to NSS. Sure, but that doesn't necessarily affect ca-certificates directly, in that we can update ca-certificates orthogonally right now. Sure. The proposed patch here, is more or less only to merge that very file, blacklist.txt. The *other* thing proposed to the release team (in #867461) is to sync the *other* changes to certdata.txt from sid. But considering *that* work seems mostly stalled, I wonder how hard to push on that. Of course, we could also just decide, in LTS, to sync with jessie at least: we do not need release-team approval for this. This would be (let's be honest here) really to get Let's Encrypt directly in wheezy, and I think it would be worthwhile. I think it's useful to phrase the goal which is: - Remove StartCom - Remove WoSign - Add Let's Encrypt Which is easier to get behind than "should we synchronize the file". Sure. The point I was trying to make here was that we seem to be favoring certain well-known CAs over other less well-known. I'm actually with that (e.g. because I don't like Amazon very much), but I'm not sure that's a position that should be reflected in our work. My point was that you state what your delta is and essentially boils down to attach the diff of what will actually happen to the .deb. I think it's generally fine to add new CAs and remove fully distrusted ones, instead of saying "it should just be in sync with unstable". The latter contains a lot more nuance if you know that some of the rules are only available in code. Kind regards and thanks for your work Philipp Kern [0] https://anonscm.debian.org/cgit/collab-maint/ca-certificates.git/plain/mozilla/blacklist.txt
Bug#867461: should ca-certificates certdata.txt synchronize across all suites?
On 07/17/2017 09:41 PM, Antoine Beaupré wrote: > Let's not jump the gun here. We're not shipping NSS in ca-certificates, > just a tiny part of it: one text file, more or less. Yeah, and the consensus of the world external to Debian seems to be that this might not be the smartest choice. > Also, what Mozilla enforced in NSS, we enforced in ca-certificates in > other ways, through the use of a blacklist.txt file. So we can > definitely fix #858539 without syncing all of NSS to wheezy. That is incorrect. nss/lib/certhigh/certvfy.c contains code specific to the StartCom/WoSign mitigation. Now the time has come for full distrust, we can sync dropping the certs entirely by adding them to blacklist.txt, sure. (Although they will continue to live on in the NSS source additionally.) But my point stands that in the next round of distrust (say, uh, Symantec), we might actually need to push code changes to NSS. > The proposed patch here, is more or less only to merge that very file, > blacklist.txt. The *other* thing proposed to the release team (in > #867461) is to sync the *other* changes to certdata.txt from sid. But > considering *that* work seems mostly stalled, I wonder how hard to push > on that. Of course, we could also just decide, in LTS, to sync with > jessie at least: we do not need release-team approval for this. This > would be (let's be honest here) really to get Let's Encrypt directly in > wheezy, and I think it would be worthwhile. I think it's useful to phrase the goal which is: - Remove StartCom - Remove WoSign - Add Let's Encrypt Which is easier to get behind than "should we synchronize the file". What's the timeline on Let's Encrypt dropping the cross certification? Is that actually planned? Because the whole point of that was that adding LE directly isn't actually critical. (And people should use the chain provided by ACME rather than relying on certificates shipped by Debian.) Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Bug#867461: should ca-certificates certdata.txt synchronize across all suites?
On 07/06/2017 08:01 PM, Antoine Beaupré wrote: > In looking at fixing #858539 (blocking WoSign and StartCom, in CC) for > wheezy, I noticed the issue was also pending in jessie. Furthermore, the > idea originally raised by pabs[1] was to also update the packages for > the latest changes in certdata.txt in wheezy, including the ISRG Root > for Let's Encrypt (LE). > > While it should be fairly trivial to do this update, I wonder if the > same logic should apply to jessie itself. Right now, jessie and stretch > are synchronized, but that's only because there's an update pending in > unstable to synchronize with the upstream 2.11 NSS database. > > This raises the question of how synchronized we want this file to be? It > seems a little arbitrary to me to synchronize the file from jessie to > wheezy only for this one certificate authority (LE). How about the other > authorities? It doesn't seem like we should be calling the shots on > this: if we follow the Mozilla policies here, either we update all > supported suites at once, or we accept that some suites will have > outdated material. > > I have therefore opened this specific discussion with the release team > in #867461 (in CC as well). Hopefully this will bring a consistent > policy. > > For what it's worth, my opinion is that we should attempt to synchronize > certdata.txt (and blacklist.txt, for that matter) across all suites (but > not other changes to the packaging). This would remove another decision > point in our infrastructure and ensure harmonious X509 processing across > suites. > > [1]: https://lists.debian.org/1490430746.9127.2.ca...@debian.org > > Thanks for any feedback. For now I'll hold on another week or so for the > wheezy update, since it seems unreasonable to push that update out > before jessie is updated and that question is resolved. But it's not just about certdata.txt. The WoSign and StartCom distrust was actually hardcoded in NSS and hence what Mozilla enforced in NSS we couldn't check in any other tools using ca-certificates. We also do not sync the NSS version or backport the cert checks when such distrusts happen. So we can only react in a similar way when the time for full distrust has come (which is sort of the case now with these two), otherwise we diverge in logic and potentially break users with different expectations[1]. Kind regards Philipp Kern [1] If they are realistic is another question. signature.asc Description: OpenPGP digital signature
Bug#863465: unblock: cubemap/1.3.2-1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
X-Debbugs-Cc: se...@debian.org
Please unblock package cubemap
Sesse found a bug in cubemap that sends the whole video backlog to the
client on connect in case the stream is unaptly named (i.e. seven
characters long). The fix is straightforward as depicted below and the
new release only contains the one-line fix.
This is the full debdiff:
> diff -Nru cubemap-1.3.1/debian/changelog cubemap-1.3.2/debian/changelog
> --- cubemap-1.3.1/debian/changelog2016-12-13 21:25:07.0 +0100
> +++ cubemap-1.3.2/debian/changelog2017-05-27 11:17:45.0 +0200
> @@ -1,3 +1,9 @@
> +cubemap (1.3.2-1) unstable; urgency=medium
> +
> + * New upstream release (Closes: #863280)
> +
> + -- Philipp Kern Sat, 27 May 2017 11:17:45 +0200
> +
> cubemap (1.3.1-3) unstable; urgency=medium
>
>* Create the cubemap user before debhelper tries to start the service.
> diff -Nru cubemap-1.3.1/NEWS cubemap-1.3.2/NEWS
> --- cubemap-1.3.1/NEWS2016-07-23 00:45:08.0 +0200
> +++ cubemap-1.3.2/NEWS2017-05-24 21:28:51.0 +0200
> @@ -1,3 +1,12 @@
> +Cubemap 1.3.2, 2017-05-24
> +
> + * Fix a bug where streams with paths exactly seven characters long
> +(e.g. “/abc.ts”) would get broken buffering behavior, as they would
> +start at the start of the backlog, not the end as they should.
> +This caused massively increased latency and/or problems playing back
> +the streams properly.
> +
> +
> Cubemap 1.3.1, 2016-07-23
>
>* Support Metacube timestamp blocks. This allows Metacube producers
> diff -Nru cubemap-1.3.1/server.cpp cubemap-1.3.2/server.cpp
> --- cubemap-1.3.1/server.cpp 2016-07-23 00:45:08.0 +0200
> +++ cubemap-1.3.2/server.cpp 2017-05-24 21:28:51.0 +0200
> @@ -653,7 +653,7 @@
>
> string url = request_tokens[1];
> client->url = url;
> - if (url.find("?backlog") == url.size() - 8) {
> + if (url.size() > 8 && url.find("?backlog") == url.size() - 8) {
> client->stream_pos = -2;
> url = url.substr(0, url.size() - 8);
> } else {
> diff -Nru cubemap-1.3.1/version.h cubemap-1.3.2/version.h
> --- cubemap-1.3.1/version.h 2016-07-23 00:45:08.0 +0200
> +++ cubemap-1.3.2/version.h 2017-05-24 21:28:51.0 +0200
> @@ -3,7 +3,7 @@
>
> // Version number. Don't expect this to change all that often.
>
> -#define SERVER_VERSION "1.3.1"
> +#define SERVER_VERSION "1.3.2"
> #define SERVER_IDENTIFICATION "Cubemap/" SERVER_VERSION
>
> #endif // !defined(_VERSION_H)
unblock cubemap/1.3.2-1
signature.asc
Description: OpenPGP digital signature
Bug#858943: unblock: systemd/232-22
On 04/01/2017 01:45 AM, Cyril Brulebois wrote: >>> * udev: Create persistent net names for virtio CCW devices. >>> This only affects s390x as only this has CCW devices. This provides >>> stable network interface names for those and avoids changing the names >>> on updating Stretch to Buster. (Closes: #856559) >> >> https://anonscm.debian.org/git/pkg-systemd/systemd.git/commit/?h=stretch&id=bb9ad652f309a90a5424381503083ee9a530a888 >> >> (might be relevant for the installer) >> >> This only affects s390x, so regression potential is low and it's >> important to get into stretch, otherwise we'd have migration issues in >> buster (as names would change, which would be ugly) > > Adding debian-s...@lists.debian.org to the loop to make sure they're > aware of this. Can't really judge whether this could be annoying in d-i, > it seems to me that's just fixing a move which hadn't happened with the > net.ifnames transition, for specific hardware? FWIW, I have tested this on an installation and haven't seen any problems. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Re: Next d-i release
On 10/26/2016 08:24 PM, Cyril Brulebois wrote: > Samuel Thibault (2016-10-23): >> We have the newer brltty release, 5.4, which provides support for some >> more devices, and fixes various issues. It has been tested for some time >> in experimental and sid now, so I feel quite safe about it, but it'd be >> probably useful to have it for testing in d-i sooner than later. > ACK, thanks. It migrated on its own already. It'd also be nice if zipl-installer could still make it. #840230 is pretty nasty. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Re: Porter roll call for Debian Stretch
Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the Stretch release (est. end of 2020): For s390x, I - triage d-i bugs - test d-i regularly - fix d-i bugs/issues - am currently trying to get an automated test setup running for d-i - provide hardware for a buildd and am working with IBM to obtain more support on that front I am a DD. I have no real opinion about -fPIE/-pie on s390x. Ubuntu sets both, so it seems sane to me to do the same in Debian. Philipp Kern signature.asc Description: OpenPGP digital signature
Re: Thinking about a "jessie and a half" release
Hi, On 2016-07-04 18:08, Cyril Brulebois wrote: How would we keep that working given that backports keeps changing? Backports changing isn't an issue AFAICT if we're only publishing a netinst image which has all the kernel bits (kernel udebs), as opposed to netboot. Or are you thinking of other issues? that was the main issue. Apart from the updates part below. Would we copy the kernel at the time into a special suite? I don't think that's needed. How would updates work? Updates to? - d-i: nothing has to change (except if we want to republish a new image with an ever newer kernel version), see above. Where to would we upload d-i? Under what name? With what content? Would we re-spin stable d-i plus backports-related changes into backports? Would backports ftp-masters be ok with that? I feel somewhat uncomfortable with one-offs that are not being updated anymore and cannot even be updated if need be because the kernel will have disappeared by them (as it tracks testing rather than its own version line). - installed system: as usual for systems with backported packages (NotAutomatic & ButAutomaticUpgrades). So which metapackages would we need to install to keep track of new major kernel versions in backports? Kind regards and thanks Philipp Kern
Re: Thinking about a "jessie and a half" release
On 2016-07-04 15:12, Cyril Brulebois wrote: 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. Does that mean "kernel from backports"? How would we keep that working given that backports keeps changing? Would we copy the kernel at the time into a special suite? How would updates work? That is to mean: I can see how this would work as a sort of continuously built thing whenever the kernel in backports changes and the supporting d-i changes are committed. But in the terms of a release seems to be a little hard. * rebuilt d-i to match that kernel You know there are patches around for that. * X drivers I don't see backports for them. Would it also mean X proper or "just" drivers? Kind regards Philipp Kern
Re: [Stretch] Status for architecture qualification
On 2016-06-15 00:37, Dimitri John Ledkov wrote: There is openmainframe project https://www.openmainframeproject.org/ , which I believe offers access to z/VM instances hosted by Marist colledge. At the openmainframeproject EU meetup, it was indicated that SUSE joined with indication that Open Build Service might be able to use resources hosted by Marist. I wonder if it makes sense to reach out, and see if there are resources available to use as porter boxes & build boxes. That way Debian might be able to get such donated resource available on ongoing basis and hopefully with some hw support. Debian already makes use of Marist's resources. The challenge was/is to get redundancy as DSA very sensibly insists on. Kind regards Philipp Kern
Re: [Stretch] Status for architecture qualification
On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote: > Philipp Kern: > > On 2016-06-05 12:01, Niels Thykier wrote: > >> * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el, > >>s390x > >>- *No* blockers at this time from RT, DSA nor security. > >>- s390, ppc64el and all arm ports have DSA concerns. > > What is the current DSA concern about s390x? > The concern listed as: "rely on sponsors for hardware (mild concern)" > > As I recall the argument went something along the lines of: > > "Debian cannot replace the hardware; if any of the machines dies, we > need a sponsor to replace it. If all of them dies and we cannot get > sponsored replacements, we cannot support the architecture any longer" > > (My wording) Yeah, but that's unfortunately one of the universal truths of this port. I mean in theory sometimes they turn up on eBay and people try to make them work[1]. It also seems true for other ports where we commonly relied on sponsors to hand us replacements. But maybe it's only ppc64el these days, maybe there are useful builds available for the others (including arm64 and mips) on the market now. Kind regards and thanks Philipp Kern [1] https://www.youtube.com/watch?v=45X4VP8CGtk (Here's What Happens When an 18 Year Old Buys a Mainframe)
Re: [Stretch] Status for architecture qualification
On 2016-06-05 12:01, Niels Thykier wrote: * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el, s390x - *No* blockers at this time from RT, DSA nor security. - s390, ppc64el and all arm ports have DSA concerns. What is the current DSA concern about s390x? Kind regards and thanks Philipp Kern
Re: initramfs-tools support for nvme in Linux 4.4+
On Sun, Apr 17, 2016 at 01:16:42AM +0100, Ben Hutchings wrote: > By default, initramfs-tools includes various classes of driver modules > in the initramfs based on the directory they are installed in. In > particular, most block drivers that don't belong to another subsystem > such as SCSI are installed in > /lib/modules//kernel/drivers/block. That installation > directory is derived from the subdirectory in the Linux source tree > that contains the driver source. > > Unfortunately the nvme driver moved from drivers/block to drivers/nvme > in Linux 4.4, and initramfs-tools only knows about this since v0.121. > So long as you install the kernel and initramfs-tools from the same > suite, everything is fine, but if you use jessie and install a newer > kernel from jessie-backports or build your own custom kernel, nvme will > be missing. > > The obvious approach of adding initramfs-tools to jessie-backports > won't work, as the current version requires upgrading busybox, > e2fsprogs, klibc and (for those that still use it) sysvinit. > > The fix is a one-liner and works for old and new kernels. Does this > seem suitable for inclusion in the next jessie point release? Just considering nvme in addition to block and gracefully coping with it not existing seems fine to me. Kind regards Philipp Kern
Re: Kernel version for stretch
On Sat, Jan 30, 2016 at 03:34:16PM +0100, Moritz Mühlenhoff wrote: > I would need to confirm that, but AFAICS the non-LTS kernels after 3.11 are > all maintained for two years (since they are now made available at "hardware > enablement kernels" for the Ubuntu LTS releases. Non-LTS kernels can be quite short. [1] visualizes that. For instance once the new LTS and the HWE got backported to the old LTS, all intermediate ones (except base + new LTS) are dropped pretty much instantly. You are also expected to migrate HWEs in the meantime when new ones are made available. Kind regards Philipp Kern [1] https://wiki.ubuntu.com/Kernel/Support?action=AttachFile&do=get&target=Ubuntu+Kernel+Release+Schedule.png
Re: Updating ca-certificates through stable-updates
> Could I perhaps convince you to file this (kind of) request as a pu bug? > They are much easier for us to track than mails to the mailing list. > I appreciate that you might have been sending this mail to avoid the > pu-bug. Unfortunately, we often end up forgetting the mail on our TODO > list if it is not listed in the bug tracker. There's that and it helps to look at the debdiff to see what the actual changes are. Cert updates are likely to be much easier on us than packaging/script updates. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#804383: jessie-pu: package libinfinity/0.6.7-1~deb8u1
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu I would like to upload libinfinity 0.6.7-1 from stretch as 0.6.7-1~deb8u1 to jessie (debdiff of 0.6.6-1 to 0.6.7-1 attached). To quote the upstream NEWS file of this maintenance release: * Fix a possible crash when an entry is removed from the document browser. * Fix a possible crash in infinoted when access control lists are enabled. * Fix an assertion failure when operating with text documents and using glib 2.46 or newer. The release contains a little bit of autotools, changelog, and po churn, but apart from that does only contain the above changes. If needed I can back out the glib 2.46 change, although I'd prefer to upload the whole thing as the change is arguably more correct even with older glibs. Kind regards and thanks Philipp Kern diff -Nru libinfinity-0.6.6/ChangeLog libinfinity-0.6.7/ChangeLog --- libinfinity-0.6.6/ChangeLog 2015-05-13 02:57:57.089748067 +0200 +++ libinfinity-0.6.7/ChangeLog 2015-10-14 01:34:53.805216085 +0200 @@ -1,6 +1,115 @@ +commit a7bdd262474898d180285129f5aed3e87b04461a +Author: Armin Burgmeier +Date: Tue Oct 13 19:34:35 2015 -0400 + +Release libinfinity 0.6.7 + + NEWS | 8 + 1 file changed, 8 insertions(+) + +commit d447fc406c0ceb2766f69ffec28f017baa7ed7a9 +Author: Armin Burgmeier +Date: Mon Oct 12 19:51:50 2015 -0400 + +InfTextChunk: fix segment lookup for offset=0 (#10) + +This used to work with glib 2.42, but it seems that the semantics of +g_sequence_search() have changed with respect to what item is returned +when the comparison function returns 0. The behavior in that case is not +documented. Fix this by passing a different comparison function that +never returns 0, so that there is no ambiguity in which segment is +returned. + + libinftext/inf-text-chunk.c | 29 - + 1 file changed, 28 insertions(+), 1 deletion(-) + +commit 3fb2be4fb355ed44541d6da486dc73c5dd739ca3 +Author: Armin Burgmeier +Date: Mon Oct 12 19:51:40 2015 -0400 + +Fix integrity check in inf_text_chunk_get_byte_index_utf8() + + libinftext/inf-text-chunk.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +commit 4fc1227317eea35b87e10686daf467642c9abe1e +Author: Armin Burgmeier +Date: Tue Jun 9 21:20:23 2015 -0400 + +Fix uninitialized variable when suggesting a SASL mechanism + + libinfinity/common/inf-xmpp-connection.c | 1 + + 1 file changed, 1 insertion(+) + +commit 28dd0736c7618861dd9a23e8793e4db865ce6a5e +Author: Armin Burgmeier +Date: Sun Jun 7 21:27:23 2015 -0400 + +InfXmppConnection: Fix strncmp invocation when suggesting SASL mechanism + + libinfinity/common/inf-xmpp-connection.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +commit 4dfaf22925dbe12008627d0a604b179fd6e4b7b4 +Author: Armin Burgmeier +Date: Wed May 27 22:21:22 2015 -0400 + +Fix g_free / g_slice_free mismatch + + libinfinity/server/infd-directory.c | 18 -- + 1 file changed, 16 insertions(+), 2 deletions(-) + +commit d17398a0f850a79ffbe78c10bbe8ebfd0cd5e63c +Author: Armin Burgmeier +Date: Wed May 27 21:12:28 2015 -0400 + +InfdDirectory: Fix error reply to client when session proxy cannot +be created + + libinfinity/server/infd-directory.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +commit 822b227c662e5fcaab3c1bdfdf224eebaefe7728 +Author: Armin Burgmeier +Date: Sat May 23 14:39:59 2015 -0400 + +Fix session becoming inconsistent with active local users during +subscription + +When the server sends the vector time of local users during subscription, +it now sends the last send vector instead of the real value of the +user time, +so that subsequent state vector diffs are consistent for the newly joined +client. + +Conflicts: + libinfinity/adopted/inf-adopted-session.c + + libinfinity/adopted/inf-adopted-session.c | 34 - + 1 file changed, 33 insertions(+), 1 deletion(-) + +commit cf4588011a5023af36d6393f1f724a11742b84f1 +Author: Armin Burgmeier +Date: Fri May 22 19:22:26 2015 -0400 + +Fix a possible crash when removing a browser entry + + libinfgtk/inf-gtk-browser-store.c | 5 + + libinfgtk/inf-gtk-browser-view.c | 11 +++ + 2 files changed, 16 insertions(+) + +commit 4522baf6a975f38e6874c90695b00af0d2854dfc +Author: Armin Burgmeier +Date: Tue May 12 20:58:49 2015 -0400 + +Post-release bump to 0.6.7 + + configure.ac | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + commit a5bc24e87714d3c3fa75711c5d06b9b8e4c81d53 Author: Armin Burgmeier -Date: Tue May 12 20:12:52 2015 -0400 +Date: Tue May 12 20:12:52 2015 -0400 Release libinfinity 0.6.6 @@ -9,7 +118,7 @@ commit 3862714b942fe626308f06e01730df7b48921faf Author: Armin Burgmeier -Date: Tue May 12 20:55:41 2015 -0400 +Date: Tue May 12 20:55:41 2015 -0400 Fix make distcheck for r
Bug#804381: jessie-pu: package s390-dasd/0.0.32~deb8u1
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
I'd like to update s390-dasd 0.0.32 from stretch to sid, as
0.0.32~deb8u1. The debdiff is attached. It fixes installation of Debian
within KVM on System z and within full-system emulation using qemu.
The critical hunk is this:
@@ -233,7 +235,8 @@
return get_channel_input ();
else if (di_tree_size (channels) > 0)
return get_channel_select ();
- return WANT_ERROR;
+ di_info("s390-dasd: no channel found");
+ return WANT_FINISH;
}
This lets s390-dasd exit cleanly if no DASD disks are found. Within qemu
virtio is used to provide disks, which is totally different from what
traditionally used to happen on the mainframe.
The remaining changes are .po updates, mainly in the comments, and
the logging of the various error conditions s390-dasd emits. Without
the logging you cannot deduce why it exited with a failure.
I'm also happy to skip the .po changes if needed, but it seemed cleaner
to just backport stretch's current version.
Kind regards and thanks
Philipp Kern
diff -Nru s390-dasd-0.0.30/dasd-config.c s390-dasd-0.0.32/dasd-config.c
--- s390-dasd-0.0.30/dasd-config.c 2013-12-04 00:53:16.0 +0100
+++ s390-dasd-0.0.32/dasd-config.c 2015-11-01 22:37:03.0 +0100
@@ -1,4 +1,5 @@
#include
+#include
#include
#include
#include
@@ -224,6 +225,7 @@
channel_current = di_tree_lookup (channels, &dev);
if (channel_current)
return WANT_NEXT;
+ di_error("s390-dasd: could not get selected channel device %d", dev);
return WANT_ERROR;
}
@@ -233,7 +235,8 @@
return get_channel_input ();
else if (di_tree_size (channels) > 0)
return get_channel_select ();
- return WANT_ERROR;
+ di_info("s390-dasd: no channel found");
+ return WANT_FINISH;
}
static enum state_wanted enable (void)
@@ -242,14 +245,23 @@
struct sysfs_attribute *attr;
device = sysfs_open_device ("ccw", channel_current->name);
- if (!device)
+ if (!device) {
+ di_error("s390-dasd: could not open device %s",
+ channel_current->name);
return WANT_ERROR;
+ }
attr = sysfs_get_device_attr (device, "online");
- if (!attr)
+ if (!attr) {
+ di_error("s390-dasd: could not read online attribute for %s",
+ channel_current->name);
return WANT_ERROR;
- if (sysfs_write_attribute (attr, "1", 1) < 0)
+ }
+ if (sysfs_write_attribute (attr, "1", 1) < 0) {
+ di_error("s390-dasd: could not set %s online: %s",
+ channel_current->name, strerror(errno));
return WANT_ERROR;
+ }
sysfs_close_device (device);
diff -Nru s390-dasd-0.0.30/debian/changelog s390-dasd-0.0.32/debian/changelog
--- s390-dasd-0.0.30/debian/changelog 2014-03-14 22:59:51.0 +0100
+++ s390-dasd-0.0.32/debian/changelog 2015-11-01 22:59:19.0 +0100
@@ -1,3 +1,18 @@
+s390-dasd (0.0.32) unstable; urgency=medium
+
+ * If no channel is found, exit cleanly. This allows s390-dasd to step
+out of the way on VMs with virtio disks.
+ * Log error conditions.
+
+ -- Philipp Kern Sun, 01 Nov 2015 22:59:11 +0100
+
+s390-dasd (0.0.31) unstable; urgency=medium
+
+ [ Updated translations ]
+ * Turkish (tr.po) by Mert Dirik
+
+ -- Christian Perrier Sun, 26 Jul 2015 09:15:33 +0200
+
s390-dasd (0.0.30) unstable; urgency=low
[ Dmitrijs Ledkovs ]
diff -Nru s390-dasd-0.0.30/debian/po/be.po s390-dasd-0.0.32/debian/po/be.po
--- s390-dasd-0.0.30/debian/po/be.po 2013-12-04 00:53:16.0 +0100
+++ s390-dasd-0.0.32/debian/po/be.po 2015-05-23 19:12:43.0 +0200
@@ -11,11 +11,13 @@
# Nasciona Piatrouskaja , 2006.
# Paul Petruk , 2007.
# Pavel Piatruk , 2008, 2009, 2011.
-# Viktar Siarheichyk , 2010, 2011, 2012.
+# Viktar Siarheichyk , 2010, 2011, 2012, 2015.
# Translations from iso-codes:
# Alastair McKinstry , 2004.
# Alexander Nyakhaychyk , 2009.
# Ihar Hrachyshka , 2007, 2010.
+# Viktar Siarheichyk , 2014.
+# Viktar Siarheichyk , 2014, 2015.
msgid ""
msgstr ""
"Project-Id-Version: be\n"
@@ -23,8 +25,7 @@
"POT-Creation-Date: 2010-03-30 23:19+\n"
"PO-Revision-Date: 2010-07-06 01:58+0300\n"
"Last-Translator: Viktar Siarheichyk \n"
-"Language-Team: Belarusian (Official spelling) \n"
+"Language-Team: Belarusian \n"
"Language: be\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
diff -Nru s390-dasd-0.0.30/debian/po/et.po s390-dasd-0.0.32/debian/po/et.po
--- s390-dasd-0.0.30/debian/po/et.po 2013-12-04 00:53:16.0 +0100
+++ s390-dasd-0.0.32/debian/po/et.po 2015-02-08 11:42:16.0 +0100
@@ -24,7 +24,7 @@
# Margus Väli , 2000.
# Siim Põder , 2006.
# Tõivo Leedjärv , 2000, 2001, 2008.
-# Mattias Põldaru , 2009-2011, 2012.
+# Mattias Põldaru , 2009-2012,
Re: binNMUs: please exercise some care
On Fri, Oct 23, 2015 at 02:46:23PM +0200, Thorsten Glaser wrote: > On Fri, 23 Oct 2015, Adam D. Barratt wrote: > > and testing), so the only way to be certain what binNMU number to use is to > > check manually. In practice what actually happens is that people forget > > about > Maybe wb could do a “dak ls” and whatever the equivalent for dpo mini-dak is. Unfortunately it is not being run on the same host as dak either. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#800793: jessie-pu: package netcfg/1.131+deb8u1
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
I would like to fix netcfg in stable and allow KVM on s390x to boot the
installer with working networking. The simple patch is this and is
already in testing.
diff --git a/debian/changelog b/debian/changelog
index 8dc90b9..4f2d3bc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+netcfg (1.131+deb8u1) stable; urgency=medium
+
+ * Fix is_layer3_qeth on s390x to avoid bailing out if the network
+driver is not qeth. (Closes: #798376)
+
+ -- Philipp Kern Sat, 03 Oct 2015 18:42:26 +0200
+
netcfg (1.131) unstable; urgency=medium
* Kill the DHCP client on Linux again and keep it running on kFreeBSD.
diff --git a/netcfg-common.c b/netcfg-common.c
index 7c2c002..376e6ca 100644
--- a/netcfg-common.c
+++ b/netcfg-common.c
@@ -293,11 +293,11 @@ int is_layer3_qeth(const char *iface)
goto out;
}
-buf[slen + 1] = '\0';
+buf[slen] = '\0';
driver = strrchr(buf, '/') + 1;
if (strcmp(driver, "qeth") != 0) {
-di_error("no qeth found: %s", driver);
+di_info("no qeth found: %s", driver);
goto out;
}
Kind regards and thanks
Philipp Kern
Bug#786720: jessie-pu: package libinfinity/0.6.6-1~deb8u1
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu I'd like to update libinfinity in jessie from 0.6.5-1 to 0.6.6-1. That maintenance upstream release contains a three line fix for a security issue (CVE-2015-3886), one fix to avoid some failing assertions when handling the cursor while editing a document and a crash fix in the client code. I'd upload the version as 0.6.6-1~deb8u1 to jessie. The release noise is fairly minimal, see the attached diff between 0.6.5-1 (stable) and 0.6.6-1 (unstable). I can also pull any of the patches into 0.6.5-1 and base a +deb8u1 off that. Kind regards and thanks Philipp Kern diff -Nru libinfinity-0.6.5/ChangeLog libinfinity-0.6.6/ChangeLog --- libinfinity-0.6.5/ChangeLog 2015-01-18 02:29:29.071909458 +0100 +++ libinfinity-0.6.6/ChangeLog 2015-05-13 02:57:57.089748067 +0200 @@ -1,3 +1,99 @@ +commit a5bc24e87714d3c3fa75711c5d06b9b8e4c81d53 +Author: Armin Burgmeier +Date: Tue May 12 20:12:52 2015 -0400 + +Release libinfinity 0.6.6 + + NEWS | 9 + + 1 file changed, 9 insertions(+) + +commit 3862714b942fe626308f06e01730df7b48921faf +Author: Armin Burgmeier +Date: Tue May 12 20:55:41 2015 -0400 + +Fix make distcheck for recent automake versions + +Recent automake versions run with a more restrictive umask, so that the +version.xml files are created with read-only permissions. This fails when +trying to override them, so remove them explicitly before. + + docs/reference/Makefile.am | 2 ++ + 1 file changed, 2 insertions(+) + +commit 06fa9455c687a67e4fc2c2f201817c64c73a3fcf +Author: Armin Burgmeier +Date: Mon May 11 22:59:34 2015 -0400 + +Fix expired certificate validation (gobby #61) + + libinfgtk/inf-gtk-certificate-manager.c | 6 -- + 1 file changed, 4 insertions(+), 2 deletions(-) + +commit 244c7e8d69b98330ac7a285922c6fcb0a167ae20 +Author: Armin Burgmeier +Date: Tue May 5 20:45:45 2015 -0400 + +Update caret position when only updating fixline state + +When the user inserts some newlines that are "swallowed" by the fixline +buffer, then still advance the user's cursor such that newly +to-be-written +text is inserted after the imaginary newline. + + libinftext/inf-text-fixline-buffer.c | 54 ++ + 1 file changed, 54 insertions(+) + +commit fb0c8532694476f3f624f66eb12becf851147e27 +Author: Armin Burgmeier +Date: Mon May 4 20:31:12 2015 -0400 + +fixline buffer: Fix crash when iterating backwards through empty +base buffer + + libinftext/inf-text-fixline-buffer.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +commit da06a82642c1d2d0d5a44f1ea3f62ad0b2b22c9a +Author: Armin Burgmeier +Date: Sun May 3 17:07:46 2015 -0400 + +Fix insert/erase notifications in InfTextFixlineBuffer + +The notifications were missing when the fixline buffer was modified +directly +with the API, and not in response to modifications to the underlying base +buffer. + + libinftext/inf-text-fixline-buffer.c | 10 ++ + 1 file changed, 10 insertions(+) + +commit 9b009160dd658fe9272d69025a8225b02eafb8de +Author: Armin Burgmeier +Date: Thu Apr 30 21:37:23 2015 -0400 + +Fix create_end_iter() implementation in InfTextFixlineBuffer + + libinftext/inf-text-fixline-buffer.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +commit 8990cf98ab43f3aca6a7bf12e9608b0e2e9b5c70 +Author: Armin Burgmeier +Date: Fri Apr 3 13:04:24 2015 -0400 + +Fix a crash when the server explicitly changes client account to default + + libinfinity/client/infc-browser.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +commit 0ce00121225662125b2ae4e48ff5d9f712e86a70 +Author: Armin Burgmeier +Date: Sat Jan 17 20:33:25 2015 -0500 + +Post-release bump to 0.6.6 + + configure.ac | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + commit 1a0ff8091afdfe831d317d10c377a8a025ea259d Author: Armin Burgmeier Date: Sat Jan 17 20:19:38 2015 -0500 diff -Nru libinfinity-0.6.5/configure libinfinity-0.6.6/configure --- libinfinity-0.6.5/configure 2015-01-18 02:21:51.575927350 +0100 +++ libinfinity-0.6.6/configure 2015-05-13 02:14:48.253651523 +0200 @@ -1,6 +1,6 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. -# Generated by GNU Autoconf 2.69 for libinfinity 0.6.5. +# Generated by GNU Autoconf 2.69 for libinfinity 0.6.6. # # Report bugs to . # @@ -590,8 +590,8 @@ # Identity of this package. PACKAGE_NAME='libinfinity' PACKAGE_TARNAME='libinfinity' -PACKAGE_VERSION='0.6.5' -PACKAGE_STRING='libinfinity 0.6.5' +PACKAGE_VERSION='0.6.6' +PACKAGE_STRING='libinfinity 0.6.6' PACKAGE_BUGREPORT='ar...@arbur.net' PACKAGE_URL='' @@ -1416,7 +1416,7 @@ # Omit some internal or obsolete options to make the list less imposing. # This message is too long to be a string
Re: Hints for d-i jessie RC3, part 5
On 2015-04-18 12:00, Cyril Brulebois wrote: Samuel Thibault (2015-04-18): Cyril Brulebois, le Sat 18 Apr 2015 04:57:35 +0200, a écrit : > All are in, including installation-guide; thanks everyone! Mmm, brltty didn't make it, it's waiting for 2 days. No it's not, there's a urgent hint for that. The missing armel build is an issue though. I've mentioned it on #debian-buildd, got no replies, and tried a give back, with no luck. Apr 18 10:53:13 brltty_5.2~20141018-5_armel.changes processed successfully (uploader buildd_armel-arn...@buildd.debian.org) Needed to delete the partial upload on the FTP server (FTP is so terrible) and reupload. Kind regards Philipp Kern -- 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/b5feda3692264a32e5f46ed3548bd...@hub.kern.lc
Re: concerns about the state of buildds for jessie
On 2015-02-12 13:02, Holger Levsen wrote: Possible avenues include updating the forks and working on making the forks no longer necessary. are these forks maintained in VCSs? http://anonscm.debian.org/cgit/buildd-tools/sbuild.git/log/?h=buildd-0.64 Historically forks have been needed because fixes in stable are hard. If stuff breaks in testing or unstable you usually need to fix it quicker than with a point release. A point could be made that the changes should be pushed to stable instead. As far as I know there's also still no builddadm-maintainable puppet tree. (Partly my fault I acknowledge, because I hoped to be able to do rabbitmq, but failed working against a black box I don't understand.) If we could ship the relevant helper scripts through Puppet (and unify configuration) we could also make most of the fork moot and just cherry-pick new versions from testing. Kind regards Philipp Kern -- 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/50e1ae2a77c3a7450871ca08b280e...@hub.kern.lc
Bug#776142: unblock: libinfinity/0.6.5-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libinfinity
libinfinity 0.6.5 contains multiple crash fixes. I'd feel much better if
those were included in the package. The diff is slightly noisy, but
mostly because of the new tarball (noise in the changelog, the
documentation output, and translations). A debdiff reduced to *.ac and
*.c changes is attached.
Changelog:
* Fix a crash when sending unsubscribe message causes connection failure
* InfdDirectory: Fail add-subdirectory request if name already exists
* Fix assertion failure when directory without storage is disposed
* Fix a memory leak in the plugin manager
* Make sure messages are not attempted to be sent on closed connections
* Add a missing status notify in InfXmppConnection
* Fix error message in server log when a client certificate is not
trusted
* Fix possible memory corruption on insert in fixline buffer
Only relevant for FreeBSD and Mac OS X:
* Check whether we need -lresolv for res_query() (gobby #23)
* infinoted-plugin-document-stream: Only use MSG_NOSIGNAL if available
(#7)
* inf-name-resolver: Include and
unblock libinfinity/0.6.5-1
--- libinfinity-0.6.3/configure.ac 2014-10-09 19:28:17.794128998 +0200
+++ libinfinity-0.6.5/configure.ac 2015-01-18 02:14:02.575945693 +0100
@@ -1,4 +1,4 @@
-m4_define([libinfinity_version], [0.6.3])
+m4_define([libinfinity_version], [0.6.5])
m4_define([libinfinity_api_version], [0.6])
m4_define([libinfinity_libtool_version], [0:0:0])
@@ -125,7 +125,41 @@
if test $platform = 'win32'; then
infinity_LIBS="$infinity_LIBS -lws2_32 -ldnsapi"
else
- infinity_LIBS="$infinity_LIBS -lresolv"
+ # Check whether we need libresolv for res_query()
+ # Can't use AC_SEARCH_LIBS because res_query is a macro defined in
+ # resolv.h
+ AC_MSG_CHECKING(for res_query)
+ AC_TRY_LINK(
+[
+ #include
+ #include
+ #include
+ #include
+],
+[res_query(NULL, 0, 0, NULL, 0);],
+[
+ # res_init() available in libc
+ AC_MSG_RESULT(yes)
+],
+[
+ LIBS="-lresolv"
+ AC_TRY_LINK(
+[
+ #include
+ #include
+ #include
+ #include
+],
+[res_query(NULL, 0, 0, NULL, 0);],
+[
+ AC_MSG_RESULT(in libresolv)
+ LIBS=""
+ infinity_LIBS="$infinity_LIBS -lresolv" # res_init available in libresolv
+],
+[AC_MSG_ERROR(res_query not provided by either libc or libresolv)]
+ )
+]
+ )
fi
###
--- libinfinity-0.6.3/infinoted/infinoted-plugin-manager.c 2014-08-29 16:48:38.249337739 +0200
+++ libinfinity-0.6.5/infinoted/infinoted-plugin-manager.c 2015-01-06 13:31:49.049584900 +0100
@@ -781,6 +781,8 @@
g_hash_table_unref(priv->connections);
g_hash_table_unref(priv->sessions);
+ g_free(priv->path);
+
G_OBJECT_CLASS(parent_class)->finalize(object);
}
--- libinfinity-0.6.3/infinoted/plugins/infinoted-plugin-certificate-auth.c 2014-08-29 16:48:38.253337778 +0200
+++ libinfinity-0.6.5/infinoted/plugins/infinoted-plugin-certificate-auth.c 2015-01-06 13:26:07.697569755 +0100
@@ -136,7 +136,7 @@
if(res != GNUTLS_E_SUCCESS)
inf_gnutls_set_error(&error, res);
else if( (verify_result & GNUTLS_CERT_INVALID) != 0)
- inf_gnutls_certificate_verification_set_error(&error, res);
+ inf_gnutls_certificate_verification_set_error(&error, verify_result);
if(error != NULL)
{
--- libinfinity-0.6.3/infinoted/plugins/infinoted-plugin-document-stream.c 2014-10-09 19:28:17.798128984 +0200
+++ libinfinity-0.6.5/infinoted/plugins/infinoted-plugin-document-stream.c 2015-01-18 02:14:02.575945693 +0100
@@ -40,6 +40,8 @@
#include
#include
+#include "config.h"
+
typedef enum _InfinotedPluginDocumentStreamStatus {
INFINOTED_PLUGIN_DOCUMENT_STREAM_NORMAL,
INFINOTED_PLUGIN_DOCUMENT_STREAM_RECEIVING,
@@ -882,7 +884,17 @@
do
{
-bytes = send(stream->socket, data, len, MSG_NOSIGNAL);
+bytes = send(
+ stream->socket,
+ data,
+ len,
+#ifdef HAVE_MSG_NOSIGNAL
+ MSG_NOSIGNAL
+#else
+ 0
+#endif
+);
+
errcode = errno;
if(bytes > 0)
@@ -990,7 +1002,11 @@
stream->socket,
stream->recv_queue.data + queue_offset,
stream->recv_queue.alloc - queue_offset,
+#ifdef HAVE_MSG_NOSIGNAL
MSG_NOSIGNAL
+#else
+ 0
+#endif
);
errcode = errno;
--- libinfinity-0.6.3/libinfinity/client/infc-session-proxy.c 2014-08-29 16:48:38.265337895 +0200
+++ libinfinity-0.6.5/libinfinity/client/infc-session-proxy.c 2015-01-06 16:49:15.242110509 +0100
@@ -120,7 +120,11 @@
);
}
- infc_session_proxy_release_connection(proxy);
+ /* If an error occurs while sending the "session-unsubscribe" message, the
+ * connection is released already as a result of the connection status
+ * notify handler, so we need another check here. */
+ if(priv->c
Bug#773515: unblock: mono/3.2.8+dfsg-9
tag 773515 + confirmed thanks On Fri, Dec 19, 2014 at 11:55:00AM +, Jo Shields wrote: > Please unblock package mono > > There are a couple of long-standing bugs in the Mono package, which > are fixed by this proposed upload to Unstable. > > #771389 prevents IPv6 from working in Mono-based apps It's a behavior change, but I'm inclined to let you fix the resolver here to be in line with the remainder of the distribution. > #773509 and #773511 relate to the mono-runtime-dbg package not being > correctly populated (and currently being useless) Looks fine. Please go ahead with the upload and report back once it has been accepted. Kind regards and thanks for your efforts Philipp Kern signature.asc Description: Digital signature
Bug#773712: unblock: jenkins-job-builder/0.9.0-0.1
retitle 773712 pre-approval: unblock: jenkins-job-builder/0.9.0-0.1 tag 773712 + confirmed thanks On Mon, Dec 22, 2014 at 03:29:36PM +0100, Michael Prokop wrote: > The version of jenkins-job-builder as available in current jessie is > totally broken with regards to its feature to delete Jenkins jobs. > There's a fix available from upstream which I included in > version 0.9.0-0.2. I've also verified that the fix works as needed. > > Please unblock package jenkins-job-builder: > > unblock jenkins-job-builder/0.9.0-0.2 > > Debdiff of the package versions as in jessie vs. what I just > uploaded to Debian/unstable (not yet accepted there > though signature.asc Description: Digital signature
Bug#773515: unblock: mono/3.2.8+dfsg-9
retitle 773515 pre-approval: mono/3.2.8+dfsg-9 thanks On Mon, Dec 22, 2014 at 10:11:51AM +, Jo Shields wrote: > On 22/12/14 09:35, Philipp Kern wrote: > > On Fri, Dec 19, 2014 at 11:55:00AM +, Jo Shields wrote: > >> Please unblock package mono > > > > This doesn't seem to have hit sid yet. > I was scolded for asking the release team "should I upload this, will > it be accepted for Jessie?" and told to file an unblock bug. So it's a pre-approval. Re-titling appropriately. Kind regards and thanks Philipp Kern signature.asc Description: Digital signature
Bug#773515: unblock: mono/3.2.8+dfsg-9
On Fri, Dec 19, 2014 at 11:55:00AM +, Jo Shields wrote: > Please unblock package mono This doesn't seem to have hit sid yet. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#769961: hard-coded UIDs and GIDs
On Fri, Dec 12, 2014 at 01:32:59PM +0100, Hans-Christoph Steiner wrote: > Right now, the package is only installable on systems that do not have the > linux-image meta-package installed and are very likely to in a chroot. So > that eliminates the majority of Debian installs as candidates where this > package is installable. Ideally there would be a way to actually detect the > Android kernel, I have not found that way. I wonder if you could probe for either ashmem or binder? Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#766932: wheezy-pu: package wireless-regdb/2014.10.07-1~deb7u1
Control: tag -1 + confirmed Hi, On Sun, Oct 26, 2014 at 03:07:00AM +, Ben Hutchings wrote: > I have again updated wireless-regdb in unstable to a new upstream > release. There have been many changes to the database based on new > regulations and information about additional countries. These should > also go into stable so that users can easily comply with current laws > and use the full permitted ranges of frequency and transmit power. please go ahead. Thanks! Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#717445: pu: package ndiswrapper/1.57-1+deb7u1
Control: tag -1 + moreinfo Hi, On Sun, Jan 26, 2014 at 02:57:22PM +0100, Julian Andres Klode wrote: > I'm most likely going to ship the patch below in 1.59-2, it just drops > the detection and hard-codes the modprobe.d/ndiswrapper.conf file, as > the other locations are not supported anymore. if this request still applies, please provide an updated debdiff against stable of what you want to ship. Thanks! Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#717457: pu: package oss4/4.2-build2006-2+deb7u2
Hi, On Sat, Aug 03, 2013 at 07:09:58PM +0200, Andreas Beckmann wrote: > Attached is a new version of the patch with the dependency on libc6-dev > replaced by > libc6-dev [!alpha !ia64 !hurd-i386] | libc0.3-dev [hurd-i386] | > libc6.1-dev [alpha ia64] | libc-dev > (as used by build-essential). hurd-i386 doesn't make sense for a linux-any package. alpha is not a release architecture in wheezy. So I think this could be simplified as "libc6-dev [!ia64] | libc6.1-dev [ia64]". I wonder if the single provider of libc-dev would just be picked correctly if that'd be used. Assuming that you tested that in a minimal chroot and that this is sufficient vs. build-essential, I'd be inclined to approve the upload. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#769394: unblock: gamera/3.4.1+svn1423-2
On Sat, Nov 15, 2014 at 03:04:39AM +0100, Daniel Stender wrote: > For my package Gamera another RC bug (#766740) remains and I'm working > on a solution, I'm going to file another unblock request, when it's in > Sid. > > Question regarding the upcoming new package I would like to ask in > front: In the meanwhile I've forwarded some patches and toggled the > patch header accordingly. These changes are already in the SVN repo. > The changes for 3.4.1+svn1423-3 are going to be on top of these > automatically - would it be alright to include that also, next to the > fix of the remaining RC bug, or would that be a clean violation of the > freeze policy in terms of that only changes are necessary to fix the bug > are allowed, and I would have to work around the SVN situation? If you just changed metadata on top of the patches, that shouldn't pose a problem when reviewing. If patch content itself changed, that'd be different. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#769591: unblock: owfs/2.9p8-6
Control: tag -1 + confirmed On Fri, Nov 14, 2014 at 09:06:08PM +0100, Vincent Danjean wrote: > Please unblock package owfs > > Hi, > > In #769523, it has been reported that some spurious output can > occurs when installing owfs-common. The reason is that "ls" is used > to find with shell globs some files to handle but, when the glob > do not match anything, "ls" complain. > The bug is not RC but it occurs on (some) upgrade and the fix is > really simple (redirect stderr of "ls" to /dev/null). As the bug > is not RC, I ask you is it would be ok to upload this fix now (or if > I must wait for jessie release). I know it is a purely cosmetic bug, no bad > behavior is involved in any case. Sounds good to me. Please ping the bug once it has reached the archive. Thanks. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#769316: unblock: gobby-infinote/0.5.0-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package gobby-infinote
The changes to gobby-infinote include a tiny cleanup (non-existent recommends
libinfinity-0.5-dbg to libinfinity-0.6-dbg) plus a fix to a not-cleaned-up
alternative.
diff -Nru gobby-infinote-0.5.0/debian/changelog
gobby-infinote-0.5.0/debian/changelog
--- gobby-infinote-0.5.0/debian/changelog 2014-10-19 10:31:47.0
+
+++ gobby-infinote-0.5.0/debian/changelog 2014-11-12 01:43:38.0
+
@@ -1,3 +1,10 @@
+gobby-infinote (0.5.0-4) unstable; urgency=medium
+
+ * Correct libinfinity-0.6-dbg recommends on gobby-dbg.
+ * Remove the gobby-0.5 alternative unconditionally. (Closes: #768242)
+
+ -- Philipp Kern Wed, 12 Nov 2014 02:42:44 +0100
+
gobby-infinote (0.5.0-3) unstable; urgency=medium
* Update debian/copyright to reflect the re-licensing from GPL to
diff -Nru gobby-infinote-0.5.0/debian/control
gobby-infinote-0.5.0/debian/control
--- gobby-infinote-0.5.0/debian/control 2014-10-18 22:01:56.0 +
+++ gobby-infinote-0.5.0/debian/control 2014-11-12 01:42:42.0 +
@@ -31,7 +31,7 @@
Depends: ${misc:Depends}, gobby (= ${binary:Version})
Breaks: gobby-0.5-dbg (<< 0.5.0-2~)
Replaces: gobby-0.5-dbg (<< 0.5.0-2~)
-Recommends: libinfinity-0.5-dbg, libgtkmm-2.4-dbg
+Recommends: libinfinity-0.6-dbg, libgtkmm-2.4-dbg
Description: infinote-based collaborative text editor - debugging symbols
Gobby is an editor which allows one to edit text documents and source files
collaboratively over a network. All users could work on the file
diff -Nru gobby-infinote-0.5.0/debian/gobby-0.5.postinst
gobby-infinote-0.5.0/debian/gobby-0.5.postinst
--- gobby-infinote-0.5.0/debian/gobby-0.5.postinst 1970-01-01
00:00:00.0 +
+++ gobby-infinote-0.5.0/debian/gobby-0.5.postinst 2014-11-12
12:06:10.0 +
@@ -0,0 +1,4 @@
+#!/bin/sh
+set -e
+update-alternatives --remove gobby /usr/bin/gobby-0.5
+#DEBHELPER#
unblock gobby-infinote/0.5.0-4
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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/20141112193645.30791.43103.report...@simplex.0x539.de
Bug#768920: RM: gobby-infinote/0.4.13-2
On Mon, Nov 10, 2014 at 08:55:20AM +, Adam D. Barratt wrote: > What about sobby? That has both build- and runtime dependencies on both > libobby and libnet6. sobby too, please. (How could I forget this... But then dak rm was very confused due to gobby(bin) being provided by !gobby(src).) Kind regards and thanks Philipp Kern signature.asc Description: Digital signature
Bug#768920: RM: gobby-infinote/0.4.13-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove the following *source* packages from jessie: gobby 0.4.13-2 net6 1:1.3.14-2 obby 0.4.8-1 gobby-infinote has taken over the gobby package just in time for the jessie freeze. I do not want gobby-0.4 to stay around for jessie, it won't receive any more updates upstream. net6 and obby are support packages only around for gobby-0.4 and can (and should) hence go as well. Kind regards and thanks Philipp Kern -- 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/20141110072747.5391.93676.report...@simplex.0x539.de
Bug#764156: wheezy-pu: package debian-archive-keyring/2014.1~deb7u1
Package: release.debian.org Severity: normal Tags: wheezy User: release.debian@packages.debian.org Usertags: pu Hi, I would like to update the attached package update of debian-archive-keyring to proposed-updates. This is a backport of the package in unstable, which adds the Jessie key and replaces my key signing key with the current one in the keyring. Kind regards Philipp Kern diff -Nru debian-archive-keyring-2012.4/active-keys/add-jessie-stable debian-archive-keyring-2014.1~deb7u1/active-keys/add-jessie-stable --- debian-archive-keyring-2012.4/active-keys/add-jessie-stable 1970-01-01 01:00:00.0 +0100 +++ debian-archive-keyring-2014.1~deb7u1/active-keys/add-jessie-stable 2014-08-31 07:22:29.0 +0200 @@ -0,0 +1,68 @@ +Comment: add Jessie stable key (ID: CBF8D6FD518E17E1) +Date: Sun, 31 Aug 2014 07:22:29 +0200 +Action: import +Data: + -BEGIN PGP PUBLIC KEY BLOCK- + Version: GnuPG v1 + + mQINBFIPYFgBEAC2wn0GKL3a6ZI3WtoiRRNYeVEwiSr8xP1zhk+Xavi4XsoHPsru + vo+9DvDiIcID8zDkcbt7QG8QvLP7yN6ucKcZhGOO+NFwKtkDsmEpG35/e17j+M74 + IgrrDs1Z249JwGXb28YN6u6KQBcDudcPFeQ5oZa1bnjgFYHVIxLvriBAoiCf7sT8 + WBfqYoNnIm6w+uEJDK9p3x+6BsJx+lBSUH0ZFGGjnZg+FMhW+IgdkRK9q7y8ofJ6 + HVH1W34qJWTGdYybywJqyaiNbIG7w9a6zbInfOSWEcCTzv6qukK0qzSQecL3cxsD + 7MKbQuQKM3qHb2FDQPnMDuiZKKDb8/zL9sn7xj/OVVpk8nkwMT3wirdQ1EaKz+XM + 7NKu32TjUWsBZpZTHvip13Tu4E17/oeeB6xyjWXu8TDJyBbMXoHv28Ab+pj098it + 1UFZnGlQZRMEa15V7O6f1ym9jyWATGVZii7iH8M73bXGEhEbPT58YBzll0olIHZf + AjtxcONdX82bJDHVo0Fv/Ww4hoitC/6PfdksKpVV2s708OlXGyzBSQg1CE0ozJzK + xnAf6veD+Zol62RkmVwKihvwvK/oE04hyH5eWY+/A1NRyESVeTpI1JJ3URfYLufh + XNBsYjA6mpAgymBJs6+TODDLbquRyhUiKVhfaEmHihp6jz748jvXPU7W+QARAQAB + tDtKZXNzaWUgU3RhYmxlIFJlbGVhc2UgS2V5IDxkZWJpYW4tcmVsZWFzZUBsaXN0 + cy5kZWJpYW4ub3JnPokCPQQTAQgAJwUCUg9gWAIbAwUJDwmcAAULCQgHAwUVCAoJ + CwUWAgMBAAIeAQIXgAAKCRDL+Nb9UY4X4fOGD/94LCoWsVVV+gPfP8R9FCafg5x6 + 5y3QkuL7WlatQbTpZyVZK5XiaoIiWi31lZ3fHG3SRYoqbyYatcVIf8/m9LlRJLOB + ZwQW02sM7jLqf7oA3XLyUnpwgb4xQiNr0Wvdi7aL70/AJaNPL+J7EQZMLppIKoZU + 28UYIfuA7MCJbJXPBr7hBsyzolf6A0qVh7KSaIpdX7Rt3aHcmFkb3iSty99KHN1N + zjb+Y13AE0aXGaEbabZaH3b2cZ2/jrGp6VY2eB6qN0iIa+qQ0nkzR5lFsVq4R85E + Rhcwv6Zr8fp6IiNN/JIs5M1GJoFE8wkR7fEaQ6WK8QB/K2dUQ6y0LtA2t6rUcEVi + 8+/+Nerhal33KlT4ivUbE6X4Z4YqRqfKXDT0juJZR/LLjHWRQHy+pWPAs5DumCNi + J0xkieW6quZ80QoYOWZkyDEemWjgFknYepuT9zHPWeJqavJ5U7copMVdJ/41ESq/ + +J0NREgcWC++aJJdxNwfbOwtQbC+5/fCj0N9gOe6/rpu3BAi99CG6Si9KfBqAbCi + RzfjmLJkHjmAVCjCcduakSI/PfYW2DGS9Yt142zTuxsZP2hqGXFaBlGHbVyvh9Du + yJAPfnF6W22ueFYPoMayR3EqyGTQDohhuxZuYokp/nQZdS7AdV9tHbuMNh7f+dnc + 9u5+C3hTLYgLSvFsQYkEHAQQAQgABgUCVAH+wQAKCRBQw2NNOikc+ZdKH/44JOGM + S536RkWApUXR5b9LIlLyznjOFhf1FQuaoEvzFuY0L6bmD81QOh3r1qzMvB6Ic8Xp + 891gjsL1mqvGLKmHInhcbsplq3XmVoXdDeHjbeUz+QEOLs6mNtLk7eR3Xs7jJQuO + kYCmLY2SfVpP43tqlYwxW8IMXM8rP/XyJAut3+UFPRZznYBDSSYNv8KusxTCDgFO + i2elJiyyrljkoW/MNHBCEVrKAI9zOLkStPVnDQJjogDsWl3zpRq24byllWz/Ye67 + OdCXyLw+/6Xpm4v97Jx64crC+qreBa53D8nMnRaKV9eE9yV7p5hKfoTyyO05DYCM + 1MoQtDbIz9y/Jm09QfQuR04zJVNur7wi5dJKR7Cd3WqBPNX4u0x03UFap8dB5OdI + JVYbvFXZdvDBvqPq7XPThnqXGlrdkQjIMke2cCuC7RirmibFnm3ExLkeAaiCXNEY + tB5LF/01tGSAei4nHrSYfcnz2GvSVqMl9RmqaIEICoHEIOBJwNMs2iLhGYM1qF7I + tUobKjHPpJjmIqIQTMBlQOKUMSKWfSzXcrPEdGBk+pEeTJbZHVh5SALu1ENCUUam + D8l5FDbXesU9A2yiozUTznvcsmLbrlk78AWUtIxQCRCu+Ua9JaNUaCW0s2ooBAlU + bXYSHWt4CVccPDA1FEkqN8+IP2kxq1IZ5bidVLaY0jOtLzy8AMVjUaO/orRUk8zf + ThFN85TG6Y67oXIsELfvFFovo5aYjx8X95xm5jb3hFInwNh0GNdv0bmHS6pb0Vjn + 8WwDJ0emSocaOHMV0fKKFqHHqZ/hJfq3NRx0RbJGG6rqYAy36EkDzVL2uS+t7Zo/ + g1SQ6mByZfX6ylJGNhLgeLkoiupRam8d7CvW1yTmDlZfn7dV++Nfq/s7j3vC1Kr6 + uO+7Mbw97Sb4acxXX1acHb31qFudvec5sMYK2bl76txcE8oYT2AgXXgPKhkMEAPW + peUuiE7ou0Z0JKVdhdK5qItSa0Hz83I4GRCg21//UTmhGcWgTBe9w9OV2wtQTKeb + Dy9RK9b3WksLOU1l45/c6dxKlwcymCB43adefHcLexCIl/kIX9lrYRJkWpYJg8AQ + V5msc3TAQZreNvFat+igBRrpbBQOA/oaj41yqjsO04xsqrEcFIh7KyLGbproJy2+ + WB4D1tXOJCyMFRLCYa4wqPCdtf7wCMoIRCXRZzYjj9vBmi/6D7lDWSJvk5bqwGY8 + sfS3oYw/yIW8QtUVzyDTchuVp0er7W2AbE5Hwxx8oa9r1hvX7x2aXPlA198DLKbu + FDhd6STmiEOggZNad/dkVWz/pIDppi0bhUZhSxqTxV4+pl5y7wQ3bSOBtZre4lSB + ZzZOMnyYe5MvqndRiQIcBBABCAAGBQJUAiR8AAoJEMXOXcLFQs1ZZtoQAJ9m5wV/ + zVw/LOLoT1Foe23MPl6kGdMcCZLvyRyEGnqK58X59GjjT56JEBwLo8lI5acqhBrN + N55/qgcn1Yp5R/KYfz3fYfuHVLexxe3bKWx+Q0LNdQZIPFx/Ly7krRefIE6K1def + SqbyU62sjMXheVDeh5kdTAjgXWZvesjg+ZyXgZnaTf+8x4Fc0llFyqZsLEnxE1qP + U4KLlxUH55j8uUv1dn3wGFuvaURuqwLAIDnIZfsiE05rx8iNZfbxBnQmt2Nrs1x3 + 78aEtQX/kb4HfPreY1BBM3pZiqszOzGB552kP4LoQSm7w8NUfsxEwSDCPeKR4Yk7 + 4eSBfdQIQBPmt9rggNXqw5Si4RRGT6WpKwGFq0QLIC6C1vkiQQqqq13d3w38mIf9 + tb+GDpKGBmkiVD0JBmXDMvCrBfS44HZUZIlhvnB2ME8mQHLhQdCz+saYAixzCwuA + oVpcN3AP0Tl4MBE+xfrM5OlWhWFjjPbjVb29aJdBqsDBNFc2LyissNwn2/RjW/Kg + Scd/zQ2QN57fPQhfbFcbUKbpI49D8iWxk14rYXfV3lfTgkPYGxo/3UQMmRvZ9wdw + ffsCmIuyeAXPkNZbBMADDhD5zU47wfvgEcvK5cfuuNIrY66euUE5hw/wg1VHb/+8 + 2a65h59CeW4zAYbU/0t47ghTDi/ybqTVbcsp + =kPlg + -END PGP PUBLIC KEY BLOCK- + diff -Nru debian-archive-keyring-2012.4/active-keys/index debian-archive-keyring-2014.1~deb7u1
Re: P-a-s for stable and stable-security
Hi, On Sat, Jul 26, 2014 at 09:29:47PM +0200, Philipp Kern wrote: > Oh well, you just uncovered a bug that was not exposed widely because there's > a fallback P-a-s in the toplevel directory: > > * All the triggers source triggers/common. > * common says at the top: >PAS_BASE="/srv/buildd.debian.org/web/quinn-diff" >PAS_FILE="$PAS_BASE/$SUITE/Packages-arch-specific" > * $SUITE is set subsequently but the file has already been source and hence >we get "/srv/buildd.debian.org/web/quinn-diff//Packages-arch-specific" for >all suites. > * This file exists and points to the sid checkout. >/srv/buildd.debian.org/web/quinn-diff/Packages-arch-specific -> > sid/Packages-arch-specific > > I'll fix that. Thanks. should be fixed. Hopefully. Kind regards and thanks Philipp Kern signature.asc Description: Digital signature
Re: P-a-s for stable and stable-security
On Sat, Jul 12, 2014 at 06:55:09PM +0100, Adam D. Barratt wrote:
> tl;dr: do stable and stable-security chroots apply P-a-s correctly?
>
> DSA 2952-1 updated kfreebsd-9 in wheezy-security. As it was built on all
> architectures for which kfreebsd-9 was available in wheezy, it was then
> also accepted in to proposed-updates. It appears that packages for some
> other architectures - arm{el,hf}, ia64, mips, powerpc, s390{,x} and
> sparc - were subsequently built by the buildds in wheezy chroots.
>
> The kfreebsd-9 source package in wheezy has "Architecture: any all".
> That changed in unstable at some point last year, and the package was
> subsequently removed from the "sid" branch of P-a-s in May.
>
> However, the wheezy branch of P-a-s still contains:
>
> %kfreebsd-9: kfreebsd-i386 kfreebsd-amd64 i386 amd64 mipsel hurd-i386
> # freebsd kernel 8.x
>
> This raises a couple of questions:
>
> - are the wheezy w-b databases filtered using the wheezy branch of
> P-a-s?
>
> - are the wheezy and wheezy-security w-b databases filtered using the
> _same_ branch of P-a-s?
Oh well, you just uncovered a bug that was not exposed widely because there's
a fallback P-a-s in the toplevel directory:
* All the triggers source triggers/common.
* common says at the top:
PAS_BASE="/srv/buildd.debian.org/web/quinn-diff"
PAS_FILE="$PAS_BASE/$SUITE/Packages-arch-specific"
* $SUITE is set subsequently but the file has already been source and hence
we get "/srv/buildd.debian.org/web/quinn-diff//Packages-arch-specific" for
all suites.
* This file exists and points to the sid checkout.
/srv/buildd.debian.org/web/quinn-diff/Packages-arch-specific ->
sid/Packages-arch-specific
I'll fix that. Thanks.
Kind regards
Philipp Kern
signature.asc
Description: Digital signature
Re: backport of dpkg (>= 1.17.2) and apt (>= 0.9.16.1) for build profiles
On Fri, Jul 25, 2014 at 02:19:38PM +0200, Johannes Schauer wrote: > Quoting Philipp Kern (2014-07-24 00:25:41) > > so I think this would rather be a question for stable, than for backports? > Maybe. We'd be equally (if not more) happy if SRM would reconsider their > decision (expressed on #debian-release toward Helmut Grohne) that these > patches > are too intrusive for a stable update. There are no decisions expressed on IRC, at most tendencies. Get them on the right list (debian-release@lists.d.o) and get them reviewed there. (Which never happened to far, aside Guillem's general question avoid feasibility, but without a patchset to consider.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: backport of dpkg (>= 1.17.2) and apt (>= 0.9.16.1) for build profiles
Hi, On Sun, Jul 06, 2014 at 11:16:17PM +0200, Johannes Schauer wrote: > Please reconsider adding packages with the attached three minimal patches for > dpkg, apt and python-apt to backports. In contrast to a full backport these > patches add the ability to parse the new build profile syntax with minimal > impact. In particular no code for using build profiles is added. We already > tried to update the build infrastructure via other means (stable update, > custom > repositories, local installation), but were faced with resistance from the > relevant teams (SRM, DSA, FTP). Each of them has good reasons. We believe that > backports is a good way to enable the build profile syntax on Debian build > infrastructure. so I think this would rather be a question for stable, than for backports? As I understand it, if this backport is in, and packages in the archive can hence be modified to incorporate the new syntax, stable tooling will no longer work with them? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Handling s390 libc ABI change in Debian
On Tue, Jul 15, 2014 at 07:18:39AM +0200, Aurelien Jarno wrote: > I can follow up with a list affected packages, but we are slowly > discovering them one by one, so it might takes time. So far we have: > > * Mixing modules/libraries built with pre-2.19 and 2.19 libc > - perl > - libpng > > * Using libc 2.19 without rebuilding anything: > - gauche > - mono I think it's pretty important for perl to keep working as much as is required for the system to upgrade itself. I'd be a bit less concerned (aside already broken binary compatibility) if the base system keeps working during the upgrade. We could conceivably document the breakage in the release upgrade notes, as long as updates can complete and suggest a reboot afterwards. > It's a huge work for Debian, maybe not for other distribution, as it > basically means we have to rebootstrap everything. This includes manual > bootstrapping of self-dependent languages (haskell, gnat, ...) and > manual handling of some dependencies loop. In addition it's something > which hasn't been done since the libc5 transition, so we might discover > some unexpected issues. Will it necessarily explode if both libcs are loaded into the same address space or only if the broken functionality is used? Would setjmp/longjmp only break if used across libc6/6.1 boundaries? Passing around an incompatible pthread struct seems bad, though. If this would work, a re-bootstrap would not necessarily be needed, I think? Kind regards and thanks Philipp Kern signature.asc Description: Digital signature
Re: Fixing irqbalance in wheezy
On Wed, Jun 11, 2014 at 01:11:14AM +0100, Ben Hutchings wrote: > irqbalance in wheezy does not work with the kernel in wheezy (bug > #748595). This is because it depends on a kernel API added in Linux > 3.3. > > Possibly we could roll back irqbalance to a lower version > (1.0.3+really0.56-1?). Alternately, I could try backporting the kernel > API, which looks fairly easy. Before I do that, what would the release > team prefer? Backporting the kernel API sounds good to me. Kind regards and thanks Philipp Kern signature.asc Description: Digital signature
Bug#746946: wheezy-pu: package distro-info-data/0.20~deb7u1
On Sun, May 04, 2014 at 01:03:22PM +0200, Cyril Brulebois wrote: > Stefano Rivera (2014-05-04): > > There are also a couple of minor support date updates, included, trivial > > packaging changes, and a bugfix to the Debian release versions. I don't > > think that risks regressions. > > > > As in the past, e.g. #727020, I'd be nice if this could go through > > stable-updates, but not essential. > Adding an Ubuntu entry would look OK to me. Updating dates, probably so. > Changing behaviour in stable doesn't look right to me. Who knows how > many packages and local scripts rely on the current output? I'd argue that 8 would be right for Jessie and 7.0 somewhat wrong for Wheezy, hence I'd tend to agree to the change. Stefano, where is this used? > Undocumented packaging changes (debhelper compat bump), ewww. Agreed, those won't happen. Just the changes to the csv files. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: stable update of dpkg (>= 1.17.2) and apt (>= 0.9.16.1) for build profiles
On Thu, May 01, 2014 at 05:29:39AM +0200, Guillem Jover wrote: > On Wed, 2014-04-30 at 15:28:27 +0200, Johannes Schauer wrote: > > Quoting Johannes Schauer (2014-04-26 07:15:03) > > > Because of this syntax change, packages that use this syntax can only be > > > uploaded once tools in Debian stable support it because the build > > > infrastructure runs Debian stable. > Much of our infrastructure code comes from unpackaged projects (?), > which makes this an awkward requirement, I guess it's the price of > reusing existing packaged code by the unpackaged projects. :/ There is a general problem that you want to make changes and you have only one live host where the software is primarily run. Or it does not support upgrades properly. (Sort of true for wanna-build; even though there are people trying to run it separately — like d-p.o —, but it is painful.) For sbuild and buildd, they are actually packaged and available on https://buildd.debian.org/apt/ but they are forked because we need to be able to be on a stable codebase and be able to make changes quickly on top of that. Maintenance of buildd in unstable is tied to sbuild and stuff tended to break too often. It's hard to tie our cycle to backports which relies on testing migration of newer versions in unstable that were never even smoke-tested for our use. It's kind of a chicken-egg problem on how to bootstrap package use in absence of regression tests. I'd be very nice but I don't see how that'd work with the kind of policies we have. Any urgent change would still require a repo to push from to all the buildds, for instance. > In this case one would have expected to be able to use build profiles > right away after the required infra changes (at least I think it > would have been possible in the past?), because they don't affect the > dist-upgrade path, but it seems there's new restricting factors now. I don't think the requirements for stable updates were any more lax in the past (in fact they were much stricter), or that people were more tolerant to do incompatible changes. There was, as far back as I remember, always the notion that things need to land in stable before they can be used. dist-upgrade path was a primary motivator, but handling of packages, even source packages, with stable tooling, was as important. See things like xz compression where we also needed to wait. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#733564: pu: apache2 with ECDHE support
Hi, On Thu, Apr 17, 2014 at 06:46:00PM +0200, Kurt Roeckx wrote: > I would like to also add support for the padding extention in > stable. It's part of the 1.0.1g release. NACK, at least for now. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#745937: please drop sparc from testing
Package: ftp.debian.org Severity: normal Dear FTP masters, by tomorrow sparc's content should be dropped from testing (i.e., with the next britney run at 22 UTC). Please deconfigure it from dak afterwards. Kind regards and thanks Philipp Kern -- 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/20140426163844.1961.84707.report...@spike.0x539.de
Re: Bug#663388: gnustep-back-common: unowned files after purge (policy 6.8, 10.8) violating FHS (policy 9.1) too
On Fri, Jun 01, 2012 at 05:04:11PM +0200, Andreas Beckmann wrote: > there are now fewer directories, but there is still something in $HOME: > > 0m47.6s ERROR: FAIL: Package purging left files on system: > /root/GNUstep/ not owned > /root/GNUstep/Library/ not owned I just retested and I see the original set: 2m2.0s ERROR: FAIL: Package purging left files on system: /root/GNUstep/ not owned /root/GNUstep/Library/ not owned /var/lib/GNUstep/ not owned /var/lib/GNUstep/Fonts/not owned /var/log/gnustep-back-common.log not owned mknfonts.tool is still linked against libgnustep-base1.22 because 1.24 is still stuck in experimental. Yavor, is there any plan to do the transition? #673538 didn't look like it was blocking on us. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#745830: pu: package src:libopenobex/1.5-2+deb7u1
On Fri, Apr 25, 2014 at 06:36:26PM +0200, Gerfried Fuchs wrote: > I'd like to upload libopenobex_1.5-2+deb7u1 to fix #743925 for wheezy. > Please find attached the debdiff; actually it's just a copy of the patch > in #699740 but I left out the updated watchfile here. > diff -u libopenobex-1.5/debian/changelog libopenobex-1.5/debian/changelog > --- libopenobex-1.5/debian/changelog > +++ libopenobex-1.5/debian/changelog > @@ -1,3 +1,11 @@ > +libopenobex (1.5-2+deb7u1) stable; urgency=low > + > + * NMU. > + * Fix segfault when transferring files, taking the patch from #699740 > +(closes: #743925) > + > + -- Gerfried Fuchs Fri, 25 Apr 2014 16:47:00 +0200 ACK. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#733564: pu: apache2 with ECDHE support
Hi, On Thu, Apr 10, 2014 at 08:02:46AM +0200, Stefan Fritsch wrote: > Browser support in itself is not the interesting factor here. We are > not disabling other ciphers, so clients not supporting ECDHE will just > continue to work. The question is how many browsers have broken > implemetations AND still use it as the preffered cipher. And the only > ones that we know of are those MacOS versions mentioned above. enabling the MacOSX workaround disables ECDHE for Safari on 10.6, 10.7, and the broken 10.8 flavors as they cannot be distinguished by the fingerprinting code. On 10.6 and 10.7 it'd work otherwise. So at least for the workaround browser support is slightly relevant. Enabling ECDHE in Apache would enable IE clients to use PFS if the admin manually configured a cipher preference. So I'd say that we should go and add ECDHE support to Apache as suggested and also patch OpenSSL for the OS X bug as the fingerprinting landed upstream and we would merely replicate current upstream behavior. > I would however not go the way of requiring the admin to explicitly > enable support on upgrades. The problem is that the default configured > cipher suite is HIGH:MEDIUM:!aNULL:!MD5 which includes ECDHE if > supported. To make the change opt-in, we would either need to change > the conffiles during upgrade, I would like to avoid, or we would need > to make the configuration incompatible with upstream by requiring > something special. I'd not make the change opt-in for the reasons you suggested. Kind regards and thanks Philipp Kern signature.asc Description: Digital signature
Re: Bits from the release team (freeze time line)
On Fri, Dec 27, 2013 at 02:19:07PM +0100, Andreas Barth wrote: > However, using words like "known-buggy mips* machines" is just FUD > against the mips*-ports, and plainly inacceptable, so please stop > doing that. (For reference, there is no mipsel machine which has > hardware bugs affecting daily operations. There are two mips machines > which are pre-series and are not as stable as I wish, but as builddadm > I was more occupied recently with arm* machines not stable then with > mips machines not stable. This all doesn't mean I think nothing should > be changed, but please do not FUD against mips* (or any other > architecture).) builddadm does not keep the machines running, DSA does. ball is ancient, corelli and gabrielli are unstable under load and lucatelli does need occasional reboots too, IIRC. But mips and mipsel might not actually be the same bucket you'd want to use, that seems to be the key takeaway here. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Why doesn't aspectc++ migrate?
On Fri, Nov 08, 2013 at 10:49:39PM -0500, Reinhard Tartler wrote: > I wonder why the package aspect++ does not migrate. According to > http://release.debian.org/migration/testing.pl?package=aspectc++, it > seems to be because of missing arm builds. I expected that not to > matter as the package is no longer in testing, but obviously I'm > wrong. They are out-of-date in unstable: aspectc++ |1:1.1+svn20120529-2 | unstable | source, armel, armhf aspectc++ |1:1.2-1 | unstable | source, amd64, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel You either need to get the armel, armhf builds to be removed from unstable through a bug against ftp.debian.org or get the package to build there again. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Issue in "Bad" regexp for ruby1.8-removal transition
On Thu, Sep 05, 2013 at 04:14:06PM +0200, Thorsten Glaser wrote: > On Mon, 2 Sep 2013, Jérémy Bobbio wrote: > > On the page described the transition to get rid of Ruby 1.8 [1], > How is this supposed to work, anyway? > • I don’t see either a bts entry or an explanation linked anywhere. It was pretty clear that it will take a while until we're at a point where this can be done. But it doesn't make sense to run the tracker somewhere different. Getting rid of an old interpreter version is something which happens every one or two releases, so it's nothing new. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: status of s390 toolchain maintenance
On Mon, Jul 01, 2013 at 11:42:44AM +0200, Matthias Klose wrote: > yesterday Aurelian Jarno did switch the GCC default to 4.8 in the VCS. > However I don't see him in the Debian GCC maintainer list as GCC port > maintainer. In the past I only did see s390 contributions and s390 related > bug triage from Bastian Blank. Is this change coordinated with Bastian? > Please could both of you add the relevant information to the README.Debian > (or send me patch), if you are actively involved in GCC maintenance on > s390(x)? Aurelien did a lot to bootstrap s390x and is also working on the port both wrt buildd maintenance and debugging. He is listed on [1], too. But obviously that does not imply GCC maintainance for s390*. And indeed, we should've copied Bastian on this. I apologize. Kind regards Philipp Kern [1] http://release.debian.org/wheezy/arch_qualify.html -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130703041030.ga5...@hub.kern.lc
Re: Accepted gnutls26 2.12.23-2 (source all i386)
On Wed, May 15, 2013 at 07:27:15PM +0200, Andreas Metzler wrote: > > If the libraries aren't intended to be co-installable, why are they in > > separate source packages? > The library packages are co-installable, the development packages > can't be, due to libtasn1.so. What's the reason for them being versioned? Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#707239: transition: sip4
Control: tag -1 confirmed On Wed, May 08, 2013 at 09:55:00AM -0400, Scott Kitterman wrote: > The following packages depend on a version of sip-api and will need to be > rebuilt/updated once sip4 is uploaded to unstable as part of getting the > addition of python3.3 sorted. DD list is attached. I emailed the maintainers > of the packages and the uploaders (only for packages that aren't team > maintained). Please go ahead. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: d-i wheezy rc2 preparation, take 1
On Mon, Apr 08, 2013 at 07:31:14AM +0200, Niels Thykier wrote: > Btw, I am not sure how important choose-mirror is, but it didn't migrate > last night (AFAICT it is built, just missing a signature + upload on ia64). Apr 8 06:41:50 buildd-uploader[14181]: Set to Uploaded(sid): choose-mirror_2.45 Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#704080: unblock: libarchive/3.0.4-3
Hi, On Fri, Apr 05, 2013 at 03:21:43AM +0100, peter green wrote: > Specifically it seems that s390x has not successfully built this > package for some time (since before s390x stopped being considered a > "broken and fucked" architecture). As a result the s390x package is > out of date in both testing and unstable. Britney will not migrate > the package if there are out of date binaries in unstable (even if > there are also out of date binaries for the same package in > testing). The cause of the build failures seems to be a testsuite > failure. Afaict there are several options in this scenario. my personal guess is that there's probably nothing s390x-specific to it, it's probably broken with 64bit big endian. The d-ports build for sparc64 fails as well. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sun, Mar 31, 2013 at 12:33:46PM -0500, Dirk Eddelbuettel wrote: > In the grand scheme of things, R is a rather peripheral package. Not sure where you get that idea, but given that you insist on that: | pkern@franck ~ % dak rm -nR -s testing r-base | Working... done. […] | Checking reverse dependencies... | # Broken Depends: [ 175 lines ] | | # Broken Build-Depends: [ 181 lines ] | | Dependency problem found. I realize that you wrote the list already in your first mail, but that's absolutely not "peripheral". > Please just put a "block" on r-base-core to prevent it from migrating to > testing. All these dependencies will be held too. Blocking RC bug fixes in any of the packages build-depending (even indirectly) on r-base. Well done. > I cannot influence the R release cycle which happens within our freeze. As > have a few previous R releases, and none of those created any trouble. Thanks for trading the R release cycle with Debian's and for delaying the release. The harm has already been done, so somebody should probably go and create a transition tracker for it? Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#701538: pre-approval of acpid/1:2.0.16-1+deb7u1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi, the attached patch fixes an issue with acpid running under systemd. acpid ships its own unit files for systemd, instead of using the init script. The one that should've replaced the init script does, however, not get activated with the acpid package in wheezy and hence acpid does not start on boot. This means, for instance, that VMs running wheezy with systemd will not respond to the power button. This is how libvirt & KVM signal that a VM should shut itself down. The patch, courtesy of Michael Biebl, is very minimal: diff --git a/debian/acpid.service b/debian/acpid.service index 733edc9..b998711 100644 --- a/debian/acpid.service +++ b/debian/acpid.service @@ -5,3 +5,6 @@ Requires=acpid.socket [Service] StandardInput=socket ExecStart=/usr/sbin/acpid + +[Install] +WantedBy=multi-user.target Could the acpid maintainers upload this change with version 1:2.0.16-1+deb7u1 to t-p-u? Unstable does contain a new upstream version and hence the fix cannot propagate from there, even though it's fixed in unstable already. Kind regards Philipp Kern -- 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/20130224113724.1031.77279.report...@spike.0x539.de
Bug#696671: tpu: isc-dhcp/4.2.2.dfsg.1-5+deb70u3
Control: tag -1 confirmed
Hi,
On Sat, Feb 16, 2013 at 04:20:45PM -0500, Michael Gilbert wrote:
> On Sat, Feb 16, 2013 at 4:18 PM, Michael Gilbert wrote:
> >> I've attached an updated proposed patch, which also fixes #698582 (and
> >> consequentially #700363).
> > File attached.
> Really attached this time ...
thanks. Please go ahead. One tiny remark, though:
+ if [ -e /etc/dhcp/dhclient.conf ] && \
+ [ "`md5sum /etc/dhcp/dhclient.conf | awk '{print $1;}'`" =
6e3910d75cd5cde0042ecb6d48492ae9 ]; then
+ sed -i -e
's/rfc3442-classless-static-routes;/rfc3442-classless-static-routes,
ntp-servers;/' /etc/dhcp/dhclient.conf
+ fi
Please don't do things with awk that can be realized with cut,
especially in a preinst. But since awk is still pseudo-essential
(pre-depends of base-files) in wheezy, it doesn't make a difference.
Kind regards
Philipp Kern
signature.asc
Description: Digital signature
Bug#700367: pu: package unbound/1.4.6-1+squeeze3
Control: tag -1 confirmed Hi, On Mon, Feb 11, 2013 at 10:51:05PM -0500, Robert Edmonds wrote: > i'd like to upload unbound 1.4.6-1+squeeze3 to stable to fix #697351. > since the release of squeeze D.ROOT-SERVERS.NET has had its IPv4 address > changed, and an IPv6 address added. (i believe there is precedent for > an updated package in stable to update DNS root server hints in [0].) please go ahead, thanks! Kind regards Philipp Kern signature.asc Description: Digital signature
Re: 6.0.7 planning
Hi, sorry for the delay. On Sun, Feb 10, 2013 at 04:25:38PM +, Adam D. Barratt wrote: > We're somewhat overdue with the next Squeeze point release (6.0.7) and > it'd be good to get it done before the wheezy release, so that we can > pull in some upgrade fixes. As an opening gambit, some proposed dates, > all of which appear to currently work for me: > > February 23rd > > March 2nd > > March 9th These all work for me. I will be sort of offline, however, from February 14th to (including) 17th, which looks like the preparation range for the first date. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Thu, Feb 07, 2013 at 10:33:00AM +0100, Ansgar Burchardt wrote: > As Adam already pointed out we would still need another d-i upload to > unstable to make sure unstable has a higher-or-equal version compared to > testing. Sometimes I wonder why it cannot simply propagate to the upper suite. We do that for packages from s-p-u at point release time, too. I guess the flow would be "britney import → if version > unstable → stuff the new testing version into unstable". We used to propagate security updates from stable into testing so that they only have to be done once. But I guess both times concerns about "not being built within the suite in question" might apply. But we still do that for packages installed into *stable* (i.e. across the major divergence between stable and unstable, or at least into testing). Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#699705: Lost .changes on 2013-01-19 (was: Re: Bug#699705: unblock: iceape/2.7.12-1)
Ansgar, am Mon, Feb 04, 2013 at 05:34:48PM +0100 hast du folgendes geschrieben: > The lost binary-only uploads are > > * pygtk_2.24.0-3+b1_i386.changes > * bitcoin_0.7.2-2_kfreebsd-amd64.changes > * partman-efi_34_i386.changes > * iceape_2.7.12-1_s390.changes > * iceape_2.7.12-1_powerpc.changes thanks for the list. I reuploaded those packages. Please just mail $arch@buildd.d.o next time. > The log files for queued are now rotated. Older entries can be found in > /srv/upload.debian.org/queued/log.*.xz. Good to know, thanks. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#699705: unblock: iceape/2.7.12-1
Hi, On Mon, Feb 04, 2013 at 03:40:51PM +0100, Wouter Verhelst wrote: > [s390 removed] re-added. > It built on parry. The .upload file says: > > wouter@parry:/home/buildd/upload$ cat iceape_2.7.12-1_powerpc.upload > u iceape-dbg_2.7.12-1_powerpc.deb ftp-master.debian.org Sat Jan 19 13:58:00 > 2013 > u iceape_2.7.12-1_powerpc.deb ftp-master.debian.org Sat Jan 19 13:58:20 2013 > u iceape_2.7.12-1_powerpc.changes ftp-master.debian.org Sat Jan 19 13:58:21 > 2013 > s iceape_2.7.12-1_powerpc.changes ftp-master.debian.org Sat Jan 19 13:58:21 > 2013 > > which is quite a while ago. I can reupload if necessary, but I'd like to see > what happened to the original upload before we go that route. Added CC to > ftp-master; could you guys look at this? I sadly deleted my buildd folder a few days ago. Anyway I guess the whole upload failed because the iceape-dbg is huge and the upload was cut off somewhere in between. queued on ftp-master doesn't have any info beyond Feb 1st, and it never reached dak (neither for powerpc nor s390). dput's now running on both in a screen. Hopefully that helps. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Can bug 686100 be fixed in Debian testing?
Alexander, am Wed, Jan 23, 2013 at 12:40:57PM +0600 hast du folgendes geschrieben: > mdadm bug 686100 (with a trivial patch that the release team can > surely review) has been fixed only in experimental, but not in sid or > in wheezy. Why? maybe you should ask the maintainer that question, not us. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#696671: tpu: isc-dhcp/4.2.2.dfsg.1-5+deb70u3
On Tue, Dec 25, 2012 at 11:19:18PM -0500, Michael Gilbert wrote: > As seen in #695810 (merged with #486520), ifupdown switched to calling > dhclient with the -1 option, and in past releases it had not, so it is > now a more prevalent problem. Although sure severity is questionable, > and I'm not willing to exert much effort to include it. I'll remove > if that's what is wanted. So "-1" will fire up dhclient, try to get a lease for a preset amount of time (i.e. querying multiple times) and then fork for continuously renewing the lease or exit with failure code 2? I just want to be sure I understand the logic before ACKing it. (And sorry for the delay on that.) Thanks Philipp Kern signature.asc Description: Digital signature
Re: Please wheezy-ignore #695716
On Thu, Jan 17, 2013 at 10:50:34PM +, Neil Williams wrote: > Users should not have to upgrade stable to new testing (Jessie) to fix > RC bugs which could have been fixed in stable. Nor should users be > expected to inspect details of the package in versions outside stable > to make decisions on the licensing of packages in stable. (Otherwise, > we'd keep all the copyright files on a server somewhere and save many > Gb of archive space.) Sorry, but that's stupid. We're legally required by most licenses to ship the license info with the binary package. That's not primarily for users to base their decisions on. > If Debian allowed bugs fixed in unstable only to no longer be RC, we > might already have released but users would have been no better off. There are classes of bugs that are ignored by us if they're fixed in unstable, copyright clarifications are among them. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#697602: Bug count confusion when "unrelated" binary and source has same name
On Mon, Jan 07, 2013 at 03:16:42PM +0100, Niels Thykier wrote:
> If a source package produces and identically named binary
> (e.g. src:eclipse produces a binary named eclipse), it usually doesn't
> matter which of them gets the "blame". The problem is when a binary
> has the same name as a source that _doesn't_ built it. An example
> in the archive being:
>
> source:sm builds binary r-cran-sm,
> source:screen-message builds binary sm
>
> If a BugsV file contains "sm 123456" Britney will assume that RC bug
> applies to _both_ the source package "sm" and the binary "sm" (and
> thus "screen-message").
I'd seriously argue that one of the source packages has to change its name. I
don't think that the two namespaces (source and binary packages) should be
considered that separated, so that might warrant an addition to policy? ("Do
not build a binary package that has the name of a totally unrelated source
package"?)
Kind regards
Philipp Kern
--
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/20130115122433.ga12...@hub.kern.lc
Re: linux-2.6 update for stable?
Ben, am Sun, Jan 13, 2013 at 12:16:30AM + hast du folgendes geschrieben: > We have a huge number of important fixes from 2.6.32.60 pending in svn, > plus two SCSI driver updates (hpsa and megaraid_sas). > > Does anyone expect to commit any more changes for stable soon? > > SRMs, is it OK to upload at the moment? yes. The sooner the better. ;) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Fwd: apt-show-versions_0.19~squeeze1_amd64.changes ACCEPTED into proposed-updates->stable-new
On Sat, Jan 12, 2013 at 04:38:03PM +, Adam D. Barratt wrote: > On Thu, 2012-12-27 at 21:56 +0100, Philipp Kern wrote: > > On Wed, Oct 24, 2012 at 05:44:00PM +0100, Adam D. Barratt wrote: > > > From a very quick scan and with apologies if I'm missing something > > > due to unfamiliarity with the codebase: > > > > > > -my @official_suites = qw(oldstable stable proposed-updates testing > > > unstable); > > > +my @official_suites = qw(oldstable stable proposed-updates testing > > > unstable experimental); > > > > > > Should that list include oldstable-proposed-updates, squeeze-updates > > > and/or t-p-u? > [...] > > +apt-show-versions (0.16+squeeze1) stable; urgency=low > > + > > + * Non-maintainer upload. > > + * Fix bug which caused squeeze-updates and squeeze to mask each other. > > +Thanks to Dominic Hargreaves. (Closes: #623252) > > + * Update the list of official suites. > > + > > + -- Philipp Kern Thu, 27 Dec 2012 20:10:26 + > Looks okay to me; thanks. Uploaded. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Fwd: apt-show-versions_0.19~squeeze1_amd64.changes ACCEPTED into proposed-updates->stable-new
On Thu, Dec 27, 2012 at 09:56:34PM +0100, Philipp Kern wrote: > On Wed, Oct 24, 2012 at 05:44:00PM +0100, Adam D. Barratt wrote: > > From a very quick scan and with apologies if I'm missing something > > due to unfamiliarity with the codebase: > > > > -my @official_suites = qw(oldstable stable proposed-updates testing > > unstable); > > +my @official_suites = qw(oldstable stable proposed-updates testing > > unstable experimental); > > > > Should that list include oldstable-proposed-updates, squeeze-updates > > and/or t-p-u? > > I'd suggest this debdiff (please Cc me on reply): Ping. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: exim4 upload to stable (dovecot stability / and optionally spf quoting)
On Sat, Jan 05, 2013 at 02:20:06PM +0100, Andreas Metzler wrote:
> On top of this I would like to discuss whether it is acceptable to fix
> http://bugs.debian.org/697057 in stable, too. [ I definitily want o
> get the fix into testing - #697444.] The Debian configuration
> optionally allows to use spfquery to run SPF-checks on incoming mail.
> Due to insufficient quoting it is possible to pass on arbitrary
> arguments to spfquery and therefore bypass SPF checks. The fix is not
> invasive, but it changes dpkg conffiles.
>
> ---
> diff --git a/debian/debconf/conf.d/acl/30_exim4-config_check_rcpt
> b/debian/debconf/conf.d/acl/30_exim4-config_check_rcpt
> index ac347aa..4949587 100644
> --- a/debian/debconf/conf.d/acl/30_exim4-config_check_rcpt
> +++ b/debian/debconf/conf.d/acl/30_exim4-config_check_rcpt
> @@ -265,10 +265,10 @@ acl_check_rcpt:
> log_message = SPF check failed.
> !acl = acl_local_deny_exceptions
> condition = ${run{/usr/bin/spfquery.mail-spf-perl --ip \
> - \"$sender_host_address\" --identity \
> + ${quote:$sender_host_address} --identity \
> ${if def:sender_address_domain \
> - {--scope mfrom --identity \"$sender_address\"}\
> - {--scope helo --identity \"$sender_helo_name\"}}}\
> + {--scope mfrom --identity ${quote:$sender_address}}\
> + {--scope helo --identity
> ${quote:$sender_helo_name\
> {no}{${if eq {$runrc}{1}{yes}{no
>
>defer
> ---
Just to be clear: The underquoting does not yield a situation where one
can use shell escapes or similar? It's "just" about being able to bypass
the SPF check by supplying crafted data?
Kind regards
Philipp Kern
signature.asc
Description: Digital signature
Re: Bug#669213: bind9: new upstream release: 9.9
On Mon, Oct 29, 2012 at 02:30:13PM -0600, LaMont Jones wrote: > On Mon, Oct 29, 2012 at 05:22:10PM +, Adam D. Barratt wrote: > > Indeed. In any case, were the new version to be accepted in to the > > release then the appropriate route would be via unstable, not direct > > to t-p-u. > Works for me. I'll toss 9.8.4 into sid. As for getting it into wheezy, > it'll make the support life easier for the inevitable security fixes that > will follow. There are probably other reasons. I unblocked it now. I hope that I don't regret that. I'm unhappy about how this went, but I think we should have the fixes 9.8.4 provides in wheezy. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#696705: nmu: gnome-contacts_3.6.1-1 in experimental
On Thu, Dec 27, 2012 at 02:00:59PM +0100, Michael Biebl wrote: > On 26.12.2012 09:25, Paul Wise wrote: > > Package: release.debian.org > > Severity: minor > > User: release.debian@packages.debian.org > > Usertags: binnmu > > > > Please binNMU gnome-contacts in experimental so it is installable again. > > > > nmu gnome-contacts_3.6.1-1 . ALL . -m "Rebuild for the libcheese ABI > > transition" > binNMUs do not work for dependencies from experimental. > > If we want to have gnome-contacts built against libcheese from exp, the > build-depends needs to be bumped (i.e. it will require a sourceful upload) That's not exactly true, it is possible to add build-depends (or -conflicts) for a one-shot binNMU. But for clarity and further binNMUs (against unstable) doing the right thing a sourceful upload is preferred. (They wouldn't be copied to the new one.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bug#695761: unblock: debian-edu/1.702 and debian-edu-config/1.702
Petter, am Fri, Dec 28, 2012 at 04:57:50PM +0100 hast du folgendes geschrieben: > I prefer type over testing for specific paths, to not depend on a > specific location on disk. If nscd or other tools move from /usr/bin/ > to one of the other directories in the PATH, I want our scripts to > keep working. there's no reason at all to incur a PATH-based lookup for something that has a fixed path in a distribution. Obviously the burden's on the one who changes the location of a binary to grep the archive for changes that need to be made. Kind regards Philipp Kern signature.asc Description: Digital signature
