Bug#785520: python-qpid: Please provide a python3 package
Package: python-qpid Severity: wishlist Tags: upstream Usertags: patchme-python3 Dear Maintainer, I copied this text from Paul’s other “Please provide a Python 3 package” tickets but left out some parts which are not important, because the seems to be no work done on qpid and python3 so far. ### Copy and paste START ### Hello there! [..] As part of an ongoing process to migrate as much as we can to Python 3 to ensure we're ready for our glorious Python 3 future, please build a Python 3 module. If you need help doing this, please feel free to contact the Debian Python Modules Team (DPMT), and we can help! If you would welcome a NMU, please do let the team know (py3porters-de...@lists.alioth.debian.org). [..] If the reason you've not built a Python 3 module is due to the dependency chain below you, just let me know, and I can add it to our list, or feel free to file a bug in coordination with the team! Have a great day, and thanks for your work! Paul, on behalf of the Python 3 Embetterment Squad ### Copy and paste END ### bg Johannes -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150517111201.30793.87020.reportbug@localhost
Bug#761735: buddy: libtool split: package needs a b-d on libtool-bin (or avoid using the libtool binary)
Hi, adding some additional info: buddy actually calls libtool during the build so it needs to build depend on libtool-bin. cheers, josch -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141007210706.19342.99757@hoothoot
Bug#651502: ImportError: No module named Scientific_numerics_package_id
Package: python-scientific Version: 2.8-3 When importing Scientific.Functions.Derivatives I get the following error: $ python -c "import Scientific.Functions.Derivatives" Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dist-packages/Scientific/Functions/Derivatives.py", line 103, in from Scientific import N; Numeric = N File "/usr/lib/python2.7/dist-packages/Scientific/N.py", line 1, in import Scientific_numerics_package_id ImportError: No module named Scientific_numerics_package_id The Scientific_numerics_package_id module is available in the python-netcdf package and installing this makes the error go away. Should python-scientific depend on python-netcdf rather than recommending it? I see from the Debian changelog that this was changed in the last upload. Thanks, Johannes -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caljqy_fsrzw1ecx969n6vmywhfgy998clwmqryh41kggnk5...@mail.gmail.com
Bug#126088: mozilla-locale-de-at breaks nautilus' web page view
Package: mozilla-locale-de-at Version: 0.9.6-1 Severity: normal When I install the German locale .deb for Moz 0.9.6, nautilus mozilla component crashes. The same doesn't happen when I install the locale .xpi from mozilla.org The difference between these two installation variants seems to be, that installing the mozilla-locale-de-at .deb changes Mozilla's locale preset to de_at while installing the XPI still leaves English as the default. So either nautilus-mozilla should be enabled to cope with this situation. It should possibly set the default to English in its own Moz profile located in ~/.nautilus/Mozilla-profile or the mozilla-locale-de-at package should not make de_AT the default language but leave it to the user to change from English to German. Since I don't know, which way is more feasible, I have filed identical bug reports for both packages. -- System Information Debian Release: 2.2 Architecture: i386 Kernel: Linux rudi 2.2.19 #1 Die Nov 13 00:15:07 MET 2001 i586 Versions of packages mozilla-locale-de-at depends on: ii mozilla-browser 2:0.9.6-8 Mozilla Web Browser - core and bro
Bug#126090: mozilla-locale-de-at breaks nautilus' web page view
Package: mozilla-locale-de-at Version: 0.9.6-1 Severity: normal When I install the German locale .deb for Moz 0.9.6, nautilus mozilla component crashes. The same doesn't happen when I install the locale .xpi from mozilla.org The difference between these two installation variants seems to be, that installing the mozilla-locale-de-at .deb changes Mozilla's locale preset to de_at while installing the XPI still leaves English as the default. So either nautilus-mozilla should be enabled to cope with this situation. It should possibly set the default to English in its own Moz profile located in ~/.nautilus/Mozilla-profile or the mozilla-locale-de-at package should not make de_AT the default language but leave it to the user to change from English to German. Since I don't know, which way is more feasible, I have filed identical bug reports for both packages. -- System Information Debian Release: 2.2 Architecture: i386 Kernel: Linux rudi 2.2.19 #1 Die Nov 13 00:15:07 MET 2001 i586 Versions of packages mozilla-locale-de-at depends on: ii mozilla-browser 2:0.9.6-8 Mozilla Web Browser - core and bro
Bug#172886: cvsweb: spelling/grammar bug in man page
Package: cvsweb Version: 3:1.112-4 Severity: minor The man page says: "cvsweb is a cgi script that offer [...]" which should be "offers" instead. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux johannes 2.4.20-xfs #2 Mon Dec 9 18:45:10 CET 2002 i686 Locale: LANG=en_US, [EMAIL PROTECTED] (ignored: LC_ALL set) Versions of packages cvsweb depends on: ii apache [httpd]1.3.26-1.1 Versatile, high-performance HTTP s ii cvs 1.11.2-5 Concurrent Versions System ii perl 5.8.0-14 Larry Wall's Practical Extraction ii rcs 5.7-13 The GNU Revision Control System -- no debconf information
requestion for adding to distribution
hi, i'm not sure who is responsible for such requestion, i hope i'm correct here, if not, please forward to the correct persons. could you please add libharu2 to the debian packages? you can find it here: http://libharu.sourceforge.net/ it is usefull for creating pdf-files and has a lot of functions. regards, johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427217: cvsps: rlog on old servers can't handle ".", use "" instead
Package: cvsps
Version: 2.1-2
Severity: normal
On some cvs servers you can't get an rlog for the repository root
because some internal assertion fails on the server side when /./ is
present on the path. However, if you use // it works fine. The
attached patch makes cvsps use an empty path ("") instead of "."
which makes it work on such servers.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.22-rc3-gcfb44989-dirty (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages cvsps depends on:
ii cvs 1:1.12.13-8Concurrent Versions System
ii libc6 2.6~20070518-1 GNU C Library: Shared libraries
ii zlib1g1:1.2.3-15 compression library - runtime
cvsps recommends no packages.
-- no debconf information
--- cvsps-2.1.orig/cvsps.c
+++ cvsps-2.1/cvsps.c
@@ -1041,7 +1041,10 @@
* from the 'nominal' repository path because of symlinks in the server
and
* the like. See also the 'parse_file' routine
*/
-strip_path_len = snprintf(strip_path, PATH_MAX, "%s/%s/", p,
repository_path);
+if (strcmp(repository_path, ".") == 0)
+ strip_path_len = snprintf(strip_path, PATH_MAX, "%s//", p);
+else
+ strip_path_len = snprintf(strip_path, PATH_MAX, "%s/%s/", p,
repository_path);
if (strip_path_len < 0 || strip_path_len >= PATH_MAX)
{
--- cvsps-2.1.orig/cvs_direct.c
+++ cvsps-2.1/cvs_direct.c
@@ -864,8 +864,13 @@
send_string(ctx, "Argument %s\n", date_str);
}
-send_string(ctx, "Argument %s\n", rep);
-send_string(ctx, "rlog\n");
+if (strcmp(rep, ".") == 0) {
+ send_string(ctx, "Argument \n");
+ send_string(ctx, "rlog\n");
+} else {
+ send_string(ctx, "Argument %s\n", rep);
+ send_string(ctx, "rlog\n");
+}
/*
* FIXME: is it possible to create a 'fake' FILE * whose 'refill'
Bug#906412: svn-buildpackage: FTBFS in buster/sid (po4a-build: Command not found)
On Fri, 17 Aug 2018 11:21:39 + Santiago Vila wrote: > I tried to build this package in buster but it failed: > > > [...] > debian/rules build-indep > dh build-indep > dh: Compatibility levels before 9 are deprecated (level 7 in use) >dh_update_autotools_config -i >dh_auto_configure -i > dh_auto_configure: Compatibility levels before 9 are deprecated (level 7 in > use) >dh_auto_build -i > dh_auto_build: Compatibility levels before 9 are deprecated (level 7 in use) > make -j1 > make[1]: Entering directory '/<>' > po4a-build > make[1]: po4a-build: Command not found > make[1]: *** [Makefile:10: docbuild] Error 127 > make[1]: Leaving directory '/<>' > dh_auto_build: make -j1 returned exit code 2 > make: *** [debian/rules:4: build-indep] Error 2 > dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit > status 2 > > > The build was made with "dpkg-buildpackage -A" in my autobuilder. > Most probably, it also fails here in reproducible builds: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/svn-buildpackage.html > > where you can get a full build log if you need it. > > If this is really a bug in one of the build-depends, please use reassign and > affects, > so that this is still visible in the BTS web page for this package. Upstream version 0.54 of po4a removed po4a-build: https://github.com/mquinson/po4a/releases There are two packages in Debian that seem to FTBFS because of that. In addition to this bug, there is also the following bug against multistrap: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906386 Since it is unclear to me what the correct replacement for po4a-build is, I contacted upstream about it: https://github.com/mquinson/po4a/issues/144 Since this bug is also still unfixed, I thought that this information might be helpful for you as well. :) Just in case, I also CC-ed the po4a maintainers. Thanks! cheers, josch signature.asc Description: signature
Bug#921471: Should pdf2htmlex be removed?
On Tue, 05 Feb 2019 23:12:03 +0100 Moritz Muehlenhoff wrote: > Should pdf2htmlex be removed? It's RC-buggy for over a year and upstream > development seems to have stopped: > http://pdf2htmlex.blogspot.de/2016/12/looking-for-new-maintainer.html Yes, possibly. Funny, that you are reporting this today because just a few hours ago, I reached out to a fork that claims to continue development. Unfortunately, things don't look rosy over there either: https://github.com/pdf2htmlEX/pdf2htmlEX/issues/20 signature.asc Description: signature
Bug#921471: Should pdf2htmlex be removed?
Control: retitle -1 ROM: pdf2htmlex -- dead upstream Control: reassign -1 ftp.debian.org Quoting Moritz Mühlenhoff (2019-03-25 22:20:36) > On Tue, Feb 05, 2019 at 11:18:01PM +0100, Johannes Schauer wrote: > > On Tue, 05 Feb 2019 23:12:03 +0100 Moritz Muehlenhoff > > wrote: > > > Should pdf2htmlex be removed? It's RC-buggy for over a year and upstream > > > development seems to have stopped: > > > http://pdf2htmlex.blogspot.de/2016/12/looking-for-new-maintainer.html > > > > Yes, possibly. > > > > Funny, that you are reporting this today because just a few hours ago, I > > reached out to a fork that claims to continue development. Unfortunately, > > things don't look rosy over there either: > > > > https://github.com/pdf2htmlEX/pdf2htmlEX/issues/20 > > Johannes, seven weeks later, what's your take, shall we remove it or keep it? Alright, I think it's time to pull the plug. :( Reassigning and retitling accordingly. signature.asc Description: signature
python-qpid python3
Hello guys, as part of the work related to debian-py3port I decided to have a look at python-qpid and check what has to be done. Is any Python3 work done already? If so, who did it, or who could know what to do/what has been done? All I found up to now is this short discussion: https://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/201408.mbox/%3c1699427857.17070236.1407350940626.javamail.zim...@redhat.com%3E Independent of this Information it would be nice to get some information about who the python-qpid code is structured and if there exists some kind of guidline/styleguide for the code. bg, Johannes -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/554d23f8.2060...@uni-muenster.de
Bug#783478: texi2html: [PATCH] Please make the build reproducible
Hi Juan, On Mon, 27 Apr 2015 08:09:03 -0300 Juan Picca wrote: > The attached patch removes extra timestamps from the build system and > ensure a stable file order when creating the source archive. Once > applied, texi2html can be built reproducibly in our current experimental > framework. thanks for your patch! I'm considering to NMU this package together with this patch of yours but am having some questions about your patch before. 1. In your patch you remove ./mdate-sh and ./doc/mdate-sh. This removal makes your patch quite big. Why do those files have to be removed and cannot stay to minimize the size of the patch? 2. you call texi2html.pl with --use-date but in #783475 you renamed the command line option to --build-date 3. the updated patch in #783475 allows texi2html to use $SOURCE_DATE_EPOCH. So maybe instead of patching upstreams ./doc/Makefile.am and ./doc/Makefile.in, you should instead not patch these files but just export $SOURCE_DATE_EPOCH in debian/rules 4. in doc/Makefile.in you are moving the line calling mdate-sh around. Why? 5. you are patching ./configure.ac in addition to ./configure. But either ./configure does get regenerated from ./configure.ac (and in this case you do not need to patch ./configure) or ./configure does not get regenerated from ./configure.ac (and in this case you do not need to patch ./configure.ac). I'd prefer if configure was regenerated at build time. Thanks again for your contribution! cheers, josch signature.asc Description: signature
Bug#194918: prboom: Please provide alternative prboom-nogl package for older hardware
Package: prboom Version: 2.2.3-johannes.1 Severity: wishlist Hi, I don't know if I'm the only one running an old K6 box with a really cheap graphics card. But for me the OpenGL enabled build is awfully slow to the point of being unusable. I've rebuilt locally with --disable-gl and it works like a charm now. Thus I wonder if you could provide a "proboom-nogl" package from the same source. Thanks, Johannes -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux rudi.3linden 2.4.20-1-k6 #1 Sat Mar 22 14:38:19 EST 2003 i586 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 Versions of packages prboom depends on: ii libc6 2.3.1-16 GNU C Library: Shared libraries an ii libsdl-mixer1.2 1.2.5-2mixer library for Simple DirectMed ii libsdl-net1.2 1.2.5-1network library for Simple DirectM ii libsdl1.2debian 1.2.5-3Simple DirectMedia Layer ii libsmpeg0 0.4.4-8SDL MPEG Player Library - shared l -- no debconf information
Bug#1026280: packaging wayfire-plugins-extra
Dear Maintainer, I've been using awesome wm but want to switch to wayland, wayfire seems to be a suitable replacement. However, I need focus-follows-mouse for my workflow, thus I need wayfire-plugins-extra. https://github.com/WayfireWM/wayfire-plugins-extra I created a package for my own needs, but it's my first attempt at packaging. I want to share my results in the hope someone will finish the work. (See attachment.) Just run "uscan -dd" to download the upstream source and then "sbuild". The resulting package works for me. Notes: - The upstream github project uses git subprojects and the build fails when using incorrect versions of these subprojects, it must use the versions given in the git subproject metadata. But I found no way to get this version data and download the correct versions automatically using the watch file. After some time I realized the github release tar.gz doesn't include the subprojects, but the tar.xz does. Thus my watch file downloads the tar.xz and the rules file enables the build of all subprojects. - wayfire-plugins-extra includes wayfire-shadows as a subproject, which alread has been packaged separately. Best Regards, Johannes wayfire-plugins-extra_0.9.0-1.debian.tar.xz Description: application/xz
Bug#1026280: packaging wayfire-plugins-extra
Dear Maintainer, wayfire-plugins-extra-0.9.0 doesn't build anymore with wlroots-0.18, it needs a update from git snapshot. For myself I built it as below using the attached wayfire-plugins-extra_0.9.0+git20241218.b51f2e9-1.debian.tar.xz - git clone --no-checkout -o upstreamvcs https://github.com/WayfireWM/wayfire-plugins-extra cd wayfire-plugins-extra git checkout -b debian/latest b51f2e96a1c8dee20187e1a5e31d0a4864a9fcc9 git submodule update --init [add debian/* and commit] gbp buildpackage --git-submodules --git-export-dir=.. --git-builder=/bin/true --git-no-pbuilder --git-no-hooks --git-no-purge --git-debian-branch=debian/latest --git-upstream-tree=b51f2e96a1c8dee20187e1a5e31d0a4864a9fcc9 then sbuild - Best Regards, Johannes wayfire-plugins-extra_0.9.0+git20241218.b51f2e9-1.debian.tar.xz Description: application/xz
Bug#918002: xml2: please include examples in the package
Package: xml2 Version: 0.5-2 Severity: normal Hi, one of the reasons to include documentation in the Debian package instead of referring to an online URL is that the remote resource might disappear anytime. This just happened with http://dan.egnor.name/xml2/ref and http://dan.egnor.name/xml2/examples that are referenced from the xml2 man page. But archive.org still has them, so it should be possible to retrieve them from there and add them to the package. Thanks! cheers, josch
Bug#983087: sbuild-createchroot misses usr/libexec/qemu-binfmt/ directory
Quoting Michael Tokarev (2021-02-22 10:49:12)
> The thing is that since quite some time ago, there's no need to mess up with
> the qemu-user-static binfmt interpreter at all, it all just works without any
> additional setup/preparation due to the fix-binary binfmt-misc flag (which
> keeps the interpreter open in the main system, so it works fine within all
> chroots without being present there). It works since kernel 4.8 and QEMU
> Debian package 2.12 (Apr-2018).
That's cool! Maybe there is a good query for codesearch.d.n to find other
remaining instances where packages are not away from this?
> > for emulator in $(update-binfmts --find "$shell"); do
> > dst="${CHROOT_PATH}$emulator"
> > if [ ! -e "$emulator" ]; then
> > info "Missing emulator: $emulator; not enabling binfmt support"
> > else
> > if [ ! -e "$dst" ]; then
> > mkdir -p "$(dirname "$dst")"
> > touch "$dst"
> > fi
> > mount --bind "$emulator" "$dst"
> > mount -o remount,ro,bind "$dst"
> > fi
> > done
> >
> > Thus, adding the tag "patch".
>
> The whole thing isn't needed for qemu and all the binfmt handling can be
> removed
> now.
Great, time to remove it, then. :)
> > Michael, your change in qemu introduced this problem. Schroot is currently
> > orphaned. Since you are responsible for this change in qemu, could you make
> > an
> > NMU of schroot with above fix? Thanks!
>
> Oww.. orphan.. that's pity.
Indeed. On the plus side, it means we can just NMU things without waiting for
maintainer action. ;)
> Okay, I'll take a look at it.
>
> Thank you for the analisys!
Thank you for looking into it! :)
cheers, josch
signature.asc
Description: signature
Bug#983087: sbuild-createchroot misses usr/libexec/qemu-binfmt/ directory
Hi Roger, Quoting Roger Leigh (2021-02-23 22:41:32) > On 22 Feb 2021, at 12:00, Johannes Schauer Marin Rodrigues > wrote: > > > >>> Michael, your change in qemu introduced this problem. Schroot is currently > >>> orphaned. Since you are responsible for this change in qemu, could you > >>> make an > >>> NMU of schroot with above fix? Thanks! > >> > >> Oww.. orphan.. that's pity. > > > > Indeed. On the plus side, it means we can just NMU things without waiting > > for > > maintainer action. ;) > > You can always open a MR against the upstream GitLab repo (branch > schroot-1.6) for any modifications you make to the code (not the Debian > packaging). https://gitlab.com/codelibre/schroot > <https://gitlab.com/codelibre/schroot> cool to hear from you again! And nice to see that there are new commits in the upstream git repo. :) Also feel free to ping me once there is a new schroot upstream version that needs packaging. Thanks! cheers, josch signature.asc Description: signature
Bug#990334: sbuild: Make usage of zfs snapshot/rollback and clone
Control: reassign -1 schroot Quoting Juri Grabowski (2021-06-25 23:00:39) > overlayfs doesn't work with ZFS right now. I mean, that through zfs > snapshot/rollback and clone features we can achieve better performance in > spawning and destroying new schroots. Possibly. But if so, then that's something that schroot has to offer. Not sbuild. signature.asc Description: signature
