Bug#706866: transition: libarchive
On Tue, May 21, 2013 at 11:13 AM, Julien Cristau wrote: > Control: tags -1 confirmed > > On Sun, May 5, 2013 at 11:49:54 -0400, Andres Mejia wrote: > >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: transition >> >> I am requesting a transition from libarchive12 to libarchive13. libarchive13 >> is from the latest release of libarchive (3.1.2). A soname bump was done >> upstream due to some ABI changes, specifically with HFS support. >> > Go ahead. Please let us know once it's installed on all archs. > > Cheers, > Julien I see the packages were built on the last two archs after retrying. The packages have been built on all archs now. -- ~ Andres -- 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/capm41nmunajourcklcsa6hqepql9vrfd4nbwrp-q5sc4ery...@mail.gmail.com
Fwd: Bug#706866: transition: libarchive
Hi, I see there's a tracker setup http://release.debian.org/transitions/html/libarchive13.html Now am I suppose to upload now, or is someone going to tell me when to upload? -- Forwarded message -- From: Andres Mejia Date: Sun, May 5, 2013 at 11:49 AM Subject: Bug#706866: transition: libarchive To: Debian Bug Tracking System Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I am requesting a transition from libarchive12 to libarchive13. libarchive13 is from the latest release of libarchive (3.1.2). A soname bump was done upstream due to some ABI changes, specifically with HFS support. Packages that need to be updated are tuxcmd-modules libtotem-plparser17 reprepro rdup libpackagekit-glib2-14 listaller-devtools listaller liblistaller-glib0 libgxps2 libgxps-utils libapache2-mod-musicindex hydrogen gvfs-backends libevdocument3-4 deb-gview cmake-qt-gui cmake-curses-gui cmake claws-mail-archiver-plugin ark archivemount libtotem-plparser-dev libgxps-dev Ben file: title = "libarchive"; is_affected = .depends ~ "libarchive12" | .depends ~ "libarchive13"; is_good = .depends ~ "libarchive13"; is_bad = .depends ~ "libarchive12"; -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- ~ Andres -- 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/CAPM41nPFvMfG5psdbUEaFuJRmt_i080KPV=t8mhubhxyi5l...@mail.gmail.com
Bug#706866: transition: libarchive
Oops, meant to reply all. On May 6, 2013 8:17 PM, "Andres Mejia" wrote: > Yes, I plan on disabling lrzip support for now. > On May 6, 2013 7:55 PM, "peter green" wrote: > >> >>> I am requesting a transition from libarchive12 to libarchive13. >>> libarchive13 >>> is from the latest release of libarchive (3.1.2). A soname bump was done >>> upstream due to some ABI changes, specifically with HFS support. >>> >>> >> I notice the most recent experimental upload FTBFS on many architectures >> with testsuite failures. Have you investigated how serious those failures >> are? Do you have plans for fixing them before uploading to sid? >> >
Bug#706866: transition: libarchive
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I am requesting a transition from libarchive12 to libarchive13. libarchive13 is from the latest release of libarchive (3.1.2). A soname bump was done upstream due to some ABI changes, specifically with HFS support. Packages that need to be updated are tuxcmd-modules libtotem-plparser17 reprepro rdup libpackagekit-glib2-14 listaller-devtools listaller liblistaller-glib0 libgxps2 libgxps-utils libapache2-mod-musicindex hydrogen gvfs-backends libevdocument3-4 deb-gview cmake-qt-gui cmake-curses-gui cmake claws-mail-archiver-plugin ark archivemount libtotem-plparser-dev libgxps-dev Ben file: title = "libarchive"; is_affected = .depends ~ "libarchive12" | .depends ~ "libarchive13"; is_good = .depends ~ "libarchive13"; is_bad = .depends ~ "libarchive12"; -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 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: http://lists.debian.org/20130505154954.26634.3826.report...@andres-laptop.home
Bug#702109: unblock: crystalhd/1:0.0~git20110715.fdd2f19-8
retitle 702109 unblock: crystalhd/1:0.0~git20110715.fdd2f19-9
stop
On Saturday, March 02, 2013 2:43:26 PM Adam D. Barratt wrote:
> As per our last d-d-a mail in January[1], release goal changes no longer
> qualify for unblocks.
>
> Regards,
>
> Adam
>
> [1] http://lists.debian.org/debian-devel-announce/2013/01/msg5.html
Ok, please unblock crystalhd/1:0.0~git20110715.fdd2f19-9.
This will only have the removal of the dkms package to
address bugs 682252 and 699470. Note the bug 682252
was marked a normal bug, but both were actually the
same bug and both were release critical.
Here is the debdiff from the current package in testing
to the new package in unstable.
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/changelog
crystalhd-0.0~git20110715.fdd2f19/debian/changelog
--- crystalhd-0.0~git20110715.fdd2f19/debian/changelog 2013-03-02
14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/changelog 2013-03-02
17:45:53.0 -0500
@@ -1,3 +1,23 @@
+crystalhd (1:0.0~git20110715.fdd2f19-9) unstable; urgency=high
+
+ * New package upload with just fixes to remove dkms package.
+ * Revert bump to Standards-Version 3.9.4.
+ * Revert build with hardening options to satisfy Wheezy release goal.
+
+ -- Andres Mejia Sat, 02 Mar 2013 17:43:59 -0500
+
+crystalhd (1:0.0~git20110715.fdd2f19-8) unstable; urgency=high
+
+ * Remove dkms package which contained buggy driver.
+Driver already existed in mainline kernel. Any issues with the driver
+should be directed to the kernel package.
+(Closes: #682252)
+(Closes: #699470)
+ * Bump to Standards-Version 3.9.4.
+ * Build with hardening options to satisfy Wheezy release goal.
+
+ -- Andres Mejia Sat, 02 Mar 2013 13:34:36 -0500
+
crystalhd (1:0.0~git20110715.fdd2f19-7) unstable; urgency=low
* Include udev rules for crystalhd-dkms.
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/control
crystalhd-0.0~git20110715.fdd2f19/debian/control
--- crystalhd-0.0~git20110715.fdd2f19/debian/control2013-03-02
14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/control2013-03-02
17:43:19.0 -0500
@@ -3,8 +3,7 @@
Maintainer: Andres Mejia
Build-Depends: debhelper (>= 8.1.3~),
libgstreamer0.10-dev,
- libgstreamer-plugins-base0.10-dev,
- dkms
+ libgstreamer-plugins-base0.10-dev
Standards-Version: 3.9.3
Section: libs
Homepage: http://www.broadcom.com/support/crystal_hd/
@@ -37,18 +36,6 @@
.
This package contains the shared library.
-Package: crystalhd-dkms
-Section: kernel
-Architecture: amd64 i386
-Depends: ${shlibs:Depends}, ${misc:Depends}, dkms
-Suggests: linux-headers
-Description: Crystal HD Video Decoder (Linux kernel driver)
- Crystal HD Solution is a product offered by Broadcom. It is used to enable
- flawless playback of 1080p high definition video across a wide range of
- systems.
- .
- This package contains the crystalhd Linux kernel driver.
-
Package: gstreamer0.10-crystalhd
Section: video
Architecture: amd64 i386
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.dkms
crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-
dkms.dkms
--- crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.dkms
2013-03-02 14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.dkms
1969-12-31 19:00:00.0 -0500
@@ -1,11 +0,0 @@
-# DKMS configuration for crystalhd
-
-PACKAGE_NAME="crystalhd"
-PACKAGE_VERSION="#MODULE_VERSION#"
-BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
-BUILT_MODULE_LOCATION[0]=driver/linux
-DEST_MODULE_LOCATION[0]="/updates/dkms/"
-AUTOINSTALL=yes
-
-MAKE[0]="cd driver/linux && ./configure && make"
-CLEAN="make -C driver/linux clean distclean"
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.install
crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-
dkms.install
--- crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.install
2013-03-02 14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.install
1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-usr/src
-lib/udev/rules.d
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/rules
crystalhd-0.0~git20110715.fdd2f19/debian/rules
--- crystalhd-0.0~git20110715.fdd2f19/debian/rules 2013-03-02
14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/rules 2013-03-02
17:43:52.0 -0500
@@ -1,8 +1,5 @@
#!/usr/bin/make -f
-UPSTREAM_VERSION = $(shell dpkg-parsechangelog | grep -G '^Version' | \
- cut -d ' ' -f 2 | sed 's/^[^:]:*//' | sed 's/-.*$$//')
-
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
EXTRA_INCLUDES = -I$(CURDIR)/include \
@@ -11,7 +8,7 @@
EXTRA_LD_PATH = -L$(CURDIR)/linux_lib/libcrystalhd
%:
-
Bug#702109: unblock: crystalhd/1:0.0~git20110715.fdd2f19-8
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package crystalhd
This new package release fixes two release critical bugs related to the
buggy driver that was distributed through a dkms package. Users of the driver
should instead use the crystalhd driver already provided in the mainline
kernel. This package also enables the hardening options which is a release
goal. This was missed in the last upload.
Finally, I did end up bumping the Standards-Version from 3.9.3 to 3.9.4.
I can place it back to 3.9.3, though there was no changes needed when
bumping the Standards-Version to 3.9.4.
Below is the debdiff.
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/changelog
crystalhd-0.0~git20110715.fdd2f19/debian/changelog
--- crystalhd-0.0~git20110715.fdd2f19/debian/changelog 2013-03-02
14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/changelog 2013-03-02
13:34:42.0 -0500
@@ -1,3 +1,15 @@
+crystalhd (1:0.0~git20110715.fdd2f19-8) unstable; urgency=high
+
+ * Remove dkms package which contained buggy driver.
+Driver already existed in mainline kernel. Any issues with the driver
+should be directed to the kernel package.
+(Closes: #682252)
+(Closes: #699470)
+ * Bump to Standards-Version 3.9.4.
+ * Build with hardening options to satisfy Wheezy release goal.
+
+ -- Andres Mejia Sat, 02 Mar 2013 13:34:36 -0500
+
crystalhd (1:0.0~git20110715.fdd2f19-7) unstable; urgency=low
* Include udev rules for crystalhd-dkms.
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/control
crystalhd-0.0~git20110715.fdd2f19/debian/control
--- crystalhd-0.0~git20110715.fdd2f19/debian/control 2013-03-02
14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/control 2013-03-02
13:01:17.0 -0500
@@ -3,9 +3,8 @@
Maintainer: Andres Mejia
Build-Depends: debhelper (>= 8.1.3~),
libgstreamer0.10-dev,
- libgstreamer-plugins-base0.10-dev,
- dkms
-Standards-Version: 3.9.3
+ libgstreamer-plugins-base0.10-dev
+Standards-Version: 3.9.4
Section: libs
Homepage: http://www.broadcom.com/support/crystal_hd/
Vcs-Git: git://git.debian.org/git/collab-maint/crystalhd.git
@@ -37,18 +36,6 @@
.
This package contains the shared library.
-Package: crystalhd-dkms
-Section: kernel
-Architecture: amd64 i386
-Depends: ${shlibs:Depends}, ${misc:Depends}, dkms
-Suggests: linux-headers
-Description: Crystal HD Video Decoder (Linux kernel driver)
- Crystal HD Solution is a product offered by Broadcom. It is used to enable
- flawless playback of 1080p high definition video across a wide range of
- systems.
- .
- This package contains the crystalhd Linux kernel driver.
-
Package: gstreamer0.10-crystalhd
Section: video
Architecture: amd64 i386
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.dkms
crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.dkms
--- crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.dkms 2013-03-02
14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.dkms 1969-12-31
19:00:00.0 -0500
@@ -1,11 +0,0 @@
-# DKMS configuration for crystalhd
-
-PACKAGE_NAME="crystalhd"
-PACKAGE_VERSION="#MODULE_VERSION#"
-BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
-BUILT_MODULE_LOCATION[0]=driver/linux
-DEST_MODULE_LOCATION[0]="/updates/dkms/"
-AUTOINSTALL=yes
-
-MAKE[0]="cd driver/linux && ./configure && make"
-CLEAN="make -C driver/linux clean distclean"
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.install
crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.install
--- crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.install 2013-03-02
14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.install 1969-12-31
19:00:00.0 -0500
@@ -1,2 +0,0 @@
-usr/src
-lib/udev/rules.d
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/patches/hardening-opts.patch
crystalhd-0.0~git20110715.fdd2f19/debian/patches/hardening-opts.patch
--- crystalhd-0.0~git20110715.fdd2f19/debian/patches/hardening-opts.patch
1969-12-31 19:00:00.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/patches/hardening-opts.patch
2013-03-02 13:21:28.0 -0500
@@ -0,0 +1,16 @@
+Description: Allow extra compiler and linker flags to be passed into build
+ system.
+Author: Andres Mejia
+
+--- a/linux_lib/libcrystalhd/Makefile
b/linux_lib/libcrystalhd/Makefile
+@@ -30,6 +30,9 @@
+ CPPFLAGS += $(MACHINE_OPTS)
+ LDFLAGS = -Wl,-soname,${BCLIB_SL} -pthread
+
++CPPFLAGS += $(EXTRA_CPPFLAGS) $(EXTRA_CXXFLAGS)
++LDFLAGS += $(EXTRA_LDFLAGS)
++
+ SRCFILES = libcrystalhd_if.cpp \
+ libcrystalhd_int_if.cpp \
+ libcrystalhd_fwcmds.cpp \
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/patches/series
crystalhd-0.0~git20110715.fdd2f19/debian/patches/serie
Re: Uncoordinated (?) x264 SONAME bump
On Thu, May 10, 2012 at 9:22 PM, Cyril Brulebois wrote: > Hi, > > (The following is written based on the assumption we weren't contacted > since the 4th of March [end of the previous x264 transition]; apologies > if I missed some mails to debian-release@.) > > please coordinate with us for next x264 SONAME bumps. I noticed that > because vlc's late rebuild for the libupnp transition got a dependency > on the new libx264-123 binary… Meaning vlc/mipsel can't migrate until > x264 is ready, decrufted, and reverse dependencies are happy too. Among > other things (I haven't assessed yet the possible damages), this delays > libupnp's end of transition, and makes britney runs very slow, which > isn't nice given the amount of entangled stuff we're dealing with > (meaning a lot of dry runs to get stuff sorted). :/ Let's also do the same for every library maintained by the Debian Multimedia team whenever a SONAME bump occurs. > > Mraw, > KiBi. > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAk+saboACgkQeGfVPHR5Nd1kTgCeKFnwZpVVNA9ynV6qjvp+tWR2 > TPMAn3wa5QHT0ZAzqnGjiDqTaxf8Xm1+ > =hle0 > -END PGP SIGNATURE- > > ___ > pkg-multimedia-maintainers mailing list > pkg-multimedia-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers -- ~ Andres -- 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/CAPM41nNhLDb9FeG7ePuncuvn=TTJWGY3K=bqefqmb3rrint...@mail.gmail.com
Bug#653195: transition: libarchive
I haven't seen any activity with evolution 3.2 / libgdata 0.10 transition. Should the transition of libarchive still wait? -- ~ Andres -- 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/CAPM41nP7kLupjZMi++eadA4cLHp66+W=vv6gk2z78xxpo50...@mail.gmail.com
Bug#653195: transition: libarchive
On Sun, Dec 25, 2011 at 5:09 PM, Niels Thykier wrote: > On Dec 25, 2011 19:42 "Andres Mejia" wrote: > >> I have finished checking what changes were required for gmameui, >> tuxcmd-modules, and deb-gview in order to build with both the current >> version of libarchive (2.8.5) and the latest version (3.0.2). >> Fortunately, all changes required are trivial. I filed bug reports and >> patches in the following locations. >> >> gmameui: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653231> >> tuxcmd-modules: >> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653233> >> deb-gview: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653237> >> >> As said before, all other packages simply need to be binNMUed. The >> package 'hydrogen' requires a sourceful upload for a seperate issue. >> >> With all this said, I am requesting a transition slot for the >> transition from libarchive 2.8.5 to libarchive 3.0.2. >> >> >> > > > Hi, > > Thanks for rebuild testing the packages. > > I have setup a tracker for the libarchive transition at [1], please confirm > it matches your expectations. Yes, this is what I expect. > In regards to timing, we will have to wait until the evolution3.2 transition > is over[2]. We will get back to you when it is done. Very well. > ~Niels > > [1] http://release.debian.org/transitions/html/libarchive.html > > [2] http://release.debian.org/transitions/html/evolution3.2.html > -- Regards, Andres Mejia -- 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/CALgfg4gdFXk3KhHAR=on2KNs8EzTPUfJZAmgay0m=3xxq1z...@mail.gmail.com
Bug#653195: transition: libarchive
I have finished checking what changes were required for gmameui, tuxcmd-modules, and deb-gview in order to build with both the current version of libarchive (2.8.5) and the latest version (3.0.2). Fortunately, all changes required are trivial. I filed bug reports and patches in the following locations. gmameui: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653231 tuxcmd-modules: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653233 deb-gview: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653237 As said before, all other packages simply need to be binNMUed. The package 'hydrogen' requires a sourceful upload for a seperate issue. With all this said, I am requesting a transition slot for the transition from libarchive 2.8.5 to libarchive 3.0.2. -- Regards, Andres Mejia -- 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/CALgfg4g-r=2Kd2RQZaAFkU=aadwvsudpcs6wh7ppybxwkh4...@mail.gmail.com
Bug#653195: transition: libarchive
On Sat, Dec 24, 2011 at 7:43 PM, Andres Mejia wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > I am requesting a transition from libarchive1 to the latest libarchive shared > library package (which will be libarchive12). The latest libarchive version to > transition to will be libarchive-3.0.2 (soon to be uploaded to experimental). > This transition will require source changes to packages that used the > following > functions from libarchive. > > archive_read_data_block > archive_read_data_into_buffer > archive_read_set_format_options > archive_read_set_filter_options > archive_read_extract_set_skip_file > archive_write_set_skip_file > archive_write_data_block > archive_write_set_format_options > archive_write_set_compressor_options > archive_write_disk_set_skip_file > archive_write_disk_set_group_lookup > archive_write_disk_set_user_lookup > archive_read_disk_gname > archive_read_disk_uname > archive_read_disk_set_gname_lookup > archive_read_disk_set_uname_lookup > archive_entry_gid > archive_entry_ino > archive_entry_uid > archive_entry_set_gid > archive_entry_set_ino > archive_entry_set_uid > archive_entry_acl_add_entry > archive_entry_acl_add_entry_w > __archive_entry_acl_parse_w > > All other packages can simply be binNMUed. The following packages are reverse > dependencies of libarchive1 (as found using apt-cache). > > ark > gmameui > tuxcmd-modules > libtotem-plparser17 > reprepro > rdup > packagekit-bash-completion > packagekit > libpackagekit-glib2-14 > gstreamer0.10-packagekit > browser-plugin-packagekit > libapache2-mod-musicindex > hydrogen > gvfs-backends > deb-gview > cpio > cmake-qt-gui > cmake-curses-gui > cmake > claws-mail-archiver-plugin > archivemount > > Also, libtotem-plparser-dev is a reverse dependency on libarchive-dev. > > -- System Information: > Debian Release: wheezy/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.1.0-1-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > I attempt to rebuild all packages in this list in a clean chroot. Out of all the packages, only gmameui, tuxcmd-modules, and deb-gview appear to require changes to their sources in order to build with the latest libarchive. All other packages can simply be binNMUed. One other note, hydrogen currently fails to build, although that stems from a different issue which has already been addressed and pending a new upload. The pending version of hydrogen builds with the latest version of libarchive. -- Regards, Andres Mejia -- 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/calgfg4hn+pnxgjzrz5utxvre1v2ukd0dyhj1haxwzrdxb4x...@mail.gmail.com
Bug#653195: transition: libarchive
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I am requesting a transition from libarchive1 to the latest libarchive shared library package (which will be libarchive12). The latest libarchive version to transition to will be libarchive-3.0.2 (soon to be uploaded to experimental). This transition will require source changes to packages that used the following functions from libarchive. archive_read_data_block archive_read_data_into_buffer archive_read_set_format_options archive_read_set_filter_options archive_read_extract_set_skip_file archive_write_set_skip_file archive_write_data_block archive_write_set_format_options archive_write_set_compressor_options archive_write_disk_set_skip_file archive_write_disk_set_group_lookup archive_write_disk_set_user_lookup archive_read_disk_gname archive_read_disk_uname archive_read_disk_set_gname_lookup archive_read_disk_set_uname_lookup archive_entry_gid archive_entry_ino archive_entry_uid archive_entry_set_gid archive_entry_set_ino archive_entry_set_uid archive_entry_acl_add_entry archive_entry_acl_add_entry_w __archive_entry_acl_parse_w All other packages can simply be binNMUed. The following packages are reverse dependencies of libarchive1 (as found using apt-cache). ark gmameui tuxcmd-modules libtotem-plparser17 reprepro rdup packagekit-bash-completion packagekit libpackagekit-glib2-14 gstreamer0.10-packagekit browser-plugin-packagekit libapache2-mod-musicindex hydrogen gvfs-backends deb-gview cpio cmake-qt-gui cmake-curses-gui cmake claws-mail-archiver-plugin archivemount Also, libtotem-plparser-dev is a reverse dependency on libarchive-dev. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/8 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: http://lists.debian.org/4ef671b2.c7c5e00a.7819.1...@mx.google.com
Bug#624807: libav 0.7 transition
Has there been any work on transitioning to libav-0.7? -- Regards, Andres Mejia -- 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/CALgfg4j=n5splfw-gskzjzbhyplbk6gavlpzbokjl-togh-...@mail.gmail.com
Bug#635286: nmu: tiff_3.9.5-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu tiff_3.9.5-1 . ALL . -m "Migrate to libjpeg8" I'm requesting a binnmu of tiff to build against libjpeg8. No changes were needed for tiff to build against libjpeg8. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/8 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: http://lists.debian.org/4e2c5335.044b340a.3c66.7...@mx.google.com
Bug#635269: nmu: sdl-image1.2_1.2.10-2.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu sdl-image1.2_1.2.10-2.1 . ALL . -m "Migrate to libjpeg8" I'm requesting a binNMU of sdl-image1.2 to build against libjpeg8. No changes are needed for sdl-image1.2. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/8 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: http://lists.debian.org/4e2c343d.cf73dc0a.49e1.1...@mx.google.com
Bug#604872: unblock: faad2/2.7-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package faad2. This upload fixes a segfault found in 2.7-4 [1]. Here is the entire changelog. faad2 (2.7-6) unstable; urgency=high [ Alessio Treglia ] * Fix segmentation fault in faad due to an incorrect pointer size (Closes: #603807, LP: #665802). * Add gbp config file. [ Andres Mejia ] * Revert changes in 2.7-5. Upload of 2.7-5 was unintentionally done. * Refresh patches. -- Andres Mejia Mon, 22 Nov 2010 19:17:36 -0500 Changes done in 2.7-5 were all reverted, since it was uploaded unintentionally. Here is a diff for the changes from 2.7-4 to 2.7-6 [2]. 1. http://bugs.debian.org/603807 2. http://git.debian.org/?p=pkg-multimedia/faad2.git;a=commitdiff;h=005521ed80bd75e2c88319373b6a885db721a903;hp=ae1c31447582637aed1f23087240c567d34ef2ac unblock faad2/2.7-6 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 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: http://lists.debian.org/4ced9dd0.4a2fdc0a.28bf.0...@mx.google.com
Please unblock faad2 2.7-6
Please unblock faad2 2.7-6. This upload fixes a segfault found in 2.7-4 [1]. Here is the entire changelog. faad2 (2.7-6) unstable; urgency=high [ Alessio Treglia ] * Fix segmentation fault in faad due to an incorrect pointer size (Closes: #603807, LP: #665802). * Add gbp config file. [ Andres Mejia ] * Revert changes in 2.7-5. Upload of 2.7-5 was unintentionally done. * Refresh patches. -- Andres Mejia Mon, 22 Nov 2010 19:17:36 -0500 Changes done in 2.7-5 were all reverted, since it was uploaded unintentionally. Here is a diff for the changes from 2.7-4 to 2.7-6 [2]. 1. http://bugs.debian.org/603807 2. http://git.debian.org/?p=pkg- multimedia/faad2.git;a=commitdiff;h=005521ed80bd75e2c88319373b6a885db721a903;hp=ae1c31447582637aed1f23087240c567d34ef2ac -- Regards, Andres Mejia -- 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/201011231118.20962.mcita...@gmail.com
Re: libvdpau (updated package)
On Friday 12 November 2010 16:45:57 Julien Cristau wrote: > On Fri, Nov 12, 2010 at 16:31:57 -0500, Andres Mejia wrote: > > Hello, > > > > The current package of libvdpau in experimental (0.4.1-1) would fix bug > > #603220. The package in libvdpau is 0.4-5. The differences between the > > two packages can be found at [1]. The only change by upstream from 0.4 > > to 0.4.1 were minor documentation changes in the public headers [2]. > > > > Question I have is, would it be alright to make an upload of the package > > from experimental to unstable and if so, could I be granted a freeze > > exception? > > The packaging changes make the diff a bit of a pain, but yeah, go ahead. > > Cheers, > Julien Ok then, the upload has been made. Please unblock libvdpau 0.4.1-2. -- Regards, Andres Mejia -- 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/201011130831.13415.mcita...@gmail.com
libvdpau (updated package)
Hello, The current package of libvdpau in experimental (0.4.1-1) would fix bug #603220. The package in libvdpau is 0.4-5. The differences between the two packages can be found at [1]. The only change by upstream from 0.4 to 0.4.1 were minor documentation changes in the public headers [2]. Question I have is, would it be alright to make an upload of the package from experimental to unstable and if so, could I be granted a freeze exception? 1. http://packages.debian.org/changelogs/pool/main/libv/libvdpau/current/changelog 2. http://cgit.freedesktop.org/~aplattner/libvdpau/diff/?id=76fdf83a7690ce366edbd4816b3c4b6728eeb9ee&id2=581d8bbcd36b85fb368446180053204118829fc1 -- Regards, Andres Mejia -- 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/201011121631.58154.mcita...@gmail.com
Re: Please Don't !! (Was: faad2_2.7-1_i386.changes ACCEPTED)
On Thursday 06 August 2009 11:17:12 Luk Claes wrote: > Fabian Greffrath wrote: > > Pierre Habouzit schrieb: > >> Okay, I should retract that, xine-lib is part of the imagemagick > >> transition as well, sorry that I missed that, we have to wait for it to > >> be done first, I'm sorry. > > > > Now that the imagemagick transition is done, is it safe to upload > > faad2_2.7 to unstable? > > I'm afraid that libcdio is still blocking your transition. libcdio is at 100%. Can we upload faad2 to unstable now? -- Regards, Andres -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
faad2 2.7 Transition
Hello Release team, faad2-2.7 packages are ready for upload. A SO version bump is made and the shared library package will go from lbfaad0 to libfaad2. May we upload the new packages to unstable? If not, may we upload the new packages to experimental in the meantime? Here is a list of reverse build dependencies on libfaad-dev. $ grep-dctrl -FBuild-Depends -sPackage libfaad-dev /var/lib/apt/lists/ftp.us.debian.org*Sources Package: mpd Package: qmmp Package: cmus Package: ffmpeg-debian Package: gst-plugins-bad0.10 Package: libquicktime Package: moc Package: mpd Package: vlc Package: xine-lib Package: xmms2 -- Regards, Andres -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Please do a binNMU for unicap on sparc
Please do a binNMU for unicap on sparc. Right now, the unicap libraries and -dev packages are uninstallable on sparc because it depends on an unavailable version of the ffmpeg-debian libraries, due to a bug that was in ffmpeg-debian. This bug has been resolved with ffmpeg-debian-4:0.5+svn20090420-2. See bug #527350. -- Regards, Andres -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Please unblock nvidia-cg-toolkit 2.0.0015.deb3
I'm not sure what happened to my last email. Please unblock nvidia-cg-toolkit
2.0.0015.deb3.
On Thursday 23 October 2008 04:04:26 am Marc 'HE' Brockschmidt wrote:
> "Andres Mejia" <[EMAIL PROTECTED]> writes:
> > I have a fix for this (and similar issues I found with perlcritic)
> > ready for upload. Could an exception be made for this kind of fix?
>
> Patch? If this is a one-liner or something similar, I approve of getting
> rid of the annoying warnings.
>
> Marc
I took care of this problem by taking care of the gentle warnings produced by
Perl::Critic. It's not a one-liner, but I thought the other lines could pose
a problem in the future anyway, so I corrected them as well.
Just in case it's already been forgotten, I'm asking for a freeze exception on
nvidia-cg-toolkit (2.0.0015.deb3).
--
Regards,
Andres
diff --git a/debian/changelog b/debian/changelog
index 2d25617..c869395 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+nvidia-cg-toolkit (2.0.0015.deb3) unstable; urgency=low
+
+ * Fixed all gentle warnings in script found with Perl::Critic.
+ * This also fixes some bugs reporting Perl warnings.
+(Closes: #502234)
+(Closes: #503331)
+
+ -- Andres Mejia <[EMAIL PROTECTED]> Sun, 16 Nov 2008 10:07:18 -0500
+
nvidia-cg-toolkit (2.0.0015.deb2) unstable; urgency=low
* Adding Japanese translations. (Closes: #493566)
diff --git a/nvidia-cg-toolkit-installer b/nvidia-cg-toolkit-installer
index bc16e3d..ca2d893 100755
--- a/nvidia-cg-toolkit-installer
+++ b/nvidia-cg-toolkit-installer
@@ -29,7 +29,6 @@ use File::Temp qw/ tempfile tempdir /; # For temporary files and directories.
use File::Path 'rmtree'; # Needed for removing directories recursively.
use File::Copy; # Needed for copying files.
use File::Basename; # Used in retrieving the basename/dirname of a file.
-use File::Glob ':glob'; # Needed for selecting specific files from a directory.
use Compress::Zlib; # Needed for compressing files in gzip format.
use Digest::MD5; # Needed to verify MD5 checksums.
use Time::HiRes qw ( time ); # Needed for high resolution timers
@@ -133,7 +132,7 @@ sub download {
my $percent; # The percentage downloaded
my $tick; # Used for counting.
my $start_time = time; # Record of the start time
-open(FILE, '>', $file); # Destination file to download content to
+open(my $fh, '>', $file); # Destination file to download content to
my $response = $ua->get($url, ":content_cb" =>
sub {
my ($chunk, $response) = @_;
@@ -180,20 +179,20 @@ sub download {
}
# Write the contents of the download to our specified file
if ($response->is_success) {
-print FILE $chunk; # Print content to file
+print $fh $chunk; # Print content to file
} else {
# Print message upon failure during download
print STDERR "\n" . $response->status_line . "\n";
-return undef;
+return 0;
}
}
); # Our GET request
-close FILE; # Close the destination file
+close $fh; # Close the destination file
# Print error message in case we couldn't get a response at all.
if (!$response->is_success) {
print $response->status_line . "\n";
-return undef;
+return 0;
}
# At this point, the download should have been successful. Print a success
@@ -209,7 +208,7 @@ sub download {
sub getProxy {
# Determine if a proxy is going to be used at all
if ($no_proxy) {
-return undef;
+return 0;
}
# Determine if the proxy option was specified in the command line.
@@ -219,10 +218,8 @@ sub getProxy {
}
# Attempt to acquire a proxy URL from apt-config.
-if (open(APT_CONFIG, "apt-config dump |")) {
-my @apt_config = ;
-close(APT_CONFIG);
-foreach my $tmp (@apt_config) {
+if (open(my $apt_config_output, '-|', '/usr/bin/apt-config dump')) {
+foreach my $tmp (<$apt_config_output>) {
if ($tmp =~ m/^.*Acquire::http::Proxy\s+/) {
$proxy = $tmp;
chomp($proxy);
@@ -231,15 +228,14 @@ sub getProxy {
return $proxy;
}
}
+close $apt_config_output;
}
# Attempt to acquire a proxy URL from the user's or system's wgetrc
# configuration.
# First try the user's wgetrc
-if (open(WGETRC, '<', "$ENV{'HOME'}/.wgetrc")) {
-my @wgetrc = ;
-close(WGETRC);
-foreach my $tmp (@wgetrc) {
+if (open(my $wgetrc, '<', "$ENV{'HOME'}/.wgetrc")) {
+foreach my $tmp
Please unblock nvidia-cg-toolkit 2.0.0015.deb3
I'm not sure what happened to my last email. Please unblock nvidia-cg-toolkit
2.0.0015.deb3.
On Thursday 23 October 2008 04:04:26 am Marc 'HE' Brockschmidt wrote:
> "Andres Mejia" <[EMAIL PROTECTED]> writes:
> > I have a fix for this (and similar issues I found with perlcritic)
> > ready for upload. Could an exception be made for this kind of fix?
>
> Patch? If this is a one-liner or something similar, I approve of getting
> rid of the annoying warnings.
>
> Marc
I took care of this problem by taking care of the gentle warning produced by
Perl::Critic. It's not a one-liner, but I thought the other lines could pose
a problem in the future anyway, so I corrected them as well.
Just in case it's already been forgotten, I'm asking for a freeze exception on
nvidia-cg-toolkit (2.0.0015.deb3).
--
Regards,
Andres
diff --git a/debian/changelog b/debian/changelog
index 2d25617..c869395 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+nvidia-cg-toolkit (2.0.0015.deb3) unstable; urgency=low
+
+ * Fixed all gentle warnings in script found with Perl::Critic.
+ * This also fixes some bugs reporting Perl warnings.
+(Closes: #502234)
+(Closes: #503331)
+
+ -- Andres Mejia <[EMAIL PROTECTED]> Sun, 16 Nov 2008 10:07:18 -0500
+
nvidia-cg-toolkit (2.0.0015.deb2) unstable; urgency=low
* Adding Japanese translations. (Closes: #493566)
diff --git a/nvidia-cg-toolkit-installer b/nvidia-cg-toolkit-installer
index bc16e3d..ca2d893 100755
--- a/nvidia-cg-toolkit-installer
+++ b/nvidia-cg-toolkit-installer
@@ -29,7 +29,6 @@ use File::Temp qw/ tempfile tempdir /; # For temporary files and directories.
use File::Path 'rmtree'; # Needed for removing directories recursively.
use File::Copy; # Needed for copying files.
use File::Basename; # Used in retrieving the basename/dirname of a file.
-use File::Glob ':glob'; # Needed for selecting specific files from a directory.
use Compress::Zlib; # Needed for compressing files in gzip format.
use Digest::MD5; # Needed to verify MD5 checksums.
use Time::HiRes qw ( time ); # Needed for high resolution timers
@@ -133,7 +132,7 @@ sub download {
my $percent; # The percentage downloaded
my $tick; # Used for counting.
my $start_time = time; # Record of the start time
-open(FILE, '>', $file); # Destination file to download content to
+open(my $fh, '>', $file); # Destination file to download content to
my $response = $ua->get($url, ":content_cb" =>
sub {
my ($chunk, $response) = @_;
@@ -180,20 +179,20 @@ sub download {
}
# Write the contents of the download to our specified file
if ($response->is_success) {
-print FILE $chunk; # Print content to file
+print $fh $chunk; # Print content to file
} else {
# Print message upon failure during download
print STDERR "\n" . $response->status_line . "\n";
-return undef;
+return 0;
}
}
); # Our GET request
-close FILE; # Close the destination file
+close $fh; # Close the destination file
# Print error message in case we couldn't get a response at all.
if (!$response->is_success) {
print $response->status_line . "\n";
-return undef;
+return 0;
}
# At this point, the download should have been successful. Print a success
@@ -209,7 +208,7 @@ sub download {
sub getProxy {
# Determine if a proxy is going to be used at all
if ($no_proxy) {
-return undef;
+return 0;
}
# Determine if the proxy option was specified in the command line.
@@ -219,10 +218,8 @@ sub getProxy {
}
# Attempt to acquire a proxy URL from apt-config.
-if (open(APT_CONFIG, "apt-config dump |")) {
-my @apt_config = ;
-close(APT_CONFIG);
-foreach my $tmp (@apt_config) {
+if (open(my $apt_config_output, '-|', '/usr/bin/apt-config dump')) {
+foreach my $tmp (<$apt_config_output>) {
if ($tmp =~ m/^.*Acquire::http::Proxy\s+/) {
$proxy = $tmp;
chomp($proxy);
@@ -231,15 +228,14 @@ sub getProxy {
return $proxy;
}
}
+close $apt_config_output;
}
# Attempt to acquire a proxy URL from the user's or system's wgetrc
# configuration.
# First try the user's wgetrc
-if (open(WGETRC, '<', "$ENV{'HOME'}/.wgetrc")) {
-my @wgetrc = ;
-close(WGETRC);
-foreach my $tmp (@wgetrc) {
+if (open(my $wgetrc, '<', "$ENV{'HOME'}/.wgetrc")) {
+foreach my $tmp
Re: Bug#502234: nvidia-cg-toolkit: perl runtime warnings during upgrade
On Thursday 23 October 2008 04:04:26 am Marc 'HE' Brockschmidt wrote:
> "Andres Mejia" <[EMAIL PROTECTED]> writes:
> > I have a fix for this (and similar issues I found with perlcritic)
> > ready for upload. Could an exception be made for this kind of fix?
>
> Patch? If this is a one-liner or something similar, I approve of getting
> rid of the annoying warnings.
>
> Marc
I took care of this problem by taking care of the gentle warning produced by
Perl::Critic. It's not a one-liner, but I thought the other lines could pose
a problem in the future anyway, so I corrected them as well.
Just in case it's already been forgotten, I'm asking for a freeze exception on
nvidia-cg-toolkit (2.0.0015.deb3).
--
Regards,
Andres
diff --git a/debian/changelog b/debian/changelog
index 2d25617..c869395 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+nvidia-cg-toolkit (2.0.0015.deb3) unstable; urgency=low
+
+ * Fixed all gentle warnings in script found with Perl::Critic.
+ * This also fixes some bugs reporting Perl warnings.
+(Closes: #502234)
+(Closes: #503331)
+
+ -- Andres Mejia <[EMAIL PROTECTED]> Sun, 16 Nov 2008 10:07:18 -0500
+
nvidia-cg-toolkit (2.0.0015.deb2) unstable; urgency=low
* Adding Japanese translations. (Closes: #493566)
diff --git a/nvidia-cg-toolkit-installer b/nvidia-cg-toolkit-installer
index bc16e3d..ca2d893 100755
--- a/nvidia-cg-toolkit-installer
+++ b/nvidia-cg-toolkit-installer
@@ -29,7 +29,6 @@ use File::Temp qw/ tempfile tempdir /; # For temporary files and directories.
use File::Path 'rmtree'; # Needed for removing directories recursively.
use File::Copy; # Needed for copying files.
use File::Basename; # Used in retrieving the basename/dirname of a file.
-use File::Glob ':glob'; # Needed for selecting specific files from a directory.
use Compress::Zlib; # Needed for compressing files in gzip format.
use Digest::MD5; # Needed to verify MD5 checksums.
use Time::HiRes qw ( time ); # Needed for high resolution timers
@@ -133,7 +132,7 @@ sub download {
my $percent; # The percentage downloaded
my $tick; # Used for counting.
my $start_time = time; # Record of the start time
-open(FILE, '>', $file); # Destination file to download content to
+open(my $fh, '>', $file); # Destination file to download content to
my $response = $ua->get($url, ":content_cb" =>
sub {
my ($chunk, $response) = @_;
@@ -180,20 +179,20 @@ sub download {
}
# Write the contents of the download to our specified file
if ($response->is_success) {
-print FILE $chunk; # Print content to file
+print $fh $chunk; # Print content to file
} else {
# Print message upon failure during download
print STDERR "\n" . $response->status_line . "\n";
-return undef;
+return 0;
}
}
); # Our GET request
-close FILE; # Close the destination file
+close $fh; # Close the destination file
# Print error message in case we couldn't get a response at all.
if (!$response->is_success) {
print $response->status_line . "\n";
-return undef;
+return 0;
}
# At this point, the download should have been successful. Print a success
@@ -209,7 +208,7 @@ sub download {
sub getProxy {
# Determine if a proxy is going to be used at all
if ($no_proxy) {
-return undef;
+return 0;
}
# Determine if the proxy option was specified in the command line.
@@ -219,10 +218,8 @@ sub getProxy {
}
# Attempt to acquire a proxy URL from apt-config.
-if (open(APT_CONFIG, "apt-config dump |")) {
-my @apt_config = ;
-close(APT_CONFIG);
-foreach my $tmp (@apt_config) {
+if (open(my $apt_config_output, '-|', '/usr/bin/apt-config dump')) {
+foreach my $tmp (<$apt_config_output>) {
if ($tmp =~ m/^.*Acquire::http::Proxy\s+/) {
$proxy = $tmp;
chomp($proxy);
@@ -231,15 +228,14 @@ sub getProxy {
return $proxy;
}
}
+close $apt_config_output;
}
# Attempt to acquire a proxy URL from the user's or system's wgetrc
# configuration.
# First try the user's wgetrc
-if (open(WGETRC, '<', "$ENV{'HOME'}/.wgetrc")) {
-my @wgetrc = ;
-close(WGETRC);
-foreach my $tmp (@wgetrc) {
+if (open(my $wgetrc, '<', "$ENV{'HOME'}/.wgetrc")) {
+foreach my $tmp (<$wgetrc>) {
if ($tmp =~ m/^[^#]*http_proxy/) {
$proxy = $tmp;
security hints
Please allow no-ip 2.1.7-11 to enter testing as it fixes a security related bug #506179. -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Re: Bug#502234: nvidia-cg-toolkit: perl runtime warnings during upgrade
I have a fix for this (and similar issues I found with perlcritic) ready for upload. Could an exception be made for this kind of fix? On Tue, Oct 14, 2008 at 2:30 PM, John van der Kamp <[EMAIL PROTECTED]> wrote: > Package: nvidia-cg-toolkit > Version: 2.0.0015.deb2 > Severity: normal > > While upgrading nvidia-cg-toolkit to 2.0.0015.deb2, perl complained about > closedir() on invalid dirhandle. > Full output of the upgrade: > > Setting up nvidia-cg-toolkit (2.0.0015.deb2) ... > Using '/var/cache/nvidia-cg-toolkit/Cg-2.0_May2008_x86.tgz' > Using '/var/cache/nvidia-cg-toolkit/Cg-2.0_May2008_LanguageSpecification.pdf' > Checking MD5 sum for NVIDIA Cg Toolkit file...passed. > Checking MD5 sum for NVIDIA Cg Toolkit spec file...passed. > Uninstalling NVIDIA Cg Toolkit components: Cg compiler, header files, > libraries, documentation, examples, manual pages, (running ldconfig), done. > Uncompressing NVIDIA Cg Toolkit. > Installing NVIDIA Cg Toolkit components: Cg compiler, header files, > libraries, documentation, examples, closedir() attempted on invalid dirhandle > DIR at /usr/bin/nvidia-cg-toolkit-installer line 305. > closedir() attempted on invalid dirhandle DIR at > /usr/bin/nvidia-cg-toolkit-installer line 305. > closedir() attempted on invalid dirhandle DIR at > /usr/bin/nvidia-cg-toolkit-installer line 305. > closedir() attempted on invalid dirhandle DIR at > /usr/bin/nvidia-cg-toolkit-installer line 305. > closedir() attempted on invalid dirhandle DIR at > /usr/bin/nvidia-cg-toolkit-installer line 305. > closedir() attempted on invalid dirhandle DIR at > /usr/bin/nvidia-cg-toolkit-installer line 305. > closedir() attempted on invalid dirhandle DIR at > /usr/bin/nvidia-cg-toolkit-installer line 305. > manual pages, (running ldconfig), done. > > John > > -- System Information: > Debian Release: lenny/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: i386 (i686) > > Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) > Locale: LANG=C, LC_CTYPE=nl_NL (charmap=ISO-8859-1) > Shell: /bin/sh linked to /bin/bash > > Versions of packages nvidia-cg-toolkit depends on: > ii debconf [debconf-2.0] 1.5.24 Debian configuration management > sy > ii libcompress-zlib-perl 2.015-1Perl module for creation and > manip > ii libwww-perl 5.813-1WWW client/server library for > Perl > ii perl 5.10.0-15 Larry Wall's Practical Extraction > > nvidia-cg-toolkit recommends no packages. > > nvidia-cg-toolkit suggests no packages. > > -- debconf information: > nvidia-cg-toolkit/http_proxy: (password omitted) > nvidia-cg-toolkit/delete: false > nvidia-cg-toolkit/httpget: true > nvidia-cg-toolkit/local: > nvidia-cg-toolkit/not_exist: > > > > -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please unblock nvidia-cg-toolkit-2.0.0015.deb2
Please unblock nvidia-cg-toolkit-2.0.0015.deb2. This contains a translation update. This upload also fixes a lintian warning: command-with-path-in-maintainer-script. -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Unblock request for ogre-doc-nonfree
Please unblock ogre-doc-nonfree-1.4.9-1. It includes the documentation for ogre which was separated into it's own package since ogre-1.4.6. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock ogre
On Sunday 03 August 2008 05:00:40 am Pierre Habouzit wrote: > On Sun, Aug 03, 2008 at 02:27:24AM +0000, Andres Mejia wrote: > > Please allow ogre 1.4.9.dfsg1-1 to migrate to testing. The new upload > > fixed a bug that blocked an RC bug from another package (bug #478105). > > The new upload also fixes issues where apps would crash if a user had the > > NVIDIA 169.x or 175.x drivers (these were reported upstream). > > Huh. Last version in testing is 1.4.6.dfsg1-1 ... how come this is a > bump of *3* upstream releases ? Did anyone receive my last message about this. I had said there was a problem I didn't resolve for 1.4.7 until after 1.4.8 was released. I went ahead and packaged 1.4.8, but it wasn't accepted until the copyright file was fixed, which I didn't fix until after 1.4.9 was released. So now can ogre and ogre-doc-nonfree be unblocked? ogre-doc-nonfree has the API and manual documentation currently found in ogre 1.4.6.dfsg1-1. -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Re: Please unblock ogre
On Sunday 03 August 2008 05:00:40 am Pierre Habouzit wrote: > On Sun, Aug 03, 2008 at 02:27:24AM +0000, Andres Mejia wrote: > > Please allow ogre 1.4.9.dfsg1-1 to migrate to testing. The new upload > > fixed a bug that blocked an RC bug from another package (bug #478105). > > The new upload also fixes issues where apps would crash if a user had the > > NVIDIA 169.x or 175.x drivers (these were reported upstream). > > Huh. Last version in testing is 1.4.6.dfsg1-1 ... how come this is a > bump of *3* upstream releases ? There was a problem I didn't resolve for 1.4.7 until after 1.4.8 was released. I went ahead and packaged 1.4.8, but it wasn't accepted until the copyright file was fixed, which I couldn't fix until after 1.4.9 was released. -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Please unblock ogre
Please allow ogre 1.4.9.dfsg1-1 to migrate to testing. The new upload fixed a bug that blocked an RC bug from another package (bug #478105). The new upload also fixes issues where apps would crash if a user had the NVIDIA 169.x or 175.x drivers (these were reported upstream). -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Please unblock no-ip
Please allow no-ip 2.1.7-10 to migrate to testing. This upload fixed a grave bug (that wasn't reported) which caused no-ip to not start from a fresh install. -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Please remove vegastrike from inclusion in Lenny
Greetings Release Team! Please remove vegastrike, vegastrike-data, and vegastrike-music from inclusion in Lenny. In it's current state, vegastrike will segfault or otherwise make the game unplayable (see bug #488686). To resolve this, vegastrike and vegastrike-data need to be updated to version 0.5.0, which has not been uploaded yet. vegastrike-music should also be removed as it has a dependency on vegastrike-data. -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Re: Fwd: Please schedule binNMUs for openal -> openal-soft transition
On Monday 28 July 2008 07:13:56 pm Adeodato Simó wrote: > Hello. Most of the binNMUs succeeded. I'll give you tomorrow a list of > the ones that failed and need attetion, but for now, I know for sure > that #477353 needs fixing, in case you want to NMU or prod the > maintainer. > > Cheers, > > * Adeodato Simó [Fri, 25 Jul 2008 01:37:14 +0100]: For #477353, are you sure we're talking about openal, or is it openscenegraph? > > * Andres Mejia [Sun, 13 Jul 2008 23:51:53 -0400]: > > > Hello, > > > > Hi, > > > > > I'm resending this email from Reinhard. We're requesting binNMUs for > > > reverse dependencies of openal. Our previous issue with uploading the > > > latest version of openal-soft has been resolved. > > > > Ok, I finally got to get this, I'm very sorry for the delay. > > > > > Due to the switch from openal to openal-soft, reverse dependencies need > > > to be rebuild against the new package. The following packages are ready > > > for binNMU (testbuild successful locally on i386): > > > > Thanks for testing them! > > > > > antigrav_0.0.3-2 > > > blender_2.46+dfsg-2 > > > boson_0.13-4 > > > btanks_0.7.5800-2 > > > chromium_0.9.13.1-1 > > > flightgear_1.0.0-3 > > > freealut_1.1.0-1 > > > glest_3.1.2-1 > > > hugs98_98.200609.21-5 > > > pyopenal_0.1.6-4 > > > scorched3d_41.3dfsg-1 > > > soya_0.13.2-4 > > > supertuxkart_0.5-1 > > > torcs_1.3.0-3 > > > tremulous_1.1.0-4.1 > > > trigger_0.5.2-2 > > > vegastrike_0.5~svn12126-2 > > > warzone2100_2.1.0~1.beta2-1 > > > xpilot-ng_1:4.7.3~cvs20080224-1 > > > > All scheduled. > > > > > coin2_2.5.0-2 > > > > This one just Suggests libopenal0a, and it's hardcoded, so you'll need > > to file a bug. > > > > > mplayer_1.0~rc2-14 > > > > This one got a sourceful upload. > > > > > The package taoframework seems to require a sourceful upload and cannot > > > be handeled with a binNMU. > > > > Right, can you file a bug? (At serious, please.) > > > > > The following two packages fail because the new libopenal-dev package > > > does no longer provide a .la file. AFAUIU this file is only needed for > > > static linking, which is frowned upon by both the release and security > > > team. > > > > > > fail because of missing .la: > > > rss-glx: #489098 > > > osgal: #489096 > > > > Scheduled, as per Reinhard indications. They indeed succeed now. > > > > > other failures: > > > funguloids needs to be rebuild but fails because of #482649 > > > > I also scheduled these: > > > > nmu libsfml_1.3-1 . i386 > > nmu openarena_0.7.7-1 . arm hppa i386 ia64 mips mipsel powerpc s390 > > sparc nmu simgear_1.0.0-4 . amd64 arm armel hppa i386 ia64 mips mipsel > > powerpc s390 sparc > > > > Cheers, -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Re: Bug#478789: Vegastrike 0.5.0 Released
On Saturday 19 July 2008 01:01:57 pm Vincent Fourmond wrote: > Hello ! > > Leo 'costela' Antunes wrote: > > Checking the work on[0], I haven't found any conclusion to the 0.5.0 > > saga. Do you guys still need a hand with anything? I'm not sure how much > > time I could devote to helping, but if there's still some source > > splitting to be done, perhaps I could help. > > > > What is the final verdict on the source and binary packages? And the > > removal of the upstream copy of libboost? > > The following is my opinion only. In its current state, vegastrike > will not make it into lenny; it has a RC bug which needs an upgrade to > the newer version. The opinion of the ftpmasters on the current > vegastrike-data is that it is insanely huge - we don't want mirrors to > waste 1 GB of disk space for a package with a popcon score of 200. > > The only way now to get it into lenny (freeze is starting pretty soon > now) is to manage somehow to produce a lighter version of the > vegastrike-data package - a source tarball of around 200MB to 250MB > would be acceptable. If you feel like doing that, please do it very > quickly and have a look at the thread there: > > http://vegastrike.sourceforge.net/forums/viewtopic.php?t=11276 > > You might want to downscale some of the textures in order to make them > smaller. In this case, you might find the gimp-dds package of use. > > If you manage to produce a lighter version of vegastrike-data for the > 0.5 version that works with vegastrike 0.5 in SVN, please contact me as > soon as possible, I'll upload it. > > Cheers, > > Vincent, who's unfortunately way too busy to take care of that himself. Hello, I'm sending this mail to ftpmaster and the Debian release team as this could be the biggest package in the main archive if uploaded. I haven't heard anything else about what to do with large data packages except for the discussions back in May at debian-devel. The package vegastrike-data-0.5.0 is suitable to go into main and if uploaded and accepted would fit in the archive at about 1GB total. I recall a solution s to produce a lighter version of such large packages. We've yet to produce a "lite" version of vegastrike-data since we are more or less not sure what to exclude/include in a vegastrike-data-lite package and also, because of lack of time to produce such a package. This may be too late to fix for Lenny, but I think a temporary solution for this is to include a 'vegastrike-data-lite' that's just a dummy package that the vegastrike source package produces and that vegastrike depends on. It could have some documentation explaining the situation. Then the script to start vegastrike could be modified to ensure the file to start the game is present and if not, can display a friendly message to install 'vegastrike-data' from data.debian.org (or wherever) and exit gracefully. Afterwards, someone can work on a real lite version of vegastrike-data to include in main. Of course if we do this now, what is the Section that it will go to? Will it just be in "games" or "data/games"? Also, if we ever come to a conclusion as to what to do with the vegastrike packages and they are all uploaded, is there any chance that they can be included in Lenny? -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Fwd: Please schedule binNMUs for openal -> openal-soft transition
Hello, I'm resending this email from Reinhard. We're requesting binNMUs for reverse dependencies of openal. Our previous issue with uploading the latest version of openal-soft has been resolved. -- Forwarded Message -- Subject: Please schedule binNMUs for openal -> openal-soft transition Date: Sunday 06 July 2008 From: Reinhard Tartler <[EMAIL PROTECTED]> To: debian-release@lists.debian.org Dear release team, Due to the switch from openal to openal-soft, reverse dependencies need to be rebuild against the new package. The following packages are ready for binNMU (testbuild successful locally on i386): antigrav_0.0.3-2 blender_2.46+dfsg-2 boson_0.13-4 btanks_0.7.5800-2 chromium_0.9.13.1-1 coin2_2.5.0-2 flightgear_1.0.0-3 freealut_1.1.0-1 glest_3.1.2-1 hugs98_98.200609.21-5 mplayer_1.0~rc2-14 pyopenal_0.1.6-4 scorched3d_41.3dfsg-1 soya_0.13.2-4 supertuxkart_0.5-1 torcs_1.3.0-3 tremulous_1.1.0-4.1 trigger_0.5.2-2 vegastrike_0.5~svn12126-2 warzone2100_2.1.0~1.beta2-1 xpilot-ng_1:4.7.3~cvs20080224-1 The package taoframework seems to require a sourceful upload and cannot be handeled with a binNMU. The following two packages fail because the new libopenal-dev package does no longer provide a .la file. AFAUIU this file is only needed for static linking, which is frowned upon by both the release and security team. fail because of missing .la: rss-glx: #489098 osgal: #489096 other failures: funguloids needs to be rebuild but fails because of #482649 -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] --- -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Re: Please schedule binNMUs for openal -> openal-soft transition
On Sunday 06 July 2008 03:58:55 pm Reinhard Tartler wrote: > Reinhard Tartler <[EMAIL PROTECTED]> writes: > > freealut_1.1.0-1 > > freealut_1.1.0-2 has just been uploaded. The binNMU is no longer > necessary. > > Having said this, this should allow the required binNMUs for the > > following packages to build: > > rss-glx: (FTBFS bug: #489098) > > osgal: (FTBFS bug: #489096) > > I haven't tested them yet, but I'm very confident that they will build > with freealut_1.1.0-2. > > -- > Gruesse/greetings, > Reinhard Tartler, KeyID 945348A4 Can we wait until after OpenAL Soft 1.4.272 is uploaded? -- Regards, Andres signature.asc Description: This is a digitally signed message part.
Re: New openal-soft packages in mentors.d.n
On Sunday 08 June 2008 4:22:56 pm Reinhard Tartler wrote: > Andreas Barth <[EMAIL PROTECTED]> writes: > > * Reinhard Tartler ([EMAIL PROTECTED]) [080608 21:51]: > >> Executive summary: the new package is basically an soname bump, all > >> reverse depends need to be rebuilt. This has been tested, only one > >> package is problematic: boson. We expect that this issue can be handled > >> befor the lenny release. > > > > Can we do it with an compatible package for the transition? (Which > > means: have both versions available for some time in testing and > > unstable, and transition the packages step by step) > > Just discussed on irc: > > 22:03:26 < siretart> aba: in principle, that should be doable. however, I'm > not sure if that makes sense. both packages provide an 'libopenal-dev' > package with headers, and I don't think you want to adjust packages to > switch from 'libopenal-dev' to some 'libopenal-soft-dev' header package, do > you? 22:03:56 < aba> siretart: just kill the -dev-package from the old > package 22:04:04 < aba> so packages will use the new one after being > rebuild 22:04:17 < siretart> aba: ah, right. that should be no problem > 22:05:56 < aba> siretart: so I would propose: you first upload a version of > the new lib into unstable without the -dev-package. After that migrated to > testing, you upload a new version of both libs to unstable where the > -dev-package changes source package 22:07:04 < aba> if you do it that way, > it isn't a transition we can worry about 22:07:18 < aba> (of course, we can > still schedule binNMUs) > 22:07:49 < siretart> aba: I could do that, however I see no much point in a > library package without any users. I'd therefore prefer to switch the -dev > package before openal-soft reaches testing. 22:07:59 < siretart> however if > you say that this is the way to go, no problem 22:08:25 < aba> siretart: > because it makes sure that no other package can be blocked if somehow the > package FTBFS or whatever else happens. 22:08:35 < aba> it just is "move > any potential blocker out of the way" 22:09:16 < siretart> okay, I see. > well, first it needs to get out of NEW anyways... 22:10:14 < aba> it > currently waits for experimental? > 22:10:54 < siretart> yes. because I didn't want to start a new transition > without talking to you 22:11:04 < siretart> I can reupload targeting to > unstable, if that helps 22:11:05 < aba> yep, good. > 22:11:13 < aba> yes, but please without the dev-package > 22:11:50 < siretart> okay, will do that > > -- > Gruesse/greetings, > Reinhard Tartler, KeyID 945348A4 So in summary: 1. Upload openal-soft to unstable but without -dev package. 2. Wait for it to enter testing. 3. Once openal-soft enters testing, reupload openal-soft with -dev package and openal without -dev package. Is this correct? -- Regards, Andres signature.asc Description: This is a digitally signed message part.
