Bug#944148: RM: apachedex -- ROM; popcon=8
Package: ftp.debian.org Severity: normal Hi, Considering the very low popcon and that I don't have time to maintain it anymore, I think it is better to remove this package from the archive. I have also asked the upstream author and he doesn't mind as he is not using the Debian package anyway. Cheers, Arnaud Fontaine
Bug#939532: RM: slapos.core -- ROM; python2-only; dead upstream; popcon=2; not in stable
Hi, > It is already supported but let me talk with the upstream to see if it > still makes sense to have it in Debian considering the very low popcon > and I will get back to you. After talking with the upstream developers, it does not make sense anymore to have this package in Debian. Also, I have just requested removal of python-xmlmarshaller which was only needed for slapos.core (#939902). Cheers, -- Arnaud Fontaine
Bug#939902: RM: xmlmarshaller -- ROM; removal triggered by the Python2 removal; popcon=26
Package: ftp.debian.org Severity: normal Hi, As slapos.core has been removed from unstable (#939532) and it was the only package depending on xmlmarshaller and considering its very low popcon, I think it is better to remove it from the archive even though it supports python3. Cheers, Arnaud Fontaine
Bug#895787: Fwd: RFS: pcapy/0.11.3-1 [ITA]
Hi, Do you still intend to take over maintenance of this package? (last time I suggested to sponsor your upload if needed but I'm unfortunately not going to have time to do that anymore, sorry) Regards, -- Arnaud Fontaine
Bug#939532: RM: slapos.core -- ROM; python2-only; dead upstream; popcon=2; not in stable
Hi, >> "dead upstream" is completely wrong >> considering that the last upstream release was less than a month >> ago[0]. >> [0] https://pypi.org/project/slapos.core/ > > interesting, as i've navigated thru their website to: > > [...] Indeed. The Homepage should be updated, sorry about that. >> + While I agree that the popcon is very low and that I have not >> updated it for some time, > > As you know, any package in debian introduces an indirect "cost" to > the rest of the packages; in this case, we're trying to remove python2 > from the distribution for bullseye release > (https://wiki.debian.org/Python/2Removal) and currently slapos.core > depends on ~20 packages (that means removing slapos.core will remove a > reverse depends on each one of the) > > can we make slapos python3 compatible in Debian? in a timely manner? > If not, maybe RM it is the right approach? It is already supported but let me talk with the upstream to see if it still makes sense to have it in Debian considering the very low popcon and I will get back to you. Cheers, -- Arnaud Fontaine
Bug#920404: Orphaning rope* packages
retitle 920404 O: rope -- Python refactoring library retitle 920405 O: ropemacs -- Emacs mode for Python refactoring retitle 920407 O: ropemode -- ropemode, a helper for using rope refactoring library in IDE thanks Hi, After several months as RFA, I'm now orphaning these packages. Regards, -- Arnaud Fontaine
Bug#939642: O: python-medusa -- Framework for implementing asynchronous servers
Package: wnpp Severity: normal I intend to orphan the python-medusa package. This package is very low maintenance and since there has recently been a new release to support Python3, it should cause any problem for the removal of python2. The package description is: Medusa is a 'server platform' -- it provides a framework for implementing asynchronous socket-based servers (TCP/IP and on Unix, Unix domain, sockets). Regards, Arnaud Fontaine
Bug#939532: RM: slapos.core -- ROM; python2-only; dead upstream; popcon=2; not in stable
Hi, I'm the maintainer of this package and I have been very surprised by this removal because: + I don't think I have been asked nor even contacted about the removal despite being the maintainer. + While I agree that the popcon is very low and that I have not updated it for some time, "dead upstream" is completely wrong considering that the last upstream release was less than a month ago[0]. Regards, -- Arnaud Fontaine [0] https://pypi.org/project/slapos.core/
Bug#930462: ERROR: unable to download video data: HTTP Error 403: Forbidden
Package: youtube-dl Version: 2019.01.17-1.1 Severity: grave Hi, I get this error when trying to download videos from youtube. Updating the package to 2019.06.08 fixes the issue. Cheers, Arnaud Fontaine
Bug#923376: Should only be in unstable
Source: slapos.core Severity: serious As per upstream request, this package should not be available in testing and hence in stable release so filling this bug report. Regards, Arnaud Fontaine
Bug#920398: RM: twill -- ROM; abandoned upstream
block 920398 by 920478 920479 920480 thanks Hi, There are, however, users in the archive: Checking reverse dependencies... # Broken Build-Depends: flask-testing: python-twill trac: python-twill trac-xmlrpc: python-twill Dependency problem found. Please ask them to drop the build-depends and remove the moreinfo tag once that is done. I should have checked before filling this bug report, sorry about that. I have thus submitted bug reports on these packages. Cheers, Arnaud Fontaine
Bug#920480: Build-Depends on twill going to be removed from the archive
Package: trac-xmlrpc Severity: normal Hi, For the reasons stated in #920398, as twill maintainer I have asked for it to be removed from the archive. However your package Build-Depends on it. Would it be possible to remove it? Cheers, Arnaud Fontaine
Bug#920478: Build-Depends on twill going to be removed from the archive
Source: flask-testing Severity: normal Hi, For the reasons stated in #920398, as twill maintainer I have asked for it to be removed from the archive. However your package Build-Depends on it. Would it be possible to remove it? Cheers, Arnaud Fontaine
Bug#920479: Builds-Depends on twill going to be removed from the archive
Package: trac Severity: normal Hi, For the reasons stated in #920398, as twill maintainer I have asked for it to be removed from the archive. However your package Build-Depends on it. Would it be possible to remove it? Cheers, Arnaud Fontaine
Bug#920407: RFA: ropemode
Package: wnpp Severity: normal I no longer use ropemacs nor have time to maintain it so I would like someone to take over maintenance of rope and its related packages (namely pymacs, ropemacs and ropemode) for which I have also filled RFAs.
Bug#920404: RFA: rope
Package: wnpp Severity: normal I no longer use ropemacs nor have time to maintain it so I would like someone to take over maintenance of rope and its related packages (namely pymacs, ropemacs and ropemode) for which I have also filled RFAs.
Bug#920406: RFA: pymacs -- interface between Emacs Lisp and Python
Package: wnpp Severity: normal I no longer use ropemacs nor have time to maintain it so I would like someone to take over maintenance of rope and its related packages (namely pymacs, ropemacs and ropemode) for which I have also filled RFAs.
Bug#920405: RFA: ropemacs
Package: wnpp Severity: normal I no longer use ropemacs nor have time to maintain it so I would like someone to take over maintenance of rope and its related packages (namely pymacs, ropemacs and ropemode) for which I have also filled RFAs.
Bug#920402: RM: pyscript -- ROM; abandoned upstream
Package: ftp.debian.org Severity: normal Hi, I no longer use nor have time to take care of the package but for the following reasons I'm requesting its removal rather than orphaning it: * No release for ~13 years and even then considered beta by its author. * Very low popcon. Cheers, Arnaud Fontaine
Bug#920399: RM: nethack-el -- ROM; abandoned upstream
Package: ftp.debian.org Severity: normal I no longer use nor have time to take care of the package but for the following reasons I'm requesting its removal rather than orphaning it: * This lisp port has been dead upstream for ~12 years. * Not tested with recent nethack version and its maintainer no longer wish to maintain the patch (#909026). * Low popcon. Cheers, Arnaud Fontaine
Bug#920398: RM: twill -- ROM; abandoned upstream
Package: ftp.debian.org Severity: normal I no longer use nor have time to take care of the package but for the following reasons I'm requesting its removal rather than orphaning it: * There has been no upstream release for 5 years. * Upstream website is no longer available. * It ships a (very old) modified copy of Python mechanize module. * Popcon is very low. Cheers, Arnaud Fontaine
Bug#919542: RFA: nethack-el -- Emacs major-mode for playing NetHack
Package: wnpp Severity: normal I no longer use nethack-el nor have the time to maintain it properly anymore, so I'm looking for someone to take over this package. The package description is: Nethack is a wonderfully silly, yet quite addicting, Dungeons and Dragons-style adventure game. You play the part of a fierce fighter, wizard, or any of many other classes, fighting your way down to retrieve the Amulet of Yendor (try saying THAT one backwards!) for your god. On the way, you might encounter a quantum mechanic or two, or perhaps a microscopic space fleet, or -- if you're REALLY lucky -- the Ravenous Bugblatter Beast of Traal. . Features of NetHack for Emacs include: * Customizable Keys * Event Hooks * Customizable colors * And all the power of Emacs
Bug#916409: 'download' fails on '~' in version with 'Error: pattern not supported by this subcommand:'
Source: aptitude
Severity: normal
Hi,
# aptitude download dirmngr=2.1.18-8~deb9u3
Error: pattern not supported by this subcommand: 'dirmngr=2.1.18-8~deb9u3'
Although the command actually called by 'aptitude download' ('apt download')
handles it without problem:
# apt download dirmngr=2.1.18-8~deb9u3
Get:1 http://ftp.jp.debian.org/debian stable/main amd64 dirmngr amd64
2.1.18-8~deb9u3 [597 kB]
Fetched 597 kB in 1s (857 kB/s)
Cheers,
Arnaud Fontaine
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Bug#900322: FTBFS if built twice in a row
Package: nitrokey-app
Version: 1.3.0-1
Severity: important
User: debian...@lists.debian.org
Usertags: qa-doublebuild
Hi,
Building twice in a row fails because of .ts files being updated during the
build. Here is the error message on the second build:
dpkg-buildpackage: info: source package nitrokey-app
dpkg-buildpackage: info: source version 1.3.0-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Jan Luca Naumann
dpkg-buildpackage: info: host architecture amd64
dpkg-source --before-build nitrokey-app-1.3.0
dpkg-source: info: applying 0001-use-debhelper-for-bash-completion.patch
fakeroot debian/rules clean
dh clean --with bash-completion
dh_auto_clean
dh_clean
rm -f debian/debhelper-build-stamp
rm -rf debian/.debhelper/
rm -f -- debian/nitrokey-app.substvars debian/files
rm -fr -- debian/nitrokey-app/ debian/tmp/
find . \( \( \
\( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o
-path .\*/.hg -o -path .\*/CVS -o -path .\*/.pc -o -path .\*/_darcs \) -prune
-o -type f -a \
\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
-o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
-o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
-o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
\) -exec rm -f {} + \) -o \
\( -type d -a -name autom4te.cache -prune -exec rm -rf {} +
\) \)
dpkg-source -b nitrokey-app-1.3.0
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building nitrokey-app using existing
./nitrokey-app_1.3.0.orig.tar.gz
dpkg-source: info: local changes detected, the modified files are:
nitrokey-app-1.3.0/i18n/nitrokey_arabic.ts
nitrokey-app-1.3.0/i18n/nitrokey_de_DE.ts
nitrokey-app-1.3.0/i18n/nitrokey_en.ts
nitrokey-app-1.3.0/i18n/nitrokey_fr.ts
dpkg-source: info: you can integrate the local changes with dpkg-source
--commit
dpkg-source: error: aborting due to unexpected upstream changes, see
/tmp/nitrokey-app_1.3.0-1.diff.glsyzx
dpkg-buildpackage: error: dpkg-source -b nitrokey-app-1.3.0 subprocess
returned exit status 2
Cheers,
Arnaud Fontaine
Bug#900321: Icons not displayed
Package: nitrokey-app Version: 1.3.0-1 Severity: important Tags: patch upstream Hi, First of all, thanks for packaging nitrokey-app! Since nitrokey-app 1.3.0, icons are not displayed anymore: QSystemTrayIcon::setVisible: No Icon set qt.svg: Cannot open file ':/images/new/icon_NK.svg', because: No such file or directory qt.svg: Cannot open file ':/images/new/icon_safe.svg', because: No such file or directory qt.svg: Cannot open file ':/images/new/icon_harddrive.svg', because: No such file or directory qt.svg: Cannot open file ':/images/new/icon_fragezeichen.svg', because: No such file or directory qt.svg: Cannot open file ':/images/new/icon_quit.svg', because: No such file or directory More generally all the resources (as listed in resources.qrc) are not available because they are not compiled and linked to the final executable. This has been reported upstream already[0] and the fix has been merged too[1]. After applying the patch of this merge request[2] and rebuilding the package, I can confirm that icons and other text files are now visible. Could you please apply this patch? Thanks! Cheers, Arnaud Fontaine [0] https://github.com/Nitrokey/nitrokey-app/issues/345 [1] https://github.com/Nitrokey/nitrokey-app/pull/346 [2] https://github.com/Nitrokey/nitrokey-app/pull/346/commits/30587e2e8915b14c0256feff39bca39b6646203c -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-1+ck1-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages nitrokey-app depends on: ii libc6 2.27-3 ii libgcc1 1:8.1.0-3 ii libnitrokey33.3-2 ii libqt5core5a5.10.1+dfsg-7 ii libqt5gui5 5.10.1+dfsg-7 ii libqt5svg5 5.10.1-2 ii libqt5widgets5 5.10.1+dfsg-7 ii libstdc++6 8.1.0-3 Versions of packages nitrokey-app recommends: ii libccid 1.4.29-2 ii pcscd 1.8.23-3 ii scdaemon 2.2.7-1 nitrokey-app suggests no packages. -- no debconf information
Bug#429577: #429577: ITP: emacs-snapshot -- The GNU Emacs editor (development snapshot)
Rob Browning <r...@defaultvalue.org> writes: > The unversioning is nearly finished, so I suspect the thing to do is for > me to finish the work, and then we'll look at your changes in that > context. Any changes outside debian/ should be relatively unaffected, > but others may require accommodation. In any case, I'll be happy to > work with you on that once we're there. > > Unless something unexpected happens, I expect to upload the unversioned > packages in the next week or so, if not sooner. Great, thanks! Let me know when it has been pushed so I can merge/rebase my changes. I will probably have a few more by then as there are a few more Lintian warnings that I want to fix before uploading emacs-snapshot to NEW... -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#429577: #429577: ITP: emacs-snapshot -- The GNU Emacs editor (development snapshot)
Hi, >> I have almost finished preparing emacs-snapshot[0] and as I said to >> Rob, my plan is to keep emacs-snapshot package as close as possible >> to emacsXY package. I know that you've been working on unversioning >> emacs package (BTW Where is that repository?). > > How many of the existing add-on packages in sid have you tested with > your emacs-snapshot package? Do you have some plan to prevent/manage > breakage of add-ons by a new upload of emacs-snapshot? It seems like > every upload is potentially like a library transition, in that changes > in emacs tend to break add-on packages. I use it myself on a daily basis for a few months (and Dima for much longer so he may know more than me about that) with around 20 add-ons. Except the fact that old-style backquotes have been removed for which I have a few patches ready (and which is something that will have to be deal for emacs26 anyway AFAIK), I have not had any problem so far. Anyhow, emacs-snapshot will only be available in sid/experimental and, except 4 source packages, all of them don't Build-Depends on emacs-snapshot. Also, most of the time, add-ons breakage to expect are on deprecated/removed interfaces (such as old-style backquotes) which is something that will have to be dealt anyway on new Emacs stable releases. But I get your point and indeed there need to be a plan to check before each upload of emacs-snapshot whether it breaks add-ons. A shell script installing in a clean chroot emacs-snapshot to be uploaded and all available add-ons in the archive would probably be enough and fairly easy to write? Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#899333: RM: zope-maildrophost -- ROM; Obsolete
Package: ftp.debian.org Severity: normal Hello, As part of the Debian Zope Team, I would like zope-maildrophost to be removed from the archive because it is now obsolete as confirmed by its current Cc'ed maintainer: Jonas Meurer <jo...@freesources.org> writes: > Maildrophost is completely obsolete as the internal Zope MailHost > got support for asynchronous mail delivery in recent releases. So > in other words: the package should be removed from Debian. Regards, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#429577: #429577: ITP: emacs-snapshot -- The GNU Emacs editor (development snapshot)
[Resending this email to debian-emacsen@ as per Rob's request] Hi, I have almost finished preparing emacs-snapshot[0] and as I said to Rob, my plan is to keep emacs-snapshot package as close as possible to emacsXY package. I know that you've been working on unversioning emacs package (BTW Where is that repository?). I have a few questions before uploading emacs-snapshot though: * bin_priority (for update-alternatives): I think it would make sense to have an higher one for emacs-snapshot, what about a number big enough so it doesn't clash with future stable release (such as 999)? * I have made several changes to emacs25 branch, feel free to merge them if they look fine to you (mostly debian/copyright work and fixing lintian warnings): https://salsa.debian.org/arnau/deb-emacs/commits/deb/emacs25/d/sid/master And some packaging questions I will document in debian/README.source: * Do you plan to keep using git-dpm? (I'm asking because Dima, the current packager of emacs-snapshot, is using gbp-pq. I have no preference/opinion on this subject, just asking) I ran the following command after importing patches from emacs25 and merging them with the ones from emacs-snapshot from Dima: $ git-dpm init --record-patch-name ../emacs-snapshot_20180414-1+git836dce6.orig.tar.xz deb/emacs-snapshot/d/sid/upstream However, I'm not so familiar with git-dpm, so would you mind explaining how you use it for emacs25/unversioned emacs? * I followed deb-emacs25[1] naming scheme for branches and tags, thus: + Branches: deb/emacs-snapshot/d/sid/master deb/emacs-snapshot/d/sid/upstream + Tags: deb/emacs-snapshot/v/upstream/20180414-1+git836dce6 I guess unversioned emacs Git repository follows this scheme too, right? * Could you please explain how you remove non-DFSG documentation (such as emacs.texi) from the Git repository? * Here is what I have been using to create a new upstream release from deb/emacs-snapshot/d/sid/master branch: $ git tag -s -m "Upstream tagged for Debian version 20180414-1+git836dce6." deb/emacs-snapshot/v/upstream/20180414-1+git836dce6 deb/emacs-snapshot/d/sid/upstream $ gbp buildpackage --git-builder=/bin/true --git-upstream-tree=deb/emacs-snapshot/v/upstream/20180414-1+git836dce6 => Thanks to debian/gbp.conf I added, this will automatically generate the tarball with pristine-tar. If that's ok, maybe debian/gbp.conf should be added to emacs25/unversioned emacs branch too? Cheers, -- Arnaud Fontaine [0] https://salsa.debian.org/arnau/deb-emacs [1] https://salsa.debian.org/rlb/deb-emacs/ signature.asc Description: PGP signature
Bug#429577: #429577: ITP: emacs-snapshot -- The GNU Emacs editor (development snapshot)
Hi, >> I have almost finished preparing emacs-snapshot and temporarily >> pushed it there, so please have a look when you have some time as I >> may have messed things around ;-): >> https://salsa.debian.org/arnau/deb-emacs > > Could you repost the questions that I don't sufficiently address below > to debian-emac...@lists.debian.org? I think there are people there > who should also see them, particularly those like David and Sean who > are working on the broad add-on packaging effort. Ok. >> * I was thinking about having deb-emacs repository for both emacs25 >> and emacs-snapshot in collab-maint Git (as emacs.git) instead of a >> user repository. What do you think? > > For the moment I'd prefer to keep the "emacs25" (soon to be > "emacs"[1]) flavor repository separate, which might suggest creating a > collab-maint emacs-snapshot repository for now, if that's what you'd > like. Ok. > [1] In case you weren't already aware, we're about to unversion the > emacsXY package to just be "emacs". It's possible that won't affect > your work too seriously, though it does involve a bunch of changes > to the emacs25 debian/ files. As part of that, the "emacsXY" binary > package is becoming "emacs-gtk" because we're also moving the > "emacs" metapackage into the upcoming unversioned emacs source > package. > > I say "we" because although I'm handling the code, David, Sean, > etc. have been helping figure out the details. > >> * Rob: I have made several changes to emacs25 branch, feel free to >> merge them if they look fine to you: >> https://salsa.debian.org/arnau/deb-emacs/commits/deb/emacs25/d/sid/master > > Appreciated -- my current plan is to finish the unversioning, and then > look back at what's pending elsewhere, emacs 26, bugs, etc. I'd guess > that it might make sense for you to rebase at that point (or at least > compare the changes), and then we can see where we stand. There are not so many changes and most of them are for debian/copyright which is not related to your work on unversioning the emacsXY package. Would you mind at least applying the changes I did which does not clash with your work? Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#896930: New upstream release 1.2.0
Package: terminology Version: 1.1.1-3 Severity: wishlist Hi, First of all, thanks for maintaining terminology. Could you please package the new upstream release released recently? Thanks! Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#429577: #429577: ITP: emacs-snapshot -- The GNU Emacs editor (development snapshot)
Hi, [Cc'ing the ITP FTR] I have almost finished preparing emacs-snapshot and temporarily pushed it there, so please have a look when you have some time as I may have messed things around ;-): https://salsa.debian.org/arnau/deb-emacs I have a few questions though: * bin_priority (for update-alternatives): I think it would make sense to have an higher one for emacs-snapshot, what about a number big enough so it doesn't clash with future stable release (such as 999)? * Currently emacs-snapshot version is: 2:MMDD--g-1 Considering that this is not really the LATEST_AVAILABLE_TAG but MASTER_COMMIT_ID at the time of packaging and in order to shorten the version which is currently rather long, MASTER_COMMIT_ID only should be enough, isn't it? This would mean having something like this after bumping the epoch and where the first '-1' is only in case of we upload two different Git snapshots on the same day: 3:MMDD-1+git-1 What do you think? * I put myself as Maintainer, and Rob and Dima as Uploaders, but if either Rob or Dima wish to be in the Maintainer field, please let me know as either is fine to me. * I was thinking about having deb-emacs repository for both emacs25 and emacs-snapshot in collab-maint Git (as emacs.git) instead of a user repository. What do you think? * Rob: I have made several changes to emacs25 branch, feel free to merge them if they look fine to you: https://salsa.debian.org/arnau/deb-emacs/commits/deb/emacs25/d/sid/master And some packaging questions I will add to debian/README.source: * Dima is using gbp-pq and Rob git-dpm. In order to keep it as close as possible to emacs25 packaging, I have been using git-dpm. I don't really well both of them as this is the first time I use them so I have absolutely no opinion on this. Dima: is that ok? Rob: I ran the following command after importing patches from emacs25 and merging them with the ones from emacs-snapshot from Dima: $ git-dpm init --record-patch-name ../emacs-snapshot_20180414-1+git836dce6.orig.tar.xz deb/emacs-snapshot/d/sid/upstream However, I'm not so familiar with git-dpm, so would you mind explaining how you use it for emacs25? * Rob: I followed your naming scheme for branches and tags, thus: + Branches: deb/emacs-snapshot/d/sid/master deb/emacs-snapshot/d/sid/upstream + Tags: deb/emacs-snapshot/v/upstream/20180414-1+git836dce6 * Rob: Could you please explain how you remove non-DFSG documentation (such as emacs.texi) from the Git repository? * Here is what I have been using to create a new upstream release from deb/emacs-snapshot/d/sid/master branch: $ git tag -s -m "Upstream tagged for Debian version 20180414-1+git836dce6." deb/emacs-snapshot/v/upstream/20180414-1+git836dce6 deb/emacs-snapshot/d/sid/upstream $ gbp buildpackage --git-builder=/bin/true --git-upstream-tree=deb/emacs-snapshot/v/upstream/20180414-1+git836dce6 => Thanks to debian/gbp.conf I added, this will automatically generate the tarball with pristine-tar. If that's ok, maybe debian/gbp.conf should be added to emacs25 branch too? Cheers, -- Arnaud signature.asc Description: PGP signature
Bug#895787: RFA: pcapy
Package: wnpp Severity: normal Hello, I no longer use pcapy nor have the time to maintain it properly anymore, so I'm looking for someone to take over this package. Regards, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#895785: RFA: impacket
Package: wnpp Severity: normal Hello, I no longer use impacket nor have the time to maintain it properly anymore, so I'm looking for someone to take over this package. Regards, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#895783: RFA: ply
Package: wnpp Severity: normal Hello, I no longer use ply nor have the time to maintain it properly anymore, so I'm looking for someone to take over this package. Regards, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#895786: RFA: cheetah
Package: wnpp Severity: normal Hello, I no longer use cheetah nor have the time to maintain it properly anymore, so I'm looking for someone to take over this package. Regards, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#895784: RFA: pyscript
Package: wnpp Severity: normal Hello, I no longer use pyscript nor have the time to maintain it properly anymore, so I'm looking for someone to take over this package. Regards, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#755911: Python3 version
Hi, Sorry, I completely forgot about this. I will do it within this week. Regards, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#846987: emms: diff for NMU version 4.2-1.1
Rob Browning <r...@defaultvalue.org> writes: > I've prepared an NMU for emms (versioned as 4.2-1.1) and > uploaded it to DELAYED/10. Please feel free to tell me if I > should delay it longer. Thanks for the NMU. -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#845495: src:python-tz: Non-maintainer upload of python-tz/2016.7-0.1 to DELAYED/5
Hilko Bengen <ben...@debian.org> writes: >> Unless I'm mistaken, as you have not specified that pytest should be >> used (by adding 'export PYBUILD_TEST_PYTEST=1' to debian/rules), it is >> still not used and no test is ran: > > I have just re-run the source package I uploaded in an unstable-amd64 > sbuild environment. The tests were executed. After checking /usr/share/perl5/Debian/Debhelper/Buildsystem/pybuild.pm, it seems that --test-pytest argument is automatically passed to pybuild if python(3)-pytest is in Build-Depends. Sorry for the noise. Thanks for the upload. Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#845495: src:python-tz: Non-maintainer upload of python-tz/2016.7-0.1 to DELAYED/5
Hilko Bengen <ben...@debian.org> writes: > thank you for your suggestions. I have enabled running upstream's tests > and otherwise made the build script a bit simpler. Since there has been > no reaction from any of the listed maintainers, I have NMU'd > python-tz/2016.7-0.2 to DELAYED/3. Unless I'm mistaken, as you have not specified that pytest should be used (by adding 'export PYBUILD_TEST_PYTEST=1' to debian/rules), it is still not used and no test is ran: I: pybuild pybuild:212: cp /tmp/pytz-2016.7/README.txt /tmp/pytz-2016.7/.pybuild/pythonX.Y_2.7/build; cp -r /tmp/pytz-2016.7/pytz/tests /tmp/pytz-2016.7/.pybuild/pythonX.Y_2.7/build/pytz/ I: pybuild base:184: cd /tmp/pytz-2016.7/.pybuild/pythonX.Y_2.7/build; python2.7 -m unittest discover -v -- Ran 0 tests in 0.000s OK After adding 'export PYBUILD_TEST_PYTEST=1' to debian/rules: I: pybuild base:184: cd /tmp/pytz-2016.7/.pybuild/pythonX.Y_2.7/build; python2.7 -m pytest == test session starts === platform linux2 -- Python 2.7.12+, pytest-3.0.4, py-1.4.31, pluggy-0.4.0 rootdir: /tmp/pytz-2016.7, inifile: collected 234 items pytz/tests/test_docs.py .. pytz/tests/test_lazy.py ... pytz/tests/test_tzinfo.py . === 234 passed in 0.54 seconds ======= -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#845495: src:python-tz: Non-maintainer upload of python-tz/2016.7-0.1 to DELAYED/5
Hello, Thanks for taking care of this. > diff --git a/debian/python-tz.install b/debian/python-tz.install > new file mode 100644 > index 000..dbdb301 > --- /dev/null > +++ b/debian/python-tz.install > @@ -0,0 +1 @@ > +/usr/lib/python2* > diff --git a/debian/python3-tz.install b/debian/python3-tz.install > new file mode 100644 > index 000..fef6392 > --- /dev/null > +++ b/debian/python3-tz.install > @@ -0,0 +1 @@ > +/usr/lib/python3* > diff --git a/debian/rules b/debian/rules > index 399f7d5..f1d5e38 100755 > --- a/debian/rules > +++ b/debian/rules > override_dh_install: > - dh_install > + dh_install --fail-missing Files will be automatically copied by pybuild if you add 'export PYBUILD_NAME=tz' to debian/rules, so you don't need the dh_auto_install override, nor the *.install files. See the following link: https://wiki.debian.org/Python/LibraryStyleGuide#debian.2Frules > --- a/debian/rules > +++ b/debian/rules > [...] > -override_dh_auto_test: > - python -m unittest discover -v pytz/tests > - for python in $(PY3VERS); do \ > - $$python -m unittest discover -v pytz/tests; \ > - done > - I tested this and it seems that no tests are being ran: dh_auto_test -O--buildsystem=pybuild -O--test-pytest I: pybuild base:184: cd /tmp/pytz-2016.7/.pybuild/pythonX.Y_2.7/build; python2.7 -m unittest discover -v -- Ran 0 tests in 0.000s OK I: pybuild base:184: cd /tmp/pytz-2016.7/.pybuild/pythonX.Y_3.5/build; python3.5 -m unittest discover -v -- Ran 0 tests in 0.000s OK Here are the 2 ways I know to run Unit Tests at build time (source package of 2015.7 uses debian/test-pytz): * Use python-pytest: + Add to debian/rules: export PYBUILD_TEST_PYTEST=1 export PYBUILD_TEST_ARGS=--doctest-modules + Add Build-Depends against python-pytest and python3-pytest. + Remove override_dh_auto_install and debian/test-pytz as they are not needed anymore. * Or, copy debian/test-pytz before running tests (PYBUILD_BEFORE_TEST) and override dh_auto_test. Not sure if there is a better way though... Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#834369: ITP: python-libusb1 -- Python wrapper for libusb1
Hello, > Any news on the ITP ? > If I can help getting this packaged in any way, please tell me. Sorry for the lag. I have prepared a package: https://people.debian.org/~arnau/packages/python-libusb1_1.5.3-1_all.deb And the git repository of the package: https://anonscm.debian.org/cgit/python-modules/packages/python-libusb1.git/ Please try it out. Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#783377: Packaging new version of ZODB (Zope Object Database)
Hi,
> I write to debian-python, because some of the involved packages are
> not specific to Zope. Actually, I even think that ZODB itself is not
> specific to Zope, but well, changing section of existing packages can
> be another topic.
This has already been discussed but all the packages in pkg-zope SVN
repository will have to be moved to python-{modules, apps} repositories
(because there is almost no activity on pkg-zope and most modules are
used independently of Zope anyway) and we should use debian-python ML
for the same reason, so yes, please use debian-python ML and commit
everything to python-{modules, apps} repositories.
Also, let me know when you want to upload as I can sponsor without
problem.
Cheers,
--
Arnaud Fontaine
signature.asc
Description: PGP signature
Bug#773727: [debian-mysql] Bug#773727: Bug#773727: mariadb-server-10.0: Mroonga & TokuDB plugins missing
Hi, > 2015-02-27 8:31 GMT+02:00 Arnaud Fontaine <ar...@debian.org>: >> Great. I don't think it's an urgent task but I will start splitting up >> the package when I have some time if that's ok with you? > > Do you think you might have some time now..? :) I'm really sorry, I don't have much time for Debian ATM as I'm too busy with work at the moment but will do when I can find some time... Cheers, -- Arnaud Fontaine
Bug#787797: O: netenv
Package: wnpp Severity: normal Hello, I have not been using netenv for a while and don't have time to maintain it anymore, therefore I'm orphaning it. It currently does not work well with systemd but besides of that, there isn't any big issue. Regards, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#780388: RM: trafficserver/5.0.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Hello, Considering that trafficserver is currently affected by 3 security bugs (CVE-2014-3624, CVE-2014-10022 (#778895) and #749846) fixed in Sid but which was not uploaded on time to testing before the freeze, and that these bugs cannot be easily fixed, it would probably be better to remove it from testing as suggested by Arno Töll, the maintainer of trafficserver, on #778895: However, the Release Team was uncomfortable to unblock that package (cf. #769689). I'm afraid, that we better ask for removal of that package in Testing rather than bothering with it, as we - as maintainers - cannot guarantee for the security of it already, even less so over the lifespan of a Debian Release, and upstream is moving faster than us. Thanks in advance. Regards, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#780187: ITP: python-coloredlogs -- Colored stream handler for the Python logging module
Package: wnpp Severity: wishlist Owner: Arnaud Fontaine ar...@debian.org * Package name: python-coloredlogs Version : 0.8 Upstream Author : Peter Odding * URL : https://github.com/xolox/python-coloredlogs * License : MIT/X Programming Lang: Python Description : Colored stream handler for the Python logging module The coloredlogs.ColoredStreamHandler class is a simple logging handler that inherits from logging.StreamHandler_ and uses ANSI escape sequences_ to render your logging messages in color. It uses only standard colors so it should work on any UNIX terminal. It's currently tested on Python 2.6, 2.7 and 3.4. This module will be maintained within Python Modules team. Regards, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#780188: ITP: slapos.libnetworkcache -- Client for ShaCache and ShaDir
Package: wnpp Severity: wishlist Owner: Arnaud Fontaine ar...@debian.org * Package name: slapos.libnetworkcache Version : 0.14.2 Upstream Author : ViFiB SARL and Contributors * URL : https://pypi.python.org/pypi/slapos.libnetworkcache * License : GPL-3 Programming Lang: Python Description : Client for ShaCache and ShaDir The goal of libnetworkcache python library is to abstract the HTTP calls. It works as wrapper of python httplib to use the Networkcache HTTP Server. The Networkcache HTTP Server is sub-divided into two Web services: - SHACACHE A simple HTTP Server used to cache files. - SHADIR A simple HTTP Server used to cache information, working like a directory. This package will be maintained within Python Apps team. Regards, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#773727: [debian-mysql] Bug#773727: Bug#773727: mariadb-server-10.0: Mroonga TokuDB plugins missing
Otto Kekäläinen o...@seravo.fi writes: 2015-02-26 10:36 GMT+02:00 Arnaud Fontaine ar...@debian.org: I'd vote for this. Let's put at least all the big plugins in their own packages. The main mariadb-server-10.0 could include only the plugins that are loaded by default or that are just really small. Actually, none of these plugins are enabled by default AFAIK. On my laptop, here is what I have: Interesting. As said, I am not a plugin expert and I don't even know what all of these plugins do, let alone why they are bundled and not active. To be fair, I didn't know neither until recently and it's only because of mroonga ;-). Motivated to have in their own packages: mroonga, tokudb, cassandra, spider. Connect and oqgraph are already. Do we want to keep Sphinx built-in maybe? I don't really see why Sphinx would be kept builtin and not mroonga? What about defining a size limit instead? Such as 50K or so? 50K limit sounds OK to me. Great. I don't think it's an urgent task but I will start splitting up the package when I have some time if that's ok with you? Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#773727: [debian-mysql] Bug#773727: Bug#773727: mariadb-server-10.0: Mroonga TokuDB plugins missing
Hi,
Otto Kekäläinen o...@seravo.fi writes:
I'd vote for this. Let's put at least all the big plugins in their own
packages. The main mariadb-server-10.0 could include only the plugins
that are loaded by default or that are just really small.
Actually, none of these plugins are enabled by default AFAIK. On my
laptop, here is what I have:
MariaDB [(none)] SELECT COUNT(*) FROM information_schema.ALL_PLUGINS WHERE
PLUGIN_LIBRARY IS NOT NULL;
+--+
| COUNT(*) |
+--+
| 54 |
+--+
= Number of plugins.
MariaDB [(none)] SELECT COUNT(*) FROM information_schema.ALL_PLUGINS WHERE
PLUGIN_LIBRARY IS NOT NULL AND PLUGIN_STATUS='ACTIVE';
+--+
| COUNT(*) |
+--+
|1 |
+--+
= Number of plugins enabled, here I have only 1, namely mroonga, that I
have enabled manually.
File size listing:
/usr/lib/mysql/plugin$ ll -h | awk '{ print $5 \t $9}' | sort -hr
2,8M ha_mroonga.so
2,4M ha_innodb.so
1,9M ha_tokudb.so
1,3M ha_cassandra.so
858K ha_spider.so
238K handlersocket.so
116K ha_sphinx.so
49K server_audit.so
40K semisync_master.so
39K ha_sequence.so
15K semisync_slave.so
11K sql_errlog.so
11K query_response_time.so
11K query_cache_info.so
11K metadata_lock_info.so
11K auth_pam.so
10K dialog.so
6,4K locales.so
6,1K auth_socket.so
5,9K mysql_clear_password.so
Motivated to have in their own packages: mroonga, tokudb, cassandra,
spider. Connect and oqgraph are already. Do we want to keep Sphinx
built-in maybe?
I don't really see why Sphinx would be kept builtin and not mroonga?
What about defining a size limit instead? Such as 50K or so?
I am actually no expert in all of these plugins and I don't even know
what e.g. sql_errorlog or semisync_master actually do.
TokuDB is a special case because it only works on arch amd64, and that
is good to reflect in packaging.
Indeed.
Cheers,
--
Arnaud Fontaine
signature.asc
Description: PGP signature
Bug#773727: [debian-mysql] Bug#773727: Bug#773727: mariadb-server-10.0: Mroonga TokuDB plugins missing
Hi Otto, Otto Kekäläinen o...@seravo.fi writes: After thinking about it for a while, I am starting to think that the best policy would be to _not_ load bundled plugins by default if they are not compulsory for the server to run. It is better to keep the server lean and sleek, and let the user activate extra plugins if they need them. Indeed. We could however facilitate the activation of plugins by shipping them in separate packages (e.g. like mariadb-connect-engine-10.0 is now) so all the user needs to do is run 'apt-get install mariadb-mroonga-search-10.0' or similar. These packages could then contain the plugin files itself, any configuration that need to be dropped in /etc/mysql/conf.d/ and potentially also install/remove scripts. What do you think, does this sound like a good policy? Considering that it is currently inconsistent (eg CONNECT and OQGRAPH engines are in separate packages but Mroonga and Spider are not), then it would be good to address this inconsistency. Excluding the ones that are already packaged separately (namely OQGRAPH and CONNECT engines): SELECT PLUGIN_NAME, PLUGIN_LIBRARY FROM information_schema.ALL_PLUGINS WHERE PLUGIN_LIBRARY IS NOT NULL GROUP BY PLUGIN_LIBRARY; +--++ | PLUGIN_NAME | PLUGIN_LIBRARY | +--++ | pam | auth_pam.so| | unix_socket | auth_socket.so | | handlersocket| handlersocket.so | | InnoDB | ha_innodb.so | | SEQUENCE | ha_sequence.so | | SPHINX | ha_sphinx.so | | SPIDER | ha_spider.so | | LOCALES | locales.so | | METADATA_LOCK_INFO | metadata_lock_info.so | | QUERY_CACHE_INFO | query_cache_info.so| | QUERY_RESPONSE_TIME | query_response_time.so | | rpl_semi_sync_master | semisync_master.so | | rpl_semi_sync_slave | semisync_slave.so | | SERVER_AUDIT | server_audit.so| | SQL_ERROR_LOG| sql_errlog.so | +--++ 15 rows in set (0.01 sec) So, here are several solutions I could think of: 1. Create one package per plugin as you suggested, but this would create many (some of them really small) packages though. Or perhaps one package containing several plugins, because some of them, such as query_cache_info, are really small? 2. Keep it as it is, eg let users manage plugins by themselves and thus not load any plugin by default. This is not really convenient as some plugins requires more than a plugin-load configuration option (mroonga does requires CREATE FUNCTION for example). 3. Keep all the plugins in mariadb-server-10.0 but let users choose which plugins to install (and then run necessary scripts) through a debconf menu. What do you think? Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#736314: awesome: Windows not managed after changing resolution through RandR in 3.5.x with multiple outputs
Jonathan McCrohan jmccro...@gmail.com writes: This appears to have been fixed as part of Awesome 3.5.6. Would you be able to upload this to experimental or unstable when you get a chance please? Sure, I will upload it to experimental very soon and to unstable once Jessie has been released. Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#736314: awesome: Windows not managed after changing resolution through RandR in 3.5.x with multiple outputs
This appears to have been fixed as part of Awesome 3.5.6. Would you be able to upload this to experimental or unstable when you get a chance please? Sure, I will upload it to experimental very soon and to unstable once Jessie has been released. FTR, after checking, 3.5.6 does not actually fix this issue but it has been fixed in master branch so I will package this branch instead. Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#773852: unblock: zodb/1:3.9.7-5 (pre-approval)
Hi, Adam D. Barratt a...@adam-barratt.org.uk writes: Control: tags -1 + confirmed moreinfo On 2014-12-24 3:25, Arnaud Fontaine wrote: Some time ago I uploaded python-zodb to fix RC bug #767554 but I forgot to remove some headers files, sorry about that. Would it be possible to upload python-zodb with the (really straightforward) diff attached? Please go ahead, and remove the moreinfo tag once the package has been accepted. Thank you very much. I have just uploaded it and removed the moreinfo tag. Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773727: [debian-mysql] Bug#773727: mariadb-server-10.0: Mroonga TokuDB plugins missing
Hello,
AFAIK, mroonga also requires some CREATE FUNCTION (and of course to be
loaded either in MariaDB configuration or through INSTALL PLUGIN). I'm
not sure how other plugins do, but what is the general stance about such
things? Shall we do it automatically or leave it to the user?
I'm asking because I recently had to automatically install mroonga for a
customer. I have attached to this email a (very rough) patch to
automatically load the plugin and issue CREATE FUNCTION (if necessary of
course) on startup.
Cheers,
--
Arnaud Fontaine
--- a/debian/additions/debian-start
+++ b/debian/additions/debian-start
@@ -30,6 +30,7 @@ trap SIGHUP
upgrade_system_tables_if_necessary;
check_root_accounts;
check_for_crashed_tables;
+ upgrade_mroonga_if_necessary;
) 2
exit 0
--- a/debian/additions/debian-start.inc.sh
+++ b/debian/additions/debian-start.inc.sh
@@ -70,3 +70,30 @@ function check_root_accounts() {
logger -p daemon.warn -i -t$0 WARNING: mysql.user contains $ret root accounts without password!
fi
}
+
+function upgrade_mroonga_if_necessary() {
+ set -e
+ set -u
+
+ if [ -e /var/lib/mysql/upgraded-debian.flag ]; then
+logger -p daemon.info -i -t$0 Upgrading mroonga.
+
+# From storage/mroonga/data/install.sql.in
+echo -e \
+ DROP FUNCTION IF EXISTS last_insert_grn_id;\n \
+ CREATE FUNCTION last_insert_grn_id RETURNS INTEGER SONAME 'ha_mroonga.so';\n \
+ DROP FUNCTION IF EXISTS mroonga_snippet;\n \
+ CREATE FUNCTION mroonga_snippet RETURNS STRING SONAME 'ha_mroonga.so';\n \
+ DROP FUNCTION IF EXISTS mroonga_command;\n \
+ CREATE FUNCTION mroonga_command RETURNS STRING SONAME 'ha_mroonga.so';\n \
+ DROP FUNCTION IF EXISTS mroonga_escape;\n \
+ CREATE FUNCTION mroonga_escape RETURNS STRING SONAME 'ha_mroonga.so';\n | \
+ $MYSQL --skip-column-names
+
+if [ $? -ne 0 ]; then
+ logger -p daemon.warn -i -t$0 WARNING: Could not upgrade mroonga!
+else
+ rm -f /var/lib/mysql/upgraded-debian.flag
+fi
+ fi
+}
--- a/debian/additions/mariadb.cnf
+++ b/debian/additions/mariadb.cnf
@@ -15,3 +15,4 @@
#collation-server = utf8_general_ci
#character_set_server = utf8
#collation_server = utf8_general_ci
+plugin-load=Mroonga=ha_mroonga.so
--- a/debian/mariadb-server-10.0.postinst
+++ b/debian/mariadb-server-10.0.postinst
@@ -229,6 +229,8 @@ EOF
echo $replace_query| $MYSQL_BOOTSTRAP 21 | $ERR_LOGGER
echo $install_plugins | $MYSQL_BOOTSTRAP 21 | $ERR_LOGGER
set -e
+
+touch /var/lib/mysql/upgraded-debian.flag
;;
abort-upgrade|abort-remove|abort-configure)
Bug#773852: unblock: zodb/1:3.9.7-5 (pre-approval)
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hello,
Some time ago I uploaded python-zodb to fix RC bug #767554 but I forgot
to remove some headers files, sorry about that. Would it be possible to
upload python-zodb with the (really straightforward) diff attached?
Thank you very much in advance.
Regards,
--
Arnaud Fontaine
diff -Nru zodb-3.9.7/debian/changelog zodb-3.9.7/debian/changelog
--- zodb-3.9.7/debian/changelog 2014-12-16 17:16:27.0 +0900
+++ zodb-3.9.7/debian/changelog 2014-12-24 12:17:32.0 +0900
@@ -1,3 +1,11 @@
+zodb (1:3.9.7-5) unstable; urgency=medium
+
+ * Team upload.
+ * persistent module was removed in the previous upload, but some headers
+were not. Thanks to Kirill Smelkov. Closes: #773699.
+
+ -- Arnaud Fontaine ar...@debian.org Wed, 24 Dec 2014 12:16:03 +0900
+
zodb (1:3.9.7-4) unstable; urgency=medium
* Team upload.
diff -Nru zodb-3.9.7/debian/patches/persistent-module-4.x-no-headers.patch zodb-3.9.7/debian/patches/persistent-module-4.x-no-headers.patch
--- zodb-3.9.7/debian/patches/persistent-module-4.x-no-headers.patch 1970-01-01 09:00:00.0 +0900
+++ zodb-3.9.7/debian/patches/persistent-module-4.x-no-headers.patch 2014-12-24 12:15:57.0 +0900
@@ -0,0 +1,25 @@
+Description: Don't provide persistent headers in python-zodb
+ python-zodb now depends on separate python-persistent and to be compatible
+ with that in python-zodb, after building the package, we remove installed
+ persistent completely. However ZODB also used to install persistent headers in
+ ZODB namespace which were left and now correspond to nothing provided in
+ python-zodb and duplicate persistent headers in python-persistent.
+After splitting persistent into separate package, upstream already removed
+ that 'headers install' in zodb package:
+- 57dca750 (Fixed: An unneeded left-over setting in setup.py caused
+ installation with pip to fail).
+- f5b98e96 (ZODB w/ externally-distributed 'persistent'.)
+ so do it here too.
+
+--- zodb-3.9.7.orig/setup.py
zodb-3.9.7/setup.py
+@@ -188,9 +188,6 @@ setup(name=ZODB3,
+ packages = find_packages('src'),
+ package_dir = {'': 'src'},
+ ext_modules = exts,
+- headers = ['src/persistent/cPersistence.h',
+- 'src/persistent/py24compat.h',
+- 'src/persistent/ring.h'],
+ license = ZPL 2.1,
+ platforms = [any],
+ description = doclines[0],
diff -Nru zodb-3.9.7/debian/patches/series zodb-3.9.7/debian/patches/series
--- zodb-3.9.7/debian/patches/series 2014-12-16 16:51:28.0 +0900
+++ zodb-3.9.7/debian/patches/series 2014-12-24 12:15:57.0 +0900
@@ -1,5 +1,6 @@
lp_135108.patch
persistent-module-4.x-compat.patch
+persistent-module-4.x-no-headers.patch
test-spurious-failure-under-python27.patch
testUtils.patch
new-transaction.patch
Bug#767554: Bug#769853: /769854: unblock: python-persistent and python-zodb
Hi,
Julien Cristau jcris...@debian.org writes:
On Fri, Dec 12, 2014 at 12:44:08 +0900, Arnaud Fontaine wrote:
I have attached the debdiff with the packages currently in unstable,
would you consider unblocking these changes if I upload the packages to
unstable?
Yes, I would.
Thanks! I have just uploaded both packages to unstable. Compared to my
previous debdiff, I have just merged the work done by Gediminas for the
next version of ZODB (basically only patch filenames are different and
the changelog entry has been modified accordingly), but the content of
python-zodb binary package is exactly the same.
I have attached debdiffs for both packages in case of.
Adam D. Barratt a...@adam-barratt.org.uk writes:
Control: tags 769854 + confirmed moreinfo
Control: tags 769853 + confirmed moreinfo
If the upload can be made soon, that should be fine. Please remove the
moreinfo tags once the packages are in unstable.
Done.
Cheers,
--
Arnaud Fontaine
diff -Nru python-persistent-4.0.8/debian/changelog python-persistent-4.0.8/debian/changelog
--- python-persistent-4.0.8/debian/changelog 2014-11-14 18:30:25.0 +0900
+++ python-persistent-4.0.8/debian/changelog 2014-12-10 17:41:09.0 +0900
@@ -1,3 +1,13 @@
+python-persistent (4.0.8-3) unstable; urgency=medium
+
+ * Team upload.
+ * Revert change in previous upload in favor of removing persistent
+module from python-zodb and make it depend upon this package (with
+upstream ACK). Closes: #767554.
++ d/control: Add Breaks/Replaces against python-zodb 1:3.9.7-4~.
+
+ -- Arnaud Fontaine ar...@debian.org Wed, 10 Dec 2014 17:33:13 +0900
+
python-persistent (4.0.8-2) unstable; urgency=medium
* Team upload.
diff -Nru python-persistent-4.0.8/debian/control python-persistent-4.0.8/debian/control
--- python-persistent-4.0.8/debian/control 2014-11-14 18:31:01.0 +0900
+++ python-persistent-4.0.8/debian/control 2014-12-10 17:37:40.0 +0900
@@ -22,7 +22,8 @@
Package: python-persistent
Architecture: any
Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
-Conflicts: python-zodb ( 3.11.0~)
+Breaks: python-zodb ( 1:3.9.7-4~)
+Replaces: python-zodb ( 1:3.9.7-4~)
Description: Automatic persistence for Python objects
This package contains a generic persistence implementation for Python. It
forms the core protocol for making objects interact transparently with
diff -Nru zodb-3.9.7/debian/changelog zodb-3.9.7/debian/changelog
--- zodb-3.9.7/debian/changelog 2014-11-17 12:10:50.0 +0900
+++ zodb-3.9.7/debian/changelog 2014-12-16 17:16:27.0 +0900
@@ -1,3 +1,29 @@
+zodb (1:3.9.7-4) unstable; urgency=medium
+
+ * Team upload.
+ * Revert change in previous upload in favor of removing persistent
+module from this package and make it depend upon python-persistent
+(with upstream ACK). Closes: #767554.
++ d/control: Add Depends against python-persistent.
++ d/rules: Delete persistent module from final package.
++ d/p/persistent-module-4.x-compat.patch: persistent 4.x uses bytes
+ instead of repr() but ZODB 4.0.0a4 still uses repr() which is
+ incompatible.
++ d/tests/all: Remove persistent from the list of tests being ran.
++ d/tests/control: zope.testing.doctest has been removed in
+ python-zope.testing 4.0.0 and tests cannot be ran anymore. So update
+ Depends accordingly even though 4.0.0~ is only in stable instead of
+ backporting many patches. Fix this issue properly when packing NUR
+ after the release of Jessie.
+ * d/p/test-spurious-failure-under-python27.patch: Fix python2.7 tests.
+
+ [ Gediminas Paulauskas ]
+ * d/p/new-transaction.patch: Fix test failure with new transaction.
+ * d/p/testUtils.patch: Fix test failure with python2.7 (= 2.7.6).
+ * d/tests: Switch to zope.testrunner.
+
+ -- Arnaud Fontaine ar...@debian.org Tue, 16 Dec 2014 17:12:06 +0900
+
zodb (1:3.9.7-3) unstable; urgency=medium
* Team upload.
@@ -237,4 +263,3 @@
* Initial release (Closes: #158552, #159072, #188435)
-- Fabio Tranchitella kob...@debian.org Thu, 18 Aug 2005 21:49:17 +
-
diff -Nru zodb-3.9.7/debian/control zodb-3.9.7/debian/control
--- zodb-3.9.7/debian/control 2014-11-17 12:09:52.0 +0900
+++ zodb-3.9.7/debian/control 2014-12-16 16:40:16.0 +0900
@@ -19,13 +19,12 @@
Depends: ${pydeb:Depends},
${python:Depends},
${misc:Depends},
- ${shlibs:Depends}
+ ${shlibs:Depends},
+ python-persistent
Provides: ${pydeb:Provides},
${python:Provides},
- python-persistent
Suggests: ${pydeb:Suggests}
-Conflicts: zope3,
- python-persistent
+Conflicts: zope3
Description: Zope Object Database (ZODB)
The Zope Object Database is an object-oriented database for Python that
provides a high-degree of transparency. Applications can take advantage of
diff -Nru zodb-3.9.7/debian/patches/new-transaction.patch zodb-3.9.7/debian/patches/new
Bug#767554: Bug#769853/769854: unblock: python-persistent and python-zodb
Hi,
Julien Cristau jcris...@debian.org writes:
I don't think that's ok. Can't you remove the conflicting files from
python-zodb, and make it depend on python-persistent?
Thanks for the suggestion. I talked with upstream authors and this
should be fine. However, python-persistent in the archive (4.x) is
incompatible with ZODB 4.0.0a4 and thus with the version available in
the archive (3.9.7). Therefore, I had to backport some patches from
upstream so that python-zodb could depend on python-persistent.
With these patches, all the unit tests of python-zodb pass when being
ran with python-persistent and python-zodb installed (even though, they
only ran with python-zope.testing from stable, due to change in the unit
tests framework only from zope.testing 4.x).
Here are the changelog entries for both packages:
python-persistent (4.0.8-3) unstable; urgency=medium
* Team upload.
* Revert change in previous upload in favor of removing persistent
module from python-zodb and make it depend upon this package (with
upstream ACK). Closes: #767554.
+ d/control: Add Breaks/Replaces against python-zodb 1:3.9.7-4~.
-- Arnaud Fontaine ar...@debian.org Wed, 10 Dec 2014 17:33:13 +0900
zodb (1:3.9.7-4) unstable; urgency=medium
* Team upload.
* Revert change in previous upload in favor of removing persistent
module from this package and make it depend upon python-persistent
(with upstream ACK). Closes: #767554.
+ d/control: Add Depends against python-persistent.
+ d/rules: Delete persistent module from final package.
+ d/p/fix_persistent_module_4.x_incompatibilities.patch: persistent 4.x
uses bytes instead of repr() but ZODB 4.0.0a4 still uses repr() which
is incompatible.
+ d/tests/all: Remove persistent from the list of tests being ran.
+ d/tests/control: zope.testing.doctest has been removed in
python-zope.testing 4.0.0 and tests cannot be ran anymore. So update
Depends accordingly even though 4.0.0~ is only in stable instead of
backporting many patches. Fix this issue properly when packing NUR
after the release of Jessie.
* d/p/debian/patches/fix_unit_tests.patch: Fix python2.7 tests failures.
-- Arnaud Fontaine ar...@debian.org Fri, 12 Dec 2014 11:47:47 +0900
I have attached the debdiff with the packages currently in unstable,
would you consider unblocking these changes if I upload the packages to
unstable?
Regards,
--
Arnaud Fontaine
diff -Nru python-persistent-4.0.8/debian/changelog python-persistent-4.0.8/debian/changelog
--- python-persistent-4.0.8/debian/changelog 2014-11-14 18:30:25.0 +0900
+++ python-persistent-4.0.8/debian/changelog 2014-12-10 17:41:09.0 +0900
@@ -1,3 +1,13 @@
+python-persistent (4.0.8-3) unstable; urgency=medium
+
+ * Team upload.
+ * Revert change in previous upload in favor of removing persistent
+module from python-zodb and make it depend upon this package (with
+upstream ACK). Closes: #767554.
++ d/control: Add Breaks/Replaces against python-zodb 1:3.9.7-4~.
+
+ -- Arnaud Fontaine ar...@debian.org Wed, 10 Dec 2014 17:33:13 +0900
+
python-persistent (4.0.8-2) unstable; urgency=medium
* Team upload.
diff -Nru python-persistent-4.0.8/debian/control python-persistent-4.0.8/debian/control
--- python-persistent-4.0.8/debian/control 2014-11-14 18:31:01.0 +0900
+++ python-persistent-4.0.8/debian/control 2014-12-10 17:37:40.0 +0900
@@ -22,7 +22,8 @@
Package: python-persistent
Architecture: any
Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
-Conflicts: python-zodb ( 3.11.0~)
+Breaks: python-zodb ( 1:3.9.7-4~)
+Replaces: python-zodb ( 1:3.9.7-4~)
Description: Automatic persistence for Python objects
This package contains a generic persistence implementation for Python. It
forms the core protocol for making objects interact transparently with
diff -Nru zodb-3.9.7/debian/changelog zodb-3.9.7/debian/changelog
--- zodb-3.9.7/debian/changelog 2014-11-17 12:10:50.0 +0900
+++ zodb-3.9.7/debian/changelog 2014-12-12 12:00:34.0 +0900
@@ -1,3 +1,24 @@
+zodb (1:3.9.7-4) unstable; urgency=medium
+
+ * Team upload.
+ * Revert change in previous upload in favor of removing persistent
+module from this package and make it depend upon python-persistent
+(with upstream ACK). Closes: #767554.
++ d/control: Add Depends against python-persistent.
++ d/rules: Delete persistent module from final package.
++ d/p/fix_persistent_module_4.x_incompatibilities.patch: persistent 4.x
+ uses bytes instead of repr() but ZODB 4.0.0a4 still uses repr() which
+ is incompatible.
++ d/tests/all: Remove persistent from the list of tests being ran.
++ d/tests/control: zope.testing.doctest has been removed in
+ python-zope.testing 4.0.0 and tests cannot be ran anymore. So update
+ Depends accordingly even
Bug#767554: python-persistent and python-zodb: error when trying to install together
Hi, Arnaud Fontaine wrote (26 Nov 2014 09:03:09 GMT) : Really sorry about that. FTR, I have not uploaded anything yet because the release team would prefer to avoid the Conflicts if possible and make python-zodb depends upon python-persistent instead. AFAIK, it does not seem to be an issue but I have just sent an email to upstream author to confirm it's not going to be an issue... Any answer from them? Yes, sorry about the lag. The upstream said there should be no problem for python-zodb to Depends on python-persistent (and thus remove persistent module from python-zodb). Barry: if that's ok, I will upload python-persistent with the Breaks/Replaces and upload python-zodb without persistent module? Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#767554: python-persistent and python-zodb: error when trying to install together
Hello, Andreas Beckmann a...@debian.org writes: Followup-For: Bug #767554 Control: found -1 767554 4.0.8-2 The Conflicts does not work ... without the proper epoch ... you need Conflicts: python-zodb ( 1:3.11.0~) Selecting previously unselected package python-persistent. Unpacking python-persistent (from .../python-persistent_4.0.8-2_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/python-persistent_4.0.8-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/python2.7/dist-packages/persistent/dict.py', which is also in package python-zodb 1:3.9.7-2 Errors were encountered while processing: /var/cache/apt/archives/python-persistent_4.0.8-2_amd64.deb Really sorry about that. FTR, I have not uploaded anything yet because the release team would prefer to avoid the Conflicts if possible and make python-zodb depends upon python-persistent instead. AFAIK, it does not seem to be an issue but I have just sent an email to upstream author to confirm it's not going to be an issue... Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#769854: Bug#769853: unblock: python-persistent/4.0.8-2
Hi, Julien Cristau jcris...@debian.org writes: Please confirm you really meant to use Conflicts (and why). Otherwise please use Replaces+Breaks instead. After discussing on #767554 with other maintainers, there is really no other solution, at least for Jessie. Here is the relevant discussion about this on #767554: From upstream point of view, ZODB3 (aka python-zodb in Debian) used to include persistent, BTrees, ZODB and ZEO modules. However, since ZODB3 3.11.0a1, upstream has split it up into 4 distinct packages (one for each module), bump the version to 4.0 and made ZODB3 a metapackage depending on all of them. As of fixing this RC bug for Jessie: Among the four, only persistent package is currently available in Debian, so there is no way to get rid of ZODB3 (at least for Jessie). Barry: If persistent = 4.0 Debian package is useful on its own to anyone (and thus should not be removed From testing), then can I add a Conflict on both packages and upload them to fix this bug? And here is the reply from Barry Warsaw (maintainer of python-persistent): I think a Conflicts is the right way to handle this for now, given where we are in the Jessie release cycle. After releasing Jessie, we plan to update python-zodb and upload split up modules (namely python-zeo and python-btrees which are not in the archive yet). I don't think that's ok. Can't you remove the conflicting files from python-zodb, and make it depend on python-persistent? I didn't think about that and that would be the best indeed, especially considering that nothing Build-Depends on python-zodb. Gediminas: what do you think? Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#769497: unblock: slapos.core/1.2.4.1-2
retitle 769497 unblock: slapos.core/1.2.4.1-2
thanks
Hi,
Niels Thykier ni...@thykier.net writes:
Ack, please upload those changes to unstable (with a reasonable
changelog entry) and let us know once it has been accepted.
I have just uploaded it to unstable and I have attached the debdiff to
this email. Thank you very much in advance.
unblock slapos.core/1.2.4.1-2
Cheers,
--
Arnaud Fontaine
diff -Nru slapos.core-1.2.4.1/debian/changelog slapos.core-1.2.4.1/debian/changelog
--- slapos.core-1.2.4.1/debian/changelog 2014-10-16 11:34:13.0 +0900
+++ slapos.core-1.2.4.1/debian/changelog 2014-11-20 15:49:53.0 +0900
@@ -1,3 +1,12 @@
+slapos.core (1.2.4.1-2) unstable; urgency=medium
+
+ * d/control: Depends on python-psutil = 2.0.0 due to API change leading
+to AttributeError when running 'slapos node collect' subcommand.
+ * d/slapos-node-unofficial.cron.d: Fix wrong crontab making the package
+unuseable with master node.
+
+ -- Arnaud Fontaine ar...@debian.org Thu, 20 Nov 2014 15:49:53 +0900
+
slapos.core (1.2.4.1-1) unstable; urgency=medium
* New upstream release.
diff -Nru slapos.core-1.2.4.1/debian/control slapos.core-1.2.4.1/debian/control
--- slapos.core-1.2.4.1/debian/control 2014-10-16 11:07:17.0 +0900
+++ slapos.core-1.2.4.1/debian/control 2014-11-20 15:46:30.0 +0900
@@ -52,7 +52,8 @@
# slapos.format
bridge-utils,
uml-utilities,
- python-netaddr (= 0.7.5~)
+ python-netaddr (= 0.7.5~),
+ python-psutil (= 2.0.0),
Breaks: ${python:Breaks},
slapos-client ( 1.0.2.1-1~)
# slapos.grid
diff -Nru slapos.core-1.2.4.1/debian/slapos-node-unofficial.cron.d slapos.core-1.2.4.1/debian/slapos-node-unofficial.cron.d
--- slapos.core-1.2.4.1/debian/slapos-node-unofficial.cron.d 2014-04-26 18:30:35.0 +0900
+++ slapos.core-1.2.4.1/debian/slapos-node-unofficial.cron.d 2014-11-20 15:48:36.0 +0900
@@ -2,7 +2,18 @@
PATH=/usr/bin:/usr/sbin:/sbin:/bin
MAILTO=root
-*/5 * * * * root /usr/bin/slapos node software --log-file=/var/log/slapos/slapos-node-software.log
-*/5 * * * * root /usr/bin/slapos node instance --log-file=/var/log/slapos/slapos-node-instance.log
-0 0 * * * root /usr/bin/slapos node report --log-file=/var/log/slapos/slapos-node-report.log
-0 0 * * * root /usr/bin/slapos node format
+# Run Installation/Destruction of Software Releases and Deploy/Start/Stop Partitions once per minute
+* * * * * root/usr/bin/slapos node software --verbose --logfile=/var/log/slapos/slapos-node-software.log --pidfile=/var/run/slapos-node-software.pid /dev/null 21
+* * * * * root/usr/bin/slapos node instance --promise-timeout 20 --verbose --log-file=/var/log/slapos/slapos-node-instance.log --pidfile=/var/run/slapos-node-instance.pid /dev/null 21
+
+# Run Destroy Partitions to be destroyed once per hour
+0 * * * * root/usr/bin/slapos node report --maximal_delay=3600 --verbose --logfile=/var/log/slapos/slapos-node-report.log /dev/null 21
+
+# Run Check/add IPs and so on once per hour
+0 * * * * root/usr/bin/slapos node format /var/log/slapos/slapos-node-format.log 21
+
+# Run Booting on every system start
+@reboot root/usr/bin/slapos node boot /var/log/slapos/slapos-node-boot.log 21
+
+# Run Collect once a minute
+* * * * * root/usr/bin/slapos node collect /var/log/slapos/slapos-node-collect.log 21
signature.asc
Description: PGP signature
Bug#770421: Should Build-Depends on dpkg = 1.17.14
Source: apache2 Version: 2.4.10-8 Severity: normal Tags: patch Hello, From apache2 2.4.10-7, dpkg-maintscript-helper is used and Pre-Depends have been added. Howevever, Build-Depends have not been updated accordingly and the following error happens when trying to build apache2 on wheezy: dh_installdeb -O--parallel dh_installdeb: unknown dpkg-maintscript-helper command: symlink_to_dir make: *** [binary] Error 255 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 debuild: fatal error at line 1357: dpkg-buildpackage -rfakeroot -D -us -uc -tc failed Thus, could you please add 'dpkg = 1.17.14' to Build-Depends? Thank you very much in advance. Regards, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#769865: [debian-mysql] Bug#769865: mariadb-10.0: FTBFS on i386
Otto Kekäläinen o...@seravo.fi writes: The latest upload if mariadb-10.0 failed during the testsuite on i386: https://buildd.debian.org/status/package.php?p=mariadb-10.0 https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.0arch=i386ver=10.0.14-3stamp=1416208329 A number of architectures are still building at this point, so the issue might not be specific to i386 (but mips, mipsel and ppc64el built fine). Thanks for reporting this. I've localized the root cause and pushed a fix: http://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/commit/debian/patches/username-in-tests-replace.patch?id=c413d37ab10b7c817d00f3a41bfac569736c6e4a Now we need to upload mariadb-10.0.14-4, all builds are likely to fail with current revision. Do you need me to upload it? Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#767554: python-persistent and python-zodb: error when trying to install together
Hi, Gediminas Paulauskas mene...@pov.lt writes: If that's ok with you, I'm going to upload both packages to fix this bug: * python-persistent: Conflicts: python-zodb ( 3.11.0~) * python-zodb: Conflicts: python-persistent Since ZODB3 before the split included persistent, it should provide it: Provides: python-persistent One package that Build-Depends on python-persistent but should be installable with only python-zodb is zope.component. Thank you very much for pointing this out. I will upload now with the Provides then. Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#769853: unblock: python-persistent/4.0.8-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package python-persistent
This fixes an error when trying to install it together with python-zodb,
here is the changelog entry with further explanations:
diff -Nru python-persistent-4.0.8/debian/changelog
python-persistent-4.0.8/debian/changelog
--- python-persistent-4.0.8/debian/changelog 2014-06-26 04:29:59.0
+0900
+++ python-persistent-4.0.8/debian/changelog 2014-11-14 18:30:25.0
+0900
@@ -1,3 +1,13 @@
+python-persistent (4.0.8-2) unstable; urgency=medium
+
+ * Team upload.
+ * d/control: ZODB3 = 3.11a1 (python-zodb in Debian) has been split up
+into distinct packages (persistent, BTrees, ZODB and ZEO), so until
+python-zodb is updated to at least that version (eg after Jessie), add
+a Conflicts. Thanks to Andreas Beckmann. Closes: #767554.
+
+ -- Arnaud Fontaine ar...@debian.org Fri, 14 Nov 2014 18:22:35 +0900
+
python-persistent (4.0.8-1) unstable; urgency=medium
* Initial release. (Closes: #752679)
diff -Nru python-persistent-4.0.8/debian/control
python-persistent-4.0.8/debian/control
--- python-persistent-4.0.8/debian/control2014-06-26 00:34:29.0
+0900
+++ python-persistent-4.0.8/debian/control2014-11-14 18:31:01.0
+0900
@@ -22,6 +22,7 @@
Package: python-persistent
Architecture: any
Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
+Conflicts: python-zodb ( 3.11.0~)
Description: Automatic persistence for Python objects
This package contains a generic persistence implementation for Python. It
forms the core protocol for making objects interact transparently with
Thanks in advance!
unblock python-persistent/4.0.8-2
Regards,
--
Arnaud Fontaine
signature.asc
Description: PGP signature
Bug#769854: unblock: zodb/1:3.9.7-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package zodb
This fixes an error when trying to install it together with
python-persistent and also add a Provides, here is the changelog entry
with further explanations:
diff -Nru zodb-3.9.7/debian/changelog zodb-3.9.7/debian/changelog
--- zodb-3.9.7/debian/changelog 2011-11-08 22:53:42.0 +0900
+++ zodb-3.9.7/debian/changelog 2014-11-17 12:10:50.0 +0900
@@ -1,3 +1,14 @@
+zodb (1:3.9.7-3) unstable; urgency=medium
+
+ * Team upload.
+ * d/control: ZODB3 = 3.11a1 (python-zodb in Debian) has been split up
+into distinct packages (persistent, BTrees, ZODB and ZEO), so until
+python-zodb is updated to at least that version (eg after Jessie), add
+a Conflicts and Provides of python-persistent. Thanks to Andreas
+Beckmann. Closes: #767554.
+
+ -- Arnaud Fontaine ar...@debian.org Fri, 14 Nov 2014 18:34:36 +0900
+
zodb (1:3.9.7-2) unstable; urgency=low
* Team upload.
diff -Nru zodb-3.9.7/debian/control zodb-3.9.7/debian/control
--- zodb-3.9.7/debian/control 2011-10-21 14:24:36.0 +0900
+++ zodb-3.9.7/debian/control 2014-11-17 12:09:52.0 +0900
@@ -20,9 +20,12 @@
${python:Depends},
${misc:Depends},
${shlibs:Depends}
-Provides: ${pydeb:Provides}, ${python:Provides}
+Provides: ${pydeb:Provides},
+ ${python:Provides},
+ python-persistent
Suggests: ${pydeb:Suggests}
-Conflicts: zope3
+Conflicts: zope3,
+ python-persistent
Description: Zope Object Database (ZODB)
The Zope Object Database is an object-oriented database for Python that
provides a high-degree of transparency. Applications can take advantage of
Thanks in advance!
unblock zodb/1:3.9.7-3
Regards,
--
Arnaud Fontaine
signature.asc
Description: PGP signature
Bug#769856: unblock: mariadb-10.0/10.0.14-3
++--replace_result $replace drop user USER + eval drop user $USER; + + --echo # + +=== modified file 'mysql-test/t/failed_auth_unixsocket.test' +--- a/mysql-test/t/failed_auth_unixsocket.test 2014-03-24 19:02:00 + b/mysql-test/t/failed_auth_unixsocket.test 2014-11-12 10:10:13 + +@@ -16,11 +16,17 @@ change_user $USER; + + eval install plugin unix_socket soname '$AUTH_SOCKET_SO'; + +---replace_result $MASTER_MYSOCK MASTER_SOCKET $MASTER_MYPORT MASTER_PORT $USER USER ++# Make sure that the replace works, even if $USER is 'user' or something else ++# that matches other parts of the error message. ++--echo connect(localhost,USER,,test,MASTER_PORT,MASTER_SOCKET); ++--let $replace=Access denied for user '$USER' ++--replace_result $MASTER_MYSOCK MASTER_SOCKET $MASTER_MYPORT MASTER_PORT $replace Access denied for user 'USER' ++--disable_query_log + --error ER_ACCESS_DENIED_NO_PASSWORD_ERROR + connect (fail,localhost,$USER); ++--enable_query_log + +---replace_result $USER USER ++--replace_result $replace Access denied for user 'USER' + --error ER_ACCESS_DENIED_NO_PASSWORD_ERROR + change_user $USER; Thanks in advance! unblock mariadb-10.0/10.0.14-3 Regards, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#769853: unblock: python-persistent/4.0.8-2
Niels Thykier ni...@thykier.net writes: If files have been moved around, you need Replaces: python-zodb ( 3.11.0~) Breaks: python-zodb ( 3.11.0~) And not conflicts. There is rarely a need for (lone) Conflict these days (notable exception being Policy §7.5.2[1]). Please confirm you really meant to use Conflicts (and why). Otherwise please use Replaces+Breaks instead. After discussing on #767554 with other maintainers, there is really no other solution, at least for Jessie. Here is the relevant discussion about this on #767554: From upstream point of view, ZODB3 (aka python-zodb in Debian) used to include persistent, BTrees, ZODB and ZEO modules. However, since ZODB3 3.11.0a1, upstream has split it up into 4 distinct packages (one for each module), bump the version to 4.0 and made ZODB3 a metapackage depending on all of them. As of fixing this RC bug for Jessie: Among the four, only persistent package is currently available in Debian, so there is no way to get rid of ZODB3 (at least for Jessie). Barry: If persistent = 4.0 Debian package is useful on its own to anyone (and thus should not be removed From testing), then can I add a Conflict on both packages and upload them to fix this bug? And here is the reply from Barry Warsaw (maintainer of python-persistent): I think a Conflicts is the right way to handle this for now, given where we are in the Jessie release cycle. After releasing Jessie, we plan to update python-zodb and upload split up modules (namely python-zeo and python-btrees which are not in the archive yet). Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#767554: python-persistent and python-zodb: error when trying to install together
Barry Warsaw ba...@debian.org writes: On Nov 12, 2014, at 05:50 PM, Arnaud Fontaine wrote: From upstream point of view, ZODB3 (aka python-zodb in Debian) used to include persistent, BTrees, ZODB and ZEO modules. However, since ZODB3 3.11.0a1, upstream has split it up into 4 distinct packages (one for each module), bump the version to 4.0 and made ZODB3 a metapackage depending on all of them. It looks like Debian still has zodb 3.9.7, right? Unfortunately, yes. As of fixing this RC bug for Jessie: Among the four, only persistent package is currently available in Debian, so there is no way to get rid of ZODB3 (at least for Jessie). Barry: If persistent = 4.0 Debian package is useful on its own to anyone (and thus should not be removed From testing), then can I add a Conflict on both packages and upload them to fix this bug? IIRC, I needed to update python-persistent for the Python 3 zope.component transition, as it's a build-dep. There are no other reverse dependencies that I know of. I think a Conflicts is the right way to handle this for now, given where we are in the Jessie release cycle. Arnaud, thanks for handling this! If that's ok with you, I'm going to upload both packages to fix this bug: * python-persistent: Conflicts: python-zodb ( 3.11.0~) * python-zodb: Conflicts: python-persistent Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#769497: unblock: slapos.core/1.2.4.1-2 (pre-approval)
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
unblock slapos.core/1.2.4.1-2
slapos-node-unofficial currently in unstable should Depends on at least
version = 2.0.0 of python-psutil (because of API change in
python-psutil) but it does not currently and this makes subcommands
fails (with AttributeError because of psutil API change) when using it
on stable (where only psutil 0.5.1 is available).
Also, I noticed that the crontab is wrong and makes the package
unuseable with a master node (which is one of the main usage at the end)
because one script is only ran once a day and this is not enough.
I have attached a diff and would like to know if I could get an unblock
for this? Thanks in advance!
Cheers,
--
Arnaud Fontaine
Index: debian/control
===
--- debian/control (revision 11537)
+++ debian/control (working copy)
@@ -52,7 +52,8 @@
# slapos.format
bridge-utils,
uml-utilities,
- python-netaddr (= 0.7.5~)
+ python-netaddr (= 0.7.5~),
+ python-psutil (= 2.0.0),
Breaks: ${python:Breaks},
slapos-client ( 1.0.2.1-1~)
# slapos.grid
Index: debian/slapos-node-unofficial.cron.d
===
--- debian/slapos-node-unofficial.cron.d (revision 11537)
+++ debian/slapos-node-unofficial.cron.d (working copy)
@@ -2,7 +2,18 @@
PATH=/usr/bin:/usr/sbin:/sbin:/bin
MAILTO=root
-*/5 * * * * root /usr/bin/slapos node software --log-file=/var/log/slapos/slapos-node-software.log
-*/5 * * * * root /usr/bin/slapos node instance --log-file=/var/log/slapos/slapos-node-instance.log
-0 0 * * * root /usr/bin/slapos node report --log-file=/var/log/slapos/slapos-node-report.log
-0 0 * * * root /usr/bin/slapos node format
+# Run Installation/Destruction of Software Releases and Deploy/Start/Stop Partitions once per minute
+* * * * * root/usr/bin/slapos node software --verbose --logfile=/var/log/slapos/slapos-node-software.log --pidfile=/var/run/slapos-node-software.pid /dev/null 21
+* * * * * root/usr/bin/slapos node instance --promise-timeout 20 --verbose --log-file=/var/log/slapos/slapos-node-instance.log --pidfile=/var/run/slapos-node-instance.pid /dev/null 21
+
+# Run Destroy Partitions to be destroyed once per hour
+0 * * * * root/usr/bin/slapos node report --maximal_delay=3600 --verbose --logfile=/var/log/slapos/slapos-node-report.log /dev/null 21
+
+# Run Check/add IPs and so on once per hour
+0 * * * * root/usr/bin/slapos node format /var/log/slapos/slapos-node-format.log 21
+
+# Run Booting on every system start
+@reboot root/usr/bin/slapos node boot /var/log/slapos/slapos-node-boot.log 21
+
+# Run Collect once a minute
+* * * * * root/usr/bin/slapos node collect /var/log/slapos/slapos-node-collect.log 21
signature.asc
Description: PGP signature
Bug#767554: python-persistent and python-zodb: error when trying to install together
Hello, Andreas Beckmann a...@debian.org writes: Package: python-persistent,python-zodb Version: 4.0.8-1 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Control: found -1 1:3.9.7-2 First of all, thanks for finding and reporting such issues, it's greatly appreciated! Selecting previously unselected package python-zodb. Preparing to unpack .../python-zodb_1%3a3.9.7-2_amd64.deb ... Unpacking python-zodb (1:3.9.7-2) ... dpkg: error processing archive /var/cache/apt/archives/python-zodb_1%3a3.9.7-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/python2.7/dist-packages/persistent/wref.py', which is also in package python-persistent 4.0.8-1 Errors were encountered while processing: /var/cache/apt/archives/python-zodb_1%3a3.9.7-2_amd64.deb This is a serious bug as it makes installation fail, and violates sections 7.6.1 and 10.1 of the policy. An optimal solution would consist in only one of the packages installing that file, and renaming or removing the file in the other package. Depending on the circumstances you might also consider Replace relations or file diversions. If the conflicting situation cannot be resolved then, as a last resort, the two packages have to declare a mutual Conflict. Please take into account that Replaces, Conflicts and diversions should only be used when packages provide different implementations for the same functionality. Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): usr/lib/python2.7/dist-packages/persistent/__init__.py [...] From upstream point of view, ZODB3 (aka python-zodb in Debian) used to include persistent, BTrees, ZODB and ZEO modules. However, since ZODB3 3.11.0a1, upstream has split it up into 4 distinct packages (one for each module), bump the version to 4.0 and made ZODB3 a metapackage depending on all of them. As of fixing this RC bug for Jessie: Among the four, only persistent package is currently available in Debian, so there is no way to get rid of ZODB3 (at least for Jessie). Barry: If persistent = 4.0 Debian package is useful on its own to anyone (and thus should not be removed From testing), then can I add a Conflict on both packages and upload them to fix this bug? Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
Bug#769227: unblock: python-chameleon/2.16-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package python-chameleon
python-chameleon binary package has been split up into python-chameleon
and python-chameleon-doc but the latter does not define Breaks/Replaces
against the previous version. Thus, installation of python-chameleon-doc
fails on current stable (bug #768205).
The version I have just uploaded only fix this issue and nothing else. I
have attached to this email the debdiff with the version currently in
testing. Thank you very much!
unblock python-chameleon/2.16-4
diff -Nru python-chameleon-2.16/debian/changelog python-chameleon-2.16/debian/changelog
--- python-chameleon-2.16/debian/changelog 2014-06-29 05:01:35.0 +0900
+++ python-chameleon-2.16/debian/changelog 2014-11-12 16:50:58.0 +0900
@@ -1,3 +1,11 @@
+python-chameleon (2.16-4) unstable; urgency=medium
+
+ * Team upload.
+ * d/control: Add missing python-chameleon-doc Breaks/Replaces against
+python-chameleon. Thanks to Andreas Beckmann. Closes: #768205.
+
+ -- Arnaud Fontaine ar...@debian.org Wed, 12 Nov 2014 16:37:07 +0900
+
python-chameleon (2.16-3) unstable; urgency=medium
* d/tests:
diff -Nru python-chameleon-2.16/debian/control python-chameleon-2.16/debian/control
--- python-chameleon-2.16/debian/control 2014-07-01 07:23:12.0 +0900
+++ python-chameleon-2.16/debian/control 2014-11-12 16:36:56.0 +0900
@@ -53,6 +53,8 @@
Section: doc
Architecture: all
Depends: ${misc:Depends}
+Breaks: python-chameleon ( 2.16-1~)
+Replaces: python-chameleon ( 2.16-1~)
Description: XML-based template compiler
Chameleon compiles templates to Python byte-code. It includes a complete
implementation of the Zope Page Templates (ZPT) language.
signature.asc
Description: PGP signature
Bug#745135: RFS: mariadb-10.0/10.0.13-1 [ITP] -- Latest version of worlds most popular non-Oracle database)
Tobias Frost t...@frost.de writes: (Srry, my mail yesterday didn't go out...) So, I leave it up to you; when you feel ready to upload, just upload. I joined the IRC (irssi client on my home server) so I will (try to remember to) check there for any message. I will also drop a message on IRC before uploading. Ok, thanks! Otto told me about some tests failures on amd64 and i386 so I will wait for him to confirm that everything is fine and then upload. Regarding the upload: I think d/copyright should be improved first, (at least the parts where license-reconsile claims that the wrong license is applied needs to be clearified) But as this is a huge package and it is already through NEW I would be also okish for me improve here over the next uploads. Yes, that should be fixed before uploading to unstable but for now that's probably enough for experimental. Thanks for your work. Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687484: [debian-mysql] Bug#687484: Status of CVE-2012-4414: SQL injection
Henri Salo he...@nerv.fi writes: What is current status of CVE-2012-4414? Information about the issue in http://www.openwall.com/lists/oss-security/2012/09/11/4 Marked as grave and security without any comments from maintainers. Plans to patch this issue? If not could you please give reasoning, thank you. I think this bug only affects squeeze (oldstable) which reached its EOL and is now only supported by volunteers as part of the Debian-LTS project so you should probably get in touch with them: https://wiki.debian.org/LTS Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745135: RFS: mariadb-10.0/10.0.13-1 [ITP] -- Latest version of worlds most popular non-Oracle database)
Hello, Tobias Frost t...@frost.de writes: To avoid a collision: I suggest that Arnaud Fontaine and either agree on who will upload, or that both of us announces on the BTS *before* we start looking at the package.. Arnau -- is this ok with you? Sure. Actually, I saw the comments you sent on the mailing list and then did further comments on IRC (probably better to use the BTS or the ML next time though). Do you want to upload this time or the one available after Otto fixed all the reported issues upload? Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745135: RFS: mariadb-10.0/10.0.13-1
Hello, What's blocking the upload to unstable? If that helps, I could spend some time trying to sponsor MariaDB 10.0 as I would like this package to be available for Jessie if possible. Cheers, -- Arnaud Fontaine pgp1MhlZp8HL3.pgp Description: PGP signature
Bug#755033: ITP: ropemode -- helper for using rope refactoring library in IDEs
Package: wnpp Severity: wishlist Owner: Arnaud Fontaine ar...@debian.org * Package name: ropemode Version : 0.2 Upstream Author : Ali Gholami Rudi * URL : http://rope.sf.net/ * License : GPL Programming Lang: Python Description : Helper for using rope refactoring library in IDEs This package includes common parts of ropemacs and ropevim and is required to package ropemacs = 0.7. It will be maintained as part of Debian Python Modules Team. Regards, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755034: ITP: re6stnet -- Resilient, scalable, IPv6 network application
Package: wnpp Severity: wishlist Owner: Arnaud Fontaine ar...@debian.org * Package name: re6stnet Upstream Author : Nexedi re6st...@erp5.org * URL : http://re6st.net * License : GPL Programming Lang: Python Description : Resilient, scalable, IPv6 network application re6stnet creates a resilient, scalable, ipv6 network on top of an existing ipv4 network, by creating tunnels on the fly, and then routing targeted traffic through these tunnels. re6stnet can be used to: - guarantee connectedness between computers connected to the internet, for which there exists a working route (in case the direct route isn't available). - create large networks - give ipv6 addresses to machines with only ipv4 available Regards, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754352: ITP: apachedex -- Compute APDEX from Apache-style logs
Package: wnpp Severity: wishlist Owner: Arnaud Fontaine ar...@debian.org * Package name: apachedex Version : 1.6.2 Upstream Author : Vincent Pelletier vinc...@nexedi.com * URL : http://git.erp5.org/gitweb/apachedex.git * License : GPLv2 Programming Lang: Python Description : Compute APDEX from Apache-style logs APacheDEX parses Apache-style logs and generates several statistics intended for a website developer audience: * APDEX (Application Performance inDEX, see http://www.apdex.org) ratio (plotted) because you want to know how satisfied your users are. * hit count (plotted) because achieving 100% APDEX is easy when there is nobody around. * HTTP status codes, with optional detailed output of the most frequent URLs per error status code, along with their most frequent referers because your forgot to update a link to that conditionally-used browser compatibility javascript you renamed. * Hottest pages (pages which use rendering time the most) because you want to know where to invest time to get highest user experience improvement. * ERP5 sites: per-module statistics, with module and document views separated because module and document types are not born equal in usage patterns. -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752741: Should depend upon python-six = 1.4.1
Package: python-cliff Version: 1.6.1-1 Severity: important Hello, Since 1.6.0, cliff requires six = 1.4.1. Could you please explicitly add this to Depends? Thanks. Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752741: Should depend upon python-six = 1.4.1
Hello, Could you please also add a versioned depends against python-prettytable (= 0.7 0.8)? Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739190: netenv doesn't come up initializing via systemd
Hello, Michael Biebl bi...@debian.org writes: Under systemd all services run in a defined context. This also means you can't prompt for input by reading from the console. # X-Interactive: true as used by the netenv sysv init script does not work by design. See [1]: Services cannot read from stdin, as this will be connected to /dev/null. That means interactive init scripts are not supported (i.e. Debian's X-Interactive in the LSB header is not supported either.) Thankfully most distributions do not support interaction in init scripts anyway. If you need interaction to ask disk or SSL passphrases please consider using the minimal password querying framework systemd supports. (details, manual page) [...] That leaves netdev. Tbh I don't know what to do about that. The password agents [2] were designed to prompt for passphrases, not to select from a list from pre-defined values. So they are not applicable to the case. While you can change a service file's StandardInput= setting so it actually get's access to the console during boot, a systemctl start netdev.service in you terminal emulator does not work with that either afair. But for this case you could simply provide a command-line tool like netenv-select or so As a closing remark, let me add that it is generally discouraged to prompt for input during boot. Since when has it been discouraged? I may have misunderstood something but, considering the password agents built in systemd, I don't see any reason why only inputting passwords should be allowed/available at boot time and not something else at the end (especially for system-level prompt such as system-wide network configuration as netenv does), whatever the technical reason is... Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750967: Byte-compilation fails upon apel upgrade, thus making emacs and apel upgrade fails
Hi, Tatsuya Kinoshita t...@debian.org writes: On June 9, 2014 at 12:31PM +0900, arnau (at debian.org) wrote: elscreen-apel.patch +++ debian/emacsen-install 2014-06-09 12:23:03.642097192 +0900 +if [ ! -f /usr/share/$FLAVOR/site-lisp/apel/alist.elc ]; then exit 0; fi Your patch looks fine. See also emacsen-common's bug#737389. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737389 Thanks for the URL. I was not aware about this bug. It would indeed be better if that could be fixed in emacsen-common rather than individually in each package, but in the meantime that should probably do it... Masayuki: Could you please have a look at the patch and apply it or can I upload an NMU fixing this issue? Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750967: Byte-compilation fails upon apel upgrade, thus making emacs and apel upgrade fails
Package: elscreen
Version: 1.4.6-5.1
Severity: serious
Tags: patch
[CC'ing the Emacs24 maintainer just to know if this is an expected
behavior and whether the attached patch is correct...]
Hello,
Today, when upgrading Emacs24 and Apel at the same time, I got the
following error upon Emacs24 upgrade (so even before Apel postinst
script is being ran):
Install bbdb for emacs24
install/bbdb: Byte-compiling for emacs24 ...
Generating bbdb-autoloads...
Byte-compiling bbdb...
done.
Install cmake-data for emacs24
install/cmake-data: Byte-compiling for emacs24
Wrote /usr/share/emacs24/site-lisp/cmake-data/cmake-mode.elc
Install debian-el for emacs24
debian-el files already compiled in /usr/share/emacs24/site-lisp/debian-el.
Install elscreen for emacs24
install/elscreen: Handling install for emacsen flavor emacs24
Loading /etc/emacs/site-start.d/00debian-vars.el (source)...
Loading /etc/emacs/site-start.d/20apel.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/50bbdb.el (source)...
Loading /etc/emacs/site-start.d/50cmake-data.el (source)...
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...
Error while loading 50dictionaries-common: Symbol's value as variable is
void: debian-aspell-only-dictionary-alist
Loading /etc/emacs/site-start.d/50dpkg-dev-el.el (source)...
Package dpkg-dev-el not fully installed. Skipping setup.
Loading /etc/emacs/site-start.d/50elscreen.el (source)...
Loading /etc/emacs/site-start.d/50emacs-goodies-el.el (source)...
Package emacs-goodies-el not fully installed. Skipping setup.
Loading /etc/emacs/site-start.d/50emacs-mozc.el (source)...
Loading /etc/emacs/site-start.d/50flim.el (source)...
Loading /etc/emacs/site-start.d/50lookup-el.el (source)...
Loading /etc/emacs/site-start.d/50lua-mode.el (source)...
Loading /etc/emacs/site-start.d/50magit.el (source)...
Loading /usr/share/emacs/site-lisp/magit/magit-install.el (source)...
Loading /etc/emacs/site-start.d/50namazu2.el (source)...
Loading /etc/emacs/site-start.d/50psvn.el (source)...
Loading /etc/emacs/site-start.d/50pylint.el (source)...
Error while loading 50pylint: Cannot open load file: pylint
Loading /etc/emacs/site-start.d/50pymacs.el (source)...
Loading /etc/emacs/site-start.d/50sdic.el (source)...
Loading /etc/emacs/site-start.d/50systemtap-common.el (source)...
Loading /usr/share/emacs/site-lisp/systemtap-common/systemtap-init.el
(source)...
Loading /etc/emacs/site-start.d/50w3m-el-snapshot.el (source)...
Loading /etc/emacs/site-start.d/51debian-el.el (source)...
Loading /etc/emacs/site-start.d/51emms.el (source)...
Loading /etc/emacs/site-start.d/70sdic-edict.el (source)...
Error while loading 70sdic-edict: Symbol's value as variable is void:
sdic-waei-dictionary-list
In toplevel form:
elscreen-color-theme.el:25:1:Error: Cannot open load file: alist
In toplevel form:
elscreen-dired.el:26:1:Error: Cannot open load file: alist
In toplevel form:
elscreen-dnd.el:26:1:Error: Cannot open load file: alist
In toplevel form:
elscreen-gf.el:28:1:Error: Cannot open load file: alist
In toplevel form:
elscreen-goby.el:26:1:Error: Cannot open load file: alist
In toplevel form:
elscreen-howm.el:26:1:Error: Cannot open load file: alist
In toplevel form:
elscreen-server.el:27:1:Error: Cannot open load file: alist
In toplevel form:
elscreen-speedbar.el:25:1:Error: Cannot open load file: alist
In toplevel form:
elscreen-w3m.el:26:1:Error: Cannot open load file: alist
In toplevel form:
elscreen.el:28:1:Error: Cannot open load file: alist
ERROR: install script from elscreen package failed
I guess this is what triggers this issue upon Emacs24 upgrade:
1. All the byte-compiled files in /usr/share/emacs24/site-lisp/ are
purged.
2. Byte-compilation is triggered but at this point apel is only in
unpacked state so no byte-compilation occurs. However, elscreen
(depending upon apel) does not check whether apel has been
byte-compiled and fails.
I have attached a patch checking for alist.elc before
byte-compilation. I'm not sure this is the right fix though, could you
please have a look? Thanks!
Regards,
--
Arnaud Fontaine
--- debian/emacsen-install.ORIG 2014-06-09 12:22:57.118021446 +0900
+++ debian/emacsen-install 2014-06-09 12:23:03.642097192 +0900
@@ -8,6 +8,7 @@
FLAVOR=$1
PACKAGE=elscreen
+if [ ! -f /usr/share/$FLAVOR/site-lisp/apel/alist.elc ]; then exit 0; fi
if [ ${FLAVOR} = emacs ]; then exit 0; fi
echo install/${PACKAGE}: Handling install for emacsen flavor ${FLAVOR}
Bug#741316: Please package new upstream release (6.5.5)
Package: offlineimap Severity: wishlist Hello, Could you please package offlineimap 6.5.5? Thanks! Regards, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705436: elscreen: From Emacs 24.3: Symbol's value as variable is void: last-command-char
Hello, As I have got no reply about this bug report for a while, I will upload a NMU including only the patch above in the following days. Cheers, -- Arnaud Fontaine pgppUY_6p1EE1.pgp Description: PGP signature
Bug#739584: Please enable Japanese user interface translations
Hi, David Prévot taf...@debian.org writes: On Thu, Feb 20, 2014 at 04:11:49PM +0900, Arnaud Fontaine wrote: It seems that Japanese translation is available for Owncloud but it is not enabled as it is not in /usr/share/owncloud/settings/languageCodes.php. In the “personal” setup menu, I’m able to chose “Japanese (日本語)” (it’s even the sixth choice from the first set of languages) and when I do, the UI is in Japanese (at least it uses letters I don’t understand that looks like Japanese to me). Is your experience different, are you expecting something else? Well, if your browser is set up in Japanese (eg HTTP Accept-Language is ja fist), then the interface should be in Japanese straightaway from the login page, eg you should not have to select manually the language. All other languages for owncloud I tested, such as polish and german, behave this way but Japanese. Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739402: awesome-extra: 2012061101 version is out of date, please upgrade
Hi, Jonathan McCrohan jmccro...@gmail.com writes: On 18/02/14 09:08, Arnaud Fontaine wrote: Adam Lee adam8...@gmail.com writes: 2012061101 version is out of date, broken with new kernel, driver and awesome wm. Please upgrade? Thanks. Indeed. Last month, Jonathan McCrohan prepared an update of awesome-extra and I reviewed it, but I have not heard from him since then, so I'm Cc'ing him to know if he has been able to work on it since then... Its on my to-do list. I hope to get some time this weekend. Great, thanks! Arnaud, what is the current status of awesome 3.5? Can it be uploaded to unstable yet? As #736314 has still not been fixed, it's still in experimental. But that should not affect awesome-extra which should work with 3.4 anyway, right? Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739584: Please enable Japanese user interface translations
Source: owncloud Version: 6.0.1+dfsg-1 Severity: wishlist Tags: upstream Hello, It seems that Japanese translation is available for Owncloud but it is not enabled as it is not in /usr/share/owncloud/settings/languageCodes.php. However, after testing, simply adding 'ja_JP' does not seem to be enough as AFAIU the keys of this hash tables is supposed to match HTTP Accept-Language header which would be 'ja' only for Japanese. Therefore, there should probably be a symlink from 'ja' to 'ja_JP' or maybe findLanguage() (lib/private/l10n.php) should be fixed (see RFC 2616)? On our instance I personnally did the second one even though it's not entirely correct but I didn't want to create many simlinks everywhere (and it may be needed to do the same for apps as well...). Regards, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739257: Acknowledgement (docker.io: leftover after purge: /var/lib/docker)
Paul Tagliamonte paul...@debian.org writes: On Mon, Feb 17, 2014 at 05:15:38PM +0900, Arnaud Fontaine wrote: Hi again, Also, docker user is created in postinst, but not removed on purge neither. Could you please fix it? Thank you very much. https://wiki.debian.org/AccountHandlingInMaintainerScripts I don't believe that's needed. I don't really mind either way, but purging and re-installing may give the user a new uid, which is a huge pain if you have any files owned by the daemon on the machine that you backed up. I think we're pretty split on if we should do this, is there a good reason besides it looks ugly in /etc/passwd or something? Not really. To be honest I think you're right and I didn't think about the issue you mentioned above (thanks for pointing that out, it's good to know ;-)), so it should be probable be left as is it for the user at least. Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739401: awesome: 3.5 series should be migrated to unstable
forcemerge 736314 739401 thanks Hi, Adam Lee adam8...@gmail.com writes: Package: awesome Version: 3.5.2-1 Severity: normal More than a half year has passed since 3.5 series is uploaded to experimental. I'm using it every day, think it's stable enough to be migrated to unstable distro. Please look at #736314 which explains why Awesome 3.5 is still in experimental. Thanks. Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739402: awesome-extra: 2012061101 version is out of date, please upgrade
Hi, Adam Lee adam8...@gmail.com writes: Package: awesome-extra Version: 2012061101 Severity: normal Hi, 2012061101 version is out of date, broken with new kernel, driver and awesome wm. Please upgrade? Thanks. Indeed. Last month, Jonathan McCrohan prepared an update of awesome-extra and I reviewed it, but I have not heard from him since then, so I'm Cc'ing him to know if he has been able to work on it since then... Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739476: ImportError: cannot import name ScopedSession
Source: elixir Severity: grave Tags: upstream Hello, When trying to import elixir module, I get the following traceback which makes elixir completely unusable: import elixir Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/pymodules/python2.7/elixir/__init__.py, line 29, in module from elixir.entity import Entity, EntityBase, EntityMeta, EntityDescriptor, \ File /usr/lib/pymodules/python2.7/elixir/entity.py, line 17, in module from sqlalchemy.orm import MapperExtension, mapper, object_session, \ ImportError: cannot import name ScopedSession Also, considering that a security bug, #670919, which is almost two years old has never been fixed and there has been no upstream release since 11/2009 (actually around the time a declarative layer has been implemented in sqlalchemy AFAIU), I'm wondering whether this package should be kept in the archive at all. What do you think? -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-trunk-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 Regards, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739257: Acknowledgement (docker.io: leftover after purge: /var/lib/docker)
Hi again, Also, docker user is created in postinst, but not removed on purge neither. Could you please fix it? Thank you very much. Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738928: ITA: ropemacs -- Emacs mode for Python refactoring
retitle 738928 ITA: rope -- Python refactoring library owner 738928 ! retitle 738929 ITA: ropemacs -- Emacs mode for Python refactoring owner 738929 ! thanks Hello, I'm already using rope for Emacs a lot and already started to prepare an upload for pymacs as well. I will maintain it as part of python-modules team. Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739257: docker.io: leftover after purge: /var/lib/docker
Source: docker.io Severity: normal Hello, Even after purging docker.io packages, /var/lib/docker is not removed. Moreover, it seems that this directory is not even managed by the package itself, probably it should be added through dh_installdirs? Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738510: AttributeError: 'module' object has no attribute '_AsciiBase85Encode'
reassign 738510 python-reportlab thanks Matthias Klose d...@debian.org writes: Am 10.02.2014 06:29, schrieb Arnaud Fontaine: Package: python-reportlab Version: 3.0~a1-1 Severity: important Tags: upstream When trying to scan with 'hp-scan', I get an error because of reportlab new version where '_AsciiBase85Encode' is not defined anymore in pdfutils module: sure, a name starting with an underscore hints at a private symbol. so hplip should be fixed. reportlab.lib.rl_accel seems to provide asciiBase85Encode now. Sorry if it was not clear in my initial email but as you can see from the traceback below, hp-scan from hplip package only does: from reportlab.pdfgen import canvas c = canvas.Canvas(output, (brx/0.3528, bry/0.3528)) c.drawInlineImage(image, (tlx/0.3528), (tly/0.3528), ((brx-tlx)/0.3528),((bry-tly)/0.3528)) Then, internally in reportlab API, it tries to access _AsciiBase85Encode from reportlab.pdfgen.pdfimages.PDFImage().PIL_imagedata() which is not available anymore in reportlab pdfutils, because as you rightly pointed out, it has been renamed to asciiBase85Encode. So to sum up, the issue is clearly in python-reportlab package because of the API changes in 3.0 and not in hplip. [...] Traceback (most recent call last): File /usr/bin/hp-scan, line 1021, in module c.drawInlineImage(image, (tlx/0.3528), (tly/0.3528), ((brx-tlx)/0.3528),((bry-tly)/0.3528)) File /usr/lib/python2.7/dist-packages/reportlab/pdfgen/canvas.py, line 826, in drawInlineImage img_obj = PDFImage(image, x,y, width, height) File /usr/lib/python2.7/dist-packages/reportlab/pdfgen/pdfimages.py, line 40, in __init__ self.getImageData() File /usr/lib/python2.7/dist-packages/reportlab/pdfgen/pdfimages.py, line 165, in getImageData imagedata, imgwidth, imgheight = self.PIL_imagedata() File /usr/lib/python2.7/dist-packages/reportlab/pdfgen/pdfimages.py, line 130, in PIL_imagedata data = pdfutils._AsciiBase85Encode(data) #...sadly this may not be AttributeError: 'module' object has no attribute '_AsciiBase85Encode' Cheers, -- Arnaud Fontaine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738510: AttributeError: 'module' object has no attribute '_AsciiBase85Encode'
Package: python-reportlab Version: 3.0~a1-1 Severity: important Tags: upstream Hello, When trying to scan with 'hp-scan', I get an error because of reportlab new version where '_AsciiBase85Encode' is not defined anymore in pdfutils module: $ hp-scan --adf [...] Using device: hpaio:/net/... warning: No destinations specified. Adding 'file' destination by default. Using device hpaio:/net/... Opening connection to device... Resolution: 300dpi Mode: gray Compression: JPEG Scan area (mm): Top left (x,y): (0.00mm, 0.00mm) Bottom right (x,y): (215.99mm, 355.66mm) Width: 215.99mm Height: 355.66mm Destination(s): file Output file: warning: File destination enabled with no output file specified. Setting output format to PDF for ADF mode. warning: Defaulting to '/tmp/hpscan001.pdf'. Warming up... Page 1: Scanning... Reading data: [***] 100% 8.4 MB Read 8.4 MB from scanner. Page 2: Scanning... Reading data: [***] 100% 8.5 MB Read 8.5 MB from scanner. Page 3: Scanning... Reading data: [***] 100% 8.5 MB Read 8.5 MB from scanner. Page 4: Scanning... Out of documents. Scanned 3 pages total. Closing device. Traceback (most recent call last): File /usr/bin/hp-scan, line 1021, in module c.drawInlineImage(image, (tlx/0.3528), (tly/0.3528), ((brx-tlx)/0.3528),((bry-tly)/0.3528)) File /usr/lib/python2.7/dist-packages/reportlab/pdfgen/canvas.py, line 826, in drawInlineImage img_obj = PDFImage(image, x,y, width, height) File /usr/lib/python2.7/dist-packages/reportlab/pdfgen/pdfimages.py, line 40, in __init__ self.getImageData() File /usr/lib/python2.7/dist-packages/reportlab/pdfgen/pdfimages.py, line 165, in getImageData imagedata, imgwidth, imgheight = self.PIL_imagedata() File /usr/lib/python2.7/dist-packages/reportlab/pdfgen/pdfimages.py, line 130, in PIL_imagedata data = pdfutils._AsciiBase85Encode(data) #...sadly this may not be AttributeError: 'module' object has no attribute '_AsciiBase85Encode' Cheers, Arnaud Fontaine -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-trunk-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 Versions of packages python-reportlab depends on: ii python 2.7.5-5 Versions of packages python-reportlab recommends: ii python-pil 2.3.0-1 ii python-renderpm 3.0~a1-1 ii python-reportlab-accel 3.0~a1-1 Versions of packages python-reportlab suggests: ii evince [pdf-viewer]3.10.0-2 pn python-egenix-mxtexttools none pn python-reportlab-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
