Bug#796990: Ogr2ogr with wrapdateline fails on armhf
On Wed, Aug 26, 2015 at 7:03 PM, Sebastiaan Couwenberg
sebas...@xs4all.nl wrote:
I'm not sure what to do with this bugreport, if it's a problem with gdal
on arm{el,hf} we should forward it upstream, but since it can also very
likely be caused by the ongoing transitions we should probably keep it
around for now and check it again when the GCC 5 transitions have completed.
This is not an upstream issue. I checked and ubuntu utopic does not
show this behaviour (with gdal 1.11.2 and before the libstdc++
migration).
Bug#796996: kfreebsd-10: CVE-2015-5675: IRET privilege escalation
Package: kfreebsd-10 Version: 10.1~svn274115-9 Severity: grave Tags: security upstream patch Hi, Local users can trigger a kernel panic, or possibly escalate privileges, by exploiting a flaw in the IRET handler in kfreebsd-9 and -10: https://www.freebsd.org/security/advisories/FreeBSD-SA-15:21.amd64.asc kfreebsd-8 may also be affected, but that release no longer has security support. kfreebsd-11 was fixed long ago in SVN r275833. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64-xenhvm-ipsec Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
Bug#783659: wheezy-pu: package unrar-nonfree/1:4.1.4-1+deb7u1
Control: tags -1 + pending On Wed, 2015-08-26 at 01:38 +0200, Felix Geyer wrote: On 21.08.2015 16:40, Adam D. Barratt wrote: Control: tags -1 + confirmed On Tue, 2015-04-28 at 22:06 +0200, Felix Geyer wrote: unrar-nonfree is affected by a symlink directory traversal vulnerability, see bug #774171. Please go ahead; apologies for the delay. Thanks, uploaded. and flagged for acceptance. Regards, Adam
Bug#738161: cmake: Patch to bootstrap without Qt
On Wed, Aug 26, 2015 at 11:58 AM, Daniel Schepler dschep...@gmail.com wrote: As for cmake - curl, I don't have my notes on the exact cycle I wanted to break, but I think it involved the curl - krb5 Build-Depends. If you have a bootstrap process that can bootstrap krb5 and curl before cmake without requiring cross-compilation using cmake, that would be fine. Come to think of it, I now seem to remember that pkg-kde-tools was an essential part of the Build-Depends cycle that was involved. Since it was only pkg-kde-tools that was involved, and not the binary-arch libdlrestrictions packages, it might not be an issue for the case of bootstrap a new port freely using existing Architecture: all packages. -- Daniel
Bug#789875: subsurface: FTBFS in experimental
On Wed, 2015-08-26 at 09:05 -0700, Dirk Hohndel wrote: Some of us have expressed our dismay with the way distributions work these days. Well to be honest such dismay comes usually always from the same fraction within open source... which is typically exactly that fraction which tries to put more and more control over what the user does and what he (should) want. Quite often this fraction styles itself as the modernists which allegedly bring fancy and blessed technology to opensource, like cloud. And also quite often, what this fraction pushes for is in reality a major step back, security wise, and especially when it comes to longer term questions of freedom of users. That being said, the way distributions work is still considered by many (if not the vast majority) to be simply the way it should be. You may not get they hype with it as when you have a fully totalitarian ruled appstore with some fruit logo on it,... and you may not fully expose your user's data to all kinds of criminals and agencies, as when you put everything in the cloud or even worse run programs directly from there - but therefore you get a system based on proven paradigms which are amongst the main reasons why open source software is so successful and often simply superior. But let's get real here. We are not hostile against core paradigms of the FLOSS community. Well but in fact you seem quite close to be: - You don't want distros to use the software as they wish (like using an old version, or properly using the system libs (as nearly all other projects manage to do)) so you even openly say that you work against distros shipping it. Doesn't sound quite friendly towards the community, does it? And even if you'd now argue again well distros are conceptually broken and thus they're not the 'community' we wish - it still limits the freedom of users, cause shipping a program properly as part of a distro, even if upstream doesn't want that to happen, is still part of that freedom. Of course you can always argue like People can just fork or the license still allows it, but that's merely a sticker of we're free/open then, not real freedom/openness and thus it's quite obvious hostility against core paradigms. As I've said before,... it's the Oracle way of OpenSource, put a OSS license on it, lock out the community, fully control the whole lifecycle of the project and regularly step on all users toes. - You argue with the user experience... so basically, everyone who doesn't to as you define what the current experience is, should either stop so or forrename. If all projects would behave like this, pushing their wishes trough regardless of other (whether majorities or minorities), we'd probably have millions of forks, and the whole idea of FLOSS would be dead. That's basically the GNOME/Mozilla way of open source, a la we provide a product, like it as it is, if not, go away... and if we break with long standing and proven behaviours... either like what we give you go away,... Well in the GNOME case many people went away ;-) which is why we have Cinnamon, et al. This kind of arguing (i.e. with the experience you'd need to protect for the sake of the users) is actually the most hostile part against FLOSS here. Below you complain that Debian shipped old versions (for which it has quite some reasons, i.e. the idea of stableness,... and which you as upstream probably provoked as well, by making subsurface more and more difficult to package, unless of course you're happy with providing an installer blow which ships at least parts of it's ext dependencies with it). Which version a distro ships is in most cases (there are some special exceptions) none of upstream's business. It's part of the freedoms one should get by FLOSS. What comes next? That one could argue our products experience is destroyed if it's shipped in an non QT desktop environment? Or you must not change the maps provider e.g. to non-OSM-whatever, as it destroys the experience? Will future versions of the binary subsurface have a internal update system that nags every 10 minutes to update, because they use a version which no longer matches the current experience? Arguing with the user experience sounds all to familiar to what evil greedy companies like MS/Apple/etc. do. Fully controlling everything, pushing out competitors or non-endorsed usage models... and all of course just for the sake of their users. And yes, you're not doing this (yet),... but the way you argue is just that. Having the sticker of GPL attached to some piece of, code alone doesn't make it free yet - sure everyone could fork subsurface, but as said before this is more theory than practise. - Shall I continue? I guess not... The catholic church had the crusaders, Islam has ISIS, the open source community has their extremists. Neither of those extremist groups speak for the whole
Bug#796990: Ogr2ogr with wrapdateline fails on armhf
On 26-08-15 21:15, Johan Van de Wauw wrote: This function uses GEOS, so we should check again after rebuilding that: Thanks for digging futher! This is all the more reason to start the geos transition soon as mentioned in the bugreport (#791045). Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#797003: libical 1.0.1-0.1 has broken its ABI (again)
Package: libical-dev
Version: 1.0.1-0.1
Severity: serious
Hi,
it seems that the latest upload of libical (1.0.1-0.1) has broken its
ABI yet again. Please see the attached diff (generated using
snapshots.debian.org [0]) for a comparison of the contents of
/usr/include/ between version 1.0-1.3 and 1.0.1-0.1.
This has happened in the past already: See #773916 [1] and its merged
bug reports for a description of the problem and the resulting effects.
For me, this results (again) in evolution (and gnome-shell) displaying
recurring events without end making the calendar functionality unusable
(even more than last time, since evolution simply crashes now). YMMV.
I don't understand the underlying issue well enough to write a patch,
but having a close look at the two patches which were dropped according
to the changelog [2] as well as #796360 [3] seems like a good start. In
the end, this will probably mean uploading a fixed version with a
different SONAME again and starting the corresponding transition.
Best regards
Alexander Kurtz
[0] http://snapshot.debian.org/archive/debian/20150825T214917Z/pool/mai
n/libi/libical/
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773916
[2] https://tracker.debian.org/news/705666
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796360diff -Naur libical-dev_1.0-1.3_amd64/usr/include/ical.h libical-dev_1.0.1-0.1_amd64/usr/include/ical.h
--- libical-dev_1.0-1.3_amd64/usr/include/ical.h 2015-01-03 14:58:53.0 +0100
+++ libical-dev_1.0.1-0.1_amd64/usr/include/ical.h 2014-10-09 17:07:05.0 +0200
@@ -4,7 +4,7 @@
CREATOR: ajc 2008-sep-01
(C) COPYRIGHT 2008 by Art Cancro
- http://freeassociation.sourceforge.net
+ http://libical.github.io/libical/
This program is free software; you can redistribute it and/or modify
it under the terms of either:
diff -Naur libical-dev_1.0-1.3_amd64/usr/include/libical/icalcomponent.h libical-dev_1.0.1-0.1_amd64/usr/include/libical/icalcomponent.h
--- libical-dev_1.0-1.3_amd64/usr/include/libical/icalcomponent.h 2015-01-03 14:58:53.0 +0100
+++ libical-dev_1.0.1-0.1_amd64/usr/include/libical/icalcomponent.h 2014-10-09 17:07:05.0 +0200
@@ -281,5 +281,8 @@
icalcomponent* icalcomponent_new_xdaylight(void);
icalcomponent* icalcomponent_new_vagenda(void);
icalcomponent* icalcomponent_new_vquery(void);
+icalcomponent* icalcomponent_new_vavailability(void);
+icalcomponent* icalcomponent_new_xavailable(void);
+icalcomponent* icalcomponent_new_vpoll(void);
#endif /* !ICALCOMPONENT_H */
diff -Naur libical-dev_1.0-1.3_amd64/usr/include/libical/icalderivedparameter.h libical-dev_1.0.1-0.1_amd64/usr/include/libical/icalderivedparameter.h
--- libical-dev_1.0-1.3_amd64/usr/include/libical/icalderivedparameter.h 2015-01-03 14:59:18.0 +0100
+++ libical-dev_1.0.1-0.1_amd64/usr/include/libical/icalderivedparameter.h 2015-08-19 19:28:06.0 +0200
@@ -60,15 +60,18 @@
ICAL_MEMBER_PARAMETER = 18,
ICAL_OPTIONS_PARAMETER = 19,
ICAL_PARTSTAT_PARAMETER = 20,
+ICAL_PUBLICCOMMENT_PARAMETER = 37,
ICAL_RANGE_PARAMETER = 21,
ICAL_RELATED_PARAMETER = 22,
ICAL_RELTYPE_PARAMETER = 23,
+ICAL_RESPONSE_PARAMETER = 38,
ICAL_ROLE_PARAMETER = 24,
ICAL_RSVP_PARAMETER = 25,
ICAL_SCHEDULEAGENT_PARAMETER = 34,
ICAL_SCHEDULEFORCESEND_PARAMETER = 35,
ICAL_SCHEDULESTATUS_PARAMETER = 36,
ICAL_SENTBY_PARAMETER = 26,
+ICAL_STAYINFORMED_PARAMETER = 39,
ICAL_TZID_PARAMETER = 27,
ICAL_VALUE_PARAMETER = 28,
ICAL_X_PARAMETER = 29,
@@ -157,7 +160,8 @@
ICAL_RELTYPE_PARENT = 20047,
ICAL_RELTYPE_CHILD = 20048,
ICAL_RELTYPE_SIBLING = 20049,
-ICAL_RELTYPE_NONE = 20050
+ICAL_RELTYPE_NONE = 20050,
+ICAL_RELTYPE_POLL = 20107
} icalparameter_reltype;
typedef enum icalparameter_role {
@@ -190,6 +194,13 @@
ICAL_SCHEDULEFORCESEND_NONE = 20068
} icalparameter_scheduleforcesend;
+typedef enum icalparameter_stayinformed {
+ICAL_STAYINFORMED_X = 20108,
+ICAL_STAYINFORMED_TRUE = 20109,
+ICAL_STAYINFORMED_FALSE = 20110,
+ICAL_STAYINFORMED_NONE = 20111
+} icalparameter_stayinformed;
+
typedef enum icalparameter_value {
ICAL_VALUE_X = 20069,
ICAL_VALUE_BINARY = 20070,
@@ -237,7 +248,7 @@
ICAL_XLICERRORTYPE_NONE = 20106
} icalparameter_xlicerrortype;
-#define ICALPARAMETER_LAST_ENUM 20107
+#define ICALPARAMETER_LAST_ENUM 20112
/* ACTIONPARAM */
icalparameter* icalparameter_new_actionparam(icalparameter_action v);
@@ -344,6 +355,11 @@
icalparameter_partstat icalparameter_get_partstat(const icalparameter* value);
void icalparameter_set_partstat(icalparameter* value, icalparameter_partstat v);
+/* PUBLIC-COMMENT */
+icalparameter* icalparameter_new_publiccomment(const char* v);
+const char* icalparameter_get_publiccomment(const icalparameter* value);
+void icalparameter_set_publiccomment(icalparameter* value, const char* v);
+
/* RANGE */
icalparameter*
Bug#796998: RFS: sfcgal/1.1.0
Hi Sven, Thanks for your work on sfcgal. On 26-08-15 20:17, Sven Geggus wrote: I have just uploaded a new Version of sfcgal to mentors.debian.net. This is a very minor change. I included a patch from upstream which will make it compile again using boost boost 1.58 and gcc5 The Tracker reports a missing symbols in the builds logs, see: https://tracker.debian.org/pkg/sfcgal https://qa.debian.org/bls/packages/s/sfcgal.html To fix this you need to update the symbols file again using the build logs (with pkgkde-getbuildlogs pkgkde-symbolshelper). I took the liberty to fix this for you. Because of the switch to GCC 5 after the will very likely be more symbols changes on the other architectures. Keep an eye on the build status and update the symbols if any of the logs report dh_makeshlibs symbols diffs. https://buildd.debian.org/status/package.php?p=sfcgal The BTS also reports an outstanding bug that you should address in this upload, no need to postpone the fix. See: https://bugs.debian.org/src:sfcgal https://bugs.debian.org/794317 Because of the architecture dependent sfcgal-config Multi-Arch: same cannot be used for libsfgcal-dev, it will have to be Multi-Arch: foreign. https://wiki.debian.org/Multiarch/Implementation Also be aware that sfcgal will soon be part of the cgal GCC 5 transition that still needs to start. https://bugs.debian.org/790996 Please address the Multi-Arch bugreport and update the symbols for GCC 5, it should be ready for upload then. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#796941: followup
Hello KiBi, you were right, it was due to the missing apt-setup/use_mirror. I think we can close this particular braindropping-bug. On 26-08-15 13:08, Cyril Brulebois wrote: Hi, NeatNerdPrime neatnerdpr...@neatnerds.be (2015-08-26): Followup on this issue: The sources.list file in /target/etc/apt appear to be different when performing installation preseeded or manual. It appears that the sources.list file generated with the preseed method has forgotten to add the mirror settings and the updates section of apt. It is generated correctly in the manual case. Great, this explains what's happening here. You explicitly disabled the network mirror in your preseed file: apt-setup/use_mirror is set to false. No surprise that jessie and jessie-updates entries pointing to the network mirror are missing. ;) Mraw, KiBi.
Bug#796573: pu: package cross-gcc/14
Control: tags -1 + pending On Sun, 2015-08-23 at 00:59 +0100, Wookey wrote: +++ Adam D. Barratt [2015-08-22 22:51 +0100]: Control: tags -1 + jessie confirmed On Sat, 2015-08-22 at 18:17 +0100, Wookey wrote: cross-gcc-dev in stable has a serious bug: (780583) which means that if your default shell is not bash (or zsh) it simply won't work. As Debian defaults to dash for sh this a real problem making the package broken for the majority of users. The fix is a trivial one-liner (patch attached) which is very safe and thus seems appropriate for a stable update. [...] With the version fixed, and the changelog distribution set to jessie, please go ahead. OK, built, tested, uploaded (to the normal ftp.upload.debian.org where I understand uploads to 'jessie' are sent to s-p-u automatically - according to https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable ). My dupload config doesn't have a 'proposed-updates' defined, which older docs talk about explicitly uploading to. Well, they're sent to a policy queue called stable-new, from where the Release Team can accept them (or not) in to proposed-updates, but in essence, yes. Flagged for acceptance. Regards, Adam
Bug#609656: squeeze's screen doesn't like $TERM=rxvt-256color
On Mi, 26 aug 15, 17:54:17, Axel Beckert wrote: I'll add a Suggests: ncurses-term to screen. I don't want to use recommends, because it's always a big discussion if ncurses-term causes more harm than good. Sounds reasonable. Thanks for looking into it. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Bug#796998: RFS: sfcgal/1.1.0
Package: sponsorship-requests Severity: normal Hello, I have just uploaded a new Version of sfcgal to mentors.debian.net. This is a very minor change. I included a patch from upstream which will make it compile again using boost boost 1.58 and gcc5 * Package name: sfcgal Version : 1.1.0-3 Upstream Author : Mickael Borne (IGN), Hugo Mercier (Oslandia), Vincent Mora (Oslandia), Olivier Courtin (Oslandia) * URL : http://www.sfcgal.org/ * License : LGPL-2+ Section : science Sources have already been uploaded to alioth and are availabe via the following URL: git+ssh://git.debian.org/git/pkg-grass/sfcgal.git Regards Sven -- Exploits and holes are a now a necessary protection against large corporate interests. (Alan Cox) /me is giggls@ircnet, http://sven.gegg.us/ on the Web signature.asc Description: Digital signature
Bug#796999: apt: segmentation fault
Package: apt Version: 1.1~exp10 Severity: grave # apt-get upgrade Segmentation faultsts... 32% # apt-cache policy apt Segmentation fault This is on i386. -- Jakub Wilk
Bug#785977: libgetdata: diff for NMU version 0.7.3-6.2
Control: tags 785977 + patch Control: tags 785977 + pending Dear maintainer, I've prepared an NMU for libgetdata (versioned as 0.7.3-6.2) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards, SR diff -Nru libgetdata-0.7.3/debian/changelog libgetdata-0.7.3/debian/changelog --- libgetdata-0.7.3/debian/changelog 2015-08-14 02:41:12.0 -0700 +++ libgetdata-0.7.3/debian/changelog 2015-08-26 12:46:29.0 -0700 @@ -1,7 +1,15 @@ +libgetdata (0.7.3-6.2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Port from python-support to dh_python2 (Closes: #785977) + * Call dh_numpy, to generate dependencies based on the numpy ABI. + + -- Stefano Rivera stefa...@debian.org Wed, 26 Aug 2015 11:55:50 -0700 + libgetdata (0.7.3-6.1) unstable; urgency=medium * Non-maintainer upload. - * Build against gcc5/gfortran for transition. + * Build against gcc5/gfortran for transition. -- Alastair McKinstry mckins...@debian.org Fri, 14 Aug 2015 10:40:54 +0100 diff -Nru libgetdata-0.7.3/debian/control libgetdata-0.7.3/debian/control --- libgetdata-0.7.3/debian/control 2011-09-19 14:27:07.0 -0700 +++ libgetdata-0.7.3/debian/control 2015-08-26 12:46:36.0 -0700 @@ -2,7 +2,7 @@ Priority: extra Maintainer: Michael Milligan mmilli...@astro.umn.edu Uploaders: Steven Benton steveben...@rogers.com -Build-Depends: debhelper (= 7.0.50~), autotools-dev, python-numpy, python-all-dev, python-support (= 0.90), fortran-compiler +Build-Depends: debhelper (= 7.0.50~), autotools-dev, dh-python, python-numpy, python-all-dev, fortran-compiler Standards-Version: 3.9.2 DM-Upload-Allowed: yes Section: libs diff -Nru libgetdata-0.7.3/debian/python-pygetdata.install libgetdata-0.7.3/debian/python-pygetdata.install --- libgetdata-0.7.3/debian/python-pygetdata.install 2011-07-07 15:17:35.0 -0700 +++ libgetdata-0.7.3/debian/python-pygetdata.install 2015-08-26 12:31:04.0 -0700 @@ -1 +1 @@ -/usr/lib/python* +/usr/lib/python2.*/*-packages/*.so diff -Nru libgetdata-0.7.3/debian/rules libgetdata-0.7.3/debian/rules --- libgetdata-0.7.3/debian/rules 2011-07-18 12:24:11.0 -0700 +++ libgetdata-0.7.3/debian/rules 2015-08-26 12:46:41.0 -0700 @@ -12,7 +12,7 @@ PYVERS=$(shell pyversions -vs) %: - dh $@ + dh $@ --with python2 override_dh_auto_configure: dh_auto_configure -Bbuild-main -- --disable-python @@ -37,6 +37,7 @@ for v in $(PYVERS); do \ dh_auto_install -Bbuild-py$$v; \ done + dh_numpy override_dh_auto_clean: dh_auto_clean -Bbuild-main diff -Nru libgetdata-0.7.3/debian/watch libgetdata-0.7.3/debian/watch --- libgetdata-0.7.3/debian/watch 2011-07-19 06:33:07.0 -0700 +++ libgetdata-0.7.3/debian/watch 2015-08-26 11:55:11.0 -0700 @@ -1,4 +1,3 @@ version=3 http://sf.net/getdata/getdata-(.*)\.tar\.gz -
Bug#796870: Further update
The patch fixes the crash, however, the message output when such messages are viewed doesn't actually help verify the problematic emails. I have moved ~/.gnupg/pubring.gpg* aside and the message still appears - the key needs to be reimported to allow verification. I suggest that the message is updated to indicate this (although the message is already quite long). Instead of: The signature can't be checked - End of file. Removing left-over ~/.gnupg/pubring.gpg might solve the problem if you have installed gpg-v21 Possibly: The signature can't be checked. If you have installed gpg-v21, remove ~/.gnupg/pubring.gpg and reimport the key. Alternatively, claws-mail could check for the existence of gpgv-21 (by finding pubring.kbx) and skip that part of the message. My preference would be for the crash to be fixed first and the message improvement later. Further, my public key also had to be re-imported before claws could sign this email. OK, the string output by this patch is actually quite pointless. Yes, moving pubring.gpg and reimporting the key allows verification but importing the key simply regenerates pubring.gpg too - the same size as before. So removing the file has no effect at all. The key simply needs to be reimported. Possibly: The signature can't be checked. If you have installed gpg-v21, remove ~/.gnupg/pubring.gpg and reimport the key. The signature can't be checked. If you have installed gpg-v21, the key needs to be reimported. Alternatively, claws-mail could check for the existence of gpgv-21 (by finding pubring.kbx) and skip that part of the message. ... The signature can't be checked. The key needs to be reimported for compatibility your updated gpg. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpd9_m2VDTqq.pgp Description: OpenPGP digital signature
Bug#796995: game-data-packager: Doom Quake1 add support for GOG.com package
Package: game-data-packager Version: 42 Severity: wishlist Tags: newcomer From today, Doom Quake 1 ara available on GOG.com too. http://www.gog.com/promo/bethesda_launch_id_software_bundle_260815 g-d-p should already be able to package these games in two steps: - innoextract setup-*doom*.exe -d /tmp - game-data-packager doom /tmp If you bought these games, please provide output of game-data-packager make-template setup-.exe in order to fully automate game assets packaging. Thanks ! -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (450, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-1-amd64 (SMP w/6 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages game-data-packager depends on: ii fakeroot1.20.2-1 ii python3 3.4.3-4 ii python3-debian 0.1.27 ii python3-yaml3.11-2 pn python3:any none game-data-packager recommends no packages. Versions of packages game-data-packager suggests: ii arj 3.10.22-14 ii binutils 2.25.1-1 ii cabextract1.6-1 ii cdparanoia3.10.2+debian-11 ii dynamite 0.1.1-2 ii gcc 4:4.9.2-4 ii gir1.2-gtk-3.03.16.6-1 ii gir1.2-pango-1.0 1.36.8-3 pn innoextract none ii lgc-pg1.3.0-1 ii lhasa [lzh-archiver] 0.3.0-2 ii make 4.0-8.1 ii p7zip-full9.20.1~dfsg.1-4.2 ii python3-gi3.16.2-1 ii unace-nonfree 2.5-8 ii unar 1.8.1-4 ii unrar 1:5.3.2-1 ii unshield 1.0-1 ii unzip 6.0-18 ii vorbis-tools 1.4.0-6 -- Configuration Files: /etc/bash_completion.d/game-data-packager 2c4fd36c89462ca56d14cf6cdfb9cd29 [Errno 2] Aucun fichier ou dossier de ce type: u'/etc/bash_completion.d/game-data-packager 2c4fd36c89462ca56d14cf6cdfb9cd29' /etc/game-data-packager.conf changed [not included] -- no debconf information -- debsums errors found: debsums: changed file /usr/share/applications/doom2-masterlevels.desktop (from game-data-packager package)
Bug#797002: dh_strip manpage: incorrectly claims that ddebs are enabled by default
Package: debhelper Version: 9.20150811 The dh_strip manpage claims that ddebs are built by default, which is not the case. It also doesn't say how to enable them. -- Jakub Wilk
Bug#797004: mysql-server 5.5.44-0+deb8u1 not installable on fresh install of Stretch
Package: mysql-server-5.5 Version: 5.5.44-0+deb8u1 Severity: important Dear Maintainer, * What led up to the situation? Trying to setup MythTV which requires mysql-server. Tried to install and it failed. This machine is a fresh install of Stretch (testing). If I remember right, been a week since, mariadb was removed so mysql could be installed I have searched but not found this exact issue. When the install is attempted it asks for a root password then fails. from /var/log/mysql/error.log 150826 14:30:29 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 150826 14:30:29 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead. 150826 14:30:29 [Note] /usr/sbin/mysqld (mysqld 5.5.44-0+deb8u1) starting as process 30358 150826 14:30:29 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead. 150826 14:30:29 [Note] Plugin 'FEDERATED' is disabled. /usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist 150826 14:30:29 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it. 150826 14:30:29 InnoDB: The InnoDB memory heap is disabled 150826 14:30:29 InnoDB: Mutexes and rw_locks use GCC atomic builtins 150826 14:30:29 InnoDB: Compressed tables use zlib 1.2.8 150826 14:30:29 InnoDB: Using Linux native AIO 150826 14:30:29 InnoDB: Initializing buffer pool, size = 128.0M 150826 14:30:29 InnoDB: Completed initialization of buffer pool 150826 14:30:29 InnoDB: highest supported file format is Barracuda. 150826 14:30:29 InnoDB: Waiting for the background threads to start 150826 14:30:30 InnoDB: 5.5.44 started; log sequence number 1595675 150826 14:30:30 [ERROR] /usr/sbin/mysqld: unknown variable 'plugin-load- add=unix_socket=auth_socket.so' 150826 14:30:30 [ERROR] Aborting 150826 14:30:30 InnoDB: Starting shutdown... 150826 14:30:31 InnoDB: Shutdown completed; log sequence number 1595675 150826 14:30:31 [Note] /usr/sbin/mysqld: Shutdown complete 150826 14:30:31 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mysql-server-5.5 depends on: ii adduser 3.113+nmu3 ii debconf [debconf-2.0] 1.5.57 ii initscripts 2.88dsf-59.2 ii libc62.19-19 ii libdbi-perl 1.633-1 ii libgcc1 1:5.1.1-14 ii libstdc++6 5.1.1-14 ii lsb-base 4.1+Debian14 ii mysql-client-5.5 5.5.44-0+deb8u1 ii mysql-common 5.5.44-0+deb8u1 ii mysql-server-core-5.5 5.5.44-0+deb8u1 ii passwd 1:4.2-3 ii perl 5.20.2-6 ii psmisc 22.21-2 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages mysql-server-5.5 recommends: ii libhtml-template-perl 2.95-2 Versions of packages mysql-server-5.5 suggests: ii heirloom-mailx [mailx] 12.5-5 pn tinyca none -- debconf information: mysql-server/no_upgrade_when_using_ndb: mysql-server-5.5/postrm_remove_databases: false * mysql-server/password_mismatch: * mysql-server/error_setting_password: mysql-server-5.5/start_on_boot: true mysql-server-5.5/really_downgrade: false mysql-server-5.5/nis_warning: -- If it ain't broke tweek it
Bug#791464: bird6: /etc/bird6.conf not migrated in jessie upgrade
Christoph Biedl wrote... In other words, the patch below attributes /etc/bird6.conf correctly and fixes the problem for me. Please review carefully. And please fix this via a jessie point release, assuming routers are usually upgraded rather late, hence there's a chance to avoid that situation on many systems. Gentle ping? The next point release is pretty close, so if you can take care of this within the next two days, that'd be great. Christoph signature.asc Description: Digital signature
Bug#797006: subunit: please support DEB_BUILD_OPTIONS=nocheck
Source: subunit Severity: minor Dear subunit-maintainers, to help the bootstraping folks, please consider supporting skipping the testsuite, as there is a dependency loop on check. Many thanks! -- tobi -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#792382: flamethrower: diff for NMU version 0.1.8-3.1
On Wed, Aug 26, 2015 at 04:01:00PM +0200, gregor herrmann wrote: Dear maintainer, I've prepared an NMU for flamethrower (versioned as 0.1.8-3.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. Great, thanks!
Bug#622265: TERM=screen.mlterm breaks dircolors
On 2015-08-26 12:05, Axel Beckert wrote: Matthew Gabeler-Lee wrote: This isn't just mlterm. This breaks xterm, xterm-256color, etc. too I'm sorry, but while I can reproduce the issue with env TERM=mlterm screen, I can't reproduce it with env TERM=xterm-256color screen (on Jessie). In the latter case, dircolors just look fine to me. I'm on stretch (testing) personally. Launching screen inside gnome-terminal is b0rked because of this for me, or at least it was until I added logic to my ~/.bashrc to undo these broken TERM values and push everything back to just being screen. Some systems don't even think the munged TERM values are real and cause problems like less complaining WARNING: terminal is not fully functional. That's IMHO a different issue. You should be able to work around it by either uninstalling ncurses-term locally or installing it remotely. IIRC if screen can't find the according terminfo entries, it won't use them and hence won't change $TERM to something more fancy than just screen. I'm hitting this when using ssh from within a local screen. I can't demand that the sysadmins of every old non-Debian system I might want to SSH to install a potentially unavailable package on their servers. And if I uninstall ncurses-term on my local system, then trying to connect to my from inside a screen on another system that does have that package will be broken. There needs to somehow be a trade-off here between supporting the newer terminal features inside the screen session and not breaking access to older systems. I doubt the openssh folks would be impressed by an enhancement request to support conditional expression-based changes to the TERM variable, not to mention the degenerate case of plain old telnet. The best compromise I can come up with at the moment is an option to screen to disable this munging and just use plain old TERM=screen within a given session. That (plus the fix to dircolors, which from the other recent email seems like an independent issue) would be a usable workaround / compromise for me. That would be an upstream feature request I guess...
Bug#796589: apparmor: Has init script in runlevel S but no matching service file
Hi, here are my initial notes and (incomplete) drafts, partly inspired by OpenSuSe's unit. I think we'll need at least two units. That's kind of blocked by the ongoing discussion on /usr and click-specific bits, though. sys-kernel-security.mount = [Unit] Description=Security File System Documentation=XXX DefaultDependencies=no ConditionPathExists=/sys/kernel/security [Mount] What=none Where=/sys/kernel/security Type=securityfs apparmor-load-policy.service [Unit] Description=Load AppArmor profiles DefaultDependencies=no # Load policy before bringing up the first network interface, # to be able to confine processes that access the network early, # such as dhclient: Wants=network-pre.target Before=network-pre.target # ... however, let's not add an exagerated Before=basic.target # or Before=sysinit.target, meant to ensure that the policy for basic system # services is applied: in most case that's not needed, and it is prone # to introducing dependency loops # (https://wiki.debian.org/Teams/pkg-systemd/rcSMigration). # Instead, basic system services that should be confined with AppArmor # should add an After=apparmor.service, just like it's done already e.g. # by networking.service (Debian -specific) and libvirtd.service. After=local-fs.target systemd-journald-audit.socket RequiresMountsFor=/sys/kernel/security # XXX: do we need to do anything at shutdown? # If yes, then add Conflicts=shutdown.target and Before=shutdown.target, # or we won't be gracefully stopped on shutdown due to DefaultDependencies=no. ConditionSecurity=apparmor ConditionPathIsReadWrite=/sys/kernel/security/apparmor/.load ConditionVirtualization=!container # do not perform start/stop/reload actions when running from the Ubuntu liveCD: ConditionPathExists=!/rofs/etc/apparmor.d Documentation=man:apparmor(7) Documentation=http://wiki.apparmor.net/ [Service] Type=oneshot ExecStart=XXX ExecReload=XXX ExecRestart=XXX ExecStop=XXX RemainAfterExit=yes # XXX: if we do anything else than trivially loading policy in ExecStart=, # then we may need to add RequiresMountsFor=/usr (see the corresponding discussion # on Debian#782700); hopefully it won't be the case, as it would almost # certainly break the /usr on a remote filesystem use case, e.g. because # of our Before=network-pre.target. [Install] WantedBy=multi-user.target Cheers, -- intrigeri
Bug#793536: liblingua-de-ascii-perl: diff for NMU version 0.11-1.1
Control: tags 793536 + patch Control: tags 793536 + pending Dear maintainer, I've prepared an NMU for liblingua-de-ascii-perl (versioned as 0.11-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Beatles: I'm The Walrus diff -u liblingua-de-ascii-perl-0.11/debian/changelog liblingua-de-ascii-perl-0.11/debian/changelog --- liblingua-de-ascii-perl-0.11/debian/changelog +++ liblingua-de-ascii-perl-0.11/debian/changelog @@ -1,3 +1,12 @@ +liblingua-de-ascii-perl (0.11-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #793536) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 17:40:51 +0200 + liblingua-de-ascii-perl (0.11-1) unstable; urgency=low * Initial release (Closes: #377220). diff -u liblingua-de-ascii-perl-0.11/debian/rules liblingua-de-ascii-perl-0.11/debian/rules --- liblingua-de-ascii-perl-0.11/debian/rules +++ liblingua-de-ascii-perl-0.11/debian/rules @@ -41,7 +41,7 @@ dh_clean -k $(MAKE) test - $(MAKE) install PREFIX=$(CURDIR)/debian/liblingua-de-ascii-perl/usr \ + $(MAKE) install DESTDIR=$(CURDIR)/debian/liblingua-de-ascii-perl \ MAN3EXT=3perl rm -f $(CURDIR)/debian/liblingua-de-ascii-perl/usr/share/man/man3/*.3pm signature.asc Description: Digital Signature
Bug#795611: libpoe-component-client-ident-perl: diff for NMU version 1.07-2.1
Control: tags 795611 + patch Control: tags 795611 + pending Dear maintainer, I've prepared an NMU for libpoe-component-client-ident-perl (versioned as 1.07-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: The Dubliners: Sam Hall diff -u libpoe-component-client-ident-perl-1.07/debian/rules libpoe-component-client-ident-perl-1.07/debian/rules --- libpoe-component-client-ident-perl-1.07/debian/rules +++ libpoe-component-client-ident-perl-1.07/debian/rules @@ -76,7 +76,7 @@ dh_clean -k dh_installdirs - $(MAKE) install PREFIX=$(DEST_DIR)/usr + $(MAKE) install DESTDIR=$(DEST_DIR) [ ! -d $(DEST_DIR)/usr/lib/perl5 ] || \ rmdir --ignore-fail-on-non-empty --parents $(DEST_DIR)/usr/lib/perl5 touch install-stamp diff -u libpoe-component-client-ident-perl-1.07/debian/changelog libpoe-component-client-ident-perl-1.07/debian/changelog --- libpoe-component-client-ident-perl-1.07/debian/changelog +++ libpoe-component-client-ident-perl-1.07/debian/changelog @@ -1,3 +1,12 @@ +libpoe-component-client-ident-perl (1.07-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR instead of PREFIX in debian/rules. +(Closes: #795611) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 17:54:21 +0200 + libpoe-component-client-ident-perl (1.07-2) unstable; urgency=low * Fix failure to build with perl 5.10 signature.asc Description: Digital Signature
Bug#609656: squeeze's screen doesn't like $TERM=rxvt-256color
Hi, Andrei POPESCU wrote: I'm on sid machine, with rxvt-unicode 9.09-3. If I ssh to a squeeze machine and try to start screen I get: $ screen Cannot find terminfo entry for 'rxvt-256color'. $ Please install ncurses-term on that machine. That should fix it because that package contains those missing definitions, even already on Squeeze. # dpkg -S rxvt-256color ncurses-term: /usr/share/terminfo/m/mrxvt-256color ncurses-term: /usr/share/terminfo/r/rxvt-256color # lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 6.0.10 (squeeze) Release:6.0.10 Codename: squeeze # I'll add a Suggests: ncurses-term to screen. I don't want to use recommends, because it's always a big discussion if ncurses-term causes more harm than good. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#795679: set-crontab-perl: diff for NMU version 1.02-1.1
Control: tags 795679 + patch Control: tags 795679 + pending Dear maintainer, I've prepared an NMU for set-crontab-perl (versioned as 1.02-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Red Hot Chili Peppers: Desecration Smile diff -u set-crontab-perl-1.02/debian/rules set-crontab-perl-1.02/debian/rules --- set-crontab-perl-1.02/debian/rules +++ set-crontab-perl-1.02/debian/rules @@ -41,7 +41,7 @@ dh_installdirs # Add here commands to install the package into debian/tmp. - $(MAKE) install PREFIX=$(TMP)/usr; \ + $(MAKE) install DESTDIR=$(TMP) # Build architecture-independent files here. binary-indep: build install diff -u set-crontab-perl-1.02/debian/changelog set-crontab-perl-1.02/debian/changelog --- set-crontab-perl-1.02/debian/changelog +++ set-crontab-perl-1.02/debian/changelog @@ -1,3 +1,12 @@ +set-crontab-perl (1.02-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #795679) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 18:41:01 +0200 + set-crontab-perl (1.02-1) unstable; urgency=low * New upstream release. signature.asc Description: Digital Signature
Bug#682580: [bug-gettext] Bug#682580: xgettext: fails to properly replace some placeholders in output .pot (PACKAGE, YEAR, C. HOLDER) (fwd)
On Tue, 25 Aug 2015 11:58:31 +0900 Daiki Ueno wrote: Francesco Poli invernom...@paranoici.org writes: I'd definitely vote for 3, but, wait!, even better, I would add a new option named --copyright-notices (or maybe there's a better name, I don't know...), where all the copyright notices may be specified with their own line breaks, as in: I'm afraid it would break configurability through po/Makevars, since a make variable including a multi-line argument cannot be used in a portable Makefile. That's unfortunate. By the way, if we chose (4), the patch would be like the attached, which reads the file po/HEADER (if exists) and insert the content into POT file. The file would look like: # Copyright (C) 2001-2012 Python Software Foundation. # Copyright (C) 2000 BeOpen.com. # Copyright (C) 1995-2000 Corporation for National Research Initiatives. # Copyright (C) 1991-1995 Stichting Mathematisch Centrum. If this is sufficient, I would revert the multiple --copyright-holder change, as I am reluctant to add new option to xgettext, which already has too many options. I would definitely prefer to see xgettext changed, rather than having to do sed or awk tricks to post-process its output. So, to me, (4) is the least preferred option. Since multi-line arguments cause problems, maybe an option named --copyright-notice could be implemented in xgettext, to be used multiple times as in: $ xgettext --copyright-notice=Copyright (C) 2001-2012 Python Software Foundation. \ --copyright-notice=Copyright (C) 2000 BeOpen.com. \ --copyright-notice=Copyright (C) 1995-2000 Corporation for National Research Initiatives. \ --copyright-notice=Copyright (C) 1991-1995 Stichting Mathematisch Centrum. \ --package-name=myapplication --package-version=0.1 \ --language=python myapplication.py -o myapplication2.pot Again, this would cause myapplication2.pot to include: # Copyright (C) 2001-2012 Python Software Foundation. # Copyright (C) 2000 BeOpen.com. # Copyright (C) 1995-2000 Corporation for National Research Initiatives. # Copyright (C) 1991-1995 Stichting Mathematisch Centrum. in stead of: # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER I hope you think this is a good suggestion. Please let me know, thanks for your time! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! . Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE pgpSr4uEzrHcX.pgp Description: PGP signature
Bug#796088: jessie-pu: package libvirt/1.2.9-9+deb8u1
Control: tags -1 + pending On Wed, 2015-08-26 at 09:58 +0200, Guido Günther wrote: Hi, On Mon, Aug 24, 2015 at 10:16:40PM +0100, Adam D. Barratt wrote: Control: tags -1 + confirmed On Mon, 2015-08-24 at 20:10 +0200, intrigeri wrote: Control: tag -1 - moreinfo Hi, Guido Günther wrote (20 Aug 2015 11:57:36 GMT) : On Wed, Aug 19, 2015 at 04:53:32PM +0100, Adam D. Barratt wrote: I have to admit that I'm also confused by the patch for #786650: [...] We've discussed this on #786650, and as a result here's an updated debdiff: the only change, compared to the one Guido submitted initially, is that Allow-access-to-libnl-3-config-files.patch now does not include these changes, that are unrelated to #786650, that this patch as meant to fix. That means it also still contains the typo where it claims to fix bug #7788171. :-) I've just built and tested on Jessie, and could successfully start a VM with AppArmor enforced. Thanks. Please feel free to upload, preferably with the changelog typo fixed. Uploaded with the bugnumber fixed. Thanks intrigeri, Adam and Felix! Flagged for acceptance, thanks. Regards, Adam
Bug#724518: openldap: Patch to allow bootstrapping without heimdal-dev
On Wed, Aug 26, 2015 at 12:26 PM, Helmut Grohne hel...@subdivi.de wrote: Control: user helm...@debian.org Control: usertags + rebootstrap Hi Ryan and Daniel, Thanks to Daniel for highlighting this bug to me. I know I'm being late to the party, but let us please reconsider this stage before uploading. On Tue, Aug 25, 2015 at 12:51:56PM -0700, Ryan Tandy wrote: No hurry. Revised patch attached... I think it's correct, but would appreciate a thumbs-up when you have time. Thanks a lot for your help! I think that when adding a stage one should look further than just the immediate cycle. This is the main reason that prevented me from submitting a stage for openldap: I was lacking assurance that I was doing it correctly. Given further testing I now have somewhat more confidence, so let me propose a very different stage1: --disable-slapd Why does this make sense? This stage builds way less than the stage proposed by Daniel. It also drops heimdal, but it also drops cyrus-sasl2. Keep in mind that cyrus-sasl2 and openldap do have a direct cycle that needs to be addressed in either cyrus-sasl2 or openldap. So rather than add yet another stage to drop libsasl2-dev or add a stage to cyrus-sasl2 dropping libldap2-dev, I therefore think that openldap's stage1 should also drop the libsasl2-dev dependency. Turns out the easiest way to do so is just not building the server. I am attaching my current stage1 for openldap for discussion. What do you think? I don't have any objections - based on my experience, just libldap2-dev and dependencies are sufficient for progressing the bootstrap. On the other hand, I also have a cyrus-sasl2 bootstrap that also gets rid of krb5-multidev, libpq-dev, heimdal-multidev, libmysqlclient-dev, libkrb5-dev Build-Depends in addition to libldap2-dev; so unless you have a drastically different bootstrapping process that makes those dependencies available, I don't see it reducing the number of bootstrap builds needed. I also don't see your patch removing the openldap Build-Depends on libsasl2-dev. -- Daniel
Bug#796870: Confirming patch
tag 796870 - moreinfo tag 796870 + patch thanks The patch fixes the crash, however, the message output when such messages are viewed doesn't actually help verify the problematic emails. I have moved ~/.gnupg/pubring.gpg* aside and the message still appears - the key needs to be reimported to allow verification. I suggest that the message is updated to indicate this (although the message is already quite long). Instead of: The signature can't be checked - End of file. Removing left-over ~/.gnupg/pubring.gpg might solve the problem if you have installed gpg-v21 Possibly: The signature can't be checked. If you have installed gpg-v21, remove ~/.gnupg/pubring.gpg and reimport the key. Alternatively, claws-mail could check for the existence of gpgv-21 (by finding pubring.kbx) and skip that part of the message. My preference would be for the crash to be fixed first and the message improvement later. Further, my public key also had to be re-imported before claws could sign this email. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpwBPla0dP9L.pgp Description: OpenPGP digital signature
Bug#738161: cmake: Patch to bootstrap without Qt
Maybe use d-cross@l.d.o for profile questions in general (even when they affect native building)? I believe all profile people are subscribed there. On Wed, Aug 26, 2015 at 07:16:26PM +0200, Johannes Schauer wrote: It indeed uses filter as Daniel already pointed out. Yes, please always use filter for testing profiles. Having one canonical way of doing so helps with reading the code later. A difference between using the system libraries vs. the bundled one might be the feature set that curl is built with. Afaik cmake uses curl to submit test results to a dashboard and to allow downloading files during a build. I wouldn't expect differences in curl to impact cmake in the context of Debian package builds. On the other hand, it would impact user-visible functionality. See for example http://www.cmake.org/pipermail/cmake/2014-October/058911.html. So, doing this without a rename of the resulting cmake package would technically violate the requirement we're discussing. Whether it's a small enough violation that it could be ignored, I don't really know. I'd be fine with adding this to cmake. Please let me know if this would be useful. I CC-ed Helmut who is currently the best person to know whether making libcurl*-dev optional for src:cmake makes any sense at all or not. Is this for the native bootstrap? I think cmake should not be part of the cross bootstrap. curl is part of the strong essential set on http://bootstrap.debian.net/essential.html. So you can assume that curl is available in the native bootstrap. In resolving the cross bootstrap manually, I figured that curl is indeed necessary and it will soon show up on rebootstrap[1]. The currently missing parts are cyrus-sasl2, openldap, libverto and krb5. For cyrus-sasl2 I already submitted a patch to make it build at #792851 and for openldap I will be proposing a stage1 that drops slapd. Thus we not only know that curl will be needed, but we also know that building curl without cmake is feasible. I conclude that curl will be available when building cmake (no matter whether native or cross). What was the original need that made you ponder dropping curl? Daniel, can you point out how you bootstrap stuff? I've seen you proposing stages in a number of cases where I thought that none should be necessary. I'm really curious: Maybe I am using too many stages in other places. rebootstrap currently stages glibc, libselinux, util-linux, file, db5.3, libidn, cracklib2 and pam. I am pondering to use stages for cdebconf, newt, libcap-ng, python2.7, cyrus-sasl2, openldap and systemd. Does any of those work without stages for you? Helmut [1] https://wiki.debian.org/HelmutGrohne/rebootstrap
Bug#724518: openldap: Patch to allow bootstrapping without heimdal-dev
On Wed, Aug 26, 2015 at 12:36:00PM -0700, Daniel Schepler wrote: I don't have any objections - based on my experience, just libldap2-dev and dependencies are sufficient for progressing the bootstrap. On the other hand, I also have a cyrus-sasl2 bootstrap that also gets rid of krb5-multidev, libpq-dev, heimdal-multidev, libmysqlclient-dev, libkrb5-dev Build-Depends in addition to libldap2-dev; so unless you have a drastically different bootstrapping process that makes those dependencies available, I don't see it reducing the number of bootstrap builds needed. I also don't see your patch removing the openldap Build-Depends on libsasl2-dev. Hmm, not sure what I saw here. My reasoning about cyrus-sasl2 is obviously wrong after looking closely enough. Indeed, cyrus-sasl2 already has DEB_BUILD_OPTIONS=no-ldap (not quite a stage but close). It's a while since I stared at the relevant graphs. What I can say for sure though is that the cross bootstrap still has trouble with perl and the thinner stage1 drops libperl-dev, which means that I can cross openldap without having to figure out Perl yet. There is no (apparent) cycle with Perl, so the need for this is less clear. I guess what is committed works, but it forces me to look into Perl. If this thinner stage1 works for you as well, maybe we can just use it? Helmut
Bug#789699: vulture review
On Tue, 25 Aug 2015 19:32:16 +0200 Daniel Stender deb...@danielstender.com
wrote:
On 25.08.2015 19:17, Gianfranco Costamagna wrote:
... yeah, this would be an option, Py3 as default is coming up, anyway.
This is going to be an enhancement for Prospector, which is on Py2, but I
think it runs Vulture
as an app, an not imports anything from it.
I'll take a look and come back!
I've rechecked now ... actually Prospector imports vulture.py to work with it.
A Py3 package
on the side would be reasonable to have it available when Prospector gets
transfered to Py3
some day in the future. There are also other reasons to prepare it, but to
build/run Vulture
solely on Py3 is a non option because of that.
A Py3 package on the side ... the binaries-have-conflict could be handled like
Jakub suggested
for python-afl.
For the name of binaries, I would prefer vulture{,3} over
python{,3}-vulture like Pylint does
it, but it appears Pybuild expects this ... does it?
Daniel
--
http://www.danielstender.com/blog/
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
Bug#796973: ITP: pseudo -- advanced tool for simulating superuser privileges
On Wed, Aug 26, 2015, at 08:35, Andrew Shadura wrote: * Package name: pseudo Version : 1.6.7. Upstream Author : Yocto Project, Wind River Systems Inc. * URL : https://www.yoctoproject.org/tools-resources/projects/pseudo * License : LGPL-2.1 Programming Lang: C Description : advanced tool for simulating superuser privileges The pseudo utility offers a way to run commands in a virtualized root environment, allowing ordinary users to run commands which give the illusion of creating device nodes, changing file ownership, and otherwise doing things necessary for creating distribution packages or filesystems. Pseudo has a lot of similarities to fakeroot but is a new implementation that improves on the problems seen using fakeroot. Pseudo is now extensively used by Poky as a replacement to fakeroot but can also be used standalone in many other use cases. Are there any drawbacks when compared to use of fakeroot? If there are none, shouldn't it supersed fakeroot ? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique de Moraes Holschuh h...@debian.org
Bug#738161: cmake: Patch to bootstrap without Qt
On Wed, Aug 26, 2015 at 11:23 AM, Helmut Grohne hel...@subdivi.de wrote: In resolving the cross bootstrap manually, I figured that curl is indeed necessary and it will soon show up on rebootstrap[1]. The currently missing parts are cyrus-sasl2, openldap, libverto and krb5. For cyrus-sasl2 I already submitted a patch to make it build at #792851 and for openldap I will be proposing a stage1 that drops slapd. Thus we not I've already submitted an openldap patch in #724518, and a maintainer was recently in contact with me about updating it to the newest Build-Profiles syntax and incorporating it. That patch, which just gets rid of slapd-smbk5pwd, is sufficient in my setup to get openldap bootstrapped. only know that curl will be needed, but we also know that building curl without cmake is feasible. I conclude that curl will be available when building cmake (no matter whether native or cross). What was the original need that made you ponder dropping curl? Daniel, can you point out how you bootstrap stuff? I've seen you proposing stages in a number of cases where I thought that none should be necessary. I'm really curious: Maybe I am using too many stages in other places. rebootstrap currently stages glibc, libselinux, util-linux, file, db5.3, libidn, cracklib2 and pam. I am pondering to use stages for cdebconf, newt, libcap-ng, python2.7, cyrus-sasl2, openldap and systemd. Does any of those work without stages for you? I test (native only) bootstrapping from a default pbuilder chroot + fakeroot, with no packages available to be installed except what's in that original chroot image. So that's why e.g. nomultilib bootstraps for at least zlib and libffi are useful for my case; and also, since apt-transport-https is not in this set, curl also isn't in this set. I also have numerous bootstrap scripts for the packages needed to make debhelper installable, which essentially start with debhelper built without po4a and then for the others dpkg -i --force-depends debhelper.deb plus po-debconf.deb, gettext.deb, etc. as needed. (I also want to make Architecture: all packages bootstrappable simultaneously, which I've achieved for the most part except for a large number of Java packages involved in maven - and mostly because of a few Build-Depends on fop, that spills over into the general bootstrapping problem.) As for cmake - curl, I don't have my notes on the exact cycle I wanted to break, but I think it involved the curl - krb5 Build-Depends. If you have a bootstrap process that can bootstrap krb5 and curl before cmake without requiring cross-compilation using cmake, that would be fine. As for the others you mentioned: I do have a complex bootstrap script for gcc + glibc to native bootstrap multilib compilers/libraries from the non-multilib environment; and I do use scripts for libselinux, util-linux, file (part of the debhelper dependency bootstrapping mentioned above), db5.3, libidn, cracklib2, pam, python2.7, cyrus-sasl2, openldap, systemd. (The script for util-linux just invokes the standard stage1 profile though, which is just a workaround for the fact that my driver script doesn't automatically try using build profiles at the moment.) I don't have anything for cdebconf, newt or libcap-ng. I can send my full set of current bootstrap scripts and patches to you, if you'd like. -- Daniel
Bug#797001: mesa-utils-extra: libEGL warning: DRI2: failed to authenticate
Package: mesa-utils-extra Version: 8.2.0-1 Severity: normal Dear maintainer, I'm trying to execute es2gears without success. I have to use a Qt program based on opengl es and I have the same error. Is opengl es supported correctly in Debian 8 for raspberry? If not when you think it will be? For me is very important. Regards. -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 8.0 (jessie) Release:8.0 Codename: jessie Architecture: armv6l Kernel: Linux 4.1.6+ (PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mesa-utils-extra depends on: ii libc6 2.19-18 ii libegl1-mesa [libegl1-x11] 10.3.2-1 ii libgles2-mesa [libgles2]10.3.2-1 ii libx11-62:1.6.2-3 ii libxext62:1.3.3-1 mesa-utils-extra recommends no packages. mesa-utils-extra suggests no packages. -- no debconf information
Bug#795611: libpoe-component-client-ident-perl: diff for NMU version 1.07-2.1
On Wed, 26 Aug 2015, gregor herrmann wrote: I've prepared an NMU for libpoe-component-client-ident-perl (versioned as 1.07-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Thanks gregor! Feel free to just upload it immediately. -- Don Armstrong http://www.donarmstrong.com Science is a way of trying not to fool yourself. The first principle is that you must not fool yourself, and you are the easiest person to fool. -- Richard Feynman What is and What Should be the Role of Scientific Culture in Modern Society; 1964
Bug#797000: ITP: oxidized -- network device configuration backup tool
Package: wnpp Severity: wishlist Owner: Jonas Genannt gena...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: oxidized Version : 0.7.2 Upstream Author : Saku Ytti s...@ytti.fi * URL : https://github.com/ytti/oxidized * License : Apache-2.0 Programming Lang: Ruby Description : network device configuration backup tool backup your network devices (router, switches) to a file or git based backend. Oxidized supports many network decives and could be easily extended to new supported devices. Oxidized also monitors router inventory, it's a rancid replacement. Maintained by the Ruby PKG Team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJV3g0XAAoJEPBM7/YBbP/Qf98P/injArnwcpHGI5ScMdUNTMSd Yhc6L4Z2ZMszt0kol9N7Uiz1BYA7kmstYaLeNBUc0oahWaJkLaz5m74fTYsUx8D8 0BoJWjPGz7dLanDTf3BWdH6We+WItkecacN9B57w+KoKOzE6VWahGUjDhqhQ1j/u 1IhiF3NKNV8MxcZDmo1TgoFLRPX2HwSQxZ0nEeNi+b45csDNdpSTIQK0bSXjyu8o P9PPUFumghYrm4oql8RWkJ0UTin3zVnhwn/8VdJezgGptHGUFYZFD2vc+0HZMqPM DBSfzrs0vSAMzi1+Qzc8NnbRi4f5+L5yQuUQRiST6N/WOUEkh4ELUJMbnhi20wBe BsVtfQvjKoTvWI3mlq20PSYUz/uXU1bz/o+Ic5UzTP+kqNsQgOBCjc+zKo0n+/aa TWQCqskTt6PvXOQBDhCjq+R0wuflYkpKulNNvvuSnGZxoEHGba0xlJ/qRxwae6PV oLn+SGbIQL441Q6HDhieDiJVF4UtYyoDKC9jAtlzrEoX2rNiguy+lIy0QDXcmdnB h/8TalIOdYmG/UVGsoevT+LckL++sE7kHMq6YxhK46uIJTPl20L0KIgeUzWWXD5J OHppBBsjLs4D4EvVM0uxlJAnT5WY1izRROqCYflfvX5LN+kYi9ApKWLhlulPe4yP mmMJnhWaiO3EjBEXvxBV =K+hx -END PGP SIGNATURE-
Bug#794090: jessie-pu: package ruby2.1/2.1.5-2+deb8u2
Control: tags -1 + pending On Tue, 2015-08-25 at 21:34 -0300, Antonio Terceiro wrote: On Mon, Aug 17, 2015 at 04:33:07PM +0100, Adam D. Barratt wrote: Control: tags -1 + confirmed On Thu, 2015-07-30 at 09:06 -0300, Antonio Terceiro wrote: Hi, I would like to upload the attached diff as a stable update for ruby2.1, fixing a minor security bug that didn't qualify for a DSA. Te following patches were cherry-picked from upstream: http://anonscm.debian.org/cgit/collab-maint/ruby.git/commit/?h=debian/jessieid=9b945cadc3b157829a60debff1dd5c536644f9b2 http://anonscm.debian.org/cgit/collab-maint/ruby.git/commit/?h=debian/jessieid=61f89c1e7b7ac864d840686aa7824eb04cba5cff Please go ahead. Just uploaded. Flagged for acceptance. Regards, Adam
Bug#796990: Ogr2ogr with wrapdateline fails on armhf
This function uses GEOS, so we should check again after rebuilding that:
See ogrgeometryfactory.cpp:
2321 if (oEnvelope.MinX dfLeftBorderX oEnvelope.MaxX 180)
2322 {
2323 #ifndef HAVE_GEOS
2324 CPLError( CE_Failure, CPLE_NotSupported,
2325 GEOS support not enabled. );
2326 #else
2327 bWrapDateline = TRUE;
2328 #endif
2329 }
Bug#724518: openldap: Patch to allow bootstrapping without heimdal-dev
Control: user helm...@debian.org
Control: usertags + rebootstrap
Hi Ryan and Daniel,
Thanks to Daniel for highlighting this bug to me. I know I'm being late
to the party, but let us please reconsider this stage before uploading.
On Tue, Aug 25, 2015 at 12:51:56PM -0700, Ryan Tandy wrote:
No hurry. Revised patch attached... I think it's correct, but would
appreciate a thumbs-up when you have time. Thanks a lot for your help!
I think that when adding a stage one should look further than just the
immediate cycle. This is the main reason that prevented me from
submitting a stage for openldap: I was lacking assurance that I was
doing it correctly.
Given further testing I now have somewhat more confidence, so let me
propose a very different stage1: --disable-slapd
Why does this make sense? This stage builds way less than the stage
proposed by Daniel. It also drops heimdal, but it also drops
cyrus-sasl2. Keep in mind that cyrus-sasl2 and openldap do have a direct
cycle that needs to be addressed in either cyrus-sasl2 or openldap. So
rather than add yet another stage to drop libsasl2-dev or add a stage to
cyrus-sasl2 dropping libldap2-dev, I therefore think that openldap's
stage1 should also drop the libsasl2-dev dependency. Turns out the
easiest way to do so is just not building the server.
I am attaching my current stage1 for openldap for discussion. What do
you think?
Helmut
diff -u openldap-2.4.40/debian/changelog openldap-2.4.40/debian/changelog
--- openldap-2.4.40/debian/changelog
+++ openldap-2.4.40/debian/changelog
@@ -1,3 +1,11 @@
+openldap (2.4.40-4.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Add stage1 build profile without heimdal. (Closes: #-1)
+ * Fix cross build. (Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de Thu, 05 Mar 2015 07:11:16 +0100
+
openldap (2.4.40-4) unstable; urgency=medium
* debian/patches/ITS8027-deref-reject-empty-attr-list.patch: Import upstream
diff -u openldap-2.4.40/debian/control openldap-2.4.40/debian/control
--- openldap-2.4.40/debian/control
+++ openldap-2.4.40/debian/control
@@ -10,11 +10,11 @@
Ryan Tandy r...@nardis.ca
Build-Depends: debhelper (= 8.9.0~),
dpkg-dev (= 1.16.1),
- libdb5.3-dev, nettle-dev,
- libgnutls28-dev, unixodbc-dev, libncurses5-dev, libperl-dev (= 5.8.0),
- libsasl2-dev, libslp-dev, libltdl-dev | libltdl3-dev (= 1.4.3),
- libwrap0-dev, perl, po-debconf,
- groff-base, time, heimdal-multidev,
+ libdb5.3-dev !stage1, nettle-dev,
+ libgnutls28-dev, unixodbc-dev !stage1, libncurses5-dev !stage1,
libperl-dev (= 5.8.0) !stage1,
+ libsasl2-dev, libslp-dev !stage1, libltdl-dev | libltdl3-dev (= 1.4.3),
+ libwrap0-dev !stage1, perl, po-debconf,
+ groff-base, time, heimdal-multidev !stage1,
dh-autoreconf
Build-Conflicts: libbind-dev, bind-dev, libicu-dev, autoconf2.13
Standards-Version: 3.9.1
@@ -36,6 +36,7 @@
Conflicts: umich-ldapd, ldap-server, libltdl3 (= 1.5.4-1)
Replaces: libldap2, ldap-utils ( 2.2.23-3)
Provides: ldap-server, ${slapd:Provides}
+Build-Profiles: !stage1
Description: OpenLDAP server (slapd)
This is the OpenLDAP (Lightweight Directory Access Protocol) server
(slapd). The server can be used to provide a standalone directory
@@ -46,6 +47,7 @@
Priority: extra
Architecture: any
Depends: slapd (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
+Build-Profiles: !stage1
Description: Keeps Samba and Kerberos passwords in sync within slapd.
Extends the PasswordModify Extended Operation to update Kerberos keys
and Samba password hashes for an LDAP user. The Kerberos support is
@@ -113,6 +115,7 @@
Priority: extra
Architecture: any
Depends: slapd (= ${binary:Version}), ${misc:Depends}
+Build-Profiles: !stage1
Description: Debugging information for the OpenLDAP server (slapd)
This package provides detached debugging information for the OpenLDAP
(Lightweight Directory Access Protocol) server (slapd). It is useful
diff -u openldap-2.4.40/debian/rules openldap-2.4.40/debian/rules
--- openldap-2.4.40/debian/rules
+++ openldap-2.4.40/debian/rules
@@ -11,12 +11,20 @@
export RESOLV_MULTI = off
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
CONFIG = $(shell grep -v ^\# debian/configure.options)
ifeq ($(DEB_HOST_ARCH_OS),hurd)
CONFIG += --disable-bdb --disable-hdb --disable-mdb
endif
+ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
+ CONFIG += --disable-slapd
+ CONFIG += --disable-slp
+endif
+ifeq ($(origin CC),default)
+export CC=$(DEB_HOST_GNU_TYPE)-cc
+endif
installdir := $(CURDIR)/debian/tmp
builddir := $(CURDIR)/debian/build
@@ -87,13 +95,16 @@
override_dh_auto_build:
dh_auto_build -- $(MAKEVARS)
+ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
$(MAKE) -C contrib/slapd-modules/smbk5pwd
$(MAKE) -C contrib/slapd-modules/autogroup
Bug#796828: RFS: xfce4-equake-plugin/1.3.8
On 08/26/2015 01:40 AM, Gianfranco Costamagna wrote: (I'll take care of warnings related to the package soon) Some questions: I installed it, and it installed many xfce dependencies on my system. The problem is that when I rebooted xfce isn't shown at the login screen. I had to manually do an apt-get install xfce4 to have it (and install some more stuff). Well, is that an use-case you want to take care of? I am not sure what I could (or should) change with regards to the package to enable successful install of the whole xfce4 DE plus dependencies, or the configuration of the xfce session for the login manager. Wouldn't it be out of the scope of a panel plugin? that said, I installed xfce4, rebooted. Where and how can I use your package? I don't see it anywhere In a 64 bits environment it is installed into /usr/lib/x86_64-linux-gnu/xfce4/panel-plugins/ when you install it using the package. If compiled from source it will go into /usr/lib/xfce4/panel-plugins/ or /usr/local/lib/xfce4/panel-plugins/ if you did not specify --prefix=/usr during when running ./configure. In xfce you need to right click the panel and select to add a new item, the requester that pops up may not always show newly installed plugins right away. You may have to close it, wait for a bit and try again. It will notice the presence of new panel-plugins eventually. It is possible that if installed into /usr/local/... it will not find it. Similarly when I installed xfce 4.12 from source into /usr/local to test equake out in a newer xfce environment the pane plugin requester, when using the /usr/local installed xfce, would only find the plugin if installed into /usr/local/... I am sure there are ways around it, but I didn't investigate further. Greetings, Jeroen
Bug#796999: apt: segmentation fault
* Jakub Wilk jw...@debian.org, 2015-08-26, 20:55: # apt-cache policy apt Segmentation fault Backtrace: #0 0xf7ed9455 in DependsList (this=0xca2c) at ../build/include/apt-pkg/cacheiterators.h:512 #1 pkgCacheGenerator::NewDepends (this=0x5657e8e8, Pkg=..., Ver=..., Version=6418874, Op=3 '\003', Type=8 '\b', OldDepLast=@0xca28: 0xf6e47070) at /build/apt-pcmtZa/apt-1.1~exp10/apt-pkg/pkgcachegen.cc:933 #2 0xf7edad31 in pkgCacheGenerator::NewPackage (this=0x5657e8e8, Pkg=..., Name=python-gobject-dev, Arch=amd64) at /build/apt-pcmtZa/apt-1.1~exp10/apt-pkg/pkgcachegen.cc:607 #3 0xf7edb854 in pkgCacheListParser::NewDepends (this=0x565857f8, Ver=..., PackageName=python-gobject-dev, Arch=amd64, Version=2.11.2, Op=2 '\002', Type=1 '\001') at /build/apt-pcmtZa/apt-1.1~exp10/apt-pkg/pkgcachegen.cc:987 #4 0xf7f39b13 in debListParser::ParseDepends (this=0x565857f8, Ver=..., Tag=0xf7f810bb Depends, Type=1) at /build/apt-pcmtZa/apt-1.1~exp10/apt-pkg/deb/deblistparser.cc:791 #5 0xf7f3a100 in debListParser::NewVersion (this=0x565857f8, Ver=...) at /build/apt-pcmtZa/apt-1.1~exp10/apt-pkg/deb/deblistparser.cc:208 #6 0xf7ed9a20 in pkgCacheGenerator::MergeListVersion (this=0x5657e8e8, List=..., Pkg=..., Version=0.10.22-3, OutVer=@0xcf1c: 0x0) at /build/apt-pcmtZa/apt-1.1~exp10/apt-pkg/pkgcachegen.cc:393 #7 0xf7edb38a in pkgCacheGenerator::MergeList (this=0x5657e8e8, List=..., OutVer=0x0) at /build/apt-pcmtZa/apt-1.1~exp10/apt-pkg/pkgcachegen.cc:248 #8 0xf7ed3321 in pkgDebianIndexFile::Merge (this=0x56581380, Gen=..., Prog=0x0) at /build/apt-pcmtZa/apt-1.1~exp10/apt-pkg/indexfile.cc:348 #9 0xf7edc6ef in operator() (I=0x56581380, __closure=synthetic pointer) at /build/apt-pcmtZa/apt-1.1~exp10/apt-pkg/pkgcachegen.cc:1403 #10 for_each__gnu_cxx::__normal_iteratorpkgIndexFile**, std::vectorpkgIndexFile* , BuildCache(pkgCacheGenerator, OpProgress*, map_filesize_t, map_filesize_t, const pkgSourceList*, FileIterator, FileIterator)::lambda(pkgIndexFile*) (__f=..., __last=..., __first=) at /usr/include/c++/5/bits/stl_algo.h:3767 #11 BuildCache (Gen=..., Progress=0x565827e8, Progress@entry=0x0, CurrentSize=@0x56579608: 6221704538560653352, TotalSize=117254225, List=0x5657c528, Start=, End=) at /build/apt-pcmtZa/apt-1.1~exp10/apt-pkg/pkgcachegen.cc:1423 #12 0xf7edeb3d in pkgCacheGenerator::MakeStatusCache (List=..., Progress=0x0, OutMap=0xd558, AllowMem=true) at /build/apt-pcmtZa/apt-1.1~exp10/apt-pkg/pkgcachegen.cc:1603 #13 0xf7ea6dae in pkgCacheFile::BuildCaches (this=0xd54c, Progress=0x0, WithLock=optimized out) at /build/apt-pcmtZa/apt-1.1~exp10/apt-pkg/cachefile.cc:97 #14 0x5655b656 in GetPkgCache (this=0xd54c) at ../build/include/apt-pkg/cachefile.h:77 #15 Policy (CmdL=...) at /build/apt-pcmtZa/apt-1.1~exp10/cmdline/apt-cache.cc:1634 #16 0xf7f7b76a in CommandLine::DispatchArg (this=0xd6c8, Map=0xd6d4, NoMatch=true) at /build/apt-pcmtZa/apt-1.1~exp10/apt-pkg/contrib/cmndline.cc:386 #17 0x56559cc7 in main (argc=3, argv=0xd834) at /build/apt-pcmtZa/apt-1.1~exp10/cmdline/apt-cache.cc:1945 This is on i386. ...with amd64 as foreign arch. $ grep '^[^#]' /etc/apt/sources.list deb http://ftp.debian.org/debian unstable main contrib non-free deb http://ftp.debian.org/debian experimental main contrib non-free deb-src http://ftp.debian.org/debian unstable main contrib non-free -- Jakub Wilk
Bug#797005: nmu: gnucash_1:2.6.7-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu gnucash_1:2.6.7-2 . ALL . -m rebuild against libktoblzcheck1v5 See also https://bugs.debian.org/791134 (g++ ABI transition in libktoblzcheck) and https://release.debian.org/transitions/html/auto-libktoblzcheck.html Thanks for considering. Best regards, Micha
Bug#793961: Update on TimGM6mb bug?
Hi all, Am Mittwoch, den 26.08.2015, 00:20 +0200 schrieb Jack Underwood: Any news on this bug? It looks like quite a simple fix, I would do it myself but I don't know how to use the debian git system (I have only ever used github before). would anyone object if I nmu, ne team-upload this? - Fabian signature.asc Description: This is a digitally signed message part
Bug#796589: [pkg-apparmor] Bug#796589: Bug#796589: apparmor: Has init script in runlevel S but no matching service file
On Wed, Aug 26, 2015 at 08:00:16PM +0200, Felix Geyer wrote: [Service] Type=oneshot ExecStart=XXX ExecReload=XXX ExecRestart=XXX ExecStop=XXX There is no ExecRestart, systemd translates restart to stop/start. That makes it a bit challenging to have a well-defined reload/restart actions. Currently we do this in the init script: - start: load all profiles - stop: clear cache - reload/restart: clear cache, load profiles, unload obsolete profiles Why does it clear the cache? Is the cache invalidation known to be problematic? I think stop clears cache was a bandaid to fix a cache invalidation issue. Since it was so painful, it also had bandaids to try to keep stop from running all that often. Last time I looked into this I was driven to insanity -- especially since it wasn't clear what was historical holdover from ancient civilzations and what was actually necessary today. Imho ideally we'd do this: - start/reload: load all profiles, unload obsolete - stop: nop Iirc detecting/unloading obsolete profiles is a bit expensive so we might not want to do that on boot though. I don't really like the unload obsolete idea much: the system policies are in /etc/apparmor.d/. Ubuntu touch / snappy has entire second set of policies for apps / snaps stored in /var/ somewhere. Perhaps other services exist that generate profiles on the fly or store them somewhere else and unloading them just because they don't also exist in /etc/apparmor.d/ feels like a mistake. Darix mentioned that systemd units can be parameterized; could this functionality be used to load profiles from multiple directories? Does it buy us anything? Thanks signature.asc Description: Digital signature
Bug#797004: [debian-mysql] Bug#797004: mysql-server 5.5.44-0+deb8u1 not installable on fresh install of Stretch
Downgrading from MariaDB 10.0 or MySQL 5.6 back to old MySQL 5.5 isn't supported and in many cases impossible. If you want to do that, then purge the old installation so that there are no configs or databases of the new format left behind, and then install MySQL 5.5. from scratch.
Bug#785978: dctrl2xml: diff for NMU version 0.18+nmu1
Control: tags 785978 + patch Control: tags 785978 + pending Dear maintainer, I've prepared an NMU for dctrl2xml (versioned as 0.18+nmu1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards, SR diff -Nru dctrl2xml-0.18/debian/changelog dctrl2xml-0.18+nmu1/debian/changelog --- dctrl2xml-0.18/debian/changelog 2010-12-12 04:00:04.0 -0800 +++ dctrl2xml-0.18+nmu1/debian/changelog 2015-08-26 13:04:55.0 -0700 @@ -1,3 +1,10 @@ +dctrl2xml (0.18+nmu1) unstable; urgency=medium + + * Non-maintainer upload. + * Port from python-support to dh_python2 (Closes: #785978) + + -- Stefano Rivera stefa...@debian.org Wed, 26 Aug 2015 13:04:55 -0700 + dctrl2xml (0.18) unstable; urgency=low * dctrl2xml: diff -Nru dctrl2xml-0.18/debian/control dctrl2xml-0.18+nmu1/debian/control --- dctrl2xml-0.18/debian/control 2010-12-12 04:00:04.0 -0800 +++ dctrl2xml-0.18+nmu1/debian/control 2015-08-26 13:04:41.0 -0700 @@ -2,8 +2,8 @@ Section: utils Priority: optional Maintainer: Frank S. Thomas f...@debian.org -Build-Depends: debhelper (= 7), python -Build-Depends-Indep: python-support (= 0.5.3), docbook2x, docbook-xml +Build-Depends: debhelper (= 7), dh-python, python +Build-Depends-Indep: docbook2x, docbook-xml Standards-Version: 3.9.1 Vcs-Git: git://git.debian.org/git/users/fst/dctrl2xml.git Vcs-Browser: http://git.debian.org/?p=users/fst/dctrl2xml.git diff -Nru dctrl2xml-0.18/debian/pyversions dctrl2xml-0.18+nmu1/debian/pyversions --- dctrl2xml-0.18/debian/pyversions 2010-12-12 04:00:04.0 -0800 +++ dctrl2xml-0.18+nmu1/debian/pyversions 1969-12-31 16:00:00.0 -0800 @@ -1 +0,0 @@ -2.6- diff -Nru dctrl2xml-0.18/debian/rules dctrl2xml-0.18+nmu1/debian/rules --- dctrl2xml-0.18/debian/rules 2010-12-12 04:00:04.0 -0800 +++ dctrl2xml-0.18+nmu1/debian/rules 2015-08-26 13:04:27.0 -0700 @@ -9,6 +9,6 @@ $(MAKE) -C doc clean %: - dh $@ + dh $@ --with python2 .PHONY: build clean
Bug#797004: [debian-mysql] Bug#797004: mysql-server 5.5.44-0+deb8u1 not installable on fresh install of Stretch
2015-08-26 22:40 GMT+03:00 Randy thejun...@gmail.com: Trying to setup MythTV which requires mysql-server. Tried to install and it I don't see that there even is any package mythtv in Debian. https://packages.debian.org/search?keywords=mythtvsearchon=namessuite=allsection=all Are you using some 3rd party repository? MythTV depend on mysql-server-virtual, which can be satisfied with any version or variant of mysql. If MythTV really only accepts certain mysql-server package, then you should file a bug against MythTV.
Bug#789875: subsurface: FTBFS in experimental
libgit,... well I'm not really into the subsurface code, but I never understood why you introduced that as a storage backend. Even the most prolific divers I know don't have more then 30k-50k dives, and usually these people stopped logging there day to day dives decades ago. Using a plain XML file or poor-man's DB like sqlite should be more than enough ... plus it would have the advantage that one can actually manually edit/parse the log without big problems. I had a few cases where I manually needed to merge dives and realign their timestamps... too rarely to write a proper code for handling such cases, but simple to script with a backend like XML. Christoph may have a point, here, indeed. I'm not a diver. For the record, I jumped in this thread because subsurface is/was team-maintained in Debian by a team historically named pkg-running, which actually tries to deal with packaging of sports-related end-user applications. I'm a runner and, indeed I use similar software to track down my runs and trainings. I run daily, which means I have thousands of recorded trainings after 10 years of practice. And, well, the software I'm using does actually use SQLite for storing its data, and is perfectly fine with that. For sure, I well understand that redisigning Subsurface to use a different storage backend is not something one can reasonably consider but maybe having this as an option could be nice. Of course, that requires someone to do the work and patches welcomed answers are perfectly fine. Whatever future happens, I use this opportunity to thank all contributors in this mini thread for their politeness despite the diverging opinionsand also send a mini apology for having been kinda rudeI do share Christoph's feeling about the raison d'être of distros and, well, I'm never happy when this is not well understood
Bug#727610: debian-policy: clearer discussion of why build-indep implies building the whole package
On Sat, 26 Oct 2013 14:14:23 +0200 Guillem Jover guil...@debian.org wrote: Hi! On Thu, 2013-10-24 at 15:47:56 +0100, Ximin Luo wrote: Package: debian-policy Severity: normal I was recently told to split part of my Build-Depends field into a separate Build-Depends-Indep field. Not one to follow orders without question, I went and did some research, and found this snippet in the policy[1]: There is no Build-Depends-Arch; this role is essentially met with Build-Depends. Anyone building the build-indep and binary-indep targets is assumed to be building the whole package, and therefore installation of all build dependencies is required. dpkg has supported Build-Depends-Arch and Build-Conflicts-Arch since 1.16.4 (complete support with 1.17.0). Although they should not be used yet, as long as other resolvers are not aware of these. Thanks, Guillem Hi Policy maintainers, With dpkg and buildds supporting build-arch and build-indep plus source uploads being tested in unstable, perhaps it is time to move forward with this again? :) The build options are currently: 1. Maintainer uses binary and build targets (i.e. *-arch AND *-indep) - buildds uses binary-arch and build-arch missing architectures 2. Maintainer uses binary-indep and build-indep targets - buildds uses binary-arch and build-arch on *every* architecture (Ben Hutching has been doing this for a while already) 3. Maintainer uploads a source only (*) - One buildd uses binary-indep and build-indep to build the arch:all packages (if present) - buildds uses binary-arch and build-arch on *every* architecture (*): Being tested in experimental atm., As noted, only option 1 uses the binary and build target. Thanks, ~Niels Please CC me on replies. signature.asc Description: OpenPGP digital signature
Bug#796323: t-p-u of Icedove 38.2.0-1~stretch
On 2015-08-25 10:43, Carsten Schoenert wrote:
Hello,
with #796323 a updated version of Icedove was uploaded to t-p-u.
Depended on the GCC5 transition and it's migration progress some blocks
coming along with this also to the current version of Icedove in
unstable. So the version in testing is the outdated version 31.7.0-1,
Wheezy and Jessie got 31.8.0-* in the between times.
The 31.8.0 marks the end of the ESR series for version 31 so we don't
wanted to package 31.8.0 for testing and worked on 38.0.1-1 in unstable
so far. In the between time updated to 38.1.0-1.
As made clear by Nils Thykier af DebConf we should not upload to
unstable anymore if not really related to GCC5 transition he proposed me
to upload newer ESR versions of Icedove to t-p-u.
That's done last week by the bugnumber above.
So sorry for maybe stupid asking, what needs to be done to get accept
the upload of Icedove 38.2.0-1~stretch in testing?
Did I need to append a debdiff?
---
Regards
Carsten Schoenert
Hi Carsten,
Thanks for looking into this.
We always use bugs to keep track of updates to tpu (and other
pu-suites). In this case, you already filed #796323, which we will be
using[1].
I see Julien has already replied to you there nothing an issue with
building icedove on mips[2]. This is preventing us from updating
icedove. The error:
Executing /«PKGBUILDDIR»/obj-icedove/dist/bin/xpcshell -g
/«PKGBUILDDIR»/obj-icedove/dist/bin/ -a
/«PKGBUILDDIR»/obj-icedove/dist/bin/ -f
/«PKGBUILDDIR»/mozilla/toolkit/mozapps/installer/precompile_cache.js -e
precompile_startupcache(resource://gre/);
Traceback (most recent call last):
File /«PKGBUILDDIR»/mozilla/toolkit/mozapps/installer/packager.py,
line 403, in module
main()
File /«PKGBUILDDIR»/mozilla/toolkit/mozapps/installer/packager.py,
line 397, in main
args.source, gre_path, base)
File /«PKGBUILDDIR»/mozilla/toolkit/mozapps/installer/packager.py,
line 156, in precompile_cache
errors.fatal('Error while running startup cache precompilation')
File /«PKGBUILDDIR»/mozilla/python/mozbuild/mozpack/errors.py, line
101, in fatal
self._handle(self.FATAL, msg)
File /«PKGBUILDDIR»/mozilla/python/mozbuild/mozpack/errors.py, line
96, in _handle
raise ErrorMessage(msg)
mozpack.errors.ErrorMessage: Error: Error while running startup cache
precompilation
As mentioned earlier, please follow up on #796323.
Thanks,
~Niels
[1] For future reference, please do not close the tpu bug in an upload.
It is closed by the release team once the upload is accepted into
testing rather than into testing-proposed-updates
[2] https://buildd.debian.org/status/package.php?p=icedovesuite=stretch
signature.asc
Description: OpenPGP digital signature
Bug#763695: console-setup: even worse than assumed
Hallo, * Samuel Thibault [Wed, Aug 26 2015, 12:21:19AM]: Eduard Bloch, le Wed 26 Aug 2015 00:11:10 +0200, a écrit : So... ok, maybe getting times from the log was a bad idea and causes exageration. Err, were you using strace for your whole timing of setupcon? It's no wonder it takes so long in that case :) Well, during initial look at the strace log the overall execution time matched the value systemd-analyze chart very well (both indicated ~5s for the whole process) and I didn't bother to cross-check. Regards, Eduard. -- Alfie Ah. Frankfurt/Main. * weasel fragt sich ja immer, ob's auch ein Frankfurt/Contrib und Frankfurt/Non-Free gibt signature.asc Description: Digital signature
Bug#796953: fglrx-driver: Kernel 4.1 backport breaks fglrx in Jessie
Source: fglrx-driver Severity: critical Justification: breaks the whole system Hello, Update 4.1 of the Linux kernel has been released in Jessie backports. The problem is that the fglrx driver did not follow, causing the X server to fail to start. The fix currently consists in uninstalling the fglrx but this solution is clearly a showstopper to newcomers. Could you please release an updated fglrx release in backports ? Thanks -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.1.0-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#790756: Packages are not [depending on libstdc++6 = 5] after rebuild
On Tue, 25 Aug 2015 at 16:50:16 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: And this is because the packages do not use any of the new symbols, so they do not get the dependency on the last version. there is nothing packagers can do about it. I wonder whether g++-5 should artificially bump the minimum dependency version for libstdc++6, so that *everything* built with libstdc++6 picks up the (= 5) dependency? Yes, that'll mean rebuilt packages can't transition until libstdc++6 does, which is why it is normally undesired (hence symbols files); but in practice it seems a reasonable number of e.g. KDE packages that are transitioning are broken anyway. It would certainly make the transition easier to track. S
Bug#796323: t-p-u of Icedove 38.2.0-1~stretch
Hello Niels, On Wed, Aug 26, 2015 at 08:18:01AM +0200, Niels Thykier wrote: Hi Carsten, Thanks for looking into this. We always use bugs to keep track of updates to tpu (and other pu-suites). In this case, you already filed #796323, which we will be using[1]. I see Julien has already replied to you there nothing an issue with building icedove on mips[2]. now I see, the reply of Julian hasn't reached me (until now). I was thinking about closing the bug in this case was not right ... but o.k. now I'm enlighted. ;) [...] As mentioned earlier, please follow up on #796323. I will do. Thanks, ~Niels [1] For future reference, please do not close the tpu bug in an upload. It is closed by the release team once the upload is accepted into testing rather than into testing-proposed-updates I tried to follow the instructions of the developers referens on 5.13.3, but exact this point is a little bit unclear I think. Maybe the reference should be a liitle bit more expanded here. Anyway, will look now into the build issue and thanks for explanations. Regards Carsten
Bug#793542: libnmap-parser-perl: diff for NMU version 1.05-2.1
Control: tags 793542 + patch Control: tags 793542 + pending Dear maintainer, I've prepared an NMU for libnmap-parser-perl (versioned as 1.05-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Mark Knopfler: The Ceilidh: Louis' Favourite / Billy's Tune diff -u libnmap-parser-perl-1.05/debian/rules libnmap-parser-perl-1.05/debian/rules --- libnmap-parser-perl-1.05/debian/rules +++ libnmap-parser-perl-1.05/debian/rules @@ -33,7 +33,7 @@ dh_clean -k # Add commands to install the package into debian/$PACKAGE_NAME here - $(MAKE) install PREFIX=$(CURDIR)/debian/libnmap-parser-perl/usr + $(MAKE) install DESTDIR=$(CURDIR)/debian/libnmap-parser-perl touch install-stamp diff -u libnmap-parser-perl-1.05/debian/changelog libnmap-parser-perl-1.05/debian/changelog --- libnmap-parser-perl-1.05/debian/changelog +++ libnmap-parser-perl-1.05/debian/changelog @@ -1,3 +1,12 @@ +libnmap-parser-perl (1.05-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #793542) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 17:50:28 +0200 + libnmap-parser-perl (1.05-2) unstable; urgency=low * Fix copyright file slightly signature.asc Description: Digital Signature
Bug#795613: libproc-syncexec-perl: diff for NMU version 1.01-1.1
Control: tags 795613 + patch Control: tags 795613 + pending Dear maintainer, I've prepared an NMU for libproc-syncexec-perl (versioned as 1.01-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Funny Van Dannen: Arbeiterkinderdenkmal diff -u libproc-syncexec-perl-1.01/debian/changelog libproc-syncexec-perl-1.01/debian/changelog --- libproc-syncexec-perl-1.01/debian/changelog +++ libproc-syncexec-perl-1.01/debian/changelog @@ -1,3 +1,12 @@ +libproc-syncexec-perl (1.01-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #795613) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 17:57:06 +0200 + libproc-syncexec-perl (1.01-1) unstable; urgency=low * New upstream release (closes: #329656). diff -u libproc-syncexec-perl-1.01/debian/rules libproc-syncexec-perl-1.01/debian/rules --- libproc-syncexec-perl-1.01/debian/rules +++ libproc-syncexec-perl-1.01/debian/rules @@ -28,7 +28,7 @@ dh_testroot dh_clean -k dh_installdirs - $(MAKE) install PREFIX=$(prefix)/usr + $(MAKE) install DESTDIR=$(prefix) find $(prefix) -depth -type d -print0 | \ xargs -0r rmdir --ignore-fail-on-non-empty touch $@ signature.asc Description: Digital Signature
Bug#796899: Acknowledgement (interesting segfault)
Aurelien Jarno wrote: The fp pointer is NULL in both of the above functions. Could you please try to get a backtrace to see which caller starts to pass a NULL pointer? Tried building curl from source to get a useful backtrace, but that build didn't have the problem. Since that build was done using gcc 4.9.2-4, it may be another hint in the direction of the recent gcc transitions. -- see shy jo signature.asc Description: Digital signature
Bug#287876: Mes de la Primavera para DISFRUTAR
Si no visualiza correctamente este E-Mail haga Click Aquí ( Link - http://list-manage10.net/track/click?u=webp=36343936383a353a353a303a303a30m=30163s=c59718f63337ee1763c30ee824fd6e4c ) | Reenvía a un amigo ( Link - http://list-manage10.net/track/click?u=forwardtop=36343936383a353a353a303a303a30m=30163s=c59718f63337ee1763c30ee824fd6e4c ) /* */ IMAGENES IMAGENES ( Link - http://www.filodelosmedanos.com/galeria.html ) CONOCENOS ( Link - http://www.filodelosmedanos.com ) ( Link - http://list-manage10.net/track/click?u=facebookp=36343936383a353a353a303a303a30m=30163s=c59718f63337ee1763c30ee824fd6e4c ) ( Link - http://list-manage10.net/track/click?u=forwardtop=36343936383a353a353a303a303a30m=30163s=c59718f63337ee1763c30ee824fd6e4c ) Facebook ( Link - https://www.facebook.com/profile.php?id=19898983236 ) Agréganos a tu lista de contactos Información de Contacto ( Link - http://list-manage10.net/track/click?u=vcardp=36343936383a353a353a303a303a30m=30163s=c59718f63337ee1763c30ee824fd6e4c ) Para desuscribirse de nuestra lista haga ( Link - http://list-manage10.net/track/click?u=unsubscribep=36343936383a353a353a303a303a30m=30163s=c59718f63337ee1763c30ee824fd6e4c )
Bug#764349: tor+http with apt-file
[Riley Baird] This isn't a permanent solution, but it's kind of a workaround. apt-file doesn't seem to allow the plus sign to be in the protocol name, I've changed it to change it to torhttp. After that, add the following line to your /etc/apt/apt-file.conf and it should work. Be careful, though, because torify isn't perfect, and I don't know if it preserves anonymity when used with diffindex-download. Thank you for this tip. While I guess apt-file can be adjusted to accept the plus sign in protocol names (or apt-transport-tor can be changed to use another protocol name), isn't it better to change apt-file to use the apt transport method in /usr/lib/apt/methods/, and thus download the exact same way apt is? Why isn't apt-file already using those methods for downloading? -- Happy hacking Petter Reinholdtsen
Bug#582664: Mes de la Primavera para DISFRUTAR
Si no visualiza correctamente este E-Mail haga Click Aquí ( Link - http://list-manage3.net/track/click?u=webp=36343936383a353a353a303a303a30m=30181s=554efd75e73656ae235fd326c7aa74ca ) | Reenvía a un amigo ( Link - http://list-manage3.net/track/click?u=forwardtop=36343936383a353a353a303a303a30m=30181s=554efd75e73656ae235fd326c7aa74ca ) /* */ IMAGENES IMAGENES ( Link - http://www.filodelosmedanos.com/galeria.html ) CONOCENOS ( Link - http://www.filodelosmedanos.com ) ( Link - http://list-manage3.net/track/click?u=facebookp=36343936383a353a353a303a303a30m=30181s=554efd75e73656ae235fd326c7aa74ca ) ( Link - http://list-manage3.net/track/click?u=forwardtop=36343936383a353a353a303a303a30m=30181s=554efd75e73656ae235fd326c7aa74ca ) Facebook ( Link - https://www.facebook.com/profile.php?id=19898983236 ) Agréganos a tu lista de contactos Información de Contacto ( Link - http://list-manage3.net/track/click?u=vcardp=36343936383a353a353a303a303a30m=30181s=554efd75e73656ae235fd326c7aa74ca ) Para desuscribirse de nuestra lista haga ( Link - http://list-manage3.net/track/click?u=unsubscribep=36343936383a353a353a303a303a30m=30181s=554efd75e73656ae235fd326c7aa74ca )
Bug#583104: Mes de la Primavera para DISFRUTAR
Si no visualiza correctamente este E-Mail haga Click Aquí ( Link - http://list-manage4.net/track/click?u=webp=36343936383a353a353a303a303a30m=30191s=dc05ead72fa448740bdf6f74eaafda7e ) | Reenvía a un amigo ( Link - http://list-manage4.net/track/click?u=forwardtop=36343936383a353a353a303a303a30m=30191s=dc05ead72fa448740bdf6f74eaafda7e ) /* */ IMAGENES IMAGENES ( Link - http://www.filodelosmedanos.com/galeria.html ) CONOCENOS ( Link - http://www.filodelosmedanos.com ) ( Link - http://list-manage4.net/track/click?u=facebookp=36343936383a353a353a303a303a30m=30191s=dc05ead72fa448740bdf6f74eaafda7e ) ( Link - http://list-manage4.net/track/click?u=forwardtop=36343936383a353a353a303a303a30m=30191s=dc05ead72fa448740bdf6f74eaafda7e ) Facebook ( Link - https://www.facebook.com/profile.php?id=19898983236 ) Agréganos a tu lista de contactos Información de Contacto ( Link - http://list-manage4.net/track/click?u=vcardp=36343936383a353a353a303a303a30m=30191s=dc05ead72fa448740bdf6f74eaafda7e ) Para desuscribirse de nuestra lista haga ( Link - http://list-manage4.net/track/click?u=unsubscribep=36343936383a353a353a303a303a30m=30191s=dc05ead72fa448740bdf6f74eaafda7e )
Bug#562700: Mes de la Primavera para DISFRUTAR
Si no visualiza correctamente este E-Mail haga Click Aquí ( Link - http://goto-5.net/track/click?u=webp=36343936383a353a353a303a303a30m=30168s=181fd186358c724bb765fa8dc41180a4 ) | Reenvía a un amigo ( Link - http://goto-5.net/track/click?u=forwardtop=36343936383a353a353a303a303a30m=30168s=181fd186358c724bb765fa8dc41180a4 ) /* */ IMAGENES IMAGENES ( Link - http://www.filodelosmedanos.com/galeria.html ) CONOCENOS ( Link - http://www.filodelosmedanos.com ) ( Link - http://goto-5.net/track/click?u=facebookp=36343936383a353a353a303a303a30m=30168s=181fd186358c724bb765fa8dc41180a4 ) ( Link - http://goto-5.net/track/click?u=forwardtop=36343936383a353a353a303a303a30m=30168s=181fd186358c724bb765fa8dc41180a4 ) Facebook ( Link - https://www.facebook.com/profile.php?id=19898983236 ) Agréganos a tu lista de contactos Información de Contacto ( Link - http://goto-5.net/track/click?u=vcardp=36343936383a353a353a303a303a30m=30168s=181fd186358c724bb765fa8dc41180a4 ) Para desuscribirse de nuestra lista haga ( Link - http://goto-5.net/track/click?u=unsubscribep=36343936383a353a353a303a303a30m=30168s=181fd186358c724bb765fa8dc41180a4 )
Bug#796991: Program close itself after choosing a directory
Subject: unison-gtk: Program close itself after choosing a directory Package: unison-gtk Version: 2.40.102-2 Severity: normal Dear Maintainer, while the first Profile Creation using local synchronization, the programm just close itself without warning, after choosing a first or secound directory. I can see the suggested directorys, but after click on one of it (maybe Other ...), the Window disapear. With running unison-gtk over a Terminal, i have the following output after the programm shutdown itself: (unison-gtk:24455): Gtk-CRITICAL **: gtk_tree_model_filter_get_value: assertion 'GTK_TREE_MODEL_FILTER (model)-priv-stamp == iter-stamp' failed (unison-gtk:24455): GLib-GObject-WARNING **: /tmp/buildd/glib2.0-2.42.1/./gobject/gtype.c:4221: type id '0' is invalid (unison-gtk:24455): GLib-GObject-WARNING **: can't peek value table for type 'invalid' which is not currently referenced Speicherzugriffsfehler This just occurs only on this Laptop with Mate installed. Another Laptop using Lxde doesn't affect to this issue. Kind Regards, Erik -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages unison-gtk depends on: ii libatk1.0-0 2.14.0-1 ii libc6 2.19-18 ii libcairo2 1.14.0-2.1 ii libfontconfig1 2.11.0-6.3 ii libfreetype62.5.2-3 ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u2 ii libglib2.0-02.42.1-1 ii libgtk2.0-0 2.24.25-3 ii libpango1.0-0 1.36.8-3 Versions of packages unison-gtk recommends: ii openssh-client [ssh-client] 1:6.7p1-5 ii ssh-askpass 1:1.2.4.1-9 Versions of packages unison-gtk suggests: pn unison-all-gtk none -- no debconf information
Bug#795630: libsnmp-mib-compiler-perl: diff for NMU version 0.06-2.1
Control: tags 795630 + patch Control: tags 795630 + pending Dear maintainer, I've prepared an NMU for libsnmp-mib-compiler-perl (versioned as 0.06-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Supertramp: Try Again diff -u libsnmp-mib-compiler-perl-0.06/debian/changelog libsnmp-mib-compiler-perl-0.06/debian/changelog --- libsnmp-mib-compiler-perl-0.06/debian/changelog +++ libsnmp-mib-compiler-perl-0.06/debian/changelog @@ -1,3 +1,12 @@ +libsnmp-mib-compiler-perl (0.06-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #795630) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 18:16:54 +0200 + libsnmp-mib-compiler-perl (0.06-2) unstable; urgency=low * New maintainer (Closes: #377864) diff -u libsnmp-mib-compiler-perl-0.06/debian/rules libsnmp-mib-compiler-perl-0.06/debian/rules --- libsnmp-mib-compiler-perl-0.06/debian/rules +++ libsnmp-mib-compiler-perl-0.06/debian/rules @@ -60,7 +60,7 @@ install-stamp: build dh_testdir dh_installdirs - $(MAKE) install PREFIX=$(b)/usr + $(MAKE) install DESTDIR=$(b) chmod a-x $(b)/usr/share/perl5/SNMP/MIB/Compiler.pm touch install-stamp signature.asc Description: Digital Signature
Bug#738161: cmake: Patch to bootstrap without Qt
Hi, On Sun, 03 Aug 2014 20:29:48 +0200 Johannes Schauer j.scha...@email.de wrote: The part about Qt 4 looks good. I'm not so sure about using the bundled libraries. Adding a stage1 profile to curl seems like a cleaner solution to me. The problem here is that at this stage of a bootstrap, the krb5, ldap, etc. build dependencies of curl are not yet available, and bootstrapping curl without that support would create packages without equivalent functionality. Which is something we try to avoid if at all possible. I agree that using bundled curl for bootstrapping cmake isn't really pretty either, though. You should also make sure that the binary packages that are built with the bundled curl instead of the system curl expose no different functionality and interfaces compared to the original binary packages. The reason is, that other source or binary packages which depend on the cmake packages must find everything they expect or otherwise this breaks the dependency system. Since src:cmake does not build a shared library, using the bundled curl instead of the system curl might work without problems. You can read more about this requirement for build profiles in this section of the spec: https://wiki.debian.org/BuildProfileSpec#Profile_built_binary_packages I've added a stage1 build profile to disable building the Qt GUI: http://anonscm.debian.org/cgit/collab-maint/cmake.git/commit/?h=experimentalid=a8bc51cb82c1ea7b5ba8ba72b39d764d22f5b828 About curl: A difference between using the system libraries vs. the bundled one might be the feature set that curl is built with. Afaik cmake uses curl to submit test results to a dashboard and to allow downloading files during a build. I wouldn't expect differences in curl to impact cmake in the context of Debian package builds. I'd be fine with adding this to cmake. Please let me know if this would be useful. Cheers, Felix
Bug#796994: vistrails: changelog file wasn't updated
Package: vistrails Version: 2.2-1 Severity: normal Dear Maintainer, It seems that the copyright file hasn't been updated in the new 2.2-1 release and still mentions Copyright (c) 2006-2011, University of Utah. Please note that VisTrails is now being developed by New York University, and this is what is stated in the copyright headers of the upstream source distribution: Copyright (c) 2014-2015, New York University Copyright (C) 2011-2014, NYU-Poly. Copyright (C) 2006-2011, University of Utah. cf https://github.com/VisTrails/VisTrails/blob/v2.2.0/LICENSE
Bug#796989: monit: Monit 5.9 has a serious umask bug.
Package: monit Version: 1:5.9-1 Severity: critical Tags: upstream Justification: causes serious data loss * What led up to the situation? I upgraded a server from Debian 7 to Debian 8.1. Monit was configured to monitor copy.com's CopyConsole and automatically start it at boot or and restart it periodically. There was no problem on Debian 7. On Debian 8.1 I found that directories created by CopyConsole were set with the executable bit off. This caused CopyConsole to fail to copy data it should have copied. I was able to recover from this but someone in different circumstances could lose data. Any software used to perform filesystem backups is at risk of losing data if it is started by Monit 5.9 due to this problem. * What exactly did you do (or not do) that was effective (or ineffective)? I downloaded 1:5.14-2 from testing and installed it manually. This fixed the problem. The bug is documented upstream: https://bitbucket.org/tildeslash/monit/issues/104
Bug#793540: libnet-nbname-perl: diff for NMU version 0.26-1.1
Control: tags 793540 + patch Control: tags 793540 + pending Dear maintainer, I've prepared an NMU for libnet-nbname-perl (versioned as 0.26-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Schmetterlinge: Mächtelmöchtel diff -u libnet-nbname-perl-0.26/debian/changelog libnet-nbname-perl-0.26/debian/changelog --- libnet-nbname-perl-0.26/debian/changelog +++ libnet-nbname-perl-0.26/debian/changelog @@ -1,3 +1,12 @@ +libnet-nbname-perl (0.26-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #793540) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 17:47:13 +0200 + libnet-nbname-perl (0.26-1) unstable; urgency=low * New upstream release (Closes: #378124) diff -u libnet-nbname-perl-0.26/debian/rules libnet-nbname-perl-0.26/debian/rules --- libnet-nbname-perl-0.26/debian/rules +++ libnet-nbname-perl-0.26/debian/rules @@ -33,7 +33,7 @@ dh_clean -k dh_installdirs - $(MAKE) install PREFIX=$(CURDIR)/debian/libnet-nbname-perl/usr + $(MAKE) install DESTDIR=$(CURDIR)/debian/libnet-nbname-perl # Build architecture-independent files here. signature.asc Description: Digital Signature
Bug#796812: Info received ((no subject))
Sent from Samsung Mobile Original message Subject: Bug#796812: Info received ((no subject)) From: ow...@bugs.debian.org To: Urbz86 urbzlin...@gmail.com CC: Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): TANIGUCHI Takaki tak...@debian.org If you wish to submit further information on this problem, please send it to 796...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 796812: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796812 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#795629: libtext-wrapi18n-perl: diff for NMU version 0.06-7.1
Control: tags 795629 + patch Control: tags 795629 + pending Dear maintainer, I've prepared an NMU for libtext-wrapi18n-perl (versioned as 0.06-7.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Supertramp: Try Again diff -u libtext-wrapi18n-perl-0.06/debian/rules libtext-wrapi18n-perl-0.06/debian/rules --- libtext-wrapi18n-perl-0.06/debian/rules +++ libtext-wrapi18n-perl-0.06/debian/rules @@ -44,7 +44,7 @@ dh_testroot dh_prep dh_installdirs - $(MAKE) install PREFIX=`pwd`/debian/libtext-wrapi18n-perl/usr + $(MAKE) install DESTDIR=`pwd`/debian/libtext-wrapi18n-perl # Build architecture-independent files here. binary-arch: build install diff -u libtext-wrapi18n-perl-0.06/debian/changelog libtext-wrapi18n-perl-0.06/debian/changelog --- libtext-wrapi18n-perl-0.06/debian/changelog +++ libtext-wrapi18n-perl-0.06/debian/changelog @@ -1,3 +1,12 @@ +libtext-wrapi18n-perl (0.06-7.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #795629) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 18:12:58 +0200 + libtext-wrapi18n-perl (0.06-7) unstable; urgency=low * Fix infinite loop in Text::WrapI18N signature.asc Description: Digital Signature
Bug#716796: [Pkg-javascript-devel] libjs-jquery2
Quoting Alexandre Rossi (2015-08-26 13:39:42) Is there an ongoing effort to get jQuery 2+ in Debian? Not that I recall - and no need asking IMO: Anyone working on such package is expected to inform about it by filing an ITP bug! Are there licensing or builddep (grunt required?) issues? Probably uses grunt, but I don't know... (I could not find any open bug or ITP/RFP) I checked as well now at https://www.debian.org/devel/wnpp/prospective and agree noone is (claiming to be) working on packaging of jquery 2.x. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#752068: apt-transport-tor: Incompatibility with some Debian utilities
[LaNaar Dakoté] Any thought about it? I'm not Tim, but I notice the apt-file issue is reported as URL: https://bugs.debian.org/764349 . I guess both apt-file, debman and others should be changed to use the apt transport methods instead of doing it on their own. I found the protocol specification in URL: http://www.fifi.org/doc/libapt-pkg-doc/method.html/ch2.html , but expect it can be found elsewhere too. Perhaps it can be useful for the apt-file and debman developers to know about this spec? -- Happy hacking Petter Reinholdtsen
Bug#738161: cmake: Patch to bootstrap without Qt
Hi, Quoting Daniel Schepler (2015-08-26 19:02:56) On Wed, Aug 26, 2015 at 9:19 AM, Felix Geyer fge...@debian.org wrote: I've added a stage1 build profile to disable building the Qt GUI: http://anonscm.debian.org/cgit/collab-maint/cmake.git/commit/?h=experimentalid=a8bc51cb82c1ea7b5ba8ba72b39d764d22f5b828 Looks good - just one minor comment: I tend to use filter instead of findstring. It probably doesn't make that much difference, though - it's not too likely that somebody will try to use another profile name that contains stage1. For what it's worth, the canonical way of checking whether a profile is active is in the build profile spec: https://wiki.debian.org/BuildProfileSpec#The_DEB_BUILD_PROFILES_environment_variable It indeed uses filter as Daniel already pointed out. A difference between using the system libraries vs. the bundled one might be the feature set that curl is built with. Afaik cmake uses curl to submit test results to a dashboard and to allow downloading files during a build. I wouldn't expect differences in curl to impact cmake in the context of Debian package builds. On the other hand, it would impact user-visible functionality. See for example http://www.cmake.org/pipermail/cmake/2014-October/058911.html. So, doing this without a rename of the resulting cmake package would technically violate the requirement we're discussing. Whether it's a small enough violation that it could be ignored, I don't really know. I'd be fine with adding this to cmake. Please let me know if this would be useful. I CC-ed Helmut who is currently the best person to know whether making libcurl*-dev optional for src:cmake makes any sense at all or not. Thanks! cheers, josch signature.asc Description: signature
Bug#789875: subsurface: FTBFS in experimental
Quoting Dirk Hohndel (d...@hohndel.org): We have asked SPECIFICALLY Debian to stop providing an out-dated version of Subsurface to its users as that caused confusion and problems for our users and support burdon for us. Debian was unwilling to follow our choices of open source components that we used. So we asked Debian to drop bundling Subsurface since we provide a version of Subsurface which a diver who happens to run Debian and wants to use Subsurface can install. One hilarious thing in this discussion is seeing how people speak about Debian does this or Debian chooses that and then later on give big details about their big background in open source (bleh) software. That's interesting because it is very common from outsiders of the Debian community to believe that the project follows a direction with some head telling people who contribute to it what they should do. Debian does nothing. It has no CTO, CEO, WhateverO. The project is a collection of hundreds of individuals who give their time to some parts of the distro. Some do packaging, some others do documentation, translation, infrastructure system adminitration or whatever else. But nobody tells us what we should do. One very minor part of my Debian tasks is being part of the pkg-running project and maintain sports-related software. But nobody can and will tell me that I should or must do this or that, including dropping a package I maintain. You asked *to the maintainers of the subsurface package* to stop distributing so-called outdated versions of Subsurface. You didn't ask Debian. If you find a way to ask Debian about something, please telle me so, because after 17 years in this project, I never found a way to do so. I would very much see people who are not involved in the project understand this. Because some griefs would be easier to leave behind. Apart from that, this discussion leads to nothing : we clearly have different views about what a distribution is and should beand we know for quite some time that the original author of Subsurface (at least I learned something) also has different views.and many actually do not really care about that...:-) signature.asc Description: Digital signature
Bug#792850: gmp-ecm,libecm-dev: copyright file missing after upgrade (policy 12.5)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Andreas: I have just installed piuparts 0.66 on my box in order to reproduce the issue: so far, I I have not succeeded to reproduced the issue. Please can you confirm the issue ? Or give the proper option to reproduce it ? Thanks in advance, Jerome -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV3fblAAoJEIC/w4IMSybjBU8IAK99p+S0YZVoHZ0gc5Lu1jLp lDTVawB7razlDFFjrFh2+m6/ykbu5INgKyxyOe82JXTcI/5+CCQ4RRMaPPLTv6Zt n39/CCHVgmk0fBsUpapaiWKGmOIqkZpg7l8PEUpPRU9jleDh6laP8rBkcrLhB+5Y 4RSMgdlbcQ9nit1jyrc3KBrvOx/Gl+KO80XkIgAidpytLQ+/Y87DxxhJXWiR0nTQ oASA74dEHDW5OkZa0c4OFXdBH81NnuweBzdWE0Jc8h/+toXpb5pKdj3poL3aL4Sl cM1BhRdU+q1Ife82uimMNepHKvXA+tIRuzMajoevohjmm6KOscd0yQvvf+uE288= =Xu44 -END PGP SIGNATURE-
Bug#796992: PTS: buildd links for arch:all packages
Package: qa.debian.org We now have arch:all buildds, so PTS should show buildd links even when the source package build only arch:all packages. -- Jakub Wilk
Bug#622265: TERM=screen.mlterm breaks dircolors
Hi, Matthew Gabeler-Lee wrote: This isn't just mlterm. This breaks xterm, xterm-256color, etc. too I'm sorry, but while I can reproduce the issue with env TERM=mlterm screen, I can't reproduce it with env TERM=xterm-256color screen (on Jessie). In the latter case, dircolors just look fine to me. Anyways, the terminfo definitions this bug is about are _not_ part of the screen package but part of the ncurses-term package. So if the terminal definitions for screen.mlterm needs to be changed, that should be a wishlist bug against ncurses-term, not screen. I'm tempted to reassign this bug report to ncurses-term. What do the ncurses-term maintainers (Cc'ed) think about this? This munging of the TERM variable also breaks access to other systems, e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609656. That bug report is not really a bug about TERM variable munging but about screen not having a package relation to ncurses-term. Some systems don't even think the munged TERM values are real and cause problems like less complaining WARNING: terminal is not fully functional. That's IMHO a different issue. You should be able to work around it by either uninstalling ncurses-term locally or installing it remotely. IIRC if screen can't find the according terminfo entries, it won't use them and hence won't change $TERM to something more fancy than just screen. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#789875: subsurface: FTBFS in experimental
On Wed, Aug 26, 2015 at 04:40:43PM +0200, Christoph Anton Mitterer wrote: On Wed, 2015-08-26 at 13:40 +0300, Lubomir I. Ivanov wrote: your approach for convincing is offensive and unwise. Well if upstreams are effectively hostile against core paradigms of the FLOSS community, it must expect that people won't be happy with it. Some of us have expressed our dismay with the way distributions work these days. I used to be the CTO of a distribution company (SuSE). One of the other outspoken Subsurface developers on this topic (and the guy who started Subsurface) also has some background with Linux, though he wasn't ever involved in a distribution... He actually talked about this at the DebConf in Portland last year: http://gensho.acc.umu.se/pub/debian-meetings/2014/debconf14/webm/QA_with_Linus_Torvalds.webm But let's get real here. We are not hostile against core paradigms of the FLOSS community. The hybris in writing things like that is actually kinda funny. We disagree with the more extreme people in some distributions. The catholic church had the crusaders, Islam has ISIS, the open source community has their extremists. Neither of those extremist groups speak for the whole community. You do not speak for the open source community. I don't either. Neither do I claim to do so. as a peace of software it now no longer obeys the Linux distribution rules; it's setting a bad example at the expense of not being available everywhere at anytime in the ecosystem. Being not available is not the problem by itself. There's many software which is not packaged for Debian. The problem is when you have projects which intentionally work against some of the base principles of open source software, as here: the apparently expressed wish of upstream to be under fully control of the program (like being the only place where it's been distributed, people not adapting it without renaming, etc.) I politely asked that if you fork it, fork it with a different name. Just like the Debian community would ask me to use a different name if I created a derived distribution that included proprietary software. So you are telling me do as I say, don't do as I do? And again, your definition of base principles of open source may not be shared by a lot of people in the open source community. otherwise, why would you even care if some odd divelog software is no longer distributed by distro X? It's like when DLRS manufacturers bring out a new mount system... they promise you everything that this will be *their* system for the future. People start to invest (money) in it,.. and not rarely it happened that the manufacturer changed the mount some years afterwards. The point is: People invested in subsurface, in the sense that they stored all their data in it,... and part of the decision for that may have been the believe that subsurface acts like any other typical sane open source project - in this example: not trying to keep distros from properly packaging software. If the subsurface people would have said from the beginning: This is our nice fancy new diving log software. Use it, but beware that we want to keep full control (unless you fork) and in 2 years we'll try to prevent distros from packaging. than I guess many people (at least myself) would have never used it in the first place. I'm sorry we mislead you. I don't quite understand how we mislead you. I don't quite understand how data in our open XML format is similar to spending money on a DLSR - but I guess we have by now well established that we are talking past each other. Subsurface is open source, continues to be open source. It has an active community of developers and runs on many different OSs and platforms. Our data format is open, our sources are open source under the GPLv2, no one is taking anything from you. We have asked SPECIFICALLY Debian to stop providing an out-dated version of Subsurface to its users as that caused confusion and problems for our users and support burdon for us. Debian was unwilling to follow our choices of open source components that we used. So we asked Debian to drop bundling Subsurface since we provide a version of Subsurface which a diver who happens to run Debian and wants to use Subsurface can install. Here's the funny thing. There aren't a lot of options for a diver looking for a decent open source dive log. But there are a TON of options for a diver looking for an OS that supports her needs. And the numbers that we have clearly show that a tiny fractions of divers seem to think that Debian is their best choice. And the audience for which Subsurface is being developed is divers, not Debian maintainers. On Wed, 2015-08-26 at 08:54 +0200, Christian PERRIER wrote: For sure, I well understand that redisigning Subsurface to use a different storage backend is not something one can reasonably considerbut maybe having this as an option could be nice. Actually, the XML backend already exists (or did
Bug#796990: Ogr2ogr with wrapdateline fails on armhf
Package:gdal Version: 1.11.2+dfsg-1 Severity: normal Hello Team members, While investigating the failing tests of rasterio in sid on armhf/armel [1,2] I tried doing the same command using ogr2ogr: ogr2ogr new.geojson test.geojson -t_srs epsg:4326 -f GeoJSON -wrapdateline ERROR 1: vector::_M_fill_insert ERROR 1: vector::_M_fill_insert ERROR 1: vector::_M_fill_insert ERROR 1: vector::_M_fill_insert The same error is encountered. This error comes from C++ so I assume it is related to the libstdc++ transition. Moreover, if I build rasterio on stretch the error does not occur (and the ogr2ogr command works fine). [1] https://buildd.debian.org/status/fetch.php?pkg=rasterioarch=armelver=0.25.0-1stamp=1440369003 [2] https://buildd.debian.org/status/fetch.php?pkg=rasterioarch=armhfver=0.25.0-1stamp=1440368428 test.geojson Description: Binary data
Bug#795627: mime-construct: diff for NMU version 1.11+nmu1
Control: tags 795627 + patch Control: tags 795627 + pending Dear maintainer, I've prepared an NMU for mime-construct (versioned as 1.11+nmu1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Red Hot Chili Peppers: My Friends diff -Nru mime-construct-1.11/debian/changelog mime-construct-1.11+nmu1/debian/changelog --- mime-construct-1.11/debian/changelog 2010-06-23 20:07:38.0 +0200 +++ mime-construct-1.11+nmu1/debian/changelog 2015-08-26 18:04:55.0 +0200 @@ -1,3 +1,12 @@ +mime-construct (1.11+nmu1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #795627) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 18:04:54 +0200 + mime-construct (1.11) unstable; urgency=low * Add --body and --attach aliases. diff -Nru mime-construct-1.11/debian/rules mime-construct-1.11+nmu1/debian/rules --- mime-construct-1.11/debian/rules 2001-07-31 16:51:14.0 +0200 +++ mime-construct-1.11+nmu1/debian/rules 2015-08-26 18:03:43.0 +0200 @@ -28,7 +28,7 @@ dh_testroot dh_clean -k dh_installdirs - $(MAKE) install PREFIX=$(prefix)/usr + $(MAKE) install DESTDIR=$(prefix) find $(prefix) -depth -type d -print0 | \ xargs -0r rmdir --ignore-fail-on-non-empty touch $@ signature.asc Description: Digital Signature
Bug#796069: protobuf: FTBFS on mips{,el} (test suite failure)
On 26/08/15 00:52, Simon McVittie wrote:
If it's any help, this is reproducible on minkus.debian.org (mips, Octeon),
but is not reproducible with DEB_BUILD_OPTIONS=noopt on the same machine.
So it might be possible to coax it into working (well enough to get
through this transition) by reducing or omitting optimization on mips.
The same thing happened on eder: a build with noopt passes its tests.
To keep the g++-5 transition moving, I'm tempted to NMU a version of
protobuf that builds with -O0 on mips{,el}, and drop this bug down to
important severity; and then the mips porters and the protobuf
maintainers can work out what is actually going on and do a more
targeted fix, without stalling various transitions in the meantime. Does
that seem a reasonable plan?
S
Bug#795635: libproc-waitstat-perl: diff for NMU version 1.00-4.1
Control: tags 795635 + patch Control: tags 795635 + pending Dear maintainer, I've prepared an NMU for libproc-waitstat-perl (versioned as 1.00-4.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Tony Joe White: Gumbo John diff -u libproc-waitstat-perl-1.00/debian/changelog libproc-waitstat-perl-1.00/debian/changelog --- libproc-waitstat-perl-1.00/debian/changelog +++ libproc-waitstat-perl-1.00/debian/changelog @@ -1,3 +1,12 @@ +libproc-waitstat-perl (1.00-4.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #795635) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 18:33:51 +0200 + libproc-waitstat-perl (1.00-4) unstable; urgency=low * Drop /usr/doc symlink by rebuilding with newer debhelper (closes: #359460). diff -u libproc-waitstat-perl-1.00/debian/rules libproc-waitstat-perl-1.00/debian/rules --- libproc-waitstat-perl-1.00/debian/rules +++ libproc-waitstat-perl-1.00/debian/rules @@ -28,7 +28,7 @@ dh_testroot dh_clean -k dh_installdirs - $(MAKE) install PREFIX=$(prefix)/usr + $(MAKE) install DESTDIR=$(prefix) find $(prefix) -depth -type d -print0 | \ xargs -0r rmdir --ignore-fail-on-non-empty touch $@ signature.asc Description: Digital Signature
Bug#795684: tagcloud: diff for NMU version 1.4-1.2
Control: tags 795684 + patch Control: tags 795684 + pending Dear maintainer, I've prepared an NMU for tagcloud (versioned as 1.4-1.2) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Bruce Springsteen The E Street Band: The River diff -u tagcloud-1.4/debian/changelog tagcloud-1.4/debian/changelog --- tagcloud-1.4/debian/changelog +++ tagcloud-1.4/debian/changelog @@ -1,3 +1,12 @@ +tagcloud (1.4-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #795684) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 19:01:49 +0200 + tagcloud (1.4-1.1) unstable; urgency=low * Non-maintainer upload. diff -u tagcloud-1.4/debian/rules tagcloud-1.4/debian/rules --- tagcloud-1.4/debian/rules +++ tagcloud-1.4/debian/rules @@ -41,7 +41,7 @@ dh_testroot dh_installdirs - $(MAKE) install PREFIX=$(TMP)/usr + $(MAKE) install DESTDIR=$(TMP) [ ! -d $(TMP)/usr/lib/perl5 ] || \ rmdir -p --ignore-fail-on-non-empty $(TMP)/usr/lib/perl5 signature.asc Description: Digital Signature
Bug#796990: Ogr2ogr with wrapdateline fails on armhf
On 26-08-15 18:02, Johan Van de Wauw wrote:
While investigating the failing tests of rasterio in sid on
armhf/armel [1,2] I tried doing the same command using ogr2ogr:
ogr2ogr new.geojson test.geojson -t_srs epsg:4326 -f GeoJSON -wrapdateline
ERROR 1: vector::_M_fill_insert
ERROR 1: vector::_M_fill_insert
ERROR 1: vector::_M_fill_insert
ERROR 1: vector::_M_fill_insert
The same error is encountered. This error comes from C++ so I assume
it is related to the libstdc++ transition. Moreover, if I build
rasterio on stretch the error does not occur (and the ogr2ogr command
works fine).
Builds on stretch have different versions in the dependency chain, as
part of the ongoing GCC 5 transitions several packages in the rasterio
dependency chain have been updated to newer upstream versions, most
importantly gdal.
The most interesting aspect of this issue is that it's limited to
arm{hf,el} which makes me suspect architecture differences are the root
cause.
I'm not sure what to do with this bugreport, if it's a problem with gdal
on arm{el,hf} we should forward it upstream, but since it can also very
likely be caused by the ongoing transitions we should probably keep it
around for now and check it again when the GCC 5 transitions have completed.
For now I'll do some porter uploads with nocheck to allow the build to
succeed and not block the gdal transition.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#738161: cmake: Patch to bootstrap without Qt
On Wed, Aug 26, 2015 at 9:19 AM, Felix Geyer fge...@debian.org wrote: I've added a stage1 build profile to disable building the Qt GUI: http://anonscm.debian.org/cgit/collab-maint/cmake.git/commit/?h=experimentalid=a8bc51cb82c1ea7b5ba8ba72b39d764d22f5b828 Looks good - just one minor comment: I tend to use filter instead of findstring. It probably doesn't make that much difference, though - it's not too likely that somebody will try to use another profile name that contains stage1. About curl: A difference between using the system libraries vs. the bundled one might be the feature set that curl is built with. Afaik cmake uses curl to submit test results to a dashboard and to allow downloading files during a build. I wouldn't expect differences in curl to impact cmake in the context of Debian package builds. On the other hand, it would impact user-visible functionality. See for example http://www.cmake.org/pipermail/cmake/2014-October/058911.html. So, doing this without a rename of the resulting cmake package would technically violate the requirement we're discussing. Whether it's a small enough violation that it could be ignored, I don't really know. I'd be fine with adding this to cmake. Please let me know if this would be useful. -- Daniel
Bug#796905: Addendum
I forgot to mention, with a non-trivial script that produces 4 more complex plots, the number of lseeks goes to ~ 31,000. Best, -Nikolaus
Bug#795628: libromana-perligata-perl: diff for NMU version 0.55-1.1
Control: tags 795628 + patch Control: tags 795628 + pending Dear maintainer, I've prepared an NMU for libromana-perligata-perl (versioned as 0.55-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Solomon Burke: Stepchild diff -u libromana-perligata-perl-0.55/debian/changelog libromana-perligata-perl-0.55/debian/changelog --- libromana-perligata-perl-0.55/debian/changelog +++ libromana-perligata-perl-0.55/debian/changelog @@ -1,3 +1,12 @@ +libromana-perligata-perl (0.55-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #795628) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 18:08:10 +0200 + libromana-perligata-perl (0.55-1) unstable; urgency=low * New maintainer (closes: #259589) diff -u libromana-perligata-perl-0.55/debian/rules libromana-perligata-perl-0.55/debian/rules --- libromana-perligata-perl-0.55/debian/rules +++ libromana-perligata-perl-0.55/debian/rules @@ -27,7 +27,7 @@ dh_clean -k dh_installdirs - $(MAKE) install PREFIX=$(CURDIR)/debian/libromana-perligata-perl/usr + $(MAKE) install DESTDIR=$(CURDIR)/debian/libromana-perligata-perl binary-indep: build install signature.asc Description: Digital Signature
Bug#795631: libstring-shellquote-perl: diff for NMU version 1.03-1.1
Control: tags 795631 + patch Control: tags 795631 + pending Dear maintainer, I've prepared an NMU for libstring-shellquote-perl (versioned as 1.03-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Kante: Im ersten Licht (Mr. Bird and Partner Version) diff -u libstring-shellquote-perl-1.03/debian/changelog libstring-shellquote-perl-1.03/debian/changelog --- libstring-shellquote-perl-1.03/debian/changelog +++ libstring-shellquote-perl-1.03/debian/changelog @@ -1,3 +1,12 @@ +libstring-shellquote-perl (1.03-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #795631) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 18:20:18 +0200 + libstring-shellquote-perl (1.03-1) unstable; urgency=low * New upstream release (only change is addition of shell-quote script). diff -u libstring-shellquote-perl-1.03/debian/rules libstring-shellquote-perl-1.03/debian/rules --- libstring-shellquote-perl-1.03/debian/rules +++ libstring-shellquote-perl-1.03/debian/rules @@ -28,7 +28,7 @@ dh_testroot dh_clean -k dh_installdirs - $(MAKE) install PREFIX=$(prefix)/usr + $(MAKE) install DESTDIR=$(prefix) find $(prefix) -depth -type d -print0 | \ xargs -0r rmdir --ignore-fail-on-non-empty touch $@ signature.asc Description: Digital Signature
Bug#795633: libtext-header-perl: diff for NMU version 1.03-2.1
Control: tags 795633 + patch Control: tags 795633 + pending Dear maintainer, I've prepared an NMU for libtext-header-perl (versioned as 1.03-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Rolling Stones: Lucky diff -Nru libtext-header-perl-1.03/debian/changelog libtext-header-perl-1.03/debian/changelog --- libtext-header-perl-1.03/debian/changelog 2003-12-23 13:05:20.0 +0100 +++ libtext-header-perl-1.03/debian/changelog 2015-08-26 18:27:28.0 +0200 @@ -1,3 +1,12 @@ +libtext-header-perl (1.03-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #795633) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 18:27:26 +0200 + libtext-header-perl (1.03-2) unstable; urgency=low * Trivial fix for -w. (closes: #217791) diff -Nru libtext-header-perl-1.03/debian/rules libtext-header-perl-1.03/debian/rules --- libtext-header-perl-1.03/debian/rules 2002-09-01 12:09:44.0 +0200 +++ libtext-header-perl-1.03/debian/rules 2015-08-26 18:25:53.0 +0200 @@ -47,7 +47,7 @@ # Add here commands to install the package into debian/tmp. #$(MAKE) install DESTDIR=`pwd`/debian/tmp - $(MAKE) install PREFIX=$(TMP)/usr + $(MAKE) install DESTDIR=$(TMP) # Build architecture-independent files here. signature.asc Description: Digital Signature
Bug#795632: libropkg-perl: diff for NMU version 0.4-1.1
Control: tags 795632 + patch Control: tags 795632 + pending Dear maintainer, I've prepared an NMU for libropkg-perl (versioned as 0.4-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Rolling Stones: Lucky diff -u libropkg-perl-0.4/debian/rules libropkg-perl-0.4/debian/rules --- libropkg-perl-0.4/debian/rules +++ libropkg-perl-0.4/debian/rules @@ -43,7 +43,7 @@ dh_clean -k dh_installdirs - $(MAKE) install PREFIX=$(TMP)/usr + $(MAKE) install DESTDIR=$(TMP) # Remove any empty directories diff -u libropkg-perl-0.4/debian/changelog libropkg-perl-0.4/debian/changelog --- libropkg-perl-0.4/debian/changelog +++ libropkg-perl-0.4/debian/changelog @@ -1,3 +1,12 @@ +libropkg-perl (0.4-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #795632) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 18:23:42 +0200 + libropkg-perl (0.4-1) unstable; urgency=low * New upstream release signature.asc Description: Digital Signature
Bug#795637: pbnj: diff for NMU version 2.04-4.1
Control: tags 795637 + patch Control: tags 795637 + pending Dear maintainer, I've prepared an NMU for pbnj (versioned as 2.04-4.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Tony Joe White: Gumbo John diff -u pbnj-2.04/debian/rules pbnj-2.04/debian/rules --- pbnj-2.04/debian/rules +++ pbnj-2.04/debian/rules @@ -35,7 +35,7 @@ dh_installdirs # Add commands to install the package into debian/$PACKAGE_NAME here - $(MAKE) install PREFIX=$(CURDIR)/debian/pbnj/usr + $(MAKE) install DESTDIR=$(CURDIR)/debian/pbnj binary-arch: build install diff -u pbnj-2.04/debian/changelog pbnj-2.04/debian/changelog --- pbnj-2.04/debian/changelog +++ pbnj-2.04/debian/changelog @@ -1,3 +1,12 @@ +pbnj (2.04-4.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #795637) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 18:37:26 +0200 + pbnj (2.04-4) unstable; urgency=low * Fix bug which caused MySQL to not work when inserting a machine signature.asc Description: Digital Signature
Bug#762637: qtile in Debian
Hi, I think that all of the dependencies, as stated in [1] for qtile are now met in jessie and testing. Miguel would you consider revisiting packaging of qtile now? If you need help I am willing to help with it (I am DM, almost DD). [1] https://github.com/qtile/qtile/blob/develop/requirements.txt -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 1.6.2 BTiCW | tel. +48 61 665 23 71 signature.asc Description: Digital signature
Bug#793012: gmp-ecm: FTBFS on mipsel: bad assembly?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Jurica: thanks a lot for your material ! On 26/08/15 15:54, Jurica Stanojkovic wrote: Hello, I was able to build package gmp-ecm_6.4.4+ds-2 with patch that is attached. First part of patch is taken from upstream (file longlong.h) I had to add second part (file sp.h) in order to build package successfully. Patch is attached. Alternatively, if following code for umul_ppm is used, instead of upstream patch, package also does build successfully. #define umul_ppmm(w1, w0, u, v) \ __asm__ (multu %2,%3\n\tmflo %0\n\tmfhi %1 \ : =d (w0), =d (w1) : d (u), d (v)) I will try first the short version, namely the three above line. Thanks, Jerome Thank you! Regards, Jurica -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV3e8WAAoJEIC/w4IMSybj3oQH/0o+JsURtfTepyN2n3WzRmI0 k8ggwYatQ5nBFcfESNb0efJSY5n5b27VCtByvEXtZAMIQBvzapyR8Br1pWKH/t04 AR8yCyRoyk2IPML0ZL6Ga/tnWl5CKwGEu2wPVEvvtWJGYSBTf0M7YcqgKGICEheV WZrsWBrWsJBoVxJFgsN79xwnfSbURY1ZzoicO2mIlQeLaKbHz82EBdJUi2uB/b1L ZRhWwnXsVM1QBfJg/X0iWXecCu/q50ardpWYo2LYdYuNwykmv6PpPGiQolE/Q2dH AAWiFb41v+CEYA9PGTOX79u49TLB0ViOGKC79sMJ+ireUbZjqT7/Ty3jRTBNom4= =pmvu -END PGP SIGNATURE-
Bug#795634: libtime-period-perl: diff for NMU version 1.20-8.1
Control: tags 795634 + patch Control: tags 795634 + pending Dear maintainer, I've prepared an NMU for libtime-period-perl (versioned as 1.20-8.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Bettina Wegner: Heimweh nach Heimat diff -u libtime-period-perl-1.20/debian/changelog libtime-period-perl-1.20/debian/changelog --- libtime-period-perl-1.20/debian/changelog +++ libtime-period-perl-1.20/debian/changelog @@ -1,3 +1,12 @@ +libtime-period-perl (1.20-8.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #795634) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 18:30:51 +0200 + libtime-period-perl (1.20-8) unstable; urgency=low * Drop /usr/doc symlink by rebuilding with newer debhelper (closes: #359529). diff -u libtime-period-perl-1.20/debian/rules libtime-period-perl-1.20/debian/rules --- libtime-period-perl-1.20/debian/rules +++ libtime-period-perl-1.20/debian/rules @@ -28,7 +28,7 @@ dh_testroot dh_clean -k dh_installdirs - $(MAKE) install PREFIX=$(prefix)/usr + $(MAKE) install DESTDIR=$(prefix) find $(prefix) -depth -type d -print0 | \ xargs -0r rmdir --ignore-fail-on-non-empty touch $@ signature.asc Description: Digital Signature
Bug#796069: protobuf: FTBFS on mips{,el} (test suite failure)
Simon McVittie wrote:
On 26/08/15 00:52, Simon McVittie wrote:
If it's any help, this is reproducible on minkus.debian.org (mips, Octeon),
but is not reproducible with DEB_BUILD_OPTIONS=noopt on the same machine.
So it might be possible to coax it into working (well enough to get
through this transition) by reducing or omitting optimization on mips.
The same thing happened on eder: a build with noopt passes its tests.
To keep the g++-5 transition moving, I'm tempted to NMU a version of
protobuf that builds with -O0 on mips{,el}, and drop this bug down to
important severity; and then the mips porters and the protobuf
maintainers can work out what is actually going on and do a more
targeted fix, without stalling various transitions in the meantime. Does
that seem a reasonable plan?
Hi,
This sounds very vaguely similar to #572923, for which the workaround
was to disable optimization of a single function:
https://sources.debian.net/src/protobuf/2.3.0-4/debian/patches/arm_optimization.diff/
I'm OK with a NMU that disables optimization of the entire build on
mips{,el} for now, though, if it will keep the GCC-5 transition moving
along. Please feel free to upload to incoming rather than DELAYED.
Thanks for looking into this!
--
Robert Edmonds
edmo...@debian.org
Bug#622265: TERM=screen.mlterm breaks dircolors
On 2015-08-26 18:05 +0200, Axel Beckert wrote: Hi, Matthew Gabeler-Lee wrote: This isn't just mlterm. This breaks xterm, xterm-256color, etc. too I'm sorry, but while I can reproduce the issue with env TERM=mlterm screen, I can't reproduce it with env TERM=xterm-256color screen (on Jessie). In the latter case, dircolors just look fine to me. Anyways, the terminfo definitions this bug is about are _not_ part of the screen package but part of the ncurses-term package. So if the terminal definitions for screen.mlterm needs to be changed, that should be a wishlist bug against ncurses-term, not screen. I'm tempted to reassign this bug report to ncurses-term. What do the ncurses-term maintainers (Cc'ed) think about this? If anything it should be reassigned to coreutils, because dircolors does not use the terminfo database in the first place but rather uses its own (viewable with dircolors -p). Cheers, Sven
Bug#795626: makepatch: diff for NMU version 2.03-1.1
Control: tags 795626 + patch Control: tags 795626 + pending Dear maintainer, I've prepared an NMU for makepatch (versioned as 2.03-1.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Zueriwest: Zorro diff -u makepatch-2.03/debian/changelog makepatch-2.03/debian/changelog --- makepatch-2.03/debian/changelog +++ makepatch-2.03/debian/changelog @@ -1,3 +1,12 @@ +makepatch (2.03-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with perl 5.22 in experimental (MakeMaker changes): +use DESTDIR in debian/rules. +(Closes: #795626) + + -- gregor herrmann gre...@debian.org Wed, 26 Aug 2015 18:01:41 +0200 + makepatch (2.03-1) unstable; urgency=low * New upstream release. diff -u makepatch-2.03/debian/rules makepatch-2.03/debian/rules --- makepatch-2.03/debian/rules +++ makepatch-2.03/debian/rules @@ -27,7 +27,7 @@ dh_testroot dh_prep dh_installdirs - $(MAKE) install PREFIX=$(prefix)/usr + $(MAKE) install DESTDIR=$(prefix) find $(prefix) -depth -type d -print0 | \ xargs -0r rmdir --ignore-fail-on-non-empty touch $@ signature.asc Description: Digital Signature
