Processed: Re: Bug#706798: where is OpenSceneGraph 3.2 status?
Processing commands for cont...@bugs.debian.org: > block 706798 by 725385 Bug #706798 [release.debian.org] transition: Libav 9 706798 was blocked by: 713354 722610 720828 720801 721544 694299 720779 720785 721025 720727 723099 692505 720820 720796 693639 693641 720668 721577 692809 720790 720826 720799 720797 692980 720816 721026 677959 722486 693106 713276 722493 720823 725071 720809 693560 720783 720808 720805 720661 720810 720824 723803 721164 720802 721493 706798 was blocking: 716735 Added blocking bug(s) of 706798: 725385 > thanks Stopping processing here. Please contact me if you need assistance. -- 706798: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706798 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.138092384114416.transcr...@bugs.debian.org
Bug#706798: where is OpenSceneGraph 3.2 status?
block 706798 by 725385 thanks On 04/10/13 21:35, Steven Chamberlain wrote: > On 04/10/13 19:16, Rebecca N. Palmer wrote: >>> spek [on s390x], >> This build failure looks like a bash crash, not an error in spek itself. >> Try again?? > > Still the same on a different buildd, unfortunately: > https://buildd.debian.org/status/logs.php?pkg=spek&ver=0.8.2-3&arch=s390x That is now bug #725385. Aurelien provided a backtrace possibly implicating libav... On 04/10/13 12:18, Steven Chamberlain wrote: > On 04/10/13 09:32, Rebecca N. Palmer wrote: >> * #719376 osgearth fixed in 2.4, but this is held in unstable because an >> unrelated upstream fix makes it non-kFreeBSD >> (https://github.com/gwaldron/osgearth/commit/a270f5f0e2c3d56f5d528db17873dc37c52a6655 >> ; SYS_gettid doesn't exist there) > > That's definitely not portable code, I'll look into that one. That is now bug #725383. It is not directly blocking the libav9 transition though. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/524f39bc.1090...@pyro.eu.org
Bug#725381: pu: package sage-extension/1.4.12-3+deb7u1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Managers,
Please find attached a proposed update for sage-extension, which fixes #724531.
(compatibility issue with Iceweasel 17). Note that the updated package has been
also tested against Iceweasel 10, so that partial upgrades are also supported.
Cheers,
--
.''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://www.dynare.org/sebastien
`- GPG Key: 4096R/381A7594
diff -Nru sage-extension-1.4.12/debian/changelog sage-extension-1.4.12/debian/changelog
--- sage-extension-1.4.12/debian/changelog 2011-12-26 23:42:49.0 +
+++ sage-extension-1.4.12/debian/changelog 2013-10-04 13:02:57.0 +
@@ -1,3 +1,11 @@
+sage-extension (1.4.12-3+deb7u1) wheezy; urgency=low
+
+ * Non-maintainer upload.
+ * checkLoadURI.patch: new patch for compatibility with Iceweasel 17,
+ensures that links in the main window are clickable. (Closes: #724531)
+
+ -- Sébastien Villemot Fri, 04 Oct 2013 15:02:51 +0200
+
sage-extension (1.4.12-3) unstable; urgency=low
* debian/patches/bump_max_version.patch:
diff -Nru sage-extension-1.4.12/debian/patches/checkLoadURI.patch sage-extension-1.4.12/debian/patches/checkLoadURI.patch
--- sage-extension-1.4.12/debian/patches/checkLoadURI.patch 1970-01-01 00:00:00.0 +
+++ sage-extension-1.4.12/debian/patches/checkLoadURI.patch 2013-09-04 18:37:21.0 +
@@ -0,0 +1,17 @@
+commit 20c9039e642ebb7338262aabf8b929794e1db8e3
+Author: Peter Andrews
+Date: Tue Oct 16 18:33:26 2012 -0700
+
+checkLoadURI no longer supported in Firefox 17
+
+--- a/chrome/sage.jar!/content/feedsummary.js
b/chrome/sage.jar!/content/feedsummary.js
+@@ -483,7 +483,7 @@
+ try {
+ feedURI = ios.newURI(this.uri, null, null);
+ attrURI = ios.newURI(uri, null, null);
+- secman.checkLoadURI(feedURI, attrURI, flags);
++ secman.checkLoadURIWithPrincipal((secman.getSimpleCodebasePrincipal || secman.getCodebasePrincipal)(feedURI), attrURI, flags); // getCodebasePrincipal renamed in Firefox 17
+ element.setAttribute(attribute, attrURI.spec);
+ } catch (e) { }
+ },
diff -Nru sage-extension-1.4.12/debian/patches/series sage-extension-1.4.12/debian/patches/series
--- sage-extension-1.4.12/debian/patches/series 2011-12-26 23:36:30.0 +
+++ sage-extension-1.4.12/debian/patches/series 2013-09-04 18:36:19.0 +
@@ -1,2 +1,3 @@
disable_encoded_content.patch
bump_max_version.patch
+checkLoadURI.patch
signature.asc
Description: Digital signature
Bug#706798: where is OpenSceneGraph 3.2 status?
On 04/10/13 19:16, Rebecca N. Palmer wrote: >> spek [on s390x], > This build failure looks like a bash crash, not an error in spek itself. > Try again?? Still the same on a different buildd, unfortunately: https://buildd.debian.org/status/logs.php?pkg=spek&ver=0.8.2-3&arch=s390x Note that only part of output from the (C++ compiled) test program is shown, before the crash. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/524f2692.9080...@pyro.eu.org
Bug#706798: openscenegraph tracker and transition scenario
Hi all, I don't know much but have been following the libav9 transition. For the openscenegraph talk shouldn't there have been the mail CC'ing the maintainer as well. At the very least, this discussion needed to be shared with him and I have cc'ed him in this mail. Looking forward to a successful transition of libav9 to testing. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- 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/CADdDZRkdD9qfOiFgNK+BJ7WQ-Zp=ajtyxchwdnv-4+2lpwv...@mail.gmail.com
Bug#725311: pu: Getting Debian Edu 7.1+edu0 into the Upcoming stable point release (7.2)
Hi, On Freitag, 4. Oktober 2013, Adam D. Barratt wrote: > > So to be (crystal) clear: we should reupload slbackup with those > > NACKed > > changes removed?! > I'm arguing with myself a little over that one, in the "should we just > cover it under 'only -edu probably use it'" general sort of area. :-) I'm curious for the result of this arguing! :) > > Ok, changelog diff attached. For all 7 packages combined. > What's happening with education-task-lxde and chmsee? I noticed that's > not in the proposed d-e changelog. You send the mail about chmsee the day after we released Debian Edu Wheezy and these changes are only those, thats why. I've removed the chmsee recommends in svn, but that change hasn't been uploaded yet. And as it's recommends it doesnt really matter anyway, though obviously I'd be happy to upload a changed package still. Which brings me back to my initial question whether we should reupload these packages to wheezy(-proposed updates) with ~deb7u1 added to the version number? cheers, Holger signature.asc Description: This is a digitally signed message part.
NEW changes in stable-new
Processing changes file: iceweasel_17.0.6esr-1~deb7u1_amd64.changes ACCEPT Processing changes file: iceweasel_17.0.6esr-1~deb7u1_armhf.changes ACCEPT Processing changes file: iceweasel_17.0.6esr-1~deb7u1_i386.changes ACCEPT Processing changes file: iceweasel_17.0.6esr-1~deb7u1_mips.changes ACCEPT Processing changes file: iceweasel_17.0.6esr-1~deb7u1_powerpc.changes ACCEPT Processing changes file: iceweasel_17.0.6esr-1~deb7u1_s390.changes ACCEPT Processing changes file: iceweasel_17.0.6esr-1~deb7u1_s390x.changes ACCEPT Processing changes file: iceweasel_17.0.9esr-1~deb7u1_amd64.changes ACCEPT Processing changes file: iceweasel_17.0.9esr-1~deb7u1_armel.changes ACCEPT Processing changes file: iceweasel_17.0.9esr-1~deb7u1_armhf.changes ACCEPT Processing changes file: iceweasel_17.0.9esr-1~deb7u1_i386.changes ACCEPT Processing changes file: iceweasel_17.0.9esr-1~deb7u1_ia64.changes ACCEPT Processing changes file: iceweasel_17.0.9esr-1~deb7u1_kfreebsd-amd64.changes ACCEPT Processing changes file: iceweasel_17.0.9esr-1~deb7u1_kfreebsd-i386.changes ACCEPT Processing changes file: iceweasel_17.0.9esr-1~deb7u1_mips.changes ACCEPT Processing changes file: iceweasel_17.0.9esr-1~deb7u1_mipsel.changes ACCEPT Processing changes file: iceweasel_17.0.9esr-1~deb7u1_powerpc.changes ACCEPT Processing changes file: iceweasel_17.0.9esr-1~deb7u1_s390.changes ACCEPT Processing changes file: iceweasel_17.0.9esr-1~deb7u1_s390x.changes ACCEPT Processing changes file: iceweasel_17.0.9esr-1~deb7u1_sparc.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-2~deb7u1_amd64.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-2~deb7u1_armel.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-2~deb7u1_armhf.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-2~deb7u1_i386.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-2~deb7u1_ia64.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-2~deb7u1_kfreebsd-amd64.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-2~deb7u1_kfreebsd-i386.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-2~deb7u1_mips.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-2~deb7u1_mipsel.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-2~deb7u1_powerpc.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-2~deb7u1_s390.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-2~deb7u1_s390x.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-2~deb7u1_sparc.changes ACCEPT Processing changes file: iceweasel_17.0.7esr-1~deb7u1_amd64.changes ACCEPT Processing changes file: iceweasel_17.0.7esr-1~deb7u1_armhf.changes ACCEPT Processing changes file: iceweasel_17.0.7esr-1~deb7u1_i386.changes ACCEPT Processing changes file: iceweasel_17.0.7esr-1~deb7u1_kfreebsd-amd64.changes ACCEPT Processing changes file: iceweasel_17.0.7esr-1~deb7u1_kfreebsd-i386.changes ACCEPT Processing changes file: iceweasel_17.0.7esr-1~deb7u1_mips.changes ACCEPT Processing changes file: iceweasel_17.0.7esr-1~deb7u1_powerpc.changes ACCEPT Processing changes file: iceweasel_17.0.7esr-1~deb7u1_s390.changes ACCEPT Processing changes file: iceweasel_17.0.7esr-1~deb7u1_s390x.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-1~deb7u1_amd64.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-1~deb7u1_armel.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-1~deb7u1_armhf.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-1~deb7u1_i386.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-1~deb7u1_kfreebsd-amd64.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-1~deb7u1_kfreebsd-i386.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-1~deb7u1_mipsel.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-1~deb7u1_powerpc.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-1~deb7u1_s390.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-1~deb7u1_s390x.changes ACCEPT Processing changes file: iceweasel_17.0.8esr-1~deb7u1_sparc.changes ACCEPT -- 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/e1vsanm-0001dk...@franck.debian.org
Bug#717852: pu: package devscripts/2.12.6+deb7u1
On Thu, Oct 03, 2013 at 07:05:46PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Fri, 2013-07-26 at 16:59 +0200, Moritz Muehlenhoff wrote: > > On Thu, Jul 25, 2013 at 05:18:02PM +0100, Adam D. Barratt wrote: > > >> diff -Nru devscripts-2.12.6/scripts/build-rdeps.pl > > > [...] > > >> -my $release_pattern = '(.*_dists_(sid|unstable))_(?:In)*Release$'; > > >> +my $release_pattern = '(.*_dists_(wheezy|stable))_(?:In)*Release$'; > > > > > > Hmmm, what are the chances that users on stable might want to derive the > > > information for unstable in any case? > > > > Fairly negligable, but > > > > | my $release_pattern = > > '(.*_dists_(sid|unstable|wheezy|stable))_(?:In)*Release$'; > > > > makes a Wheezy system with a deb-sec for unstable work as well. I upload > > that > > as well. > > Apologies for the delay in getting back to you. > > Looking closer I realised that build-rdeps has a --distribution option, > so feel free to go ahead with the original patch. Thanks, just uploaded. Cheers, Moritz -- 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/20131004190641.GA5502@pisco.westfalen.local
Processed: Re: Bug#725370: pu: package xinetd/1:2.3.14-7.1
Processing control commands: > tags -1 + wheezy Bug #725370 [release.debian.org] pu: package xinetd/1:2.3.14-7.1 Added tag(s) wheezy. -- 725370: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725370 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.b725370.13809133782.transcr...@bugs.debian.org
Bug#725370: pu: package xinetd/1:2.3.14-7.1
Control: tags -1 + wheezy On Fri, 2013-10-04 at 20:37 +0200, Salvo Tomaselli wrote: > I'd like to propose an upgrade of xinetd. > > There is a security bug, not so severe CVE-2013-4342 > handled in #324678 > However the bug is closed only in unstable. The version in stable is > different, so the patch needs to be applied to that version too. > > The patch is quite trivial, I attach the one I used in unstable, the one > needed in stable needs to be applied to a different line. The patch looks okay, but I'd prefer to see a debdiff against the stable package before giving a final ack (preferably versioned as 1:2.3.14-7.1 +deb7u1, or I guess 1:2.3.14-8 if that has never previously been used and you'd prefer). Were you planning on fixing the issue in squeeze as well? Regards, Adam -- 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/1380913101.9262.19.ca...@jacala.jungle.funky-badger.org
Bug#725370: pu: package xinetd/1:2.3.14-7.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu
Hello,
I'd like to propose an upgrade of xinetd.
There is a security bug, not so severe CVE-2013-4342
handled in #324678
However the bug is closed only in unstable. The version in stable is
different, so the patch needs to be applied to that version too.
The patch is quite trivial, I attach the one I used in unstable, the one
needed in stable needs to be applied to a different line.
Do you think it is a good idea to upgrade it?
If you agree, Salvatore Bonaccorso offered himself to sponsor the upload.
Bye
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11.2a (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Description: can set uid for tcpmux
This patch fixes CVE-2013-4342, by allowing TCPMUX to be used
under a different user.
Origin: other, https://github.com/xinetd-org/xinetd/pull/10/files
Reviewed-By: Salvo 'LtWorf' Tomaselli
.
xinetd (1:2.3.15-2) unstable; urgency=high
.
* Fix CVE-2013-4342 making TCPMUX services change the uid.
(Closes: #324678)
Author: https://github.com/octurite
Bug-Debian: http://bugs.debian.org/324678
Last-Update: 2013-10-03
--- xinetd-2.3.15.orig/xinetd/builtins.c
+++ xinetd-2.3.15/xinetd/builtins.c
@@ -617,7 +617,7 @@ static void tcpmux_handler( const struct
if( SC_IS_INTERNAL( scp ) ) {
SC_INTERNAL(scp, nserp);
} else {
- exec_server(nserp);
+ child_process(nserp);
}
}
Bug#725311: pu: Getting Debian Edu 7.1+edu0 into the Upcoming stable point release (7.2)
On Fri, 2013-10-04 at 17:58 +0200, Holger Levsen wrote: > On Freitag, 4. Oktober 2013, Adam D. Barratt wrote: > > I think at least the changelogs from the -edu-* packages would be > > helpful; they'd add some context to the diffstats. Full debdiffs will be > > too large to reach the list, although I suspect a chunk of the size is > > filterable (e.g. the removal of a .svg file and addition of another, > > documentation-only changes, etc). > > Ok, changelog diff attached. For all 7 packages combined. What's happening with education-task-lxde and chmsee? I noticed that's not in the proposed d-e changelog. Regards, Adam -- 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/1380910460.9262.13.ca...@jacala.jungle.funky-badger.org
Bug#706798: where is OpenSceneGraph 3.2 status?
It doesn't look to me that a transition was coordinated for openscenegraph? Exactly my point: it's a transition in the sense of "API-breaking change", but not one with an official tracker. (possibly temporary) [openscenegraph] build issue on mips, That *is* #720816 (and hence should go away in 3.2.0): mips built libav9 before openscenegraph. dvswitch, Fix in delayed queue (#720783). vxl [on ia64]. Should be fixable by removing --as-needed, as suggested above. spek [on s390x], This build failure looks like a bash crash, not an error in spek itself. Try again?? opencv Fixed in 2.4, but that breaks frei0r and sikuli (http://release.debian.org/transitions/html/opencv2.4.html). frei0r (#724186) looks like a build script bug, sikuli probably just needs to be built somewhere with a working jython (which sid currently isn't due to another unofficial transition, #724713: try to fix that, or use testing-proposed-updates as in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712615#45 ?). yorick-av, #722610. Sorry, no fix yet... * #719376 osgearth * #718381 / #719388 openwalnut -- 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/524f05f0.1000...@bham.ac.uk
Bug#723793: Bug#723587: release.debian.org: Non-free file in PyOpenCL - new version upload to stable and oldstable
Dnia 2013-10-02, śro o godzinie 01:12 +0200, Cyril Brulebois pisze:
> Hi again Tomasz,
>
> Cyril Brulebois (2013-09-23):
> > The squeeze.diff one seems to have unrelated noise in patches,
> > presumably because something refreshed them while you were preparing
> > the diff? Having a targeted patched like the first one would be nice,
> > so please follow up to 723...@bugs.debian.org with a cleaner debdiff.
>
> kind reminder: o-p-u NEW freeze is less than 2 weeks from now. Fixing
> this issue in a later point release is of course perfectly OK, I just
> thought I'd give you a heads-up.
>
Thanks for the reminder.
I was aware of this, but other things, completely unrelated
to software worlds, took my time and energy.
I attach new patch with proposed changes. It only changes
changelog, debian/rules (removal of offending file)
and mentioned file.
Best regards.
--
Tomasz Rybak GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
diff -Nru pyopencl-0.92/debian/changelog pyopencl-0.92.dfsg/debian/changelog
--- pyopencl-0.92/debian/changelog 2010-11-11 23:10:57.0 +0100
+++ pyopencl-0.92.dfsg/debian/changelog 2013-10-04 18:00:49.0 +0200
@@ -1,3 +1,9 @@
+pyopencl (0.92.dfsg-1) oldstable; urgency=low
+
+ * Remove non-free file from examples (#722014, #723793).
+
+ -- Tomasz Rybak Fri, 04 Oct 2013 17:54:19 +0200
+
pyopencl (0.92-1) unstable; urgency=high
* New upstream release
diff -Nru pyopencl-0.92/debian/rules pyopencl-0.92.dfsg/debian/rules
--- pyopencl-0.92/debian/rules 2010-11-11 13:30:27.0 +0100
+++ pyopencl-0.92.dfsg/debian/rules 2013-10-04 18:00:49.0 +0200
@@ -36,6 +36,7 @@
git clone $(GIT_URL) $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION)
cd $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION) && git checkout $(GIT_REVISION)
rm -rf $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION)/.git $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION)/.gitignore $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION)/.gitmodules
+ rm -rf $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION)/examples/matrix-multiply.py
tar czf $(MODULE_NAME)_$(DEB_UPSTREAM_VERSION).orig.tar.gz $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION)
rm -rf $(MODULE_NAME)-$(DEB_UPSTREAM_VERSION)
diff -Nru pyopencl-0.92/examples/matrix-multiply.py pyopencl-0.92.dfsg/examples/matrix-multiply.py
--- pyopencl-0.92/examples/matrix-multiply.py 2010-10-21 19:10:19.0 +0200
+++ pyopencl-0.92.dfsg/examples/matrix-multiply.py 1970-01-01 01:00:00.0 +0100
@@ -1,241 +0,0 @@
-# example provided by Eilif Muller
-
-from __future__ import division
-
-KERNEL_CODE = """
-
-// Thread block size
-#define BLOCK_SIZE %(block_size)d
-
-// Matrix dimensions
-// (chosen as multiples of the thread block size for simplicity)
-#define WA %(w_a)d // Matrix A width
-#define HA %(h_a)d // Matrix A height
-#define WB %(w_b)d // Matrix B width
-#define HB WA // Matrix B height
-#define WC WB // Matrix C width
-#define HC HA // Matrix C height
-
-
-/*
- * Copyright 1993-2009 NVIDIA Corporation. All rights reserved.
- *
- * NVIDIA Corporation and its licensors retain all intellectual property and
- * proprietary rights in and to this software and related documentation.
- * Any use, reproduction, disclosure, or distribution of this software
- * and related documentation without an express license agreement from
- * NVIDIA Corporation is strictly prohibited.
- *
- * Please refer to the applicable NVIDIA end user license agreement (EULA)
- * associated with this source code for terms and conditions that govern
- * your use of this NVIDIA software.
- *
- */
-
-/* Matrix multiplication: C = A * B.
- * Device code.
- */
-
-#define AS(j, i) As[i + j * BLOCK_SIZE]
-#define BS(j, i) Bs[i + j * BLOCK_SIZE]
-
-
-//! Matrix multiplication on the device: C = A * B
-//! WA is A's width and WB is B's width
-
-__kernel __attribute__((reqd_work_group_size(BLOCK_SIZE,BLOCK_SIZE,1)))
-void
-matrixMul( __global float* C, __global float* A, __global float* B)
-{
-__local float As[BLOCK_SIZE*BLOCK_SIZE];
-__local float Bs[BLOCK_SIZE*BLOCK_SIZE];
-
-// Block index
-int bx = get_group_id(0);
-int by = get_group_id(1);
-
-// Thread index
-int tx = get_local_id(0);
-int ty = get_local_id(1);
-
-// Index of the first sub-matrix of A processed by the block
-int aBegin = WA * BLOCK_SIZE * by;
-
-// Index of the last sub-matrix of A processed by the block
-int aEnd = aBegin + WA - 1;
-
-// Step size used to iterate through the sub-matrices of A
-int aStep = BLOCK_SIZE;
-
-// Index of the first sub-matrix of B processed by the block
-int bBegin = BLOCK_SIZE * bx;
-
-// Step size used to iterate through the sub-matrices of B
-int bStep = BLOCK_SIZE * WB;
-
-// Csub is used to store the element of the block sub-matrix
Bug#725311: pu: Getting Debian Edu 7.1+edu0 into the Upcoming stable point release (7.2)
Hi, On 2013-10-04 16:58, Holger Levsen wrote: On Freitag, 4. Oktober 2013, Adam D. Barratt wrote: I think at least the changelogs from the -edu-* packages would be helpful; they'd add some context to the diffstats. Full debdiffs will be too large to reach the list, although I suspect a chunk of the size is filterable (e.g. the removal of a .svg file and addition of another, documentation-only changes, etc). Ok, changelog diff attached. For all 7 packages combined. At http://layer-acht.org/edu72/ you'll find the full debdiff for all 7 packages as well as http://layer-acht.org/edu72/fulldiff.tgz which contains these 7 files in a more convinient tar archive. Thanks. > I think so yes. Would a reupload with these changes dropped be more > acceptable? The perl4libs changes at least look fine. I guess most of the rest should be okay too, albeit a little noisy. So to be (crystal) clear: we should reupload slbackup with those NACKed changes removed?! I'm arguing with myself a little over that one, in the "should we just cover it under 'only -edu probably use it'" general sort of area. Regards, Adam -- 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/6c06697426c447468ad68988ef7e0...@mail.adsl.funky-badger.org
Bug#719966: pu: package openvrml/0.18.9-5+deb7u1
[openvrml maintainers added to CC] On 2013-09-23 4:38, Cyril Brulebois wrote: Control: tag -1 moreinfo wheezy Ansgar Burchardt (2013-08-17): I prepared an update for openvrml that disable JavaScript support as the package fails to build with newer versions of libmozjs-dev. As it might be used to view downloaded files, I think it should not use libmozjs185-dev which has broken sandboxing (as far as I understand). Note that this bug (#710616) is not fixed in unstable yet, but included in the suggested patch for #710082. I think this means we get to wait until it reaches unstable so that we get some feedback before considering it for stable? Hoping this is correct, tagging the bug report accordingly. Given the current state of the package in unstable, I'd be tempted to sugggest it should rather be a removal candidate. The highest popcon of any of the binary packages is less than 90, with the "recent" count only making it to 2, it has no reverse-dependencies and a four-month old RC bug with no follow-up (well, it's six months old, but it's only been RC for four of those). It looks like we'll be accepting the newer iceweasel packages from security for 7.2, so under the circumstances I'd be prepared to accept the direct fix so long as the remaining functionality of the package gets some testing before the point release (assuming the consensus is to fix rather than RM the package). If anyone has some insight in to how useful the package is once the Javascript support has been removed, that would be appreciated. Regards, Adam -- 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/6d4f11b464d617eaf054b21e0bba6...@mail.adsl.funky-badger.org
Bug#725311: pu: Getting Debian Edu 7.1+edu0 into the Upcoming stable point release (7.2)
On 2013-10-04 15:31, Holger Levsen wrote: On Freitag, 4. Oktober 2013, Adam D. Barratt wrote: > The complete debdiffs are attached. No, they're not. :-) (or the mail would probably never have made it to -release). shall I attach them to this bug? I think at least the changelogs from the -edu-* packages would be helpful; they'd add some context to the diffstats. Full debdiffs will be too large to reach the list, although I suspect a chunk of the size is filterable (e.g. the removal of a .svg file and addition of another, documentation-only changes, etc). [debian-edu-config-gosa-netgroups] Well, we've always nacked introducing new binary packages in the past. You mention that it was in squeeze, but I can't see the packages in the main archive (only for jessie / sid). hm, seems the archive is right and my memory is wrong. So we only had that package in our squeeze release and at that time in sid too... I'm not sure we really intended the "only affects -edu" exception to extend to new packages; thoughts from other team members welcome though. slbackup (0.0.12-4) experimental; urgency=low [...] * Change in conffile management: + Drop CRON job /etc/cron.daily/slbackup. Re-enable configuration of slbackup via debconf templates (closes: #662914). + Remove conffile /etc/cron.daily/slbackup via dpkg−maintscript−helper. Didn't the above change already get NACKed at least once? I think so yes. Would a reupload with these changes dropped be more acceptable? The perl4libs changes at least look fine. I guess most of the rest should be okay too, albeit a little noisy. Regards, Adam -- 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/63d99e7af5b318d55168a71304d40...@mail.adsl.funky-badger.org
Bug#725311: pu: Getting Debian Edu 7.1+edu0 into the Upcoming stable point release (7.2)
Hi Adam, On Freitag, 4. Oktober 2013, Adam D. Barratt wrote: > > The complete debdiffs are attached. > No, they're not. :-) (or the mail would probably never have made it to > -release). shall I attach them to this bug? [debian-edu-config-gosa-netgroups] > Well, we've always nacked introducing new binary packages in the past. > You mention that it was in squeeze, but I can't see the packages in the > main archive (only for jessie / sid). hm, seems the archive is right and my memory is wrong. So we only had that package in our squeeze release and at that time in sid too... > slbackup (0.0.12-4) experimental; urgency=low > [...] > * Change in conffile management: > + Drop CRON job /etc/cron.daily/slbackup. Re-enable configuration > of slbackup via debconf templates (closes: #662914). > + Remove conffile /etc/cron.daily/slbackup via dpkg−maintscript−helper. > Didn't the above change already get NACKed at least once? I think so yes. Would a reupload with these changes dropped be more acceptable? Also, I forgot to mention, while slbackup (and slbackup-php) are not in the debian-edu* namespace, in practice they are: the "sl" stands for "skolelinux" so thats just another case of not following up to an existing naming scheme... So, what shall we do with this? (#725311 as a whole...) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#723641: pu: package xen/4.1.4-5
On Wed, October 2, 2013 19:21, Bastian Blank wrote: > On Tue, Oct 01, 2013 at 04:58:43PM +0200, Thijs Kinkhorst wrote: >> On Mon, September 30, 2013 18:52, Bastian Blank wrote: >> > I don't think this will work. The current security process ignores >> > any communitation that is otherwise part of the NMU process. As long >> as >> > the security team does not have some policy to cummunicate first and >> do >> > later, especially if the maintainer is already in the loop or, worse, >> > did it herself, I see not why this should work now. >> I think you're confusing miscommunication that happened, with a policy >> of >> not communicating. > > Why are there no NMU diffs in the BTS as mandated by the developers > reference? Why do people prefer doing stuff themself instead of > communicating? > >> Something went wrong in the past, I don't know why, but there's >> definitely >> no process to ignore communication that should happen when working with >> other people's uploads. > > It happened with different people, I remember three. This is called a > pattern. Patterns leads to informal policies. Alright. I cannot easily verify the specific cases, but I think we can resolve that at least from now on, there's no intention nor informal policy to not communicate with people that are preparing uploads. And I think we could find many of your DD-collegues that communication indeed happened around the uploads they proposed. >> > My main problem are the missing mails on uploads. If the ftp-masters >> > refuses to accept a patch---did they?---you have to do it by human >> > relay. >> We definitely do this by human relay. We missed one, there. > > The person explicitely handling this case missed it also. It's a pity and shouldn't have happened. I will not say that communication will always be perfect and that no issues will be dropped. I hope all parties involved will remember the human factor, and that if they perceive a communication problem they proactively enquire, they ping the other party, even if the ball is not strictly 'in their court', to ensure it doesn't run out of hand. I think we can expect that from all contributours in our project. >> All in all, I recognise that mistakes have been made but I do not think >> that they are 'a policy' by the team. I'm confident that it's possible >> to >> work together in a way that works for both parties. Why not just give it >> a >> fresh new chance? > > Why do you ignore what I wrote in my original mail? This where the > three points: I thought I'd addressed it, but here we go. > | - Fix dak to send mails, at least to the uploader and signer. > > Should be a small patch to dak. Did noone try it or was it rejected? > If it was rejected, why was CTTE not involved? It is even listed as a > bug somewhere. I don't know all the history of this request, but have asked ftp-master what they would think of it, so we get a fresh idea of where we stand. > | - Push NMU-diffs to the BTS. > > This is a long-standing point. And I never got an answer why this is > not done. I'll discuss it in the team. Of course, the information is always available from the archive, so it's there now, but I agree that a NMU diff in the BTS makes things slightly easier on the maintainer. I left it out initially because I thought we were discussing issues where the maintainer was already involved, and in such issues, NMU diffs were not so relevant. I'll let you know the outcome of this. Cheers, Thijs -- 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/c6f733eecbcfa0eb42798f43b3b5c7a4.squir...@aphrodite.kinkhorst.nl
NEW changes in stable-new
Processing changes file: subversion_1.6.17dfsg-4+deb7u4_mips.changes ACCEPT -- 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/e1vs3nz-0002zk...@franck.debian.org
Bug#706798: where is OpenSceneGraph 3.2 status?
Hi, [not part of Release Team but hopefully I can answer your question] On 04/10/13 09:32, Rebecca N. Palmer wrote: > Is there a tracker for the OpenSceneGraph 3.2 transition (tied to this > one by #720816)? Status as far as I can find: It doesn't look to me that a transition was coordinated for openscenegraph? Status of openscenegraph's migration to testing is best shown by: http://packages.qa.debian.org/o/openscenegraph.html http://qa.debian.org/excuses.php?package=openscenegraph http://release.debian.org/migration/testing.pl?package=openscenegraph Blocking issues are #720816 which you already submitted a patch for, a (possibly temporary) build issue on mips, and the fact openscenegraph must be rebuilt anyway as part of the libav9 transition. And then the rest of the libav9 transition needs to complete: http://release.debian.org/transitions/html/libav9.html The 'hurd' column can be ignored, as well as rows marked 'sid only'. AIUI the packages at higher dependency levels (such as openscenegraph at level 3) tend to sometimes need packages at lower levels (higher in the list) to be rebuilt first. AFAIK blockers are dvswitch, opencv, spek [on s390x], yorick-av, and vxl [on ia64]. The BTS entry for #706798 notes these and some other things as blocking bugs. I don't see that #725071 in xine-lib-1.2 really blocks this as the kfreebsd binaries are already built against newer libav9; I submitted a patch for that anyway. > * #719402 fgrun (sid only) has patch > * #719376 osgearth fixed in 2.4, but this is held in unstable because an > unrelated upstream fix makes it non-kFreeBSD > (https://github.com/gwaldron/osgearth/commit/a270f5f0e2c3d56f5d528db17873dc37c52a6655 > ; SYS_gettid doesn't exist there) That's definitely not portable code, I'll look into that one. > * #718381 / #719388 openwalnut badly broken by 3.2, being worked on > upstream (latest upstream reported to build but not work properly, > http://www.openwalnut.org/issues/298) So these are all broken by openscenegraph going into sid? I don't think that will actually prevent openscenegraph from migrating to testing automatically. But perhaps a transition should have been requested for it and a tracker set up. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/524ea417.4010...@pyro.eu.org
NEW changes in stable-new
Processing changes file: telepathy-gabble_0.16.7-0+deb7u1_armel.changes ACCEPT -- 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/e1vs392-wo...@franck.debian.org
NEW changes in stable-new
Processing changes file: telepathy-gabble_0.16.7-0+deb7u1_powerpc.changes ACCEPT Processing changes file: ifmetric_0.3-2+deb7u1_mips.changes ACCEPT -- 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/e1vs1yu-0001nv...@franck.debian.org
Re: Bug#725171: libgs8: exports jpeg symbols, clashing with libjpeg
Hi Jonas, [Full quote for the benefit of -release] On 3 October 2013 04:15, Jonas Smedegaard wrote: > forcemerge 653061 725171 > tag 653061 help > thanks > > Hi Raphael, > > Quoting Raphael Geissert (2013-10-02 11:56:44) >> Debugging a crash when using evince to open an eps file, I came to >> realize that libgs is exporting some symbols that belong to libjpeg: >> jpeg_free_large >> jpeg_free_small >> jpeg_get_large >> jpeg_get_small >> jpeg_mem_available >> jpeg_mem_init >> jpeg_mem_term >> jpeg_open_backing_store >> >> As such, whenever evince opens an eps with a jpeg image it will result >> in a crash the moment libjpeg calls jpeg_get_small and ends up calling >> libgs' version and not its own... > > Already reported as bug#653061. Sorry this wasn't checked against the > older codebase, and you've had to struggle with it anew. > > Help needed to backport upstream fix for that bug to the older codebase. It appears that the patch[1] applies and works as-is, at least in my test case with evince. debian/symbols.common also needs to be adjusted, as the symbols were added to it. Now, question for the release team: would you be okay with going ahead and dropping the above symbols from libgs that were wrongly exported in the first place? in *squeeze*. I haven't checked what other binary links to both libjpeg and libgs and that could trigger this bug. [1]http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=ceef32 Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- 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/caa7hugfrxyycjomk5r6g5zjp3u9pbk0wfdukrbthpzotcjb...@mail.gmail.com
Bug#706798: where is OpenSceneGraph 3.2 status?
Is there a tracker for the OpenSceneGraph 3.2 transition (tied to this one by #720816)? Status as far as I can find: libcitygml, choreonoid, ossim, simgear (sid only), flightgear (sid only) _probably_ just need a rebuild (the libcitygml and choreonoid build failures should go away when non-rc1 3.2 arrives, which is needed anyway for #720816) #719402 fgrun (sid only) has patch #719376 osgearth fixed in 2.4, but this is held in unstable because an unrelated upstream fix makes it non-kFreeBSD (https://github.com/gwaldron/osgearth/commit/a270f5f0e2c3d56f5d528db17873dc37c52a6655 ; SYS_gettid doesn't exist there) #718381 / #719388 openwalnut badly broken by 3.2, being worked on upstream (latest upstream reported to build but not work properly, http://www.openwalnut.org/issues/298) -- 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/524e7d15.4010...@bham.ac.uk
NEW changes in stable-new
Processing changes file: subversion_1.6.17dfsg-4+deb7u4_armel.changes ACCEPT -- 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/e1vs06l-0004ze...@franck.debian.org
