Bug#806182: Will fix python-django-registration RCs shortly (Was: Re: Request to join DPMT && python-django-registration)
Hi James, On Mi, 2016-01-06 at 07:13 -0600, James Bennett wrote: > Stephan Sürken wrote: > > Let's see if I got this right: > > > > django-registration is actually no longer discontinued, and now lives at > > > > https://github.com/ubernostrum/django-registration > > > > The (incompatible) *-redux fork lives at > > > > https://github.com/macropin/django-registration > > Yes. django-registration upstream has been revived and the latest > release of it (on PyPI as django-registration 2.0.3) is compatible with > Django 1.7 and 1.8, on any Python version supported by those versions of great! This does really simplify matters; so I will start integrating 2.0.3 first (and see, then, where it goes in respect to django 1.9). The *-redux fork should imho be packaged separately as alternative by any interested third party ;). Thx, S
Bug#806182: Will fix python-django-registration RCs shortly (Was: Re: Request to join DPMT && python-django-registration)
Hi list, interested parties, On Mi, 2015-11-11 at 16:39 +0100, Stephan Sürken wrote: > I would like to join the DPM Team. I am a DD, my user name on alioth is > "absurd" (and yes, I read the policy document and I am aware of the git > move ;). seems I am still not in the official members list https://alioth.debian.org/projects/python-modules/ but maybe I am just not getting something ;). So anyway, this is to avoid maybe ongoing duplicate work. If no one objects, I will... > As first urgent quest I would like to fix the RC django 1.8 (I already > did some work on that package for some time before it was moved to the > DPMT). ...update the package shortly (i.e., within this week). This will focus on minimal changes to make it work with django 1.8+. > As for p-d-r in general: Has there been any discussion here already > if/how to package 'p-d-r-redux' (which seems to be a (still maintained) > fork)? As we now have #806182, I am hoping for some discussion/advice there how to exactly handle this in the future (I have not looked into *-redux at all yet). So the 1st question for me is whether it's really a drop-in replacement, or if we might, at this point, create a new package *-redux (maybe with the option to fix #567739, too). Thx for any advice on this! S signature.asc Description: This is a digitally signed message part
Bug#806182: Will fix python-django-registration RCs shortly (Was: Re: Request to join DPMT && python-django-registration)
Hi James, On Mi, 2016-01-06 at 06:23 -0600, James Bennett wrote: (...) > > So the 1st question for me is whether it's really a drop-in replacement, > > or if we might, at this point, create a new package *-redux (maybe with > > the option to fix #567739, too). > > -redux is not a drop-in replacement. However, upstream > django-registration is 1.8 compatible as of the current release on PyPI, > and is about to gain a 1.9-compatible release as well. So please make > sure to check on what's happening in upstream before you duplicate the > work already done there: > > https://github.com/ubernostrum/django-registration ahh, thanks James, I guess now I understand your previous comment ;). Let's see if I got this right: django-registration is actually no longer discontinued, and now lives at https://github.com/ubernostrum/django-registration The (incompatible) *-redux fork lives at https://github.com/macropin/django-registration Thx! S signature.asc Description: This is a digitally signed message part
Bug#806593: does not start (Models for app haven't been imported yet) after upgrade
Hi Marc, On So, 2015-11-29 at 13:56 +0100, Marc Haber wrote: (...) > Please advice what to do how to get up and running again, and if this > is an issue within the package, please consider fixing it. this (at least with django 1.8) is due to python-django-registration; you would need to apply the (already provided) patch for that package (or downgrade to django 1.7). Maybe more devilry is coming up with django 1.9, so sticking with django 1.7 is the best advice for some time for a sid system, I guess. Hth! S
Bug#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)
Hi Michael, On Fr, 2015-11-20 at 14:15 +0100, Michael Biebl wrote: > Am 23.10.2015 um 17:43 schrieb Stephan Sürken: > > So yes, for a non-existing script, that's (changed behaviour) but > > correct. > > > > For the example wicd service however, it should ignore the call like > > before, afaiu. > > I think so as well. Could you please raise this issue upstream at > https://github.com/systemd/systemd/issues/new ok, upstream ticket is: https://github.com/systemd/systemd/issues/2015 Hth, S
Bug#802688: sbuild does not honor setup.fstab
Hi Marc! On Do, 2015-10-22 at 18:19 +0200, Marc Haber wrote: (...) > mini-buildd uses the setup.fstab option in /etc/schroot/chroot.d/* to > ask schroot to honor the fstab file from /etc/schroot/mini-buildd/fstab. > > This does, for some strange reason, not work on a current sid system. > > This, in turn, leaves the chroots without /var/lib/mini-buildd > mounted, which in turn leads to the strange "apt_sources.list not > found" errors in the build logs, which in turn leads to unbuildable > packages when the package has a build dependency not in Debian, but in > the mini-buildd archive. > > I was able to work around this by exchanging > "setup.fstab=mini-buildd/fstab" for "profile=mini-buildd" in > /etc/schroot/chroot.d/mini-buildd*, setting the files immutable so > that mini-buildd doesn't "fix" them any more, and copying nssdatabases > and copyfiles from /etc/schroot/default to /etc/schroot/mini-buildd. Uff, WTF ;)! However, I just tried to produce this on my sid test environment, but I could not, so I guess I am not getting something here. So, do I understand correctly, when the bug happens, '/etc/schroot/mini-buildd/fstab' _does_ have the line -- /var/lib/mini-buildd/var /var/lib/mini-buildd/var none rw,bind 0 0 -- but running something like -- schroot --chroot mini-buildd-jessie-amd64 -- ls -la /var/lib/mini-buildd/var/ -- (as user mini-buildd) does not work? Thx! S
Bug#796348: "no route to host" - which host?
Hi Marc, On Fr, 2015-08-21 at 15:05 +0200, Marc Haber wrote: > Aug 21 14:57:32 spinturn mini_buildd.misc (0588): DEBUG : Call > successful: gpg --homedir=/var/lib/mini-buildd/.gnupg --display-charset=UTF-8 > --batch --armor --textmode --clearsign > --output=/var/lib/mini-buildd/var/spool/e60204c31c1ad87c372b2bb699d1ee00089b0b29/armhf/borgbackup_0.24.0-0~zgSID+3_mini-buildd-buildrequest_armhf.changes.signed > > /var/lib/mini-buildd/var/spool/e60204c31c1ad87c372b2bb699d1ee00089b0b29/armhf/borgbackup_0.24.0-0~zgSID+3_mini-buildd-buildrequest_armhf.changes.asc > Aug 21 14:57:32 spinturn mini_buildd.packager (0037): ERROR : > borgbackup_0.24.0-0~zgSID+3: Buildrequest upload failed: [Errno 113] No route to host> this is fixed in 1.0.8; you should get some "can't get status..." including the failing URL. I.e., if I am not mistaken, this is actually an python urllib call failing -- I would really be interested in why it does so, and if there is anything in mbd that needs fixing here... Thx! S
Bug#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)
Hi Martin, On Fr, 2015-10-23 at 17:10 +0200, Martin Pitt wrote: (..) > > 227-2, sid: Fails, retval 6: > > # root? systemctl restart non-existing.service > > Failed to restart non-existing.service: Unit non-existing.service failed > > to load: No such file or directory. > > # root? systemctl restart non-existing.service > > Failed to restart non-existing.service: Unit non-existing.service failed > > to load: No such file or directory. > > That looks right -- systemctl is supposed to fail for a nonexisting > script. I don't even consider that a bug, but a fix. hmm, sorry, seems I did a cut-and-paste error here; the last two lines should have been root@manwe:~# systemctl restart wicd.service Failed to restart wicd.service: Unit wicd.service failed to load: No such file or directory. So yes, for a non-existing script, that's (changed behaviour) but correct. For the example wicd service however, it should ignore the call like before, afaiu. (...) > Starting/stopping services in a schroot has never been defined > behaviour, as in general you can't do that. chroots should have a > policy-rc.d (see /usr/share/doc/sysv-rc/README.policy-rc.d.gz) which > disables service starting/stopping from package maintainer scripts. Ahh, ok. Will have a look at that. > Also, package maintainer scripts certainly shouldn't call invoke-rc.d > on a nonexisting service? Well, the "nonexisting" example should only serve to simply demonstrate that systemd actually _has_ changed behaviour. I am concerned about actual packages failing to install or remove in a plain chroot. Hth! S
Bug#790274: Downgrading severity to normal
Hi, I am pretty sure (see my last comment) these failures were actually due to pbuilder chroots with broken shared memory. I have also just retested that it builds fine with a new cowbuilder setup under sid. So I have downgrading this to normal, so it may eventually advance to testing again. Hth!
Bug#790274: python-pyftpdlib: FTBFS: Failure in test_on_incomplete_file_sent
Hi Daniel, Andreas, On Fri, 17 Jul 2015 00:47:55 +0200 Andreas Beckmann a...@debian.org wrote: Followup-For: Bug #790274 Similar failure while rebuilding in a clean jessie pbuilder environment: [...] [...] File /usr/lib/python2.7/multiprocessing/synchronize.py, line 147, in __init__ SemLock.__init__(self, SEMAPHORE, 1, 1) File /usr/lib/python2.7/multiprocessing/synchronize.py, line 75, in __init__ sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue) OSError: [Errno 13] Permission denied debian/rules:8: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 1 make[1]: Leaving directory '/tmp/buildd/python-pyftpdlib-1.2.0' debian/rules:4: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 this very much sounds like it was build in a builder env with shared memory broken. I just retested that it builds fine in clean build environments for sid, jessie, and stretch. So I guess you both have run into (at least some variant of) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728096 and this is not in python-pyftpdlib. Could you please check, and downgrade the severity if you agree? Thx! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793888: ui-gxmlcpp includes autogenerated files that cannot be rebuilt from source
On Sa, 2015-08-01 at 19:46 +0200, Johannes Schauer wrote: Hi, (...) I reported it like that because I was not able to recreate ./configure and aclocal.m4 from source. When I deleted both files and tried to regenerate them, I ran into an error and I also got an error when I tried to rebuild with `dh --with autoreconf`. This made me believe that ./configure and aclocal.m4 can *not* be built from source. so this does not work even _with_ ui-auto installed? Thx, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793888: ui-gxmlcpp includes autogenerated files that cannot be rebuilt from source
Hi Johannes! On Di, 2015-07-28 at 17:31 +0200, Johannes Schauer wrote: Source: ui-gxmlcpp Version: 1.4.3-1 Severity: serious Justification: Policy 2.2.1 (...) the source package for ui-gxmlcpp includes a ./configure and ../aclocal.m4 without including their source. If ./configure and ../aclocal.m4 are removed, then the package cannot be built anymore. For example, the current aclocal.m4 contains parts of ui-auto but ui-gxmlcpp does not build depend on that package. Please add the missing bits so that this source package can be built from source again and does not require autogenerated scripts like ../configure and ./aclocal.m4. Ok, switching to autoreconf (with b-d on ui-auto) is an option I will consider. Could you ponder a bit more why you think this is a policy violation? It seems a bit harsh considering how autotools work, and everything can be rebuild within Debian/main -- but maybe I missed something ;). Thanks! Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790856: please consider shipping key in keyring package as /fragment in trusted.gpg.d
On Do, 2015-07-02 at 14:12 +0200, Marc Haber wrote: (...) the debian-archive-keyring package has - starting with wheezy - changed to ship the archive keys in dedicated files in /etc/apt/trusted.gpg.d instead of using apt-key. In my opinion, it would be a good idea if mini-buildd did the same in its keyring packages. fwiw, when trying to solve this, we need to keep in mind that the keyring package (i.e., both src and deb) needs to be compatible to (at least) all distributions mini-buildd claims to support via it's wizards. Hth, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790056: please consider a shorter or a configurable origin in reprepro config
On Fr, 2015-06-26 at 18:55 +0200, Marc Haber wrote: (...) the rather terse Debian in the normal Debian archives. This leads to pin lines like Pin: release n=sid-test-unstable, o=Mini-Buildd archive zg on spinturn.zugschlus.de which is like asking for trouble in my opinion regarding the spaces in the origin value. Do I need to quote the string? No. You even must not. Do I need to quote the spaces? No. You even must not. Will it work when the o= part is not last in the line? Yes. Will it work when I use an additional space before the comma separating the next pin item in the pin line? Yes ;). I cannot proof this with actual documentaion ;), but is has worked so for years and years: it seems apt splits the string on ,, and then removes leading and tailing whitespaces on the items. All this could be avoided by using a much shorter default value for Origin, or making the Origin configurable. As far as I understand the new mini-buildd logic, this field should be part of the distribution object inside mini-buildd's configuration. Agreed anyway (that this should be configurable). The default value needs to be more complicated, as we want to generate a different Origin by default for any mini-buildd instance. Hth, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793606: always builds on all architectures
On So, 2015-07-26 at 11:22 +0200, Marc Haber wrote: (...) On Sun, Jul 26, 2015 at 11:04:45AM +0200, Stephan Sürken wrote: Fwiw, currently, mini-buildd just uploads build requests to all builders and completely relies on sbuild. This *is* a nice solution, as sbuild knows best, and no extra/duplicated code/dsc knowledge at all is needed in mini-buildd. So it is sbuild that does not honor the Architecture field? No, sbuild would run fine and result with status skipped (which is a successful build). In your setup mini-buildd does not find any builder for the your arch (to eventually run sbuild on) in the first place. Htei, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793606: always builds on all architectures
Moin, On Sa, 2015-07-25 at 15:28 +0200, Marc Haber wrote: (...) my mini-buildd is configured to have architectures amd64, i386 and armhf. The armhf arch was just recently added so that I could poke locally built packages into the repository using direct reprepro calls and to be prepared to have mini-buildd actually build armhf packages. I do not yet have an armhf builder since my only armhf system is running jessie and does not have enough storage to support a sid chroot, and I would like to spare myself from backporting mini-buildd to jessie. ftra, I am always doing ports for jessie (via Debian Backports) or even wheezy (via my own repo). When mini-buildd builds a package now, the build fails because there is no armhf builder. With one build failing like that, the packages resulting from the successful builds on i386 and amd64 are not uploaded to the archive. (...) I tried my package now with Architecture: amd64 in all binary (...) Despite this, mini-buildd attempted to build the package for i386 (successful) and armhf (failed, no builder available), and didn't upload the amd64 package to the archive. (...) I think that mini-buildd should honor the Architecture: field in uploaded packages and refrain from trying to build on arches that the packager doesn't want. hmm ok, for that special setup (having no builder at all for a required arch), it would be a nice to have. Fwiw, currently, mini-buildd just uploads build requests to all builders and completely relies on sbuild. This *is* a nice solution, as sbuild knows best, and no extra/duplicated code/dsc knowledge at all is needed in mini-buildd. As this case is already covered by confing the arch as optional, can we put that to wishlist and rename it to please don't upload build requests to archs that don't need build? Should help me when returning to it ;). I guess it depends how simple it is to implement whether I am considering this... Thx! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793100: apt-dater: apt-dater(8) man page is wrong/outdated
Package: apt-dater Version: 1.0.2-1 Severity: minor Dear maintainers, it seems to me the apt-dater man page has not been updated to 1.0.x. It (for example) refers to ~/.config/apt-dater/apt-dater.config (afaict should be ../apt-dater.xml) ~/.config/apt-dater/hosts.config ( = ../hosts.xml) apt-dater.config(5) ( = apt-dater.xml(5)) Hth! S -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apt-dater depends on: ii libc6 2.19-19 ii libglib2.0-02.44.1-1.1 ii libncursesw55.9+20150516-2 ii libpopt01.16-10 ii libtcl8.5 8.5.18-2 ii libtinfo5 5.9+20150516-2 ii libxml2 2.9.2+dfsg1-3 ii lockfile-progs 0.1.17 ii openssh-client 1:6.7p1-6 ii tmux2.0-3 apt-dater recommends no packages. Versions of packages apt-dater suggests: pn apt-dater-host none pn xsltprocnone -- 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
Bug#790113: please clarify in docs wether scp to /var/lib/mini-buildd/incoming would be ok as well
Hi Marc, seems this bug is franzing out a little bit ;). On Mi, 2015-07-01 at 18:08 +0200, Marc Haber wrote: On Sat, Jun 27, 2015 at 05:21:24PM +0200, Stephan Sürken wrote: The Quickstart however now comes with a hint how to set up a ssh wrapper. That's a rather bad hack ;-) referring to the log/grep/key thingy, who could agree more ;). (...) Btw, I usually use something along the line command=/usr/share/doc/mini-buildd/examples/ssh-uploader-command KEYID ssh-rsa AA... Sure. this looks way better. Afai remember, it was not in the cards for the 'authorized_keys-Distributors' (that triggered that wrapper in the first place) do so. Just squeeze the example or rewrite to fit for your needs ;). Wouldn't it be a nicer idea to have mini-buildd take out an inotify on a new *.changes file in the incoming directory? That way, it could act on anything appearing in the directory. Well, in short: no. It was a design decision to use (py)ftpd as internal and only way to act on incoming as it gives us 1. a canonical, always there actual (networked) upload mechanism. * Note, for example, that this is also used for the repo-builder communication by exchanging special buildrequest and buildresult changes. 2. a very easy and effective way to guard against (most) race conditions/user upload errors (double uploads, file overwrites, etc). In a nutshell, inotify-based setup gives us more freedom, but none of the two. So, at least for 1.0.x (and most likely 1.2.x) wrapping around the canonical ftp is the only way to provide other upload channels. Fwiw, i am considering to officially support a ssh wrapper via the Debian package -- so it might come with 1.2.x. But then again, I did not even have the time to kick 1.2.x deveopment off yet ;). Hth! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790775: please outline a way to import a GPG key as archive signing key
Hi again Marc, On Mi, 2015-07-01 at 18:36 +0200, Marc Haber wrote: Source: mini-buildd Version: 1.0.7 Severity: wishlist I am currently in the process of migrating an old mini-buildd setup from 0.9x to 1.0.7. Due to issues when the package was upgraded, I took a backup of the old mini-buildd home directory, purged the old package and started over from scratch. Hence, my new mini-buildd setup has gotten a new archive signing key. Since I would like to save myself from logging in to all my machines to install the new key, I'd like to import the old archive signing key into the new mini-buildd instance. Is it ok to simply replace the keyring files and to re-create the archive key packages? Please document this and if not, outline a migration way. actually, it should be (nearly) that simple. I have not tested this myself, but basically, something like this should work: --- Import a foreign archive key to an existing mini-buildd instance 1. Stop the mini-buildd service. 2. Become the mini-buildd user. 3. Manipulate the user's GPG keyring * Be sure it contains exactly one key (pub+sec) when done. 4. (Re)start the mini-buildd service. * Check that the Daemon key has actually changed (f.e., on the web home, right bottom). 5. Make a pseudo change to all repository instances. * Just enter the repo editor, don't actually change anything, but do save. * This fixes the status to Prepared (Changed) (matching the external manipulation). 6. PCA ((re)prepare, check, create) all repositories. * This should bring the new key to the reprepro indices. 7. Re-create keyring packages. .. note:: The Daemon instance does not touch the GPG once it's created -- _unless you do an explicit remove_ on the instance. --- So this sketch may go to the docs later -- maybe when you have proven this actually works ;). Hth, S P.S.: Fwiw, just in case you should be so inclined to consider contributing documentation (or other things) yourself directly, I would really appreciate that ;): This is what could do, should that be the case: 1. clone the repo from alioth 2. branch from 1.0.x to something like feature/mhaber [Note: 1.2 dev on master hasn't even kicked off yet, and 1.0.x is frequently merged.] 3. add push your proposed updates there To build the docs locally test them, do s.th. like: 1. mk-build-deps --root-cmd sudo --install --remove 2. python setup.py build_sphinx --source-dir=build/sphinx 3. BROWSER build/sphinx/html/index.html Hth! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790804: keyring packages do only show up in test repository
Hi Marc, On Mi, 2015-07-01 at 22:51 +0200, Marc Haber wrote: Source: mini-buildd Version: 1.0.7 Severity: wishlist Hi, on my installation, the zg-archive-keyring packages do only show up in the test repository. And it looks like there is no easy way to copy them to a different repository other than manual filesystem operations. Is that intended? Is is ok to manually reprepro includedeb the packages, or is there a way to do so via the web interface? currently, the intended workflow is to just click on the Keyring Packages button again if, for example, you created a new repo. This builds new keyring packages for all repos. Fwiw, there is also a helper script (in examples) to get the keyring packages bulk-migrated to stable once this is done. There is definitely space here to make this much more user-friendly eventually... Hth! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790292: Please outline an import procedure of a 0.9 installation
Hi Marc, On Sa, 2015-06-27 at 23:23 +0200, Marc Haber wrote: (...) If I recall correctly, mini-buildd 0.8 did not use reprepro, and the reprepro backend was only introduced in mini-buildd 0.9. If that is correct, I fully understand why the update procedure from 0.8x outlined in the Admin Guide, using the import-08x script does not work for my 0.9 installation. yes, I fear that's so. I happen to have an old 0.9 installation, and would like to know how to get my old packages imported into the new 1.0.7 installation. The reprepro home was moved from $HOME/rep to HOME/repositories/REPOID, and the new 1.0 fully ignores what was in the old repositories. From looking at the import-08x script, which only seems to do the import into reprepro, there is no need to put the package in some mini-buildd database. If that is correct: Is it possible to pull in the old repository via reprepro's Mirroring / Updating mechanism (see /usr/share/doc/reprepro/manual.html) or would you recommend adapting import-08x to import-09x iterating through all source and binary packages to manually poke them into the new reprepro structure? Ftr, as a general notion, mini-buildd is slave to the reprepro database; it does not store any package information by itself (albeit some last builds/last packages data that is used for informational purposes only). So basically, any manual *package* manipulation using reprepro should be no (technical) problem at all, giving you some options. Maybe some remarks to the import-08x script: As 0.8.x (i.e., mini-dinstall) allowed multiple versions per distribution it iterates over them, and also sorts them by version to get the rollback dists right. In your situation you might simplify your import procedure by just discarding the rollback distributions (chances are, btw, that your 0.9 repo does not have rollback dists at all). I have never used the Mirroring / Updating feature of reprepro myself; form the manual however I assume this requires changing the reprepro config of mini-buildd manually, so I would rather not recommend this. Otoh, if you know that feature very well and want to use it (else your toes curl), and I am correct that it only requires an *additional* config file updates and the auto-generated config files are not touched, and doing some sort of one-time-update with mini-buildd stopped -- I think this will also work fine. mini-buildd will of course, happily discard all your local config changes eventually. uff, hope this helps at all ;). I guess there is no alternative to some dry testing until you find the method you prefer... S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790129: please add the possibility to allow a regular user to remove packages
Hi Marc, On Sa, 2015-06-27 at 21:11 +0200, Marc Haber wrote: (...) Currently, mini-buildd merely uses the django user management as-is, as it comes for free, using the existing user/staff/superuser flags to have some privilege handling for the API calls. Not a lot of extra code needed. But there are already fine grained privilieges for other API calls? no. The API calls currently have user/staff/superuser thing. I have already added a patch (will be in 1.0.8) so one can actually see the auth level for each API call -- for both, 'mini-buildd-tool --help' and in the web interface. This should make things clearer. Hth! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790128: please give reject reason in web interface
Hi Marc, On Sa, 2015-06-27 at 15:23 +0200, Marc Haber wrote: Hi! When mini-buildd does an early reject of a packeg, for example with REJECTED (sid-zg-experimental): ser2net 2.9.1-1~zgSID+0: Missing file +ser2net_2.9.1.orig.tar.gz' neither in upload, nor in pool (use '-sa' for uploads with new upstream) that error message does not seem to be visible in the web interface. hovering over the Status with the mouse shows the error message in the web interface. Hth, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790129: please add the possibility to allow a regular user to remove packages
Hi Marc, On Sa, 2015-06-27 at 15:28 +0200, Marc Haber wrote: (..) when a normal user tries to remove a package from a repository, the error message is 401 Unauthorized: API: 'remove': Needs superuser login. Please consider adding a user permission to do so, so that mini-buildd can be configured so that normal users can remove packages. you can already achieve this by giving a normal user the superuser flag (via the django admin interface). There is also the staff status, giving a user some more rights -- but not to remove packages. I actually deliberately moved that from 'staff' to 'superuser' in 1.0.4, as removing packages is (hardly needed) and potentially dangerous. Hth! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790113: please clarify in docs wether scp to /var/lib/mini-buildd/incoming would be ok as well
Hi Ho again, On Sa, 2015-06-27 at 12:49 +0200, Marc Haber wrote: Source: mini-buildd Version: 1.0.7 Severity: wishlist Hi, for historic reasons, using ftp makes my toes curl. Please clarify in documentation whether it is ok to scp incoming packages to /var/lib/mini-buildd/incoming instead of using the built-in ftp service. mini-buildd acts on incoming ftp connections, so no, just [s]cp'ing to incoming does not do the trick. The Quickstart however now comes with a hint how to set up a ssh wrapper. Hth! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790129: please add the possibility to allow a regular user to remove packages
On Sa, 2015-06-27 at 17:54 +0200, Marc Haber wrote: (...) you can already achieve this by giving a normal user the superuser flag (via the django admin interface). Yes, but that would give the user many more privileges. I currently cannot explain why, but my feeling says that this shuld be granularily grantable. yes. Currently, mini-buildd merely uses the django user management as-is, as it comes for free, using the existing user/staff/superuser flags to have some privilege handling for the API calls. Not a lot of extra code needed. Having a more fine grained user role concept is actually on my roadmap http://mini-buildd.installiert.net/blog/devtodo_201502.html (at least hidden somewhere there), as this has been discussed before (a lot more wishes were involved ;). I.e., this is a bigger dev task with (as of now) unclear scope, and most likely not coming any time soon. Let's keep this Debian-documented as wishlist, maybe retitling Please add more finegrained user privileges? Hth, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789103: does not listen on IPv6
Hi Marc, On Mi, 2015-06-24 at 18:41 +0200, Marc Haber wrote: (...) the notation :::8066 may be used for both mini-buildd/http via --httpd-bind option (use dpkg-reconfigure) That question does not seem to be asked in the debconf scripts of 1.0.7 (installed after a complete purge of mini-buildd, mini-buildd-common and all dependencies): yep, this is not asked for explicitly, however... [4/462]mh@spinturn:~$ sudo env DEBIAN_FRONTEND=readline dpkg-reconfigure mini-buildd -plow mini-buildd Configuring mini-buildd --- (...) Please add any mini-buildd command line options you would like to use (mini-buildd --help gives a list of available options). The only options really recommended for use here are -v/--verbose to increase the log level or -q/--quiet to decrease it. Extra options: ...this is the place where to put this; 'mini-buildd --help' gives you all the other options you may add here. Arguably, --httpd-bind is also a useful option here, and maybe should be documented in the debconf description. Hth! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789154: add uploader fails
Hi Marc, On Do, 2015-06-18 at 13:20 +0200, Marc Haber wrote: (...) first thanks for the mini-buildd rewrite. This looks vastly better than the 0.9 series, especially regarding documentation. thx, but it's obviously still lacking. However, the quickstart does not explain the role of an uploader too well. Checking and activating the default uploader didn't work (the text looked like some variable wasn't initialized), so I deleted it. Adding a new uploader fails. I exported the public key: yep, that isn't really well explained. You should not delete (or add) Uploader instances yourself, they are created automatically for each user (this is why, in the admin overview page, I patched away the add button, but it's not really feasable to patch it away from the whole django admin thing ;). I have updated the Quickstart to hopefully make this more understandable. See http://mini-buildd.installiert.net/doc/quickstart.html#epilogue http://mini-buildd.installiert.net/doc/quickstart.html#authorize-yourself-to-do-package-uploads for a preview. [2/391]mh@spinturn:~$ sudo -H -u mini-buildd gpg --list-secret-keys (...) Clicking Save leads to an 500 Internal Server Error: Sorry, something went wrong without any further explanation. Just ftr, when you set something like this (via dpkg-reconfigure) --verbose --verbose --debug=exception,http,webapp I am pretty sure you get a django trace with something moaning about missing user id or such. What did I do wrong? Don't add or delete Uploader instances. Could you check if that (newly described) workflow works for a newly created user? Thx, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789103: does not listen on IPv6
Hi Marc, On Mi, 2015-06-17 at 23:09 +0200, Marc Haber wrote: (...) mini-buildd does listen on 0.0.0.0:8066 which makes it unreachable if the system in question does not have routed IPv4. the notation :::8066 may be used for both mini-buildd/http via --httpd-bind option (use dpkg-reconfigure) as well as for the internal ftp daemon (configurable in the Daemon instance). I will change the defaults to that (dual stack) configuration in 1.1.x. ... But good you pointed this out, as actually trying --httpd-bind, it did not work any more -- a bug in a precheck helper I invented later (just comment .*test_bind in /usr/sbin/mini-buildd). Fix pending... Thx! Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789089: set-admin-password does not work
Hi Marc, On Mi, 2015-06-17 at 19:20 +0200, Marc Haber wrote: this happens after trying to install mini-buildd 1.0.6: mh@spinturn:~$ dpkg --list mini-buildd Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= iF mini-buildd1.0.6all minimal build daemon - daemon mh@spinturn:~$ sudo dpkg --configure -a Setting up mini-buildd (1.0.6) ... addgroup: The group `mini-buildd' already exists as a system group. Exiting. usermod: no changes usermod: no changes The user `mini-buildd' is already a member of `sbuild'. Setting admin password...Traceback (most recent call last): File /usr/sbin/mini-buildd, line 16, in module import daemon.pidlockfile File /usr/lib/pymodules/python2.7/daemon/pidlockfile.py, line 33, in module class PIDLockFile(LinkFileLock, object): TypeError: Error when calling the metaclass bases function() argument 1 must be code, not str alas ;). This error has been brought in by new python-lockfile (which is used by python-daemon). What's more, a new python-daemon with incompatible API changes is coming (currently stuck in NEW). So as a quick answer: under sid/stretch, downgrading python-lockfile to the jessie/stable version would fix it -- and it would also proof that this is actually your problem. Ben already provided patches for mini-buildd for the new python-daemon API; this will be coming soon and will eventually fully fix this problem. Sorry for the inconvenience ;), Fwiw, I will continue to provide jessie backports for 1.0.x, and I really recommend using that for production use. Hth! Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785712: mini-buildd: Cannot start daemon
Hi, On Di, 2015-05-19 at 21:10 +0800, ChangZhuo Chen wrote: (...) I cannot start the daemon in web interface. It always shows the following messages: Daemon is deactivated (won't start). Please (re)configure your instance as superuser. 405 Method Not Allowed: API call error: Could not start Daemon (check logs and messages). The following is systemd log: czchen@mystra:~% systemctl status -l mini-buildd ● mini-buildd.service - LSB: Start mini-buildd daemon Loaded: loaded (/etc/init.d/mini-buildd) Active: active (running) since Tue 2015-05-19 20:59:26 CST; 9min ago CGroup: /system.slice/mini-buildd.service └─7106 /usr/bin/python /usr/sbin/mini-buildd --verbose --pidfile=/var/lib/mini-buildd/.mini-buildd.pid May 19 21:06:40 mystra mini-buildd[7106]: mini_buildd.misc (0564): INFO: Calling: gpg --homedir=/var/lib/mini-buildd/.gnupg --display-charset=UTF-8 --batch --list-secret-keys --with-fingerprint --with-colons May 19 21:06:40 mystra mini-buildd[7106]: mini_buildd.misc (0564): INFO: Calling: gpg --homedir=/var/lib/mini-buildd/.gnupg --display-charset=UTF-8 --batch --list-secret-keys --with-fingerprint --with-colons May 19 21:06:40 mystra mini-buildd[7106]: mini_buildd.models.base (0037): ERROR : Ignoring unpickling error: May 19 21:06:40 mystra mini-buildd[7106]: mini_buildd.models.base (0037): ERROR : Ignoring compat unpickling error: May 19 21:06:40 mystra mini-buildd[7106]: mini_buildd.daemon (0037): WARNING : Error adding persisted last builds/packages (ignoring): 'NoneType' object is not iterable May 19 21:06:40 mystra mini-buildd[7106]: mini_buildd.views(0077): INFO: Checking daemon (force=False). [daemon:488] May 19 21:06:40 mystra mini-buildd[7106]: mini_buildd.models.base (0077): ERROR : check failed: mystra: Serving 0 repositories, 0 chroots, using 0 remotes: Can't check removed or changed object (run 'prepare' first): mystra: Serving 0 repositories, 0 chroots, using 0 remotes [base:364] May 19 21:06:40 mystra mini-buildd[7106]: mini_buildd.views(0077): WARNING : Daemon is deactivated (won't start). Please (re)configure your instance as superuser. [daemon:494] May 19 21:06:40 mystra mini-buildd[7106]: mini_buildd.views(0037): ERROR : API call error: Could not start Daemon (check logs and messages). May 19 21:06:40 mystra mini-buildd[7106]: mini_buildd.views(0077): ERROR : 405 Method Not Allowed: API call error: Could not start Daemon (check logs and messages). [views:55] for me this looks like it's actually not configured. Please go through the Quickstart http://mini-buildd.installiert.net/doc/quickstart.html#administrator-s-quickstart http://localhost:8066/doc/quickstart.html#administrator-s-quickstart or alternatively, for a test drive, use ? /usr/share/doc/mini-buildd/examples/auto-setup Hth! Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785785: mini-buildd: fails to upgrade: “The group `mini-buildd' already exists as a system group”
Hi Ben, On Mi, 2015-05-20 at 17:42 +1000, Ben Finney wrote: Package: mini-buildd Version: 1.0.6 Severity: normal Dear Maintainer, Version 1.0.6 fails to configure when upgrading from Jessie: Setting up mini-buildd (1.0.6) ... addgroup: The group `mini-buildd' already exists as a system group. Exiting. usermod: no changes usermod: no changes The user `mini-buildd' is already a member of `sbuild'. The package is then left in a half-configured state. hmm; you always get the hint The user `mini-buildd' is already a member of `sbuild'. when updating mini-buildd, so that is most likely not the source of your issue. FWIW: We are talking about an upgrade of a system from jessie to stretch/unstable? Thx, Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785785: mini-buildd: fails to upgrade: “The group `mini-buildd' already exists as a system group”
Hi Ben, On So, 2015-05-24 at 22:28 +1000, Ben Finney wrote: On 24-May-2015, Stephan Sürken wrote: FWIW: We are talking about an upgrade of a system from jessie to stretch/unstable? That's right, the upgrade was from Jessie to Stretch. The upgrade of ‘mini-buildd’ was from 1.0.5 to 1.0.6. I just tried exactly that, with no issues. Could you please provide more information on this? The complete output of s.th. like apt-get install mini-buildd on your system could be a starter ;). Thx! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776901: python-django-extensions: new upstream version available and python3 support
Hi Brian, On Mi, 2015-02-04 at 12:04 +1100, Brian May wrote: On 4 February 2015 at 09:13, Brian May b...@debian.org wrote: Do you have any objections to making this package maintained by the Debian Python Modules team? not at all, sounds like a good idea. Attached is my proposed changes to the debian directory. (I have made these changes to git also but not pushed yet) Great, just go ahead and push. Thx! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775363: python-django-registration: Uses wrong uid hash (uidb36 vs. uidb64) in auth_url.py for django = 1.6 (breaks reset password URLs)
Package: python-django-registration Version: 1.0+dfsg-2 Severity: normal Hi, in auth_url.py, this line url(r'^password/reset/confirm/(?Puidb36[0-9A-Za-z]+)-(?Ptoken.+)/$', should be replaced by this url(r'^password/reset/confirm/(?Puidb64[0-9A-Za-z]+)-(?Ptoken.+)/$', to make reset password URLs work again (if the app uses auth_url.py). Users experiencing this bug right now may just add this new line to their patterns _before_ including auth_url.py from p-d-registration. Afaiu, django has changed to use base64 starting with django-1.6; as the auth_url.py already includes code only working = 1.6, no other compat needs to be applied imho. [This is mostly for documentation purposes; hopefully I will add the fix myself ebentually ;). ] Hth, Stephan -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages python-django-registration depends on: ii libjs-sphinxdoc 1.2.3+dfsg-1 ii python 2.7.8-2 ii python-django1.7.1-1 python-django-registration recommends no packages. python-django-registration suggests no packages. -- 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
Bug#774078: does not cleanly upgrade if /home and /var are different filesystems
On Fr, 2015-01-02 at 08:48 +0100, Marc Haber wrote: On Tue, Dec 30, 2014 at 06:59:19PM +0100, Stephan Sürken wrote: That said ;), the final problem that (in the end) broke things with _your_ setup imho was the lack of space in /var, as usermod supports moving across filesystems just fine. Yes, but I don't think that a user must expect multiple gigabytes (~ 6 in my case) to be moved to /var during a package update. Sure, I was not arguing against that ;). The fix now always prefers the home of the actually existing mini-buildd user, even over a previously set debconf value. As an extra, this also handles manual (not via debconf) changes to the mini-buildd user gracefully. Such a move/copy on upgrade could now only happen in case the debconf value is explicitly changed. Hth, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774078: does not cleanly upgrade if /home and /var are different filesystems
Hi Marc, On So, 2014-12-28 at 14:49 +0100, Marc Haber wrote: Package: mini-buildd Version: 1.0.5 Severity: important (...) In my opinion, mini-buildd should not try to move its home directory on a package upgrade. It's fine to use the new /var/lib location for new installs, but an upgrade script cannot foresee possible pitfalls in moving the home directory (and, frankly, yours doesn't even try to check). yes, what you describe is actually intended behaviour ;); more precisely that code should only actually do something when the administrator explicitly changes the path via debconf. I am currently guessing that the debconf value did not exist yet in 0.9.5, and the postinstall does not handle this situation gracefully, but using the default path. Will have a look this afternoon... Thx, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774078: does not cleanly upgrade if /home and /var are different filesystems
Hi, On Di, 2014-12-30 at 11:48 +0100, Stephan Sürken wrote: Hi Marc, (...) Will have a look this afternoon... first, jftr, version 0.9.5 is ancient, has only been in experimental, and is not supported; only upgrades 0.8.x-1.0.x are really supported. However, it should of course work anyway, and furthermore package-wise and for this problem, 0.9.5 is very much like 0.8.x; so this can indeed be a problem for things I actually support. So this is actually a problem that can arise when upgrading from 0.8.x. That said ;), the final problem that (in the end) broke things with _your_ setup imho was the lack of space in /var, as usermod supports moving across filesystems just fine. mini-buildd does have the ability to set the home dir via debconf, so I need some automation going on there to make this work automatically. The actual bug here imho is assuming to use the new default path -- in case none has been set yet -- even so a user already exists. It should always use the path of an existing user, prior to anything else. Atm, you may test the fix with the latest stable snapshot from here http://mini-buildd.installiert.net/ or alternatively rebuild via git branch 1.0.x. Hth! Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771676: mate-panel: Desktop launchers drag-and-drop-copied to panel vanish silently when removed from desktop
Package: mate-panel Version: 1.8.1+dfsg1-2 Severity: minor Tags: upstream Dear maintainers, doing this 1. Create some launcher on the desktop (RM-Create Launcher) 2. Copy launcher to some panel (Drag-And-Drop) 3. Remove launcher from desktop 4. Logout+Login (so mate-panel is refreshed) silently leaves the user with no launcher visible any more in the panel. It's still in the panel's config though; (for example) resurrecting the Desktop Launcher from the Trash makes it visible again after Logout/Login. There is no way to notice for the user (i.e., via the MATE desktop) that such a broken panel item ist still configured. The only way to see is via the user's .xsession-errors file (Unable to open desktop file...). Imho, one of the following simple solutions would fix this: - Just show the broken items in the panel anyway, so the user can deal with them. - Add a pop-up whether the user wants to remove the broken items (like for broken panel apps). Furthermore, when Drag-and-drop the desktop launcher to the panel, it shows a '+', which should read 'copy', but this obviously is not a real copy -- a different issue (this is about error handling only), but related. Thx! Stephan -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16-0.bpo.3-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 mate-panel depends on: ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1 ii libatk1.0-0 2.14.0-1 ii libc62.19-13 ii libcairo21.14.0-2.1 ii libcanberra-gtk0 0.30-2.1 ii libcanberra0 0.30-2.1 ii libdbus-1-3 1.8.12-1 ii libdbus-glib-1-2 0.102-1 ii libdconf10.22.0-1 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-2 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.1-1 ii libgtk2.0-0 2.24.25-1 ii libice6 2:1.0.9-1 ii libmate-desktop-2-17 1.8.1+dfsg1-2 ii libmate-menu21.8.0-5 ii libmate-panel-applet-4-1 1.8.1+dfsg1-2 ii libmateweather1 1.8.0-2 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-01.36.8-3 ii librsvg2-2 2.40.5-1 ii libsm6 2:1.2.2-1 ii libstartup-notification0 0.12-4 ii libwnck222.30.7-2 ii libx11-6 2:1.6.2-3 ii libxau6 1:1.0.8-1 ii libxrandr2 2:1.4.2-1+b1 ii mate-desktop 1.8.1+dfsg1-2 ii mate-menus 1.8.0-5 ii mate-panel-common1.8.1+dfsg1-2 ii mate-polkit 1.8.0+dfsg1-4 ii menu-xdg 0.5 ii python 2.7.8-2 mate-panel recommends no packages. mate-panel suggests no packages. -- 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
Bug#770333: xdg-utils: xdg-email Does not work under MATE desktop (breaks 'mailto'-URLs in web browsers)
Package: xdg-utils
Version: 1.1.0~rc1+git20111210-7.1
Severity: normal
Tags: patch
Hi,
xdg-email does not work under the MATE desktop:
---
? xdg-email mailto:t...@test.com;
xdg-email: no method available for opening 'mailto:t...@test.com'
---
It seems the script already detects MATE (DE=mate) alright, but
has no action for it. Just using just the gnome action for MATE
works for me:
--- /usr/bin/xdg-email 2014-04-23 20:23:32.0 +
+++ /home/absurd/xdg-email 2014-11-20 14:09:05.755645745 +
@@ -886,7 +886,7 @@
open_kde ${mailto}
;;
-gnome)
+gnome|mate)
open_gnome ${mailto}
;;
---
Again, this worked for me, but not sure if that is a correct
patch.
Furthermore, I am inclined to think that the script should not
fail on unknown desktops (in the last switch case), but rather
use the fallback in such a case.
Fwiw, at least 'chromium' uses xdg-email directly; as such,
mailto:-URLs in (at least) chromium browser are broken under
MATE.
Thx!
Stephan
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16-0.bpo.3-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
xdg-utils depends on no packages.
Versions of packages xdg-utils recommends:
pn libfile-mimeinfo-perl none
pn libnet-dbus-perl none
pn libx11-protocol-perl none
pn x11-utils none
pn x11-xserver-utils none
Versions of packages xdg-utils suggests:
pn gvfs-bin 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
Bug#769949: mini-buildd: Wheezy chroot fails to activate due to broken dev/shm symlink
Hi Eldon, On Mo, 2014-11-17 at 13:17 -0700, Eldon Koyle wrote: Package: mini-buildd Version: 1.0.5 Severity: normal Dear Maintainer, I am unable to get a fresh wheezy LVM image to activate. For some reason, dev/shm in the chroot is a broken symlink to /var/run/shm or /run/shm (don't remember which). Various ubuntu releases seem to be having the same issue. If I mount the base chroot, delete the dev/shm symlink, and create an empty dev/shm directory the activation step will then complete successfully. I think this http://mini-buildd.installiert.net/doc/admin.html?highlight=systemd#id5 may be your problem. Could you please try the workaround described there? If so, It's actually this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728096 bug... Thx! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768046: reprepro: 'includedsc' fails for native packages with 'debian/' being a symlink
Package: reprepro Version: 4.16.0-1 Severity: normal Hi Bernhard, with a Debian native package having a setup like (for example) so debian - debian-wheezy debian-squeeze/ debian-wheezy/ , i.e., 'debian/' being a symlink, reprepro fails to find 'debian/control', and finally fails with --- No section and no priority for 'PACKAGE', skipping. There have been errors! --- This is due to 'sourceextraction.c: parse_tarfile()', which iterates through all archive entries, and will never find debian/control as archive member string. I.e., iterating of libarchive entries, you only get debian debian-wheezy/control in this case. Maybe some extra code when debian/ is a symlink may help here, in that loop. Of course this (i.e., using a symlink here) is not a standard or desireable setup; however, other Debian tools just work find with such a setup, and I don't know of any documented restrictions -- so I think this should be fixed in reprepro. Thanks! Stephan -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16-0.bpo.2-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 reprepro depends on: ii libarchive13 3.1.2-9 ii libbz2-1.0 1.0.6-7 ii libc62.19-12 ii libdb5.3 5.3.28-6 ii libgpg-error01.17-2 ii libgpgme11 1.5.1-6 ii liblzma5 5.1.1alpha+20120614-2 ii pinentry-curses 0.8.3-2 ii zlib1g 1:1.2.8.dfsg-2 Versions of packages reprepro recommends: ii apt 1.0.9.3 Versions of packages reprepro suggests: ii gnupg-agent 2.0.26-3 pn inoticoming none pn lzip 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
Bug#749588: mini-buildd: sudo can't be used in qemu-user build chroots
Hi Tzafrir, On Mi, 2014-05-28 at 15:57 +0300, Tzafrir Cohen wrote: (...) I had to re-create chroots on my server a while ago. I noticed that armhf jobs (that are the only ones I send to chroots that user qemu-user-static) failed. The error is because copying of the setup files failed. Such as: sudo cp /srv/mini-buildd/var/spool/e95cb596646d2e6db6a29efd0c8ed598ce96a19a/apt_sources.list /etc/apt/sources.list ── sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges? E: Command 'sudo cp /srv/mini-buildd/var/spool/e95cb596646d2e6db6a29efd0c8ed598ce96a19a/apt_sources.list /etc/apt/sources.list' failed to run. could you please retry if 1.0.5 fixes your problems? Afaiu, this should be gone now with the sudo workaround removed. Thanks! Stephan
Bug#767024: tracker.debian.org: Reports wrong new upstream for a native package
Package: tracker.debian.org Severity: normal Dear maintainers, strangely, (old and new) PTS report a new upstream for the mini-buildd package: https://tracker.debian.org/pkg/mini-buildd First, it reports '1.0.0~alpha.8' as new although '1.0.5' is currently in unstable. Second, it imho should not report new upstream versions anyway as it is a native package. Or is there anything I can (need to?) do in the source package to set this straight? Thx! Stephan -- System Information: Debian Release: jessie/sid Architecture: amd64 (x86_64) Kernel: Linux 3.16-0.bpo.2-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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766197: [buildd-tools-devel] Bug#766197: libsbuild-perl: Should depend on dpkg-dev = 1.17
On Mi, 2014-10-22 at 03:26 +0100, Wookey wrote: +++ Stephan Sürken [2014-10-21 13:14 +]: Package: libsbuild-perl Version: 0.65.0-1 Severity: wishlist Dear maintainers, sbuild does not work any more with dpkg-dev 1.17. Can you be a bit more specific about 'does not work'? Sorry (was to lazy to re-create the setup...). It fails on some perl import thingy only available since 1.17..mom... --- ? sbuild deps_concat is not exported by the Dpkg::Deps module Can't continue after import errors at /usr/share/perl5/Sbuild/Build.pm line 40. BEGIN failed--compilation aborted at /usr/share/perl5/Sbuild/Build.pm line 40. Compilation failed in require at /usr/bin/sbuild line 40. BEGIN failed--compilation aborted at /usr/bin/sbuild line 40. --- I.e., if you do a no-changes port (or just install the sid version) of sbuild to wheezy, you get this. Porting/installing dpkg-dev 1.17.0 to wheezy yet again makes it happy. Hth! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765695: hardcoded libeatmydata path now is wrong
Hi Mattia, On Fr, 2014-10-17 at 14:01 +0200, Mattia Rizzolo wrote: Package: mini-buildd Version: 1.0.4 The new upload of libeatmydata changed the position of the actual library (due to now supporting Multi-Arch). yes, thanks. I also already noticed that ;). You appear to be using /usr/lib/libeatmydata/libeatmydata.so directly: http://sources.debian.net/src/mini-buildd/1.0.4/mini_buildd/models/repository.py/?hl=417#L417 http://sources.debian.net/src/mini-buildd/1.0.4/mini_buildd/models/repository.py/?hl=432#L432 I don't know what's the purpose of it (given that you don't depends/recommends/suggest eatmydata), but for sure now it'll do just nothing. No, these are snippets for the build chroot's setup, so it actually does something (albeit no more for sid/jessie builds right now). FWIW: I experienced dramatically increased install times on builds without eatmydata and 'aufs' chroots. As 'aufs' is the default, this is the reason why the eatmydata snippet is also per default enabled. Again, this snippet is _not_ hardcoded, rather a hardcoded default. You can change/fix it at any time yourself changing the resp. Distribution instance (chroot setup script). Please set the severity of this bug accordingly. I'd suggest you to just use libeatmydata.so instead of using the full path. Alas, this is no possible. As ye olde eatmydata does not install in standard locations, I needed the full path to make it work. Hth! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765695: hardcoded libeatmydata path now is wrong
On Di, 2014-10-21 at 11:24 +0200, Stephan Sürken wrote: Hi Mattia, (...) I'd suggest you to just use libeatmydata.so instead of using the full path. Alas, this is no possible. As ye olde eatmydata does not install in standard locations, I needed the full path to make it work. ahh, and yes, I am currently thinking about a script goblin similar to that outlined in my bug report... So if you have an idea how to do this (i.e., posix shell snippet run as root, installing _and_ enabling eatmydata, working for all versions of eatmydata) simpler/better, I'd love to hear ;). Thx! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766191: mini-buildd: 'sudo' from sid not upgradeable when /etc/sudoers file is removed
Package: mini-buildd Version: 1.0.4 Severity: normal Within the sudoers chroot workaround (for the former sbuild bug), mini-buildd finally removes /etc/sudoers prior to building. While this is basically fine, newer versions of sudo may fail to upgrade when /etc/sudoers is missing; an upgrade may acually happen in case there is a resp. sudo package update within the (currently one week) period where the base chroots are not checked automatically and hence don't get updated. Workaround is to manually check the resp. chroots, and hence trigger an update, or just wait a wekk :). mini-buildd however should not remove /etc/sudoers, but rather create an empty file. Note that this all is just for compatibility for old-style chroots (with the sudo workaround) from mini-buildd = 1.0.4 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16-0.bpo.2-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 mini-buildd depends on: ii adduser 3.113+nmu3 ii debconf [debconf-2.0] 1.5.53 ii debootstrap 1.0.64 ii devscripts 2.14.10 ii dpkg-dev1.17.19 ii gnupg 1.4.18-4 ii libjs-jquery1.7.2+dfsg-3.2 ii libjs-sphinxdoc 1.2.3+dfsg-1 ii lintian 2.5.28 ii mini-buildd-common 1.0.5~1.gbp4571c5 ii python-cherrypy33.5.0-1 ii python-daemon 1.5.5-1 ii python-django 1.7-3 ii python-django-extensions1.3.10-1 ii python-django-registration 1.0+dfsg-2 ii python-mini-buildd 1.0.5~1.gbp4571c5 ii python-pyftpdlib1.2.0-1 pn python:any none ii reprepro4.16.0-1 ii sbuild 0.65.0-1 ii schroot 1.6.10-1+b1 ih sudo1.8.11p1-2 Versions of packages mini-buildd recommends: ii python-apt 0.9.3.10 Versions of packages mini-buildd suggests: pn binfmt-supportnone ii debootstrap 1.0.64 pn haveged none pn lvm2 none pn qemu-user-static none -- Configuration Files: /etc/default/mini-buildd changed [not included] /etc/sudoers.d/mini-buildd-sudoers [Errno 13] Permission denied: u'/etc/sudoers.d/mini-buildd-sudoers' -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766197: libsbuild-perl: Should depend on dpkg-dev = 1.17
Package: libsbuild-perl Version: 0.65.0-1 Severity: wishlist Dear maintainers, sbuild does not work any more with dpkg-dev 1.17. To document this (and to help with porting), imho we should add dpkg-dev (= 1.17) for libsbuild-perl. Thx! S -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16-0.bpo.2-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 libsbuild-perl depends on: ii adduser 3.113+nmu3 ii apt 1.0.9.3 ii apt-utils 1.0.9.3 ii dctrl-tools 2.23 ii devscripts 2.14.10 ii dpkg-dev1.17.19 ii libdpkg-perl1.17.19 ii libexception-class-perl 1.38-1 ii libfilesys-df-perl 0.92-5+b1 ii libmime-lite-perl 3.030-2 ii perl5.20.1-2 ii perl-modules [libio-zlib-perl] 5.20.1-2 ii schroot 1.6.10-1+b1 ii ssmtp [mail-transport-agent]2.64-8 libsbuild-perl recommends no packages. libsbuild-perl suggests no packages. -- 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
Bug#765641: mini-buildd: Default setup and examples don't work with new eatmydata in sid
Package: mini-buildd
Version: 1.0.5~1.gbpb2a4a1
Severity: normal
With the new eatmydata 82 now in sid, the examples and the
default setup in Distributions do no longer work for sid (and
maybe soon jessie) builds.
This is due to the new so-file location; this should be determined automatically
for the default snippets and examples.
To fix this now, update the resp part in the custom chroot setup
script of a Distribution to something like
---
# Old style
EATMYDATA_SO=$(dpkg -L eatmydata | grep 'libeatmydata.so$')
if [ -z ${EATMYDATA_SO} ]; then
# New style (eatmydata-82)
EATMYDATA_SO=$(dpkg -L libeatmydata1 | grep 'libeatmydata.so$')
fi
printf ${EATMYDATA_SO} /etc/ld.so.preload
---
-- System Information:
Debian Release: jessie/sid
Architecture: amd64 (x86_64)
Kernel: Linux 3.16-0.bpo.2-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 mini-buildd depends on:
ii adduser 3.113+nmu3
ii debconf [debconf-2.0] 1.5.53
ii debootstrap 1.0.63
ii devscripts 2.14.10
ii dpkg-dev1.17.18
ii gnupg 1.4.18-4
ii libjs-jquery1.7.2+dfsg-3.2
ii libjs-sphinxdoc 1.2.3+dfsg-1
ii lintian 2.5.28
ii mini-buildd-common 1.0.5~1.gbpb2a4a1
ii python-cherrypy33.5.0-1
ii python-daemon 1.5.5-1
ii python-django 1.7-3
ii python-django-extensions1.3.10-1
ii python-django-registration 1.0+dfsg-2
ii python-mini-buildd 1.0.5~1.gbpb2a4a1
ii python-pyftpdlib1.2.0-1
pn python:any none
ii reprepro4.16.0-1
ii sbuild 0.64.3-2
ii schroot 1.6.10-1+b1
ii sudo1.8.11p1-1
Versions of packages mini-buildd recommends:
ii python-apt 0.9.3.10
Versions of packages mini-buildd suggests:
pn binfmt-supportnone
ii debootstrap 1.0.63
pn haveged none
pn lvm2 none
pn qemu-user-static none
-- Configuration Files:
/etc/default/mini-buildd changed [not included]
/etc/sudoers.d/mini-buildd-sudoers [Errno 13] Permission denied:
u'/etc/sudoers.d/mini-buildd-sudoers'
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765378: mini-buildd: [django 1.7] Uses user profiles which have been removed
Package: mini-buildd Version: 1.0.5~1.gbp391e08 Severity: important django 1.7 deprecates user profiles for good. When used with django 1.7, you will see these types of warnings indicating the problem: --- User 'admin' does not have an uploader profile (deliberately removed?) --- So mini-buildd still runs, but this effectively breaks upload auth via user profiles. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16-0.bpo.2-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 mini-buildd depends on: ii adduser 3.113+nmu3 ii debconf [debconf-2.0] 1.5.53 ii debootstrap 1.0.63 ii devscripts 2.14.9 ii dpkg-dev1.17.18 ii gnupg 1.4.18-4 ii libjs-jquery1.7.2+dfsg-3.2 ii libjs-sphinxdoc 1.2.3+dfsg-1 ii lintian 2.5.28 ii mini-buildd-common 1.0.5~1.gbp391e08 ii python-cherrypy33.5.0-1 ii python-daemon 1.5.5-1 ii python-django 1.7-2 ii python-django-extensions1.3.10-1 ii python-django-registration 1.0+dfsg-2 ii python-mini-buildd 1.0.5~1.gbp391e08 ii python-pyftpdlib1.2.0-1 pn python:any none ii reprepro4.16.0-1 ii sbuild 0.64.3-2 ii schroot 1.6.10-1+b1 ii sudo1.8.11p1-1 Versions of packages mini-buildd recommends: ii python-apt 0.9.3.10 Versions of packages mini-buildd suggests: pn binfmt-supportnone ii debootstrap 1.0.63 pn haveged none pn lvm2 none pn qemu-user-static none -- Configuration Files: /etc/default/mini-buildd changed [not included] /etc/sudoers.d/mini-buildd-sudoers [Errno 13] Permission denied: u'/etc/sudoers.d/mini-buildd-sudoers' -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764380: A closer look
Hi Stuart, thanks for pointing to the commit. I had a closer look; it's this compat include --- try: from StringIO import StringIO BytesIO = StringIO except ImportError: from io import BytesIO, StringIO --- that previously made it work. Using io.open() implicitly makes the split_gpg_and_payload produce unicode strings. Then finally code like this --- io.BytesIO().write(b\n.join([uunicode string])) --- is run (and fails). Fwiw, for python3 split_gpg_and_payload implicitly produces 'bytes', and everything works fine. Not really sure though what a good fix could be ;). Thx, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764736: mini-buildd: Web frontend's user registration broken (python-registration)
Package: mini-buildd Version: 1.0.4 Severity: normal Hi Maintainer-Schlingel, due to incompatibities brought in by some new version of django, some parts (i.e., at least reset password and change password) of the user registration are broken (HTTP 500). Hth, S -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16-0.bpo.2-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 mini-buildd depends on: ii adduser 3.113+nmu3 ii debconf [debconf-2.0] 1.5.53 ii debootstrap 1.0.63 ii devscripts 2.14.7 ii dpkg-dev1.17.16 ii gnupg 1.4.18-4 ii libjs-jquery1.7.2+dfsg-3.2 ii libjs-sphinxdoc 1.2.3+dfsg-1 ii lintian 2.5.28 ii mini-buildd-common 1.0.5~1.gbp391e08 ii python-cherrypy33.5.0-1 ii python-daemon 1.5.5-1 ii python-django 1.7-2 ii python-django-extensions1.3.10-1 ii python-django-registration 1.0+dfsg-2 ii python-mini-buildd 1.0.5~1.gbp391e08 ii python-pyftpdlib1.2.0-1 pn python:any none ii reprepro4.16.0-1 ii sbuild 0.64.3-2 ii schroot 1.6.10-1+b1 ii sudo1.8.10p3-1 Versions of packages mini-buildd recommends: ii python-apt 0.9.3.10 Versions of packages mini-buildd suggests: pn binfmt-supportnone ii debootstrap 1.0.63 pn haveged none pn lvm2 none pn qemu-user-static none -- Configuration Files: /etc/default/mini-buildd changed [not included] /etc/sudoers.d/mini-buildd-sudoers [Errno 13] Permission denied: u'/etc/sudoers.d/mini-buildd-sudoers' -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764380: Came with 0.1.23
Hi, fwiw, this behaviour was introduced with 0.1.23. Versions 0.1.23 work fine (i.e., it's not a python update that introduced this). Hth! S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764595: mini-buildd: Can't GPG-verify changes files (since python-debian-0.1.23)
Package: mini-buildd
Version: 1.0.4
Severity: grave
Justification: renders package unusable
A reminder to myself, and for those wondering...
grave: As this basically prevents any package building.
Will be fixed asap, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764380
Workarounds:
(1)
Downgrade to python-debian 0.1.23
(2)
diff --git a/mini_buildd/ftpd.py b/mini_buildd/ftpd.py
index d763b32..46769a7 100644
--- a/mini_buildd/ftpd.py
+++ b/mini_buildd/ftpd.py
@@ -42,7 +42,7 @@ class Incoming(object):
if cls.is_changes(changes_file):
LOG.debug(Checking: {c}.format(c=changes_file))
try:
-for fd in
debian.deb822.Changes(mini_buildd.misc.open_utf8(changes_file)).get(Files,
[]):
+for fd in debian.deb822.Changes(open(changes_file,
r)).get(Files, []):
valid_files.append(fd[name])
LOG.debug(Valid: {c}.format(c=fd[name]))
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16-0.bpo.2-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 mini-buildd depends on:
ii adduser 3.113+nmu3
ii debconf [debconf-2.0] 1.5.53
ii debootstrap 1.0.63
ii devscripts 2.14.7
ii dpkg-dev1.17.16
ii gnupg 1.4.18-4
ii libjs-jquery1.7.2+dfsg-3.2
ii libjs-sphinxdoc 1.2.3+dfsg-1
ii lintian 2.5.28
ii mini-buildd-common 1.0.4
ii python-cherrypy33.5.0-1
ii python-daemon 1.5.5-1
ii python-django 1.7-2
ii python-django-extensions1.3.10-1
ii python-django-registration 1.0+dfsg-2
ii python-mini-buildd 1.0.4
ii python-pyftpdlib1.2.0-1
pn python:any none
ii reprepro4.16.0-1
ii sbuild 0.64.3-2
ii schroot 1.6.10-1+b1
ii sudo1.8.10p3-1
Versions of packages mini-buildd recommends:
ii python-apt 0.9.3.10
Versions of packages mini-buildd suggests:
pn binfmt-supportnone
ii debootstrap 1.0.63
pn haveged none
pn lvm2 none
pn qemu-user-static none
-- Configuration Files:
/etc/default/mini-buildd changed [not included]
/etc/sudoers.d/mini-buildd-sudoers [Errno 13] Permission denied:
u'/etc/sudoers.d/mini-buildd-sudoers'
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764617: mini-buildd: Chroot build setup broken (since sbuild-0.63.3)
Package: mini-buildd Version: 1.0.4 Severity: grave Justification: renders package unusable FTR: In sbuild-0.63.3 this bug has been fixed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607228 Unfortunately, the workaround in mini-buildd for that bug now actually breaks mini-buildd now the bug is fixed ;). Upcoming release will have the workaround removed, of course, and eventually close this. In the meantime, the workaround to make the obsoleted workaround work again is to install any sbuild 0.63.3. Hth, S -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16-0.bpo.2-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 mini-buildd depends on: ii adduser 3.113+nmu3 ii debconf [debconf-2.0] 1.5.53 ii debootstrap 1.0.63 ii devscripts 2.14.7 ii dpkg-dev1.17.16 ii gnupg 1.4.18-4 ii libjs-jquery1.7.2+dfsg-3.2 ii libjs-sphinxdoc 1.2.3+dfsg-1 ii lintian 2.5.28 ii mini-buildd-common 1.0.4 ii python-cherrypy33.5.0-1 ii python-daemon 1.5.5-1 ii python-django 1.7-2 ii python-django-extensions1.3.10-1 ii python-django-registration 1.0+dfsg-2 ii python-mini-buildd 1.0.4 ii python-pyftpdlib1.2.0-1 pn python:any none ii reprepro4.16.0-1 ii sbuild 0.64.3-2 ii schroot 1.6.10-1+b1 ii sudo1.8.10p3-1 Versions of packages mini-buildd recommends: ii python-apt 0.9.3.10 Versions of packages mini-buildd suggests: pn binfmt-supportnone ii debootstrap 1.0.63 pn haveged none pn lvm2 none pn qemu-user-static none -- Configuration Files: /etc/default/mini-buildd changed [not included] /etc/sudoers.d/mini-buildd-sudoers [Errno 13] Permission denied: u'/etc/sudoers.d/mini-buildd-sudoers' -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764380: python-debian: deb822.Changes() fails with io.open() for signed *.changes (regression)
Package: python-debian Version: 0.1.24 Severity: important Dear maintainers, (s.th. like) this --- files = debian.deb822.Changes(io.open(sys.argv[1], r, encoding=UTF-8)).get(Files, []) --- results in --- Traceback (most recent call last): File ./c.py, line 8, in module files = debian.deb822.Changes(io.open(sys.argv[1], r, encoding=UTF-8)).get(Files, []) File /usr/lib/python2.7/dist-packages/debian/deb822.py, line 1243, in __init__ raw_text.write(b\n.join(gpg_pre_lines)) TypeError: 'unicode' does not have the buffer interface --- on a signed changes file. Just using 'open()' works fine. Not sure if this is not supposed to be used this way (?), but it's definitely a regression (works just fine in wheezy) so code that uses it that way in wheezy will break in jessie. Could you please advice on this -- i.e. is it a bug, or do I need to change my code? Thx! Stephan -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16-0.bpo.2-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-debian depends on: ii python-chardet 2.2.1-2 ii python-six 1.8.0-1 pn python:any none Versions of packages python-debian recommends: ii python-apt 0.9.3.10 Versions of packages python-debian suggests: ii gpgv 1.4.18-4 -- 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
Bug#764380: Attaching sample script and changes
#!/usr/bin/python import sys import io import codecs import debian.deb822 # Fails files = debian.deb822.Changes(io.open(sys.argv[1], r, encoding=UTF-8)).get(Files, []) # Fails #files = debian.deb822.Changes(codecs.open(sys.argv[1], r, encoding=UTF-8)).get(Files, []) # OK #files = debian.deb822.Changes(open(sys.argv[1], r)).get(Files, []) c.changes Description: PGP signature
Bug#757256: [Debian] thrift packaging
Hi László, On Di, 2014-08-19 at 08:39 +0200, László Böszörményi (GCS) wrote: On Mon, Aug 18, 2014 at 1:00 PM, Stephan Sürken stephan.suer...@1und1.de wrote: On Mon, 2014-08-18 at 08:24 +0200, László Böszörményi (GCS) wrote: I'd like to make it monolithic. I don't see the reason for the split. More work to split them, when the language bindings should be the same version anyway. Hmm, exactly my reasoning. While we agree on this, do you know any policy on how this should be handled? Only FTP-Masters need to adjust their data about packages? no, I don't know of any special policy or special best practice for this case. I am guessing the best practical approach is: * Create an new 'ITP: thrift' -- it's a new Debian source package. * Explain that it will obsolete the existing source packages. * Explain that it replaces/continues the existing binary packages. Then upload, and deal/fix things with the ftp masters while it's in NEW. In case there _is_ a special practice for that, FTP-Masters will of course bark at you and give you names ;). A risk we all take... Hth, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757256: [Debian] thrift packaging
Hi László On Mon, 2014-08-18 at 08:24 +0200, László Böszörményi (GCS) wrote: (..) I previously talked to Evan and he eventually RFAd them; the intention was, in a nutshell, that I take them over, make it mono-source package, and add the C++ library package (that's what I need). This is my plan as well. Great! So, what are your intentions here? Are you also going to package the C++ library? Will you also convert this to a monolithic source package? I'd like to make it monolithic. I don't see the reason for the split. More work to split them, when the language bindings should be the same version anyway. Hmm, exactly my reasoning. I would still be willing to take it all over if you are fine with that; alternatively I would be honored to be able to help with/provide the C++ library packaging. I do have some headaches though with the current extra setup, deliberately splitting upstream. I hope I can do most of the work today. Then I can give it to you for testing / review if you are interested. Sure; if you have anything ready before uploading it to experimental/unstable, I could have a look. Again, thanks for packaging it! Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757256: [Debian] thrift packaging
Hi Laszlo, I see you did an ITA on libthrift-java, thrift-compiler and python-thrift. I previously talked to Evan and he eventually RFAd them; the intention was, in a nutshell, that I take them over, make it mono-source package, and add the C++ library package (that's what I need). It seems I idled, and you were faster ;). So, what are your intentions here? Are you also going to package the C++ library? Will you also convert this to a monolithic source package? I would still be willing to take it all over if you are fine with that; alternatively I would be honored to be able to help with/provide the C++ library packaging. I do have some headaches though with the current extra setup, deliberately splitting upstream. In case you already intent to also package the C++ library, I'd be perfectly fine, though, just idling on. Thx! Stephan signature.asc Description: This is a digitally signed message part
Bug#756279: ITP: ui-gxmlcpp -- High-level C++ wrapper library for libxml2/libxslt
Package: wnpp Severity: wishlist Owner: Stephan Sürken abs...@debian.org * Package name: ui-gxmlcpp Version : 1.4.3 (tarball to be released on SF soon) Upstream Author : Stephan Sürken abs...@debian.org * URL : http://ui-gxmlcpp.sourceforge.net/ * License : LGPL2+ Programming Lang: C++ Description : High-level C++ wrapper library for libxml2/libxslt ui-gxmlcpp is a high-level C++ wrapper around libxml2 and libxslt. It might be a choice for if your needs are some subset of: - XML DOM Tree parsing. - Basic read/write support from/to trees via XPath. - Serialization. - Stylesheets and stylesheet translation support. - XMLSchema and RelaxNG validation. If your needs are lower-level (e.g., proper DOM tree API support or SAX parsing), gdome2 or xml++ will be the right choices. --- This is the continuation of 'sp-gxmlcpp' (already in Debian). FYI: 'sp-gxmlcpp' has been renamed to 'ui-gxmlcpp' at some point, and also got a dependency on 'ui-utilcpp'. As the latter is now in Debian too, we can provide updates. The old 'sp' and new 'ui' lib* binary packages will not conflict, and will be installable in parallel. 'sp-gxmlcpp' however may eventually be removed completely from the archive later. Hth! Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740576: python-mini-buildd: ping mechanism still fails, this time on apt-cacher-ng
Hi Klee, On Mo, 2014-03-03 at 09:20 +0200, Andrei POPESCU wrote: I also have a similar problem connecting to package repositories that require client certificate authentication. Since there's no support for that directly in mini-buildd yet, I use the hack of disabling the client auth when activating the source. Then I can manually add the client certificate to the appropriate chroot and all is well. But since the ping check is run much more often, it breaks that hack. My temporary solution was just to mark hosts that fail to ping with a time of 1000, so they sort after low-ping hosts. I see two different approaches that might work offhand: * Change the ping code to use a full path to a repository file when checking the ping time (probably by passing a source argument to mbd_ping). * Change the ping code to consider a 404 as a successful ping (since the goal is to determine network timing, not validate the source). I'm happy to submit a patch for whatever approach you prefer, but didn't want to presume to pick one for you. thanks, you are right again ;). For the RC, I pick the second solution you outlined, as it's just less invasive. The exception is now HTTP 404 only. Are there other error codes (i.e., matching a valid use case) to include in this list? The latest stable snapshot from here http://mini-buildd.installiert.net/get.html http://mini-buildd.installiert.net/apt/hellfield_ab_wheezy_snapshot.list already has it, in case you are so daring to try. I keep in mind the (better) first solution (or maybe something completely different) for 1.1.x development branch, though. Hth, Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718576: Patch for patch in SVN
Dear Maintainer(s),
thanks for fixing this in SVN. However, there is some syntax error/typo
in it (see attached fix for fix).
I hope you manage to upload an updated revision to Debian soon.
Thx!
Stephan
Index: debian/control
===
--- debian/control (revision 27619)
+++ debian/control (working copy)
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Janos Guljas ja...@debian.org
Uploaders: Debian Python Modules Team python-modules-t...@lists.alioth.debian.org
-Build-Depends: debhelper (= 9), python (= 2.6.6-3~), python-sendfile = 2.0.0
+Build-Depends: debhelper (= 9), python (= 2.6.6-3~), python-sendfile (= 2.0.0)
Standards-Version: 3.9.4
Homepage: http://code.google.com/p/pyftpdlib/
Vcs-Svn: svn://anonscm.debian.org/python-modules/packages/python-pyftpdlib/trunk/
@@ -12,7 +12,7 @@
Package: python-pyftpdlib
Architecture: all
Depends: ${misc:Depends}, ${python:Depends}
-Recommends: python-sendfile = 2.0.0
+Recommends: python-sendfile (= 2.0.0)
Provides: ${python:Provides}
Description: Python FTP server library
Python FTP server library provides a high-level portable interface to
Bug#733281: mini-buildd: libeatmydata causes build failures when linked against opencv_highgui
Hi Klee,
On Fri, 2013-12-27 at 19:24 -0500, Klee Dienes wrote:
Package: mini-buildd
Version: 1.0.0~rc.1
Severity: normal
I'm not really sure if this is a bug in mini-buildd, or in
libeatmydata, or in OpenCV. But I first encountered the problem in
mini-buildd, so I'm starting here. It's also likely related to
#702711.
I have a package that links against opencv_highgui and also uses
help2man. This causes a FTBFS from within mini-buildd, because:
$ echo int main () { } test.c; cc -g -o test test.c -lopencv_highgui
$ LD_PRELOAD=/usr/lib/libeatmydata/libeatmydata.so ./test
Fatal: can't open /dev/urandom: Bad address
Aborted
there is already
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702711
which has a patch for eatmydata that I can confirm to fix the issue.
Also, it seems to be an issue on sid only (wheezy is fine), so I guess
the new opencv triggered the actual ctor bug in eatmydata as described
by Roland.
To fix this temporarily for a mini-buildd sid distribution, rebuild
eatmydata with the patch, and use something like
apt-get install eatmmydata/sid-test-unstable
in the chroot setup script.
Hth!
Stephan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736239: python-sphinx: 'sphinx/pycode' not installed
Package: python-sphinx Version: 1.2.1+dfsg-1 Severity: important Dear Maintainer, since 1.2.1, I get this --- Running Sphinx v1.2.1 error: /usr/share/sphinx/pycode/Grammar-py2.txt: No such file or directory --- when creating docs. Maybe 'sphinx/pycode' is new in 1.2.1, but just not installed? Thx, Stephan -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-sphinx depends on: ii python-docutils 0.11-3 ii python-jinja22.7.2-2 ii python-pygments 1.6+dfsg-1 pn python:any none ii sphinx-common1.2.1+dfsg-1 Versions of packages python-sphinx recommends: ii python 2.7.5-5 pn python-pil none pn sphinx-doc none Versions of packages python-sphinx suggests: pn dvipng none pn jsmath none pn libjs-mathjax none pn texlive-fonts-recommended none pn texlive-latex-extranone pn texlive-latex-recommended 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
Bug#733443: mini-buildd: should include apt-transport-https if https:// sources are in use
Hi Klee, On Sat, 2013-12-28 at 16:19 -0500, Klee Dienes wrote: (...) sudo apt-get --option=Acquire::Languages=none update E: The method driver /usr/lib/apt/methods/https could not be found. E: Command 'sudo apt-get --option=Acquire::Languages=none update' failed to run. (...) Since the 'apt-get update' runs before the custom chroot setup script, this is not easy to work around. It would be good to either make this part of the default behavior, or done automatically if a https: source is in use, or at minimum provide a way to run a pre-apt-get-update script. thanks for the report. I actually already ran into this myself (i.e., on a feature branch using SSL in mini-buildd itself). It should be possible quite easily doing this automatically, I guess, doing it before all other setups, with the untainted sources list of the chroot. Let's see if this is simple enough to go to RC, but I will provide a patch soon... Afaiu, we would also need ca-certificates then, to make some archives acually work out of the box. Certificates not covered by ca-certificates, or self-signed, would still not work, right? Hth, Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712711: mediathekview: /usr/bin/mediathekview unusable/symlink to jar
Hi Markus, On Thu, 2013-06-20 at 10:49 +0200, Markus Koschany wrote: (...) you can also try to reinstall mediathekview and openjdk-6-jre. What happens if you use the java7-runtime instead of version 6. I suppose something went wrong when you installed mediathekview and the binfmt update script probably did not finish as expected. In general executable jar files are detected and launched automatically as long as you have jarwrapper installed. Please refer to http://www.debian.org/doc/packaging-manuals/java-policy/x85.html ok, thanks for the explanation, I get it now. In my case, this bug occurs due to missing binfmt support with mediathekview in a chrooted environemnt. More generally: When binfmt-support.deb is not installed on the host, the jarwrapper approach does not work in chroots as the binfmt* kernel modules are never loaded. Just installing binfmt-support on the host fixes this. As per policy, this seems ok, though a little bit non-intuitive ;). So feel free to just close this. Thx! Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712711: mediathekview: /usr/bin/mediathekview unusable/symlink to jar
Package: mediathekview Version: 3.2.1+git20130327-2 Severity: important Hi Markus, after installing mediathekview, you can't start the program: --- What? mediathekview /usr/bin/mediathekview: line 1: $'PK\003\004': command not found /usr/bin/mediathekview: line 2: $'\b\025x\250B': command not found /usr/bin/mediathekview: line 3: $'\b\024x\250B': command not found /usr/bin/mediathekview: line 4: mediathek/PK: No such file or directory --- This is due to the fact that /usr/bin/mediathekview is a symlink to the jar file. java -jar /usr/share/mediathekview/MediathekView.jar works just fine, so I guess /usr/bin/mediathekview should be replaced by a script actually calling it that way. HtH! Stephan -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mediathekview depends on: ii default-jre [java6-runtime]1:1.6-47 ii jarwrapper 0.43 ii libcommons-compress-java 1.5-1 ii libcommons-lang3-java 3.1-1 ii libjgoodies-forms-java 1.6.0-4 ii libjide-oss-java 3.5.3+dfsg-1 ii libmac-widgets-java0.9.5+svn369-dfsg1-3 ii libswingx-java 1:1.6.2-1 ii openjdk-6-jre [java6-runtime] 6b27-1.12.5-2 Versions of packages mediathekview recommends: pn flvstreamer none pn vlc | mplayer | mplayer2 none mediathekview suggests no packages. -- 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
Bug#581723: Debian Bug #581723 (python-django-registration: tests fail whith custom registration form)
Hi Ihor, I know it's some time, but would you mind re-checking if your reported bug is still happening with the newly packaged 0.9 prereleases? Thx! Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581723: Debian Bug #581723 (python-django-registration: tests fail whith custom registration form)
Hi Ihor, I know it's some time, but would you mind re-checking if your reported bug is still happening with the newly packaged 0.9 prereleases? Thx! Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709839: django-registration: snapshot release from mercurial
Hi James, I am currently preparing a Debian package update for django-registration to fix django 1.5 support; I need some help to avoid choosing the wrong version for the snapshot release from mercurial. I hope you have the time to check if these assumptions are correct: - releases are done using 'python ./setup sdist'. - your next proper release will be version '0.9'. - there are no 'official' snapshots or beta releases from the hg tip/ 0.9 yet. Fwiw, my current best shot is to release from mercurial tip 440 like so: django-registration-0.9~b1+hg440.tar.gz Btw, in noted the unchanged current tip, semantically version 0.9, beta 1 afaiu, would produce a version like '0.9b1', which will not work if you are going to release '0.9' stable later; '0.9~b1' would work just fine here, in case this beta would be released officially by you ;). Thanks! Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709839: e-uae: segfaulted on first run
Hi Jonathan, On Sat, 2013-05-25 at 22:50 +0100, Jonathan Dowland wrote: TSC frequency: 1396.50 MHz Found x11pc raw keyboard mapping (...) Using cooked keymap Segmentation fault hmm, maybe just rebuilding the package under current sid might help. However, note that Adrian and I have agreed that e-uae and uae will be obsoleted for sid/jessie in favor of fs-uae http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680899 once it's accepted. @Adrian: Any news on this? Thx! Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702281: Patch
Hi, fwiw, I guess this --- root@debian:~# diff -u /usr/lib/cinnamon-settings/modules/cs_keyboard.py.orig /usr/lib/cinnamon-settings/modules/cs_keyboard.py --- /usr/lib/cinnamon-settings/modules/cs_keyboard.py.orig 2013-03-07 14:48:10.897291292 +0100 +++ /usr/lib/cinnamon-settings/modules/cs_keyboard.py 2013-03-07 14:44:23.933284714 +0100 @@ -241,7 +241,7 @@ self.label = label self.action = action self.entries = [] -self.entries.append(binding) +self.entries.append(binding if binding else ) def setBinding(self, index, val): if val is not None: --- may qualify as upstream patch (as the setBinding method has the same guard against None, __init__ should have it too I guess). At least it fixes this bug for me. HtH, Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699903: sbuild waits forever on 'Failed to copy' (stray exit call?)
Package: sbuild
Version: 0.63.2-1.1
Severity: normal
Tags: patch
Dear Maintainers,
when sbuild triggers the 'Failed to copy error' (for example,
when running on a dsc file, with orig.tar.gz missing), sbuild
logs the error but then stalls.
It seems due to a strange exit/return combo in Build.pm. Just
removing 'exit' provides the expected (sbuild prints build stats
and exits with retval not 0) results:
--- Build.pm.orig 2013-02-06 13:28:50.995641502 +
+++ Build.pm2013-02-06 13:30:42.435888257 +
@@ -779,7 +779,6 @@
$self-check_abort();
if (! File::Copy::copy($source, $dest)) {
$self-log_error(E: Failed to copy '$source' to '$dest': $!\n);
- exit (1);
return 0;
}
Looks just like a wrong code leftover. Hope it's that easy ;).
HtH,
Stephan
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-0.bpo.4-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 sbuild depends on:
ii adduser 3.113+nmu3
ii apt-utils 0.9.7.7
ii libsbuild-perl 0.63.2-1.1
ii perl5.14.2-17
ii perl-modules5.14.2-17
Versions of packages sbuild recommends:
pn debootstrap none
ii fakeroot 1.18.4-2
Versions of packages sbuild suggests:
pn deborphan none
ii wget 1.14-1
-- 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
Bug#699086: mini-buildd: sed separator should not be /
Hi Tzafrir, On Sun, 2013-01-27 at 10:17 +0100, Tzafrir Cohen wrote: + sed -i s/^ *MINI_BUILDD_OPTIONS=.*/MINI_BUILDD_OPTIONS=--verbose --home /srv/mini-buildd/ /etc/default/mini-buildd The fix: replace '/' with '|' as the separator. thanks for the report. Fix to allow '/' in custom options is pending. '--home' as custom option is however not needed, unless your mini-buildd unix user's home is not '/srv/mini-buildd', for which I don't really see a use case (?). MfG, Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633074: please make crypto key parameters configurable
Hi Marc, On Fri, 2011-07-08 at 07:26 +0200, Marc Haber wrote: Package: mini-buildd-rep Severity: wishlist Hi, I would like to take influence over the GPG/ssh keys that are generated during mini-buildd setup, including crypto algorithms and key length. Please consider implementing interfaces to allow other keys to be built than package defaults. fixed in experimental/1.0.0. In mini-buildd 1.0, one archive or daemon key is created per mini-buildd installation. This can be configured via the Daemon model, where you can give a complete creation template (except Name-Real and Name-Email) as accepted by 'gpg --gen-key' in batch mode. Daemon.[un]prepare actions are in charge of handling creation/removal. MfG, Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656746: For the record
Hi, last but not least, some clarification on these rc bugs: Unfortunately, both bugs (632955 656746) can't be fixed in 0.8.x, as they are by design -- it does 'it all' on package configuration/installation time, which usually needs human interaction. Furthermore, secret keys are generated which might also just stall if the system lacks entropy. Fortunately, this is all irrelevant for the upcoming 1.0.0* version, now (waiting) in experimental. 0.8.x will not see further updates in Debian; I will eventually provide a special 0.8.x 'PPD' for that for installations that really don't want to upgrade (would become really relevant for wheezy+1, however ;). HtH, Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686360: piuparts: New --schroot option fails on current schroot (session namespace missing)
Package: piuparts
Version: 0.45
Severity: normal
Tags: patch
Dear Maintainer,
I was just testing the nice new '--schroot' option under sid;
this fails as there are some places schroot is called with
arguments '--chroot SESSION', with SESSION not having the
session namespace.
This fails at least for schroot in sid/testing.
These simple patches fixed it for me:
--- /usr/sbin/piuparts.orig 2012-06-21 22:19:17.0 +0200
+++ /usr/sbin/piuparts 2012-08-31 16:49:57.216780933 +0200
@@ -800,7 +800,7 @@
run(['lvremove', '-f', self.lvm_snapshot])
if settings.schroot:
logging.debug(Terminate schroot session '%s' % self.name)
-run(['schroot', '--end-session', '--chroot',
self.schroot_session])
+run(['schroot', '--end-session', '--chroot', session: +
self.schroot_session])
if not settings.schroot:
shutil.rmtree(self.name)
logging.debug(Removed directory tree at %s % self.name)
@@ -845,7 +845,7 @@
def setup_from_schroot(self, schroot):
self.schroot_session = schroot.split(:)[1] + - + str(uuid.uuid1())
+ -piuparts
run(['schroot', '--begin-session', '--chroot', schroot ,
'--session-name', self.schroot_session])
-ret_code, output = run(['schroot', '--chroot', self.schroot_session,
'--location'])
+ret_code, output = run(['schroot', '--chroot', session: +
self.schroot_session, '--location'])
self.name = output.strip()
logging.info(New schroot session in '%s' % self.name);
@@ -875,7 +875,7 @@
'usr/bin/eatmydata')):
prefix.append('eatmydata')
if settings.schroot:
-return run([schroot, --preserve-environment, --run-session,
--chroot, self.schroot_session, --directory, /, -u, root, --] +
prefix + command,
+return run([schroot, --preserve-environment, --run-session,
--chroot, session: + self.schroot_session, --directory, /, -u,
root, --] + prefix + command,
ignore_errors=ignore_errors,
timeout=settings.max_command_runtime)
else:
return run([chroot, self.name] + prefix + command,
Thx!
Stephan
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-0.bpo.3-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 piuparts depends on:
ii debootstrap1.0.42
ii dpkg 1.16.8
ii lsb-release4.1+Debian7
ii lsof 4.86+dfsg-1
ii python 2.7.3-2
ii python-debian 0.1.21
piuparts recommends no packages.
Versions of packages piuparts suggests:
ii schroot 1.6.3-1
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/sbin/piuparts (from piuparts package)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660939: add info
Hi, tagged fixed-in-experimental. ftr, both issues are definitely fixed in 1.0.0, alpha3 (still in NEW, though). HtH, Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652036: [pkg-db-devel] Bug#652036: db: Salvaging db_dump triggers endless loop on certain broken databases since Berkeley DB 4.7
Hi Ondřej, On Wed, 2011-12-14 at 13:02 +0100, Ondřej Surý wrote: Hi, could you please try db5.1 (and optionally db5.2 in experimental)? ok, retested also with 5.2 from experimental. I.e., all versions I tried 4.7 are affected, and these are 4.8 (under squeeze) 5.1 (under sid) 5.2 (from experimental under sid) Thx, Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585480: RFP: puae -- Amiga Emulator for *nix Systems
Hi Adrian, On Sat, 2011-06-04 at 02:45 +0200, Adrian Glaubitz wrote: Hi, have there been any recent developments regarding the packaging? does not seem so ;(. I just stumbled across this RFP since a new version of WinUAE was just released as of June 2 [1] which now has the nice feature that it ships with the free kickstart replacement developed by the AROS community [2]. This means, that WinUAE can be used without having to use the original kickstart ROMs. So I think it would have been a nice idea to include the AROS kickstart in the Debian 'puae' package as well. This way, the emulator will be able to run without any further non-free components which means that 'puae' could go into 'main'. Hmm, ok. This would be a benefit (for [e-]uae just as well). Wishlist bug? I am btw the maintainer of the 'kcemu' package [3] which emulates 8 bit computers made in former East Germany and I would be glad to help with the packaging of 'puae'. I also think it would be ok to drop 'euae' and 'uae' in favour of 'puae' since the former two don't appear to be actively maintained anymore. Last time I checked, the puae software et.al.(tm) wasn't in a state that made me inclined to package it ;), but this may have changed. However, I still only see some git repository really; what state is puae, as a software project, actually in? When it comes to packaging, I guess starting out with the current e-uae packaging as template would be fine; be sure it can co-exist with uae/e-uae though, at least as long as I am not convinced it really obsoletes them. Then again, I also see a debian/ in the git repo, so maybe there is work already done? MfG, Stephan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625995: Adding multiple extra sources via debconf ('\n') screws up ~/.mini-buildd.conf
Package: mini-buildd Severity: normal Hi, when running 'dpkg-reconfigure mini-buildd-rep', adding multiple extra sources separated by '\n', the resulting generated ~/.mini-buildd.conf is screwed up with special characters (also breaking sources.list creation in build runs). To work around this, you must manually edit ~/.mini-buildd.conf, re-establish \n as separator in the affected line, and re-run mbd-update-rep as user mini-buildd. This was working fine in some previous version (and/or under lenny). MfG, Stephan -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-bpo.2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617673: mini-buildd-bld: When removing distributions, LVM volumes are not removed
Package: mini-buildd-bld Severity: minor mbd-setup-chroots should check if there are vg's still created for base distributions no longer configured to support, and silently remove them. This may be done based on the naming scheme mbd-DIST-ID-ARCH, which should make it sufficiently sure no 'non-mini-buildd vgs' are removed. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604011: 99mini-buildd: Logs to stderr (causing false-positiv daily error mails)
Package: mini-buildd-bld Severity: minor Hi, newer (squeeze) schroot version produce E: OUTPUT-like output for anything written to stderr by any setup.d hook script. 99mini-buildd does log some lines (to stderr). I guess the right thing is just not to do that in a setup.d script. This eventually tricks the grep magic in /etc/cron.daily/mini-buildd-rep to report false-positive errors in daily mail (which is quite annoying). MfG, Stephan -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-bpo.2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603913: mini-buildd-bld: Uses deprecated schroot option 'priority'
Package: mini-buildd-bld Severity: minor Using priority=3 in the schroot config produces many annoying warnings the the logs. This can just be removed, as it did not really ever served a purpose for mini-buildd anyway. MfG, Stephan -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-bpo.2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603919: mini-buildd-bld: For initial packages (i.e., only one cl entry), auto backport mechanism fails
Package: mini-buildd-bld Severity: normal Hi, see subject. This is due the $lastVersion calculation; this is empty in such a case, so that dpkg-buildpackage is called with option '-v' without argument. MfG, Stephan -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-bpo.2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592592: mini-buildd: sbuild configuration uses old style pgp_options
Package: mini-buildd Severity: grave Justification: renders package unusable Hi, in .sbuildrc, pgp_options used to be just a string; the version in sid/squeeze uses an array. This essentially makes all builds fail. Please replace $pgp_options = -us -k\Mini-Buildd Automatic Signing Key\; by $pgp_options = ['-us', '-k Mini-Buildd Automatic Signing Key']; and update the sbuild depends (as the new variant does not work for older sbuilds). Thx, Stephan -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-bpo.5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592594: mini-buildd: schroot.conf uses obsoleted+unneccessary schroot directives run-*-script
Package: mini-buildd Version: 0.8.14 Severity: normal run-setup-scripts and run-exec-scripts are marked obsolete with schroot in squeeze, and produce ugly warnings. The defaults however for both the squeeze and the lenny version of schroot are fine for lvm-snapshot, so these can just be left out. Thx, Stephan -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-bpo.5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592596: Please use /etc/schroot/chroot.d/ for mini-buildd's schroot configuration
Package: mini-buildd Severity: wishlist It's ugly to patch in schroot's conf directly; both the lenny (though undocumented) and the squeeze version now support chroot.d/ for that. Thx, Stephan -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-bpo.5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592599: mini-buildd: mbd-qa-check broken by bash4
Package: mini-buildd Severity: grave Justification: renders package unusable Hi, (at least) the mbd-qa-check relies on error handling behaviour of bash =3. More precisely, a snippet like this --- set -e ( false ) RET=$? --- would just continue with the subshell's retval in variable RET in bash3, but error-exit in bash4 after the sub shell. At least the construct in mbd-qa-check suffers this problem (lines 349ff). This essentially breaks mosts builds (i.e., those with warning in any of the checks). Thx, Stephan -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-bpo.5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591646: magit: New upstream version 0.8.2 available
Package: magit Version: 0.8.2-0~abSID+1 Severity: wishlist Hi, version 0.8.2 is available for some time at http://github.com/philjackson/magit/downloads Fwiw: Updated private packages available at deb http://debian.installiert.net/mini-buildd-ab sid-ab/ did not need any Debian changes. Thx, Stephan -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-bpo.2-amd64 (SMP w/2 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 magit depends on: ii dpkg 1.15.8.3 Debian package management system ii emacs [emacsen] 23.2+1-2 The GNU Emacs editor (metapackage) ii emacs23 [emacsen] 23.2+1-2 The GNU Emacs editor (with GTK+ us ii git [git-core]1:1.7.1-1.1fast, scalable, distributed revisi ii git-core 1:1.7.1-1.1fast, scalable, distributed revisi ii install-info 4.13a.dfsg.1-5 Manage installed documentation in magit recommends no packages. magit suggests no packages. -- 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
Bug#589840: libcap-dev: Static library missing
Package: libcap-dev Version: 1:2.17-2 Severity: normal Tags: patch Hi, libcap-dev is missing the static libraries (I suspect since converting to debhelper). Please add the line --- debian/tmp/lib/lib*.a --- to libcap-dev.install. Thx, Stephan -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-bpo.5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libcap-dev depends on: ii libcap2 1:2.17-2 support for getting/setting POSIX. libcap-dev recommends no packages. Versions of packages libcap-dev suggests: ii manpages-dev 3.25-1 Manual pages about using GNU/Linux -- 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
Bug#578649: log4cxx: Please add preliminary patch for issue LOGCXX-322
Package: log4cxx
Severity: normal
Hi,
the bug reported in #578649 is most likeley due to Jira issue
https://issues.apache.org/jira/browse/LOGCXX-322
I am seeing this problem here too, and a preliminary patch
solving this for me was published here
http://mail-archives.apache.org/mod_mbox/logging-log4cxx-dev/200901.mbox/%3c1232120052.30824.62.ca...@bjhlinux%3e
Attaching a ready-to-plug-in dpatch patch file.
Please consider adding this patch to the Debian package.
Thx,
Stephan
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-bpo.5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
#! /bin/sh /usr/share/dpatch/dpatch-run
## 130-bugfix-LOGCXX-322.dpatch by Stephan Sürken stephan.suer...@1und1.de
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: This is from a patch for Jira issue
## DP: https://issues.apache.org/jira/browse/LOGCXX-322
## DP: published in the mailing list thread
## DP: http://mail-archives.apache.org/mod_mbox/logging-log4cxx-dev/200901.mbox/%3c1232120052.30824.62.ca...@bjhlinux%3e
## DP: It's not yet (2010 Jul) accepted into svn, but it does fixes possible serious segfaults on program exit.
@DPATCH@
diff -urNad log4cxx-0.10.0~/src/main/cpp/aprinitializer.cpp log4cxx-0.10.0/src/main/cpp/aprinitializer.cpp
--- log4cxx-0.10.0~/src/main/cpp/aprinitializer.cpp 2008-04-01 00:34:09.0 +0200
+++ log4cxx-0.10.0/src/main/cpp/aprinitializer.cpp 2010-07-06 16:04:28.0 +0200
@@ -42,7 +42,7 @@
}
APRInitializer::~APRInitializer() {
-apr_terminate();
+//apr_terminate();
isDestructed = true;
}
diff -urNad log4cxx-0.10.0~/src/main/cpp/level.cpp log4cxx-0.10.0/src/main/cpp/level.cpp
--- log4cxx-0.10.0~/src/main/cpp/level.cpp 2008-04-01 00:34:09.0 +0200
+++ log4cxx-0.10.0/src/main/cpp/level.cpp 2010-07-06 16:04:34.0 +0200
@@ -30,44 +30,44 @@
IMPLEMENT_LOG4CXX_OBJECT_WITH_CUSTOM_CLASS(Level, LevelClass)
LevelPtr Level::getOff() {
- static LevelPtr level(new Level(Level::OFF_INT, LOG4CXX_STR(OFF), 0));
- return level;
+ static LevelPtr *level = new LevelPtr(new Level(Level::OFF_INT, LOG4CXX_STR(OFF), 0));
+ return *level;
}
LevelPtr Level::getFatal() {
- static LevelPtr level(new Level(Level::FATAL_INT, LOG4CXX_STR(FATAL), 0));
- return level;
+ static LevelPtr *level = new LevelPtr((new Level(Level::FATAL_INT, LOG4CXX_STR(FATAL), 0)));
+ return *level;
}
LevelPtr Level::getError() {
- static LevelPtr level(new Level(Level::ERROR_INT, LOG4CXX_STR(ERROR), 3));
- return level;
+ static LevelPtr *level = new LevelPtr((new Level(Level::ERROR_INT, LOG4CXX_STR(ERROR), 3)));
+ return *level;
}
LevelPtr Level::getWarn() {
- static LevelPtr level(new Level(Level::WARN_INT, LOG4CXX_STR(WARN), 4));
- return level;
+ static LevelPtr *level = new LevelPtr((new Level(Level::WARN_INT, LOG4CXX_STR(WARN), 4)));
+ return *level;
}
LevelPtr Level::getInfo() {
- static LevelPtr level(new Level(Level::INFO_INT, LOG4CXX_STR(INFO), 6));
- return level;
+ static LevelPtr *level = new LevelPtr((new Level(Level::INFO_INT, LOG4CXX_STR(INFO), 6)));
+ return *level;
}
LevelPtr Level::getDebug() {
- static LevelPtr level(new Level(Level::DEBUG_INT, LOG4CXX_STR(DEBUG), 7));
- return level;
+ static LevelPtr *level = new LevelPtr((new Level(Level::DEBUG_INT, LOG4CXX_STR(DEBUG), 7)));
+ return *level;
}
LevelPtr Level::getTrace() {
- static LevelPtr level(new Level(Level::TRACE_INT, LOG4CXX_STR(TRACE), 7));
- return level;
+ static LevelPtr *level = new LevelPtr((new Level(Level::TRACE_INT, LOG4CXX_STR(TRACE), 7)));
+ return *level;
}
LevelPtr Level::getAll() {
- static LevelPtr level(new Level(Level::ALL_INT, LOG4CXX_STR(ALL), 7));
- return level;
+ static LevelPtr *level = new LevelPtr((new Level(Level::ALL_INT, LOG4CXX_STR(ALL), 7)));
+ return *level;
}
diff -urNad log4cxx-0.10.0~/src/main/cpp/logmanager.cpp log4cxx-0.10.0/src/main/cpp/logmanager.cpp
--- log4cxx-0.10.0~/src/main/cpp/logmanager.cpp 2008-04-01 00:34:09.0 +0200
+++ log4cxx-0.10.0/src/main/cpp/logmanager.cpp 2010-07-06 16:04:21.0 +0200
@@ -57,7 +57,8 @@
// call to initialize APR and trigger start of logging clock
//
APRInitializer::initialize();
- static spi::RepositorySelectorPtr selector;
+ static spi::RepositorySelectorPtr * pselector = new spi::RepositorySelectorPtr;
+ static spi::RepositorySelectorPtr selector = * pselector;
return selector;
}
Bug#585480: RFP: puae -- Amiga Emulator for *nix Systems
Piotr, On Thu, 2010-06-10 at 22:59 +0200, Piotr Ożarowski wrote: Package: wnpp Severity: wishlist * Package name: puae Version : 2.2.0~beta Upstream Author : Mustafa 'GnoStiC' TUFAN mustafa.tu...@gmail.com * URL : http://github.com/GnoStiC/PUAE * License : GPL Programming Lang: C Description : Amiga Emulator for *nix Systems PUAE tries to continue where E-UAE left off.. PUAE versioning is based on the merged WinUAE version.. ok, interesting. I wasn't aware of yet another fork ;). Does this also mean that e-uae is officially abandoned by Mr Drummond? Anyway, looking at puae, it seems it merely consists of a git repo (with mysterious log messages ;)? Is there some more information somewhere, and are there releases to download? Thx, Stephan -- Stephan Sürken absurd at olurdix.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543788: Reopen: [uae] UAE segfaults when loading a previously saved state
Hi Antonio, On Tue, 2009-09-22 at 23:56 +0100, Antonio Marcos López Alonso wrote: Unfortunately I have to reopen this bug as after a few more tries UAE keeps on segfaulting. Here is the gdb output as you suggested: you did not really reopen this bug, so I did it now for you. Program received signal SIGSEGV, Segmentation fault. 0x0050ce0c in decide_sprites () Current language: auto; currently asm (gdb) bt #0 0x0050ce0c in decide_sprites () #1 0x005156b2 in hsync_handler () #2 0x0040a0d3 in m68k_run_2 () #3 0x00409e16 in m68k_go () #4 0x0040756f in real_main () #5 0x004076a9 in main () (gdb) exit Any ideas? Not really; maybe upstream can debug this further, but it's not very active recently. I am just leaving this open as upstream bug for the moment. Thx, Stephan -- Stephan Sürken absurd at olurdix.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583897: e-uae: Please use better build options
Hi Russel, thanks for your input. On Mon, 2010-05-31 at 14:16 +0100, Francis Russell wrote: e-uae has the ability to present SCSI devices on the host system to the emulated Amiga (typically the CD-ROM Ok. With the current options, e-uae uses OSS as its sound target. As far as I'm aware OSS is considered obsolete. Ack, that should be alsa at least. The current Debian configure line includes both the options '--with-x' and '--with-sdl-gfx'. I'm pretty sure Ok, I have tested some configurations and found --enable-threads --with-sdl-gfx --with-sdl-sound --enable-scsi-device is leaner, works quite well with my tests and should address all your problems. Thx, Stephan -- Stephan Sürken absurd at olurdix.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577850: mini-buildd: [debconf_rewrite] Debconf templates and debian/control review
Hi Christian, On Thu, 2010-04-15 at 08:06 +0200, Christian Perrier wrote: Dear Debian maintainer, (...) Please review the suggested changes, and if you have any objections, let me know in the next 3 days. Great, thanks for reviewing! I have glanced over it, only this one seems strange: --- Template: mini-buildd-bld/mbd_lvm_vg Type: string Default: auto Description: LVM2 volume group to use: - You need a dedicated lvm volume group where the chroots are - maintained (via schroot). + There will need to be a dedicated LVM volume group for the chroots + to be maintained on (with schroot). --- There will need to be sound strange for my (non-native) ears ;), maybe just a typo? Else, go for it, Stephan -- Stephan Sürken absurd at olurdix.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#136903: Additional information
Hi, seeing that the wontfix lacks an explanation here, just FYI: The patch does no longer apply and is unmaintained and no longer in the package since version 0.8.22. Thx, Stephan -- Stephan Sürken absurd at debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#345094: uae: UAE should configure with --with-sdl-sound
Hi Erik, compiling use with --with-sdl-sound is, unfortunately, still no option; sound simply does not work properly, so using oss or alsa is still better for most users. I agree however that this would be the best solution if it would work ;). [ There is also a note about that in some ancient changelog entry, however for some reasons not here ;(. ] However, the current version 0.8.29-6 uses --with-alsa, which might solve your problem; also artsd might have been replaced or is smarter (not using /dev/dsp) now. Also, e-uae might work better for you. I am keeping this as wishlist bug for later, however. Thanks, Stephan -- Stephan Sürken absurd at debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
