Bug#806247: jessie-pu: package dbconfig-common/1.8.47+nmu3
On Wed, 25 Nov 2015 21:02:11 +0100 Paul Gevers wrote:
> I will start to work on a proper debdiff, but I appreciate it to know if I
> should include the fixing of existing files in it.
Due to lack of a response, which I expect is due to the lack of a
debdiff, I went ahead and fixed the permissions on existing files.
Please find attached my proposed fix for jessie. The delta for wheezy is
nearly the same, minus the changelog.
Paul
diff -Nru dbconfig-common-1.8.47+nmu3/debian/changelog
dbconfig-common-1.8.47+nmu3+deb8u1/debian/changelog
--- dbconfig-common-1.8.47+nmu3/debian/changelog2014-11-02
21:48:57.0 +0100
+++ dbconfig-common-1.8.47+nmu3+deb8u1/debian/changelog 2015-12-03
19:56:19.0 +0100
@@ -1,3 +1,11 @@
+dbconfig-common (1.8.47+nmu3+deb8u1) jessie; urgency=medium
+
+ * Fix permission of PostgreSQL backup files, thanks Simon Ruderich
+(Closes: #805638)
+ * Repair permissions of already created backups
+
+ -- Paul Gevers Thu, 03 Dec 2015 19:48:17 +0100
+
dbconfig-common (1.8.47+nmu3) unstable; urgency=low
* Non-maintainer upload.
diff -Nru dbconfig-common-1.8.47+nmu3/debian/dbconfig-common.postinst
dbconfig-common-1.8.47+nmu3+deb8u1/debian/dbconfig-common.postinst
--- dbconfig-common-1.8.47+nmu3/debian/dbconfig-common.postinst 2013-07-14
14:19:00.0 +0200
+++ dbconfig-common-1.8.47+nmu3+deb8u1/debian/dbconfig-common.postinst
2015-12-03 20:11:07.0 +0100
@@ -15,4 +15,11 @@
dbc_write_global_config
+# Previously dumped databases in /var/cache/dbconfig-common/backups may
+# (depending on the local umask) be readable by everybody (bts: #805638). Limit
+# the permissions here on all files in that folder.
+if [ -d /var/cache/dbconfig-common/backups/ ] ; then
+find /var/cache/dbconfig-common/backups/ -type f -exec chmod 600 {} \;
+fi
+
#DEBHELPER#
diff -Nru dbconfig-common-1.8.47+nmu3/internal/pgsql
dbconfig-common-1.8.47+nmu3+deb8u1/internal/pgsql
--- dbconfig-common-1.8.47+nmu3/internal/pgsql 2013-07-20 10:12:12.0
+0200
+++ dbconfig-common-1.8.47+nmu3+deb8u1/internal/pgsql 2015-11-25
22:08:24.0 +0100
@@ -174,14 +174,14 @@
local extra retval PGSSLMODE localuser _dbc_asuser dumpfile old_umask
dumpfile=$1
localuser=`_dbc_psql_local_username`
- touch $dumpfile
- chown $localuser $dumpfile
PGSSLMODE="prefer"
retval=0
_dbc_psql_cmd_setup
if [ "$dbc_ssl" ]; then PGSSLMODE="require"; fi
old_umask=`umask`
umask 0066
+ touch $dumpfile
+ chown $localuser $dumpfile
extra=`_dbc_psql_cmd_args`
extra="-f \"$dumpfile\" $extra"
_dbc_debug "su -s /bin/sh $localuser -c \"env HOME='$_dbc_pgsql_tmpdir'
PGPASSFILE='$_dbc_pgsql_tmpdir/.pgpass' PGSSLMODE='$PGSSLMODE' pg_dump $extra
$dbc_dbname\" 2>&1"
signature.asc
Description: OpenPGP digital signature
Bug#805634: jessie-pu: torbrowser-launcher/0.2.2-2~deb8u1
Dear stable release managers, as described in this bug, torbrowser-launcher in jessie is completly broken at the moment. A reply from you about this request would have been very nice (even given intrigeri's reply), and even if it would have been "Holger, you should know we don't like new upstream versions, please do the work and cherry-pick those commits" or whatever. As it seems there is now the danger not having torbrowser-launcher fixed with the next point release, resulting in torbrowser being broken for stable users until next year :-( So anyway, let's let the past be past. If I (or someone else) would find the time to identify the commits to cherry-pick by Monday and ask for review here then, could that still be in time to be included in the next point release? cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#807002: marked as done (nmu: golang-golang-x-net-dev_0.0+git20151007.b846920+dfsg-1)
Your message dated Fri, 4 Dec 2015 12:04:46 +0100 with message-id <5661734e.9050...@debian.org> and subject line Re: Bug#807002: nmu: golang-golang-x-net-dev_0.0+git20151007.b846920+dfsg-1 has caused the Debian Bug report #807002, regarding nmu: golang-golang-x-net-dev_0.0+git20151007.b846920+dfsg-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 807002: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807002 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu Severity: normal X-Debbugs-CC: paul...@debian.org, pkg-go-maintain...@lists.alioth.debian.org Hello, Due to a typo of mine while preparing the upload, src:golang-go.crypto 1:0.0~git20151201.0.7b85b09-1 was uploaded and accidentally overwrote the "golang-golang-x-net-dev" binary package from src:golang-golang-x-net-dev. I've pushed a new upload of src:golang-go.crypto fixing the issue there (which is in binNEW now), but in talking with Paul he mentioned that a binNMU _should_ be enough to fix the situation with the binary package of src:golang-golang-x-net-dev, and that I ought to file a bug here with RT to get some help figuring out whether that's really sufficient (or whether we need to also do an FTP team RM or epoch bump the -net package). nmu golang-golang-x-net-dev_0.0+git20151007.b846920+dfsg-1 . all . -m 'Rebuild to bring back the proper binary packages' ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 --- End Message --- --- Begin Message --- On 04/12/15 00:55, Tianon Gravi wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: binnmu > Severity: normal > X-Debbugs-CC: paul...@debian.org, pkg-go-maintain...@lists.alioth.debian.org > > Hello, > > Due to a typo of mine while preparing the upload, src:golang-go.crypto > 1:0.0~git20151201.0.7b85b09-1 was uploaded and accidentally overwrote > the "golang-golang-x-net-dev" binary package from > src:golang-golang-x-net-dev. > > I've pushed a new upload of src:golang-go.crypto fixing the issue > there (which is in binNEW now), but in talking with Paul he mentioned > that a binNMU _should_ be enough to fix the situation with the binary > package of src:golang-golang-x-net-dev, and that I ought to file a bug > here with RT to get some help figuring out whether that's really > sufficient (or whether we need to also do an FTP team RM or epoch bump > the -net package). > > nmu golang-golang-x-net-dev_0.0+git20151007.b846920+dfsg-1 . all . -m > 'Rebuild to bring back the proper binary packages' We can't binNMU arch:all packages. Besides, that is not going to work. A binNMU would give you golang-golang-x-net-dev 0.0+git20151007.b846920+dfsg-1+b1 But golang-go.crypto is building: golang-golang-x-net-dev 1:0.0~git20151201.0.7b85b09-1 Which is higher because of the epoch. So AFAICS you need a sourceful upload with an epoch to fix this. Cheers, Emilio--- End Message ---
Bug#805634: jessie-pu: torbrowser-launcher/0.2.2-2~deb8u1
On 04/12/15 12:05, Holger Levsen wrote: > Dear stable release managers, > > as described in this bug, torbrowser-launcher in jessie is completly broken > at > the moment. A reply from you about this request would have been very nice > (even given intrigeri's reply), and even if it would have been "Holger, you > should know we don't like new upstream versions, please do the work and > cherry-pick those commits" or whatever. > > As it seems there is now the danger not having torbrowser-launcher fixed with > the next point release, resulting in torbrowser being broken for stable users > until next year :-( > > So anyway, let's let the past be past. If I (or someone else) would find the > time to identify the commits to cherry-pick by Monday and ask for review here > then, could that still be in time to be included in the next point release? Hmm? Is there going to be a point release next week and I completely missed the announcement? Emilio
Bug#805634: [Pkg-privacy-maintainers] Bug#805634: jessie-pu: torbrowser-launcher/0.2.2-2~deb8u1
Hi, On Freitag, 4. Dezember 2015, Emilio Pozuelo Monfort wrote: > Hmm? Is there going to be a point release next week and I completely missed > the announcement? a release team member (who is not a SRM) told me yesterday that it might be too late to be included in the next point release very soon. Given that usually point releases used to happen every other month and that we had one early June and early September this seemed plausible. It's been three months since the last one… cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#805634: [Pkg-privacy-maintainers] Bug#805634: jessie-pu: torbrowser-launcher/0.2.2-2~deb8u1
On Fri, 2015-12-04 at 13:42 +0200, Holger Levsen wrote: > Hi, > > On Freitag, 4. Dezember 2015, Emilio Pozuelo Monfort wrote: > > Hmm? Is there going to be a point release next week and I completely missed > > the announcement? > > a release team member (who is not a SRM) told me yesterday that it might be > too late to be included in the next point release very soon. Given that > usually point releases used to happen every other month and that we had one > early June and early September this seemed plausible. It's been three months > since the last one… Yes, everyone seems to have been even busier than usual recently. :-( I realise this isn't ideal, and keep hoping things will get a bit less so. There isn't currently a date for 8.3, so unless someone else is going to organise it and do all the work, it's certainly not going to be within the next couple of weeks, and then it's the holidays. If we can get one sorted for earlyish January that would be good, but needs me to find a tuit or two. Regards, Adam
Processed: block 796345 with 807038
Processing commands for cont...@bugs.debian.org: > block 796345 with 807038 Bug #796345 [release.debian.org] transition: perl 5.22 796345 was blocked by: 796923 799118 790532 787493 788073 787468 802939 787450 787453 796345 was blocking: 798309 801659 801660 801661 801662 801663 Added blocking bug(s) of 796345: 807038 > thanks Stopping processing here. Please contact me if you need assistance. -- 796345: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796345 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#784944: jessie-pu: package redmine/3.0~20140825-8~deb8u1 (was 3.0~20140825-7~deb8u1)
Hello, On Thu, Aug 13, 2015 at 02:05:08PM -0300, Antonio Terceiro wrote: > Hello, > > On Fri, Jul 03, 2015 at 09:41:22AM -0300, Antonio Terceiro wrote: > > Hello, > > > > On Sun, May 10, 2015 at 08:02:55PM -0300, Antonio Terceiro wrote: > > > Package: release.debian.org > > > Severity: normal > > > Tags: jessie > > > User: release.debian@packages.debian.org > > > Usertags: pu > > > > > > This release fixes several bugs related to upgrades from wheezy. The > > > equivalent version is already in testing. I have tested it extensively, > > > and received positive feedback from multiple bug submitters. > > > > > > debdiff attached. > > > > ping? > > > > Besides the testing I did myself, I pointed several people who reported > > bugs against the version in jessie to a jessie build I provided at > > people.debian.org, and they all gave me positive feedback. > > > > I realize that the debdiff is larger than what one would want, but some > > serious effort was made into testing it. > > Since the last ping, I have released a new update to unstable which > fixes upgrades from wheezy. I would really like to upload a jessie > update with the attached diff. I have already pointed several users at > such update I am serving from > https://people.debian.org/~terceiro/redmine-jessie/ and most of them > reported that it fixed their issues and noone reported additional > problems with it. > > Can we please get this update in jessie? ping? This is my third ping, and since it was initially posted, this stable update request received no feedback at all. As already mentioned, I have been using this in production, and have pointed several users who reported bugs after the jessie release to it, fixing some issues, and in the worst case having no negative effects. If the diff is not acceptable, please just say so, we'll close this and move along. Receiving no feedback is way more frustrating than it would be to have the request rejected. Can I _please_ hear something back? -- Antonio Terceiro signature.asc Description: PGP signature
Bug#807002: nmu: golang-golang-x-net-dev_0.0+git20151007.b846920+dfsg-1
On 4 December 2015 at 03:04, Emilio Pozuelo Monfort wrote: > Besides, that is not going to work. A binNMU would give you > > golang-golang-x-net-dev 0.0+git20151007.b846920+dfsg-1+b1 > > But golang-go.crypto is building: > > golang-golang-x-net-dev 1:0.0~git20151201.0.7b85b09-1 > > Which is higher because of the epoch. > > So AFAICS you need a sourceful upload with an epoch to fix this. Ahh, ok; thanks for confirming! I'll team-upload a fixed golang-golang-x-net-dev then. :) ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
Processed: jessie-pu: package mkvmlinuz/37+deb8u1
Processing commands for cont...@bugs.debian.org:
> block 741642 by 793556
Bug #741642 {Done: Milan Kupcevic } [mkvmlinuz]
/etc/kernel/postinst.d/mkvmlinuz exited with return code 20
Bug #791868 {Done: Milan Kupcevic } [mkvmlinuz]
/etc/kernel/postinst.d/mkvmlinuz exited with return code 20
741642 was blocked by: 793556
741642 was not blocking any bugs.
Ignoring request to alter blocking bugs of bug #741642 to the same blocks
previously set
791868 was blocked by: 793556
791868 was not blocking any bugs.
Ignoring request to alter blocking bugs of bug #791868 to the same blocks
previously set
> tags 793556 - moreinfo
Bug #793556 [release.debian.org] jessie-pu: package mkvmlinuz/37+deb8u1
Removed tag(s) moreinfo.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
741642: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741642
791868: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791868
793556: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793556
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#784944: jessie-pu: package redmine/3.0~20140825-8~deb8u1 (was 3.0~20140825-7~deb8u1)
Control: tags -1 + confirmed On Fri, 2015-12-04 at 12:10 -0200, Antonio Terceiro wrote: [...] > > > > This release fixes several bugs related to upgrades from wheezy. The > > > > equivalent version is already in testing. I have tested it extensively, > > > > and received positive feedback from multiple bug submitters. [...] > This is my third ping, and since it was initially posted, this stable > update request received no feedback at all. As already mentioned, I have > been using this in production, and have pointed several users who > reported bugs after the jessie release to it, fixing some issues, and in > the worst case having no negative effects. Apologies for the delay; I'm not sure how this managed to slip through the cracks for quite so long. One comment: +redmine (3.0~20140825-8~deb8u1) jessie; urgency=medium + + * Backport as a stable update for Jessie. + + -- Antonio Terceiro Sun, 10 May 2015 19:26:43 -0300 + +redmine (3.0~20140825-8) unstable; urgency=medium + + * Replace "interest" triggers with "interest-nowait" ones to avoid trigger +loops (Closes: #786763) + + -- Antonio Terceiro Fri, 10 Jul 2015 20:07:20 -0300 Those dates look a little odd. I'm assuming that the date on the first stanza is from when the initial package was prepared, and hasn't been updated in line with later backporting. With that in mind, please go ahead. Regards, Adam
Processed: Re: Bug#784944: jessie-pu: package redmine/3.0~20140825-8~deb8u1 (was 3.0~20140825-7~deb8u1)
Processing control commands: > tags -1 + confirmed Bug #784944 [release.debian.org] jessie-pu: package redmine/3.0~20140825-7~deb8u1 Added tag(s) confirmed. -- 784944: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784944 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
8.3 planning
Hi, We're a tad overdue for the 8.3 point release and with the holiday period coming up, getting one done in December looks like a bit of a push. On that basis, looking at January we have: 2nd/3rd - depends how much people are still suffering. :-) 9th/10th 16th/17th 23rd/24th - likely to be bad for me Regards, Adam
Re: 8.3 planning
Adam D. Barratt (2015-12-04): > 2nd/3rd - depends how much people are still suffering. :-) I'd rather avoid this one, but might be able to. > 9th/10th > 16th/17th > 23rd/24th - likely to be bad for me Any of those should work as far as d-i goes. Mraw, KiBi. signature.asc Description: Digital signature
Bug#650132: hint: binary to source mapping has unhelpful side-effects
On Sat, 2011-11-26 at 20:38 +, Adam D. Barratt wrote: > hint's automagic binary to source mapping has unintended and undesired > side-effects in some circumstances. The situation where issues have > been noticed most is with "hint clean" and renamed source packages, but > it will likely manifest in other cases. [...] > I haven't found an easy way of resolving this yet, so am filing this in > the BTS so that the issue is documented and in case anyone else has any > thoughts. After another of my periodic pokes at this, the main problem is that I can't see an easy way of fixing it without bending the encapsulation. "clean" uses the HintFileParagraph class to represent the lines it has read from the hint file, which in turn instantiates a number of Hint objects. The Hint class's constructor then parses the package list, including performing the binary to source mappings. By this point, the knowledge of which subcommand of "hint" was used is well and truly invisible. We could extend the Hint class to take keyword arguments so that the package mapping could be disabled when required, but this would then somehow need to be communicated via HintFileParagraph, which feels a little dirty. Admittedly, the HintFileParagraph is only used by the clean action, so we could simply say that the class will not modify its input, and thus have it pass a "don't do binary to source mappings" flag to the Hint class. Thoughts welcome, before I either decide that the above is a silly idea, or just do it. :-) Regards, Adam
Re: 8.3 planning
On Fri, Dec 04, 2015 at 05:43:54PM +, Adam Barratt wrote: >Hi, > >We're a tad overdue for the 8.3 point release and with the holiday >period coming up, getting one done in December looks like a bit of a >push. > >On that basis, looking at January we have: > >2nd/3rd - depends how much people are still suffering. :-) No chance for me that weekend - I've got plans already. >9th/10th >16th/17th >23rd/24th - likely to be bad for me All of these look OK so far. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshiped." -― Andy Weir, "The Martian"
Bug#650132: hint: binary to source mapping has unhelpful side-effects
Control: tags -1 + patch
On Fri, 2015-12-04 at 18:09 +, Adam D. Barratt wrote:
> On Sat, 2011-11-26 at 20:38 +, Adam D. Barratt wrote:
> > hint's automagic binary to source mapping has unintended and undesired
> > side-effects in some circumstances. The situation where issues have
> > been noticed most is with "hint clean" and renamed source packages, but
> > it will likely manifest in other cases.
> [...]
> > I haven't found an easy way of resolving this yet, so am filing this in
> > the BTS so that the issue is documented and in case anyone else has any
> > thoughts.
>
> After another of my periodic pokes at this, the main problem is that I
> can't see an easy way of fixing it without bending the encapsulation.
>
> "clean" uses the HintFileParagraph class to represent the lines it has
> read from the hint file, which in turn instantiates a number of Hint
> objects. The Hint class's constructor then parses the package list,
> including performing the binary to source mappings. By this point, the
> knowledge of which subcommand of "hint" was used is well and truly
> invisible.
>
> We could extend the Hint class to take keyword arguments so that the
> package mapping could be disabled when required, but this would then
> somehow need to be communicated via HintFileParagraph, which feels a
> little dirty.
>
> Admittedly, the HintFileParagraph is only used by the clean action, so
> we could simply say that the class will not modify its input, and thus
> have it pass a "don't do binary to source mappings" flag to the Hint
> class.
>
> Thoughts welcome, before I either decide that the above is a silly idea,
> or just do it. :-)
fwiw, here's a patch that does that.
The second "don't update" hunk also changes the behaviour in another way
- currently, if you have a hint for foo and foo is then removed from
unstable, a subsequent "hint clean" will drop the hint; after my update,
that will no longer happen. However, I think this is actually better,
for two reasons:
- currently "easy foo" would simply be replaced by "# No packages left
in hint", which isn't particularly helpful
- "easy foo bar" will be replaced by "easy bar", with no indication that
the hint has been changed. I don't think "clean" should make changes
like that.
Regards,
Adam
diff --git a/scripts/hint b/scripts/hint
index 9d38274..3b3b1ee 100755
--- a/scripts/hint
+++ b/scripts/hint
@@ -513,9 +513,11 @@ class Hint(object):
##
-def __init__(self, hintname, *args):
+def __init__(self, hintname, *args, **kwargs):
starts_with_letter = re.compile(r'(?i)^[a-z]')
+self.kwargs = kwargs
+
self.name = hintname
self.pkgs = []
@@ -562,7 +564,8 @@ class Hint(object):
suite = self.SOURCE_DISTRIBUTION
except AttributeError:
suite = 'unstable'
-if not projectb.is_source_pkg(suite, src):
+if not projectb.is_source_pkg(suite, src) and \
+ ('noupdate' not in kwargs or kwargs['noupdate'] != 1):
tmpsrc = src
src = projectb.get_source_pkg(suite, src)
if src is None:
@@ -634,7 +637,7 @@ class Hint(object):
words = [ ]
return ' '.join(words)
-def __new__(cls, hintname, *args):
+def __new__(cls, hintname, *args, **kwargs):
if hintname in \
[ 'easy', 'hint', 'force', 'force-hint', 'unblock', 'urgent', 'unblock-udeb' ]:
subclass = UnstableToTestingHint
@@ -685,8 +688,8 @@ class UnversionedHint(Hint):
class MigrationHint(Hint):
"""A hint whose packages are meant to move from one distribution to another."""
-def __init__(self, *args):
-Hint.__init__(self, *args)
+def __init__(self, *args, **kwargs):
+Hint.__init__(self, *args, **kwargs)
self._versions = None
@property
@@ -699,12 +702,13 @@ class MigrationHint(Hint):
'target': get_version_numbers(self.TARGET_DISTRIBUTION, self.pkgs),
}
-for pkg, ver in self._versions['source'].items():
-if ver is None and pkg not in self.remove_pkgs:
-print >>sys.stderr, (
-'W: package %s not in %s, skipping.'
-% (pkg, self.SOURCE_DISTRIBUTION))
-self.pkgs.remove(pkg)
+if 'noupdate' not in self.kwargs or self.kwargs['noupdate'] != 1:
+for pkg, ver in self._versions['source'].items():
+if ver is None and pkg not in self.remove_pkgs:
+print >>sys.stderr, (
+'W: package %s not in %s, skipping.'
+% (pkg, self.SOURCE_DISTRIBUTION))
+self.pkgs.remove(pkg)
return self._versions
@@ -783,8 +787,8 @@ class TpuToTestingHint(MigrationHint):
class AgeDaysHint(UnstableToTestingHint):
-def __init__(self, hintname, days, *args):
-UnstableToTestingHint.__init__(self, '%s %s'
Processed: Re: Bug#650132: hint: binary to source mapping has unhelpful side-effects
Processing control commands: > tags -1 + patch Bug #650132 [release.debian.org] hint: binary to source mapping has unhelpful side-effects Added tag(s) patch. -- 650132: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650132 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#804381: jessie-pu: package s390-dasd/0.0.32~deb8u1
Processing control commands: > tags -1 + pending Bug #804381 [release.debian.org] jessie-pu: package s390-dasd/0.0.32~deb8u1 Added tag(s) pending. -- 804381: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804381 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#804381: jessie-pu: package s390-dasd/0.0.32~deb8u1
Control: tags -1 + pending
On Sat, 2015-11-21 at 17:47 +0100, Julien Cristau wrote:
> Control: tag -1 confirmed
>
> On Sat, Nov 7, 2015 at 22:57:06 +0100, Philipp Kern wrote:
>
> > 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.
> >
> Seems ok to me.
Uploaded and flagged for acceptance.
Regards,
Adam
Processed: Re: Bug#804383: jessie-pu: package libinfinity/0.6.7-1~deb8u1
Processing control commands: > tags -1 + pending Bug #804383 [release.debian.org] jessie-pu: package libinfinity/0.6.7-1~deb8u1 Added tag(s) pending. -- 804383: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804383 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#804383: jessie-pu: package libinfinity/0.6.7-1~deb8u1
Control: tags -1 + pending On Sat, 2015-11-21 at 18:03 +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sat, 2015-11-07 at 23:29 +0100, Philipp Kern wrote: > > 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. > > Please go ahead. Uploaded and flagged for acceptance. Regards, Adam
NEW changes in stable-new
Processing changes file: cups-filters_1.0.61-5+deb8u2_amd64.changes ACCEPT Processing changes file: cups-filters_1.0.61-5+deb8u2_arm64.changes ACCEPT Processing changes file: cups-filters_1.0.61-5+deb8u2_armel.changes ACCEPT Processing changes file: cups-filters_1.0.61-5+deb8u2_armhf.changes ACCEPT Processing changes file: cups-filters_1.0.61-5+deb8u2_i386.changes ACCEPT Processing changes file: cups-filters_1.0.61-5+deb8u2_mips.changes ACCEPT Processing changes file: cups-filters_1.0.61-5+deb8u2_mipsel.changes ACCEPT Processing changes file: cups-filters_1.0.61-5+deb8u2_powerpc.changes ACCEPT Processing changes file: cups-filters_1.0.61-5+deb8u2_ppc64el.changes ACCEPT Processing changes file: cups-filters_1.0.61-5+deb8u2_s390x.changes ACCEPT Processing changes file: libinfinity_0.6.7-1~deb8u1_amd64.changes ACCEPT Processing changes file: openssl_1.0.1k-3+deb8u2_amd64.changes ACCEPT Processing changes file: openssl_1.0.1k-3+deb8u2_arm64.changes ACCEPT Processing changes file: openssl_1.0.1k-3+deb8u2_armel.changes ACCEPT Processing changes file: openssl_1.0.1k-3+deb8u2_armhf.changes ACCEPT Processing changes file: openssl_1.0.1k-3+deb8u2_i386.changes ACCEPT Processing changes file: openssl_1.0.1k-3+deb8u2_mips.changes ACCEPT Processing changes file: openssl_1.0.1k-3+deb8u2_mipsel.changes ACCEPT Processing changes file: openssl_1.0.1k-3+deb8u2_powerpc.changes ACCEPT Processing changes file: openssl_1.0.1k-3+deb8u2_ppc64el.changes ACCEPT Processing changes file: openssl_1.0.1k-3+deb8u2_s390x.changes ACCEPT Processing changes file: putty_0.63-10+deb8u1_amd64.changes ACCEPT Processing changes file: putty_0.63-10+deb8u1_arm64.changes ACCEPT Processing changes file: putty_0.63-10+deb8u1_armel.changes ACCEPT Processing changes file: putty_0.63-10+deb8u1_armhf.changes ACCEPT Processing changes file: putty_0.63-10+deb8u1_i386.changes ACCEPT Processing changes file: putty_0.63-10+deb8u1_mips.changes ACCEPT Processing changes file: putty_0.63-10+deb8u1_mipsel.changes ACCEPT Processing changes file: putty_0.63-10+deb8u1_powerpc.changes ACCEPT Processing changes file: putty_0.63-10+deb8u1_ppc64el.changes ACCEPT Processing changes file: putty_0.63-10+deb8u1_s390x.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u3_allonly.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u3_amd64.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u3_arm64.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u3_armel.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u3_armhf.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u3_i386.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u3_mips.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u3_mipsel.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u3_powerpc.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u3_ppc64el.changes ACCEPT Processing changes file: redis_2.8.17-1+deb8u3_s390x.changes ACCEPT Processing changes file: s390-dasd_0.0.32~deb8u1_s390x.changes ACCEPT
Re: Updating ca-certificates through stable-updates
On 11/25/2015 03:18 PM, Andrew Ayer wrote: > Hi Stable Release Managers, > > We're currently discussing in #806239 how to keep the > ca-certificates package more up-to-date in (old)stable. Since > ca-certificates is a data package that needs timely updating (when CAs > are removed due to lapsed audits, they should be distrusted > immediately), it satisfies the criteria for stable-updates posted here: > > https://www.debian.org/News/2011/20110215 > > I just wanted to confirm that the SRMs would be OK pushing out new > ca-certificates packages through stable-updates. Hi release team, I just requested an upload of ca-certificates (20151204) to unstable, and I would like to follow that up with stable-pu and oldstable-pu updates to include the current Mozilla CA bundle changes for jessie and wheezy. I appears that I did a wheezy-pu update last year on #743156, but wanted to clarify if these upcoming uploads will be acceptable. -- Thank you! Michael
NEW changes in stable-new
Processing changes file: libinfinity_0.6.7-1~deb8u1_arm64.changes ACCEPT Processing changes file: libinfinity_0.6.7-1~deb8u1_armel.changes ACCEPT Processing changes file: libinfinity_0.6.7-1~deb8u1_armhf.changes ACCEPT Processing changes file: libinfinity_0.6.7-1~deb8u1_i386.changes ACCEPT Processing changes file: libinfinity_0.6.7-1~deb8u1_mips.changes ACCEPT Processing changes file: libinfinity_0.6.7-1~deb8u1_powerpc.changes ACCEPT Processing changes file: libinfinity_0.6.7-1~deb8u1_ppc64el.changes ACCEPT Processing changes file: libinfinity_0.6.7-1~deb8u1_s390x.changes ACCEPT
NEW changes in stable-new
Processing changes file: libinfinity_0.6.7-1~deb8u1_mipsel.changes ACCEPT
Re: Updating ca-certificates through stable-updates
Michael Shuler: > On 11/25/2015 03:18 PM, Andrew Ayer wrote: >> Hi Stable Release Managers, >> >> We're currently discussing in #806239 how to keep the >> ca-certificates package more up-to-date in (old)stable. Since >> ca-certificates is a data package that needs timely updating (when CAs >> are removed due to lapsed audits, they should be distrusted >> immediately), it satisfies the criteria for stable-updates posted here: >> >> https://www.debian.org/News/2011/20110215 >> >> I just wanted to confirm that the SRMs would be OK pushing out new >> ca-certificates packages through stable-updates. > > Hi release team, > > I just requested an upload of ca-certificates (20151204) to unstable, > and I would like to follow that up with stable-pu and oldstable-pu > updates to include the current Mozilla CA bundle changes for jessie and > wheezy. > > I appears that I did a wheezy-pu update last year on #743156, but wanted > to clarify if these upcoming uploads will be acceptable. > Hi, Thanks for the interest in patching ca-certificates in the stable releases. 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. Thanks, ~Niels signature.asc Description: OpenPGP digital signature
