get me Rolex or Cartier or Breitling
Get the Finest Rolex Watch Replica ! We only sell premium watches. There's no battery in these replicas just like the real ones since they charge themselves as you move. The second hand moves JUST like the real ones, too. These original watches sell in stores for thousands of dollars. We sell them for much less. - Replicated to the Smallest Detail - 98% Perfectly Accurate Markings - Signature Green Sticker w/ Serial Number on Watch Back - Magnified Quickset Date - Includes all Proper Markings http://www.chooseyourwatch4u.com/ you stereography me transfinite me [2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#751767: blt breaks python-matplotlib
On Mon, Jun 16, 2014 at 03:00:36PM +0200, Martin Lutz wrote: > after upgrading blt to version 2.4z-9 the package python-matplotlib becomes > unusable. > Ditto the package 'look' and presumeably quite a bit of stuff that uses python-tk. It seems that the lastest upload of blt ships libBLT.2.4.so.8.6 rather than ...5 Neil -- signature.asc Description: Digital signature
Re: sendmail
On Mon, 14 Jul 2014 09:34:15 +0100 Michael Grant wrote: > I have noticed that sendmail is quite out of date on wheezy and there > appears to be no backport of the recent version and jessie seems to be > getting the same version as wheezy at the moment. > > Is there no maintainer for the sendmail package on debian? Correct. https://packages.qa.debian.org/s/sendmail.html "This package has been orphaned. This means that it does not have a real maintainer at the moment. Please consider adopting this package if you are interested in it. Please see bug number #740070 for more information." > Is there > someone who is 'responsible' for sendmail on debian these days? No individual, the Debian QA Group in general, it then comes down to whether someone wants to spend time on it. For sendmail, that does not include me. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: PGP signature
Re: Please resume nautilus-image-converter to testing/sid repos
On Sat, 10 Sep 2022 14:05:29 -1000 "W. Wayne Liauh" wrote: > We have been heavy users of nautilus-image-converter for many years. > This is one of the best features of nautilus. Please add it back to > the testing/sid repositories. Thanks a whole lot. Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017448 RM: nautilus-image-converter -- RoQA; unmaintained, doesn't work with nautilus 43 """ nautilus-image-converter was orphaned years ago. [1] The upstream project has been archived so is no longer receiving bug reports or fixes. [2] Nautilus 43 is a major change to the extension API. It would require someone to convert nautilus-image-converter to GTK4. """ Therefore, please remove nautilus-image-converter from Debian. So nautilus-image-converter is not likely to be added back to testing or sid, the problem lies with the upstream code, not the Debian packaging. -- Neil Williams li...@codehelp.co.uk https://linux.codehelp.co.uk pgpBeFv4p_JCz.pgp Description: OpenPGP digital signature
Re: Identify original submitter of tac_plus package
On Tue, 8 Nov 2022 15:07:49 +0100 Zouze Eater wrote: > Hi Team, > > is there a way to identify the original submitter of a package > integrated to debian package list ? Note: Personally, I have no interest in this package specifically and I will not get involved in reintroducing it. I'm only pointing you at the information that exists. It is up to you to work out how to proceed, if at all. I am not willing to respond to further questions on this package. The information you requested is on the page you provided - the link at tracker.debian.org. The first submission of the package was: https://tracker.debian.org/news/215922/accepted-tacacs-40419-4-source-all-amd64/ Contact information for the person who made that upload is in that file. Whether that person is still active is no longer a concern for Debian because the package has been removed. As a volunteer, that person may or may not respond to your questions, there is no obligation. From the orphaning bug report (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838701), it would seem that he is no longer active, at least as far as this code is concerned. Also on the tracker page is a link to the last available copyright information for the package, under "versioned links" https://tracker.debian.org/media/packages/t/tacacs%2B/copyright-4.0.4.27a-3 which includes information on the original download location. The VCS for the package has now been deleted, the package was never migrated from an old service (alioth) to the new (salsa), so the old VCS link is a 404. (The migration would have needed the maintainer to be active but the package had already been removed.) The package will need substantial work to be brought up to date to include all the required changes since the last upload by the maintainer. See https://tracker.debian.org/news/1062601/removed-40427a-3-from-unstable/ for the reasons for removal. The largest problem is going to be that the package needs Python2 - the code would have to be ported to Python3 before anything else happens. See https://mentors.debian.net/ for some idea on how you can get that work done. (It seems unlikely that anyone else cares.) > In fact i'm from a big company that used a forked version of tac_plus > daemon ( https://tracker.debian.org/pkg/tacacs%2B ) for 15 years, and > would like to give back our internal developments contributons to the > open source community. > > But first, we have to identify the "nearest" open source version > available version in terms of code base. > > Is it a fixed version of a "shruberry" version ? https://shrubbery.net/tac_plus/ is still shown as the homepage and download location if that's what you mean. That page doesn't seem to have been updated since 2014, which matches the last year of the last maintainer upload to Debian. It may be best simply to push your code to a public git repository (like github) and let people find it, if they want it. -- Neil Williams li...@codehelp.co.uk https://linux.codehelp.co.uk pgpmiewqwsPoC.pgp Description: OpenPGP digital signature
Re: dome
On 09/02/11 19:49, fcel2001 wrote: > hi > > why "dome" packet is not included in debian version later than lenny ? > http://packages.debian.org/lenny/dome http://packages.qa.debian.org/d/dome/news/20090526T070156Z.html http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419082 RM: dome -- RoQA; orphaned, upstream is dead, better alternatives, low popcon Please see the following reasons for the removal request: * Package is orphaned. * Upstream is dead (latest release is from 2002). * Better alternatives. * Few users - a popcon of 56 users only. There are no reverse depends. > Before finding this packet, I was asked to create a packet from source > or to submit it to wnpp http://www.debian.org/devel/wnpp/ as you can see > here: http://forum.debianizzati.org/viewtopic.php?f=17&t=42699 > > now what should I do ? Take the source code from Lenny, create an account somewhere like SourceForge and fix the code. Learn how to package for Debian, use mentors.debian.net to find a sponsor (maybe) and reintroduce the package as the new upstream developer. OR Just use the package from Lenny. It hasn't changed - that's the main reason it was removed, along with no evidence of any significant user-base. -- Neil Williams = http://www.linux.codehelp.co.uk/ signature.asc Description: OpenPGP digital signature
Bug#613758: gnome-pilot-conduits-data: missing Replaces on gnome-pilot-conduits 2.0.17-2
tag 613758 + pending severity 613758 important retitle 613758 Missing Replaces on gnome-pilot-conduits <= 2.0.17-2 quit On Thu, 17 Feb 2011 01:51:41 +0100 Vincent Lefevre wrote: > Package: gnome-pilot-conduits-data > Version: 2.32.1-1 > Severity: grave > Justification: renders package unusable > > I got the following error: > > Selecting previously deselected package gnome-pilot-conduits-data. > Unpacking gnome-pilot-conduits-data (from > .../gnome-pilot-conduits-data_2.32.1-1_all.deb) ... > dpkg: error processing > /var/cache/apt/archives/gnome-pilot-conduits-data_2.32.1-1_all.deb (--unpack): > trying to overwrite > '/usr/share/locale/wa/LC_MESSAGES/gnome-pilot-conduits.mo', which is also in > package gnome-pilot-conduits 2.0.17-2 It's a missing Replaces entry in the control file. A simple dpkg --force-overwrite -i /var/cache/apt/archives/gnome-pilot-conduits-data_2.32.1-1_all.deb will fix your problem in the meantime. I'll upload the fix tonight. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp00Cdfty2sw.pgp Description: PGP signature
Re: Join QA team
On Wed, 6 Apr 2011 10:51:30 -0500 Daniel Echeverry wrote: > Hi, > > I'm Daniel Echeverry and I want to join the team to maintain orphans > packages, I've been using free software from 5 years ago, and I love GNU > Debian for your philosophy, quality and great community ! First thing to do is a fair bit of reading. Have you tried doing any packaging already? http://www.debian.org/devel/ From that page, you must read the Policy Manual, Developers Reference and the New Maintainer Guide. It's often good to work with an orphaned package whilst going through these guides. http://mentors.debian.net/cgi-bin/welcome Probably the easiest way to get started is actually to triage some of the bugs outstanding against orphaned packages. Try to reproduce the problems, add comments to those bugs which you can't reproduce. There isn't going to be a lot of advice on this list, the best place for packaging advice is: http://lists.debian.org/debian-mentors/ I don't have time to sponsor uploads, so I can't help much more than point you at other places where you can ask questions and find out how things work. HTH -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp76KTPi9R8I.pgp Description: PGP signature
Re: RM: mma -- RoQA; unused, orphaned for a long time, dead upstream
On Tue, 7 Jun 2011 15:07:54 +0200 Ronny Standtke wrote: > GNU Solfege (http://packages.debian.org/squeeze/solfege) needs mma for > several exercises. Could you please revert the removal of this package > from Debian? The short answer is no. solfege should have declared the dependency on mma, or used a Recommends. (Suggests would not have prevented removal.) mma was removed Wed, 01 Sep 2010 and it's taken this long for someone to notice? Doesn't look like anyone really cares enough about it. The only way mma will get back into Debian is if someone takes on the role of maintaining it upstream, updating it, packaging it and then introducing it into Debian. That *might* get it back into unstable and thence into testing, so that it would be available for Wheezy. There is no magic "undo" button for a package removal. There is no good reason to introduce mma back into Squeeze - the best option for those who have not noticed the removal for 9 months is to simply pull in the mma package from Lenny (oldstable). Before Wheezy is released, oldstable will be cleared out and will then be replaced by Squeeze when Wheezy becomes stable. Therefore, you only have until the Wheezy release process starts to be able to get mma from Lenny - after that, it will need to be via archive.debian.org -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp4SeDNth278.pgp Description: PGP signature
Re: [i8kutils] i8kmon man page error
On Sat, 18 Jun 2011 03:15:34 +0200 Nils Dagsson Moskopp wrote: > Hello maintainer of the i8kutils package, > > the man page of i8kmon names „/etc/default/i8kmon“ and „/etc/i8kmon“ as > the configuration file; this is wrong. The correct configuration > file is „/etc/i8kmon.conf“. Please change the manpage accordingly. There is much more chance of this being fixed if you report a bug against the i8kutils package - wishlist or minor severity would seem appropriate. http://www.debian.org/Bugs/Reporting -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpkrz0ruMFBG.pgp Description: PGP signature
Bug#630974: ddccontrol: can't start because missing library libpci.so.2
tag 630974 + unreproducible tag 630974 + moreinfo quit On Sun, 19 Jun 2011 13:02:20 +0200 igno...@freemail.hu wrote: > | 20022 /home/ignotus % ddccontrol > | ddccontrol: error while loading shared libraries: libpci.so.2: cannot open > shared object file: No such file or directory > | zsh: exit 127 ddccontrol > ` > > Why does it depend on both libpci.so.3 and libpci.so.2? Umm, the package from the archive doesn't: $ wget http://ftp.uk.debian.org/debian/pool/main/d/ddccontrol/ddccontrol_0.4.2-8_i386.deb $ dpkg -f ddccontrol_0.4.2-8_i386.deb Depends ddccontrol-db (>= 20060308), libc6 (>= 2.2), libddccontrol0 (>= 0.4.2), libpci3 (>= 1:3.1.7), libxml2 (>= 2.6.27), zlib1g (>= 1:1.1.4) $ dpkg -X ddccontrol_0.4.2-8_i386.deb . $ ldd ./usr/bin/ddccontrol linux-gate.so.1 => (0xf7747000) libddccontrol.so.0 => not found libz.so.1 => not found libxml2.so.2 => not found libpci.so.3 => not found libc.so.6 => /lib32/libc.so.6 (0xf75d6000) /lib/ld-linux.so.2 (0xf7748000) $ file ./usr/bin/ddccontrol ./usr/bin/ddccontrol: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, stripped $ sha256sum ./usr/bin/ddccontrol fab394e3448d8b974d83e48e64533f3a6efb83d82c5c6914026fbab68cdcec92 ./usr/bin/ddccontrol $ sha256sum ddccontrol_0.4.2-8_i386.deb f3ed82fdc8c0f5b1118fe555af192ee8d12888506349a5b555626c139c7da5a2 ddccontrol_0.4.2-8_i386.deb which matches the buildd report: f3ed82fdc8c0f5b1118fe555af192ee8d12888506349a5b555626c139c7da5a2 82448 ddccontrol_0.4.2-8_i386.deb https://buildd.debian.org/status/fetch.php?pkg=ddccontrol&arch=i386&ver=0.4.2-8&stamp=1307106862 My main system is amd64, so I checked in an amd64 pbuilder chroot and ddccontrol runs fine: Setting up ddccontrol (0.4.2-8) ... # ldd /usr/bin/ddccontrol linux-vdso.so.1 => (0x7fff36f7b000) libddccontrol.so.0 => /usr/lib/libddccontrol.so.0 (0x7f27b5b99000) libz.so.1 => /usr/lib/libz.so.1 (0x7f27b5982000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x7f27b5624000) libpci.so.3 => /usr/lib/libpci.so.3 (0x7f27b5419000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f27b5096000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f27b4e91000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f27b4c0f000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f27b49f9000) /lib64/ld-linux-x86-64.so.2 (0x7f27b5daa000) # ddccontrol ddccontrol version 0.4.2 Copyright 2004-2005 Oleg I. Vdovikin (o...@cs.msu.su) Copyright 2004-2006 Nicolas Boichat (nico...@boichat.ch) This program comes with ABSOLUTELY NO WARRANTY. You may redistribute copies of this program under the terms of the GNU General Public License. Usage: ... Can you check the equivalent checksums etc? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpmOCQMP746f.pgp Description: PGP signature
Re: .la file removal, multiarch for plugins
On Sun, 10 Jul 2011 16:48:16 +0200 Lionel Elie Mamane wrote: > (Please CC me on replies, as I'm quite behind on reading MLs. M-F-T > set accordingly.) From the bug report: > In the unusual case that your > package uses libltdl directly, it is still necessary to empty the > dependency_libs part of all .la files remaining in the package. i.e. there is no issue here. If you want to retain the .la file, just ensure that dependency_libs is cleared. libltdl uses a different field in the .la file which does not need to be touched. .la file removal is fine for most packages, those which need to retain the .la file must simply clear the dependency_libs field. Simple. > OK. What is slightly unclear to me, is that "being loaded by libltdl" > is a thing that is external to the package. The usual mechanism is as plugins for a specific library, so why would random third-party operations be directly using plugins which are part of a different library? If libfoo has plugins libfoo-magic and libfoo-super, those plugins would normally be only accessible via calls made via libfoo itself. bar -> dynamic linkage against libfoo bar uses a symbol exported by libfoo and knows nothing about plugins. libfoo uses the plugin to complete the action requested by bar libfoo processes the results of the plugin and serves that as the return value to bar. e.g. bar contains a call to: const char * getDatabaseName (fooConnection *c) libfoo implements this symbol by loading the "database" plugin. The plugin sorts out the details. libfoo handles the plugin return value and then returns a string to bar In that scheme, bar has no need to know about the plugins. The .la file won't matter as long as libfoo has a way of finding it's own plugins. The .la file is not the only way of locating the plugin. Other methods which don't use libltdl do not necessarily need the .la file either. > If there is *one* program > anywhere (even not packaged in Debian or local to an enterprise) that > uses libltdl to load library foo, we break that program by removing > the .la file. I don't see a valid reason for a third-party program to try to directly load plugins which are part of a different library. > So I don't really understand why we (we=Debian) consider > it a good thing to remove the .la file, even if nothing in Debian, or > nothing we know of, uses libltdl to load that library. You are free to retain the .la file for any package - as long as the dependency_libs field is cleared. Why would some random library be expected to support being opened via a .la file instead of normal dynamic linkage? > > With MultiArch, you may still get problems here because those > > directories will be changing. If those paths are within the sole > > control of this package, fine - both parts can change at the same time. > > If you're relying on paths which come from a separate source package, > > it'll likely break. > > I suppose we'll have a controlled / synchronised migration for all > ODBC drivers? Or should each driver just unilaterally stick > $(dpkg-architecture -qDEB_HOST_MULTIARCH) somewhere in the path? > > I presume that > /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/odbc > is better than > /usr/lib/odbc/$(dpkg-architecture -qDEB_HOST_MULTIARCH) This is covered in the MultiArch docs but from my understanding, it would be: /usr/lib/arm-linux-gnueabi/odbc/ e.g. libgl1-mesa-dri: /usr/lib/x86_64-linux-gnu/dri -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpR8fOBkABWc.pgp Description: PGP signature
Bug#625413: 0.3.6-1 from mentors is also affected
The PTS for trousers mentions a new upstream version which is available from mentors. This is just to update the bug report that the new version is affected by the same bug, before people waste time looking at that version for an RC bug fix. http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=trousers gcc -DPACKAGE_NAME=\"trousers\" -DPACKAGE_TARNAME=\"trousers\" -DPACKAGE_VERSION=\"0.3.6\" -DPACKAGE_STRING=\"trousers\ 0.3.6\" -DPACKAGE_BUGREPORT=\"trousers-t...@lists.sf.net\" -DPACKAGE=\"trousers\" -DVERSION=\"0.3.6\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_OPENSSL_BN_H=1 -DHAVE_OPENSSL_ENGINE_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHTOLE_DEFINED=1 -DHAVE_DAEMON=1 -I.-DAPPID=\"TCSD\ TCS\" -DVAR_PREFIX=\"/var\" -DETC_PREFIX=\"/etc\" -DTSS_BUILD_TRANSPORT -DTSS_BUILD_TICK -DTSS_BUILD_COUNTER -DTSS_BUILD_RANDOM -DTSS_BUILD_CAPS -DTSS_BUILD_DIR -DTSS_BUILD_PCR_EVENTS -DTSS_BUILD_SIGN -DTSS_BUILD_QUOTE -DTSS_BUILD_SEAL -DTSS_BUILD_CHANGEAUTH -DTSS_BUILD_BIND -DTSS_BUILD_OWN -DTSS_BUILD_PS -DTSS_BUILD_ADMIN -DTSS_BUILD_AIK -DTSS_BUILD_EK -DTSS_BUILD_CERTIFY -DTSS_BUILD_KEY -DTSS_BUILD_MAINT -DTSS_BUILD_MIGRATION -DTSS_BUILD_PCR_EXTEND -DTSS_BUILD_SELFTEST -DTSS_BUILD_NV -DTSS_BUILD_AUDIT -DTSS_BUILD_SEALX -DTSS_BUILD_TSS12 -DTSS_BUILD_DELEGATION -DTSS_BUILD_QUOTE2 -DTSS_BUILD_CMK -g -O2 -m64 -DBI_OPENSSL -DTSS_NO_GUI -W -Wall -Werror -Wno-unused-parameter -Wsign-compare -I../include -DTCSD_DEFAULT_PORT=30003 -DTSS_VER_MAJOR=0 -DTSS_VER_MINOR=3 -DTSS_SPEC_MAJOR=1-DTSS_SPEC_MINOR=2 -I../../src/include -c -o libtcs_a-rpc_evlog.o `test -f 'rpc/tcstp/rpc_evlog.c' || echo './'`rpc/tcstp/rpc_evlog.c rpc/tcstp/rpc_evlog.c: In function ‘tcs_wrap_GetPcrEvent’: rpc/tcstp/rpc_evlog.c:36:27: error: variable ‘totalSize’ set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make[3]: *** [libtcs_a-rpc_evlog.o] Error 1 make[3]: Leaving directory `/home/neil/code/debian/src/trousers/trousers-0.3.6/src/tcs' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/neil/code/debian/src/trousers/trousers-0.3.6/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/neil/code/debian/src/trousers/trousers-0.3.6' dh_auto_build: make -j1 returned exit code 2 make: *** [build] Error 2 This is the same error as in 0.3.5 -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpwsfbmLJkWu.pgp Description: PGP signature
Bug#639859: apt-build fails to build packages ; it conflicts with apt
retitle 639859 apt-build uses outdated apt configuration settings tag 639859 - patch quit On Wed, 31 Aug 2011 02:40:25 +0200 Laurent Dard wrote: > Package: apt-build > Version: 0.12.38 > Severity: grave > Tags: sid wheezy patch Dropping the patch tag because the patch is incomplete (although likely to be along most of the right lines). > # apt-build install hello > it fails with: > >W: Failed to fetch > >file:/var/cache/apt-build/repository/dists/apt-build/Release Unable to find > >expected entry 'main/binary-amd64/Packages' in Release file (Wrong > >sources.list entry or malformed file) apt-build needs to update the configuration string which it passes to apt, along the same lines as recent updates in multistrap, xapt and other tools which use apt in custom locations. > >E: The value 'apt-build' is invalid for APT::Default-Release as such a > >release is not available in the sources This is another instance of #637434 and may well need a similar patch which can be seen in Emdebian SVN: http://www.emdebian.org/trac/changeset/8062 AFAICT if the test system does not use a Default-Release, this bug won't occur. apt-build *might* have to assert unstable as the Default-Release or try to replicate the system setting somehow. I don't use apt-build. > I erased "/var/cache/apt-build" and applied the following patch to get rid apt-build should do this anyway. xapt has a similar --clean option explicitly to do this kind of thing. If it doesn't, this would warrant another stage to the patch or a new bug report (severity important). > Unfortunately, it doesn't solve the problem. > "apt-get update" keeps saying: > E: The value 'apt-build' is invalid for APT::Default-Release as such a > release is not available in the sources > > Maybe an apt bug rather than an apt-build bug ? No, it will still be an apt-build bug. The question is what do you expect apt-build to do if Default-Release is set on your own system? Build for unstable (Debian expectation) or build for whatever is the Default-Release on your system? Once that is decided, the final tweak to the patch should be fairly trivial. apt-build is an orphaned package (and has been orphaned for a v.long time) and has no maintainer. If you're doing this much work on apt-build, maybe you should read the orphaning bug (#365427) and see if you can work with those who have also expressed an interest but not actually made the upload as maintainer. Maybe even form a team. Otherwise, once the Wheezy freeze starts, apt-build could well be removed. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpRIXg2LEd7s.pgp Description: PGP signature
Bug#649274: Forming a new upstream for timidity (and reporting various issues with current deb pkg)
al of timidity from Debian unstable and testing in ~ 10 days. > As said I hope to do a new upstream release soon, amongst a lot of bugfixes > this will also include IPV6 support for the relevant bits of timidity. If timidity doesn't get IPv6 support soon, it will end up being removed from Debian due to other release requirements anyway. That is another good reason to remove the current version of timidity unless someone steps up to introduce the new upstream release. So, overall, there are three very good reasons to remove the current timidity version from Debian - each of which is sufficient reason for removal on their own. Someone needs to adopt it and get your new release uploaded real soon now. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpzy7OlXDZVN.pgp Description: PGP signature
Re: 642371 to Should the scim-bridge package be removed?
On Tue, 24 Jan 2012 00:09:22 + Dale Amon wrote: > On Mon, Jan 23, 2012 at 10:27:22PM +, Debian Bug Tracking System wrote: > > Processing commands for cont...@bugs.debian.org: > > > > > retitle 642371 Should this package be removed? > > Bug #642371 [src:scim-bridge] RM: scim-bridge -- ROM; dead upstream, > > unmaintained, RC bugs, unfit for KDE4/QT4 > > Changed Bug title to 'Should this package be removed?' from 'RM: > > scim-bridge -- ROM; dead upstream, unmaintained, RC bugs, unfit for > > KDE4/QT4' > > > retitle 637066 Should this package be removed? > > Bug #637066 [src:gramofile] RM: gramofile -- RoM; unmaintained upstream, > > low popcon > > Changed Bug title to 'Should this package be removed?' from 'RM: gramofile > > -- RoM; unmaintained upstream, low popcon' > > > thanks > > Stopping processing here. > > > > Please contact me if you need assistance. > > -- > > 637066: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637066 > > 642371: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642371 > > Debian Bug Tracking System > > Contact ow...@bugs.debian.org with problems > > Answer to topic: NO Unless someone intends to write new software > to parse tapes and record tracks into individual wav files... Unless someone intends to look after the existing software and maintain it within Debian then the answer will be yes - remove it. Fix it or let it be removed due to inaction. Simple. Unmaintained software which is dead upstream and has not been ported to updated libraries in Debian is always a candidate for removal. Those who care about this software need to step up and do the work. That's all there is to it. It's not enough to just protest or complain - unless someone does the work, the package remains a candidate for removal. The RC bugs mentioned originally don't seem to be open any longer, so there is time for the work to be done. If the work isn't done, I'll reassign the removal bug myself. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpaX1SZMzPkD.pgp Description: PGP signature
Re: apt-build wish
On Tue, 31 Jan 2012 12:09:18 +0100 Jonathan Aquilina wrote: > Is this the right place to get wish list features for apt-build worked on? No. File a wishlist bug against the package after checking what bugs are already outstanding: http://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=apt-build $ reportbug apt-build Generally, if you are sufficiently interested in an orphaned package to want new features, you should work on those features yourself and submit a patch then adopt the package as maintainer. If you don't / can't, it's unlikely that someone else will because nobody else is doing work on the package - that's why it is orphaned. Orphaned packages either get removed or get their RC bugs fixed (by someone interested in the release, not the package) and not a lot else. If the fix is truly minor (e.g. applying a tested patch), it *might* get applied by someone fixing other stuff. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp5iYxUZ7pnN.pgp Description: PGP signature
Bug#642371: RM: scim-bridge -- ROM; dead upstream, unmaintained, unfit for KDE4/QT4
retitle 642371 RM: scim-bridge -- RoQA; dead upstream, unmaintained, unfit for KDE4/QT4 retitle 642560 RM: scim-bridge-el -- RoQA; removal of dependency, no response from maintainer reassign 642371 ftp.debian.org severity 642371 normal reassign 642560 ftp.debian.org quit On Sun, 19 Feb 2012 03:25:41 +0800 Aron Xu wrote: > Hi, > > The question in subject line should be revisited now. I'm not sure > about what's your opinions now, as there still isn't any activity to > implement Osamu's proposal (and a QA upload underway). There's no need to pursue this through another round of non-responses. There have been no changes since : Date: Tue, 24 Jan 2012 09:20:19 + > Unless someone intends to look after the existing software and maintain > it within Debian then the answer will be yes - remove it. Either fix it > or let it be removed due to inaction. Simple. > > Unmaintained software which is dead upstream and has not been ported to > updated libraries in Debian is always a candidate for removal. > > Those who care about this software need to step up and do the work. > That's all there is to it. It's not enough to just protest or complain - > unless someone does the work, the package remains a candidate for > removal. The RC bugs mentioned originally don't seem to be open any > longer, so there is time for the work to be done. > > If the work isn't done, I'll reassign the removal bug myself. So reassigning this bug to ftp.debian.org for removal of scim-bridge. Nobody has stepped up to do the work in the previous month, so there can be no complaints about the removal. Also seeking the removal of scim-bridge-el as there has been no response to #642560 re the removal of scim-bridge since Sat, 24 Sep 2011. If someone wants eventually does the work, the package can be re-introduced but it's been 5 months since the original bug report, so that seems unlikely. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpEvaO9XocGQ.pgp Description: PGP signature
Bug#661671: closed by Paul Wise (defoma is being removed from Debian)
On Sat, 10 Mar 2012 22:15:42 +0400 Olleg Samoylov wrote: > > > defoma is in the process of being removed from Debian, there is no point > > > filing bugs against it since they will be closed when fontconfig stops > > > build-depending on it and it is removed. > > Don't just close this bug. :) Closing is the right thing to do. It remains closed. It's not as if the original bug report contained anything which would have helped fix the bug if defoma was still being developed. The only thing that came out of your bug report was yet another reason to remove defoma, not that it lacked sufficient reasons already. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651494 for details of the removal. > At least you have to change description of > package defoma to: "Defoma doesn't work, don't have to work and will not > work, this is not a bug, but a feature". :) Packages which are scheduled for removal cannot have their package descriptions modified to indicate removal. Changing the description requires a new upload which is a complete waste of time when the next action on the package will be deletion. (Many packages are removed because the package fails to build, so making a new upload would be impossible. If the build could be fixed, the package probably wouldn't get removed.) When packages are removed, all bugs for that package are closed without any other intervention, no matter the severity of the bug. When defoma is finally removed, you would have received much the same message from ftp-masters. There is no point keeping bugs open against defoma. There is no way that your bug report can be fixed other than by removing defoma, so the bug is better closed. If your fonts aren't working, purge defoma from your system and see whether fontconfig is actually working. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpcTDadjIw1E.pgp Description: PGP signature
Bug#621645: gnunet - new upstream
retitle 621645 gnunet - new upstream available quit On Sun, 18 Mar 2012 21:01:04 +0100 "Jan-Hendrik (hennr) Peters" wrote: > 0.9.2 is out. > > Any progress? From the PTS: http://packages.qa.debian.org/g/gnunet.html > This package has been orphaned, but someone intends to maintain it. > Please see bug number #660438 for more information. 0: An orphaned package has no maintainer, so the bug emails go to a mailing list. It would help enormously if the subject line and contents of the emails to the bug report actually named the package concerned. 1: The indication that someone intends to maintain it comes from the PTS as the orphaning bug has been retitled to an ITA. The owner of that ITA is CC:'d. That's about all that can be said about gnunet AFAICT. -- http://packages.qa.debian.org/g/gnunet.html Neil Williams = http://www.linux.codehelp.co.uk/ pgpqPgp1fydCs.pgp Description: PGP signature
Bug#665535: glabels adoption
If you can add a fix for #665535 using the information from the linked build log [0], I can sponsor the upload - although this is likely to be a single sponsoring to avoid an RC bug arising in the future. (#665535 needs to be fixed by either your next upload or the upload immediately following that or glabels will get an RC bug once glib is updated in unstable.) However, I will stipulate that you need to fix #660642 as that has a patch which, although it might not apply directly, does appear to be the right fix. (It's a fix which should also go upstream because the upstream team who released 2.2.8 clearly didn't understand internationalisation of desktop files properly.) If either of these bugs are fixed in the new upstream version, you need to update those bug reports as soon as possible - tagging them pending and adding them to the Closes listing in debian/changelog. If the bugs are fixable with changes, you'll need a 3.0.0-2 upload to mentors.debian.net with the changes. (Same if your 3.0.0-1 build fails any of my sponsoring requirements [1]). I don't know if mentors.debian.net still allows re-uploads without a change in the debian changelog version, I'd prefer that any changes are done as 3.0.0-2, even adding new Closes listings to the changelog itself. I haven't even looked at your 3.0.0-1 package yet and there is zero chance of me sponsoring an upload until you've shown that #665535 is fixed. (Best way to do that is to install the glib from experimental inside a pbuilder sid chroot and build the package there.) As it is a new upstream version, you also need to test each of the existing bug reports with the new version and mark those which still apply as "found 3.0.0-2", those which you can reproduce with 2.2.8-3 but fixed in 3.0.0-2 need to be added to your 3.0.0-2 debian/changelog as Closes, those which you cannot reproduce in 2.2.8-3 need to be tagged "moreinfo" and/or "unreproducible" in the BTS and submitters asked if the bug still occurs. (I'll take care of including the 3.0.0-1 changelog entry in the eventual upload, as well as the -sa to cover the new .orig tarball.) My normal sponsoring requirements still apply. [1] Let me know when you have a suitable upload at mentors.debian.net. The new glib is due to arrive in unstable within a few weeks - if a suitable version is not ready by that time, I'll do a QA upload of 2.2.8-4 to fix just bugs #665535 and #660642 but I would prefer that the package gains a maintainer who can fix and triage the rest of the bugs too. [0] http://people.debian.org/~biebl/glib-single-include/glabels_2.2.8-3.log [1] http://people.debian.org/~codehelp/#sponsor -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpktdI6okIR8.pgp Description: PGP signature
Re: x/xloadimage fixes
On Fri, 13 Apr 2012 12:52:52 +0200 Christian Weisgerber wrote: > Hi, > here are a some fixes for xloadimage that I've had in the OpenBSD > package for a long time and that Debian might want to pick up: It's unlikely that these will be applied via the mailing list - debian-qa only deals with packages which have no maintainer currently and fixes are only applied when someone has a passing interest in the package or there are release-critical bugs against an orphaned package. Please file a bug report against the package, attaching the patches and then if someone needs to do some work on the package for some other reason, it's possible that these patches will be applied as part of that fix. http://www.debian.org/Bugs/Reporting -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpfnIzoRrLNL.pgp Description: PGP signature
Bug#673040: [adept] Short descriptions displayed instead of extended descriptions
severity 673040 normal done On Tue, 15 May 2012 12:44:37 -0400 Filipus Klutiero wrote: > Package: adept > Version: 3.0~beta7.2+qa2 > Severity: serious No justification for this severity. Downgrading. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpPO3QGOpFgv.pgp Description: PGP signature
Re: Bug#673040: [adept] Short descriptions displayed instead of extended descriptions
On Tue, 15 May 2012 14:34:44 -0400 Filipus Klutiero wrote: > severity 673040 serious Don't do severity ping-pong. adept is orphaned, so I lowered the severity as part of the QA team. You, as submitter, must provide justification for the severity. Anyone else on the QA team agree on this severity? > adept is a package manager, displaying wrong descriptions makes it unfit > for release. Not true - it is a bug but as long as adept can install packages from the package names and get the dependencies right, upgrade packages and remove packages, it is basically functional. > For reference, see #657557 That's for the www.d.o website, not a package! Completely inapplicable. Justification should reference Debian Policy, as advised by reportbug itself. adept is not unusable without extended descriptions, it is a bit harder to use but that is NOT a justification for a release critical bug, it's just a bug. Just what do you expect to happen by making adept have an RC bug when it is orphaned? Do you want to have it removed from Debian completely? Orphaned bugs rarely receive bug fixes, more likely that someone will seek to remove the package. adept has already missed the Squeeze release by being removed before that release. If it's going to miss Wheezy as well, it probably is worth removing from Debian entirely. Severity does NOTHING to influence how quickly a bug is fixed, especially with an orphaned package. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpwtdT8HOqxL.pgp Description: PGP signature
Bug#673040: [adept] Short descriptions displayed instead of extended descriptions
On Tue, 15 May 2012 15:20:50 -0400 Filipus Klutiero wrote: > > Don't do severity ping-pong. adept is orphaned, so I lowered the > > severity as part of the QA team. You, as submitter, must provide > > justification for the severity. > > I just did that - adept is unfit for release with this bug. I find that questionable but as nobody else has bothered to do much about adept, it's not worth fighting over it. It's orphaned, it has bugs, nobody is showing any sign of dealing with the existing bugs. I've filed for removal from Debian. #673085 > [...] > >> adept is a package manager, displaying wrong descriptions makes it unfit > >> for release. > > Not true - it is a bug but as long as adept can install packages from > > the package names and get the dependencies right, upgrade packages and > > remove packages, it is basically functional. > > > >> For reference, see #657557 > > That's for the www.d.o website, not a package! Completely inapplicable. > > I'm not sure what you are describing as inapplicable. Comparing a pseudo-package for a website with a package in the archive is just inapplicable. There's no basis for comparison. > I'd expect: > Users to avoid trying adept Nothing to do with the severity of any bugs, that has been happening all of it's own since 2009 according to the popcon graph. > Developers to notice that adept needs love That hasn't happened all the time adept has been orphaned (5 months), it's not likely to happen before the release. > The release team to remove adept from testing, if it can't find love No point just removing from testing. > > Do you want to have it removed from Debian completely? > > Orphaned bugs rarely receive bug fixes, more likely that someone will > > seek to remove the package. adept has already missed the Squeeze > > release by being removed before that release. If it's going to miss > > Wheezy as well, it probably is worth removing from Debian entirely. > > > > > I won't say that adept should be removed from Debian completely. As a > KDE user curious about package management, I find adept interesting to > try. Until it's fixed, it could have a place in experimental. No. That requires an upload and there's obviously nobody willing to do it. Experimental is for packages where there is some development ongoing, not bitrot stuff which has nobody to maintain it. > But > realistically, adept was started in 2005, never made a stable release > since then, is still beta (for KDE 4) and was discontinued over 3 years > ago. I wouldn't expect a stable adept too soon, and doubt it's worth to > have more NMUs. I found this bug with 10 minutes of testing - obviously > nobody's used it since 4 months. So all your bug report has done is to have brought removal closer. OK, that's what happens with RC bugs in orphaned leaf packages more often than not. So be it. #673085 -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpVt6Jlzziak.pgp Description: PGP signature
Re: FTE directory listing
On Mon, 17 Sep 2012 11:18:39 +0100 Sian Mountbatten wrote: > Dear Maintainer * The maintainer for orphaned packages like fte is a mailing list. * Questions on mailing lists will tend to get forgotten. * Feature requests for orphaned packages should be recorded as wishlist bugs against the package. * Wishlist bugs in orphaned packages are not often closed without an existing, tested, patch. * Orphaned packages, by definition, do not have anyone in particular to do ongoing development and issues, if fixed at all, are done on a fire-fighting / fly-by basis. * If an orphaned package is to get any ongoing maintenance, it will need to be adopted and that usually means adopting the upstream development as well. All of this is discernible from the PTS for the package (linked from the BTS) and from the content of qa.debian.org which is listed as the maintainer for orphaned packages. > Is it possible to change the directory listing given by FTE such that >(1) A sub-directory is marked with a d >(2) The mode of files is correctly displayed > Unfortunately, I am not familiar with C++ otherwise I would consider > doing it myself. Therefore, based on the above, the likely answer to your question is no. If you file a bug, maybe someone might do it in some random time period but I wouldn't count on it. If you don't file a bug, the chances of this being done are zero. I did the last QA upload of fte and I am not proposing to do another any time soon. I will certainly not be doing *any* QA uploads until Wheezy is released, other than to close RC bugs. This issue is NOT RC. If fte had an RC bug filed against it, I would be more likely to remove the package than spend any particular effort fixing it because it is obvious that nobody has cared enough about fte to adopt it in the year since the QA upload. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpJ8aOgKT5J8.pgp Description: PGP signature
Bug#524149: blt crash on zoom
On Sun, 20 Jan 2013 22:33:27 -0600 Paul Johnson wrote: > BLT needs fixing RIGHT NO. No more delay. blt is orphaned. This means that it does not have a real maintainer at the moment. Please consider adopting this package if you are interested in it. Please see bug number #664092 for more information. http://www.debian.org/devel/wnpp/orphaned http://packages.qa.debian.org/b/blt.html BTW always use the original bug title as the subject of emails like this because comments on bugs in orphaned packages go to a mailing list which covers several hundred packages. > If the maintainer of this package is not a blt user, I can understand > that this does not seem like a big thing. But, speaking bluntly, blt is > an old piece of software that is barely (if at all maintained) by its > original author. Nevertheless, we are heavily dependent upon it in our > research. All the other distributions except Debian have patched this > thing. Lets step forward. please. Those best placed to fix software are those with an interest in having it fixed. It sounds like this is your scratch, you'll need to fix it - without the attitude. > I first ran into this problem when I was an Ubuntu user. Here's the bug > report about it there. > > https://bugs.launchpad.net/ubuntu/+source/blt/+bug/359857 > > It seems obvious to me this should have been done in Debian in 2010. If > Ubuntu did it, why not Debian. Because nobody cared enough about it to assign it any of their free time. Right now, most people are more concerned about fixing the release and this bug is not release-critical, so it is unlikely to get fixed any time soon unless you do the work. > For details on the fix, please skip down to: > > https://bugs.launchpad.net/ubuntu/+source/blt/+bug/359857/comments/9 > > I did not write the fix. The Fedora blt maintainers wrote two patches > for blt in 2010. Since then, I have been applying those patches to blt > packaging on my Ubuntu and Debian. They work fine. Please look at providing a package via mentors.debian.net - there is help via the mailing list and IRC for preparing the package itself. http://mentors.debian.net/intro-maintainers > Please let me know what is holding us back on this. There is no maintainer, there is nobody interested in doing the work and as a result, the package remains orphaned. I have no personal interest in anything Tcl related and I won't be fixing it. The mentors system is expressly for your situation where you want this fixed but for a sponsor to upload the fixed package, you need to do the work of preparing it as per the mentors guidelines. If you are going to do the work via mentors, then you should adopt the package, following the mentors guidelines for adoption. If you don't do the work, the package and the bug will have to wait until someone else is sufficiently interested and motivated to care about the package. That's the reality of an orphaned package. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpntE8hHElXi.pgp Description: PGP signature
Bug#583846: Bad test case
severity 583846 normal tag 583846 + moreinfo quit Where did you come up with the source code for the test? I think you are missing some steps. (I used to maintain this package but orphaned it due to a lack of time and because I never got around to releasing any code that needed the library. I won't be adopting the package or writing perfect test cases for the same reasons.) Take a look at the test code within the package itself, 'src/backend/sqlite3/test/' but that code isn't directly comparable as it uses internal test namespaces which need further tweaks. SOCI doesn't have particularly good documentation but even so, nothing about your test justifies a severity of 'grave' as the internal test cases do find the backends just fine. True, tests need to do more than just call a single routine but that's just how it goes with orphaned packages like soci. Nobody cares about it anymore. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpIwywhnxeEr.pgp Description: PGP signature
Bug#454212: megahal segfaults as soon as it's launched
Niko Tyni wrote:
Confirmed using etch i386 (though an amd64 processor). Attached output
of megahal and strace.
The attached patch fixes a stack corruption issue on 64-bit architectures
(reading 8 bytes into a 4-byte buffer) and an off-by-one sprintf overflow
in the error and status file name initialization code.
The stack corruption makes megahal reliably crash for me on amd64 every
time it tries to load a saved dictionary.
However, the original problem is on i386 and happens earlier in the
initialization code. I can't reproduce it myself, but I think it might
well be caused by the sprintf overflow. Note that Neil's strace in
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;filename=megahal.trace.log;att=1;bug=454212
has
open("/home/nmcgovern/.megahal/megahal.logi", O_WRONLY|O_APPEND|O_CREAT, 0666)
= 3
and
-rw-r--r-- 1 nmcgovern users 380 2007-12-19 11:37 megahal.logi?
while the intended filename is "megahal.log". So there's definitely at
least some corruption happening here.
Could somebody (Neil?) try if the bug persists with this patch?
Confirmed that this patch fixes the issue, at least on the version in Etch.
This issue probably qualifies for a stable point update (-release in
cc). I can prepare a package if you want.
Cheers,
Neil
--
Neil McGovern
SQA - Amino Communications
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#510274: Reproduced in Lenny
> For every presentation I try to start (sample.mpg, sendmail6.mpg, > v6.mpg), mgp dies with an X error. I've reproduced this on several > systems (including one running pure testing). This might be the same > bug as #400105, though in that report the error message is > different. I can't reproduce this problem with mgp 1.13b-2 (the > version in unstable). $ rmadison mgp mgp |1.11b-7 | etch-m68k | source, m68k mgp |1.11b-7 |stable | source, alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc mgp |1.11b-7 | testing | source, alpha, amd64, arm, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc mgp |1.11b-7 | unstable | m68k mgp |1.13a-1 | unstable | source, alpha, amd64, arm, armel, hppa, hurd-i386, i386, ia64, mips, mipsel, powerpc, s390, sparc Unstable has 1.13a-1 - have you been able to test that version? 1.13a-1 works for me (despite a few warning messages on the console). If this bug is absent in 1.13a-1, debian-release may be happy to allow 1.13a-1 to migrate to fix this bug. In a Lenny chroot, I'm able to reproduce the bug (1.11b-7): X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 75 (X_PolyText16) Serial number of failed request: 206 Current serial number in output stream: 210 Taking a look at the amount of changes . . . -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpY9McOSRsUe.pgp Description: PGP signature
Bug#510274: merging with existing report
package: mgp severity 400105 grave merge 400105 510274 thanks 400105 is the same issue but the fix explored in that report doesn't fix the issue for me - I get a segmentation fault instead. draw.c| 810 ++ globals.c |4 image/compress.c |3 image/imlib_loader.c | 85 image/misc.c |2 image/rlelib.c| 428 - image/send.c | 19 m17n.c| 130 mgp.c | 67 parse.c | 41 print.c | 263 tfont.c | 14 x11.c |6 Some of these changes are trivial: image/rlelib.c| 428 - consists solely of whitespace changes. Most of the changes in draw.c are related to rotation support, as are many of the changes in print.c. Other changes include in the imlib support. mgp might just have to be removed. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgp8d0s9ezcEm.pgp Description: PGP signature
Bug#510274: Reproduced in Lenny
On Sat, 3 Jan 2009 21:47:15 +0100
Peter De Wachter wrote:
> > Neil Williams (03/01/2009):
> > > > For every presentation I try to start (sample.mpg, sendmail6.mpg,
> > > > v6.mpg), mgp dies with an X error. I've reproduced this on several
> > > > systems (including one running pure testing). This might be the
> > > > same bug as #400105, though in that report the error message is
> > > > different. I can't reproduce this problem with mgp 1.13b-2 (the
> > > > version in unstable).
> > >
> > > $ rmadison mgp
> > >mgp |1.11b-7 | etch-m68k | source, m68k
> > >mgp |1.11b-7 |stable | source, alpha, amd64, arm,
> > > hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc mgp |
> > > 1.11b-7 | testing | source, alpha, amd64, arm, armel, hppa,
> > > i386, ia64, mips, mipsel, powerpc, s390, sparc mgp |1.11b-7
> > > | unstable | m68k mgp |1.13a-1 | unstable | source,
> > > alpha, amd64, arm, armel, hppa, hurd-i386, i386, ia64, mips,
> > > mipsel, powerpc, s390, sparc
> > >
> > >
> > > Unstable has 1.13a-1 - have you been able to test that version?
>
> Yes, that version works for me. ("1.13b-2" obviously doesn't exist,
> sorry for the confusion.)
Subsequent to that email, I did verify that 1.13a-1 is apparently OK.
However, the changes between that and Lenny are too numerous to be
considered for migration to fix this bug.
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510274#17
mgp has now been requested for removal from Lenny. The version in
unstable will then migrate after the Lenny release and possibly be
available via backports. Note that mgp is still orphaned, see #509644,
so someone would probably need to adopt it to arrange a backport.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
pgpKfYkZmMz7u.pgp
Description: PGP signature
Bug#514921: [Pkg-gpe-maintainers] Processed: reassign 514921 to libmimedir0, libmimedir-gnome0-dev
On Wed, 11 Feb 2009 21:51:03 + ow...@bugs.debian.org (Debian Bug Tracking System) wrote: > Processing commands for cont...@bugs.debian.org: > > > reassign 514921 libmimedir0,libmimedir-gnome0-dev > Bug#514921: libmimedir0: tries to overwrite file owned by > libmimedir-gnome0-dev > Bug reassigned from package `libmimedir0' to > `libmimedir0,libmimedir-gnome0-dev'. > Barry, your upload of libmimedir 0.5.1-1 introduced the relevant file into libmimedir0 when it does not exist in Lenny: http://packages.debian.org/lenny/amd64/libmimedir0/filelist /usr/lib/libmimedir.so.0 /usr/lib/libmimedir.so.0.0.0 /usr/share/doc/libmimedir0/README /usr/share/doc/libmimedir0/changelog.Debian.gz /usr/share/doc/libmimedir0/changelog.gz /usr/share/doc/libmimedir0/copyright http://packages.debian.org/sid/amd64/libmimedir0/filelist /usr/lib/libmimedir.a /usr/lib/libmimedir.so.0 /usr/lib/libmimedir.so.0.0.0 /usr/share/doc/libmimedir0/README /usr/share/doc/libmimedir0/changelog.Debian.gz /usr/share/doc/libmimedir0/changelog.gz /usr/share/doc/libmimedir0/copyright Why was this file introduced? I don't see that this is a bug in libmimedir-gnome0-dev, it appears to be a bug in libmimedir0, specifically libmimedir0 (0.5.1-1) - there's nothing I can see in the changelog to explain this addition. There should be no .a file in the library package and there wasn't one in the -dev in Lenny either (for whatever reason). Now, whether libmimedir-gnome0-dev should contain /usr/lib/libmimedir.a and not something like /usr/lib/libmimedir-gnome.a is a different question. Moray? IMHO it's far less troublesome for the two -dev packages to conflict. $ apt-cache rdepends libmimedir0 libmimedir0 Reverse Depends: python-rra librra0 librra-tools libmimedir-dev $ apt-cache rdepends libmimedir-gnome0.4 libmimedir-gnome0.4 Reverse Depends: libmimedir-gnome0-dev libgpevtype1 gpe-contacts gpe-calendar gpe-bluetooth The only extra dependency of the -gnome version is libglib2.0-0 - python-rra already depends on libglib2.0-0 via a dependency on libdbus-glib, in turn via http://packages.debian.org/sid/libsynce0, and http://packages.debian.org/sid/librra0 also depends on libsynce0. Maybe the best thing would be: 1. Remove /usr/lib/libmimedir.a from libmimedir0 asap. 2. Migrate librra0 and reverse dependencies to libmimedir-gnome0.4 after Lenny 3. Remove the orphaned libmimedir0 Doing that means that the "problem" of /usr/lib/libmimedir.a in libmimedir-gnome0-dev goes away completely. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpqko0DoIL1g.pgp Description: PGP signature
Bug#392397: preparing a QA upload
Hi Marga, With xracer now orphaned, I want to prepare a QA upload that closes this bug. However, the diff attached to the bug report includes some anomalies; The faq.html and faq.txt files appear to have been patched when Makefile.am indicates that faq.chtml should be the source of faq.html and faq.txt faq.txt contains unprintable characters - this I suspect is a build error where it is assuming that html->txt conversion is done in an English locale of some kind. I may need to force that to LANG=C. (How important are the FAQ changes, bearing in mind xracer is orphaned?) A few Makefile.in files are patched, rather than the Makefile.am. Whilst this means the rebuild does not need to run automake or autoconf, if someone does run automake or autoconf to fix a different bug, the effect of your patches will be lost. I note the diff was intended as a 'work-in-progress' - is there an updated patch at all? I was thinking I'd probably add dpatch support and patch 'src/track.c' directly. No rush - I expect you're busy with DebConf. (See you in Edinburgh.) :-) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpeGnzzHhPAL.pgp Description: PGP signature
Bug#392397: xracer bug #392397
On Wed, 27 Jun 2007 00:11:03 +0800 "Ying-Chun Liu (PaulLiu)" <[EMAIL PROTECTED]> wrote: > > I'll look at the package fixes you have in debian.mentors on Thursday > > and if it checks out, I'll sponsor. > > > However, I'm using the epoch, so the new package is at new location: > http://mentors.debian.net/debian/pool/main/x/xracer/xracer_0.96.9-1.dsc > OK, there is one glitch. I happen to have an old version of autoconf installed (due to building old QA packages) and xracer broke with this version: FATAL ERROR: Autoconf version 2.52 or higher is required for this script make: *** [configure-stamp] Error 1 debuild: fatal error at line 1228: dpkg-buildpackage -rfakeroot -D -us -uc failed $ dpkg -l "autoconf*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description === ii autoconf 2.61-4automatic configure script builder un autoconf-archive (no description available) un autoconf-doc (no description available) ii autoconf2.13 2.13-58 automatic configure script builder (obsolete version) Therefore, you should add a versioned dependency on autoconf and a Conflicts: debian/control: Build-Depends: ..., autoconf (>= 2.52), ... Conflicts: autoconf2.13 (The Conflicts is important because autoconf2.13 is a suggested dependency of one of the xracer dependencies - check the pbuilder log - and because autoconf2.13 can be installed alongside autoconf >= 2.52, as on my system.) Suggested packages: autoconf2.13 autobook autoconf-archive gnu-standards autoconf-doc automake1.10-doc dh-make psgml docbook-xml docbook-dsssl cvs gettext-doc libglide3 libtool-doc g77 fortran77-compiler gcj procmail graphviz sgml-base-doc perlsgml doc-html-w3 opensp libxml2-utils doc-base Recommended packages: automaken libltdl3-dev gs gs-aladdin libmail-sendmail-perl libcompress-zlib-perl The following NEW packages will be installed: autoconf automake autotools-dev bzip2 debhelper diffstat docbook This isn't really your fault, it is one of those things that would only appear on systems that have been used to build older packages. However, it could easily result in someone opening a FTBFS bug on the basis that although it builds nicely in pbuilder, it has a 'hidden' problem building on a full system. (i.e. most people checking for fail-to-build bugs will have things like autoconf2.13 lying around as a result of some of those tests.) The package should declare the conflict to dpkg rather than failing during the build itself. The only other thing is that quilt adds support for two translations, there could easily be more. The po-debconf package is not just for debconf translations, there are people on the debian i18n list who can help you provide translations for packages too. What translators need is the xracer-0.96.9/po/xracer.pot file and you can probably unpack the source tarball and point podebconf-report-po at the (patched) po/ directory. Run once on it's own (checks that the existing patches are up to date - you can skip that email if they are) and run again with the --call option to ask for new translations. Then, once the translations are in, create (yet more) quilt patches to package them. Now translators like to handle this by: 1. having the chance to translate prior to a 'major' upload (e.g. new release, change of maintainer, etc.) 2. can choose to send new translations to you direct or as wishlist bugs against the package which you can then close in the changelog 3. need a deadline of some sort, calculated with some regard to the amount of translating that needs to be done. For a small translation like xracer, you could easily ask for 10days, possibly 7. The epoch is working nicely: $ apt-cache policy xracer xracer: Installed: 1:0.96.9-1 Candidate: 1:0.96.9-1 Version table: *** 1:0.96.9-1 0 100 /var/lib/dpkg/status 0.96.9-13 0 500 ftp://ftp.uk.debian.org unstable/main Packages That means that your epoch version is clearly seen as the upgrade from the current version in the archive which is correct. Without the epoch, 0.96.9-13 would replace 0.96.9-1. I don't have a joystick to fully test the package but it installs OK and appears to run (with a message about the lack of a joystick) even though I can't really race. I'll be happy to sponsor this once the autoconf issue is resolved and if you decide to call for some new translations, I'll upload it for you once those are in. -- Neil Williams ==
Bug#382784: Missing package check for wallpaper-tray
On 29/10/06 07:01:41, Simon Waters wrote: A little searching suggests that this bug is due to a missing linker option. In particular in the src/Makefile the loader needs flags "-Wl,-export-dynamic", as explained here; The attached patch brings in the correct pkg-config rules. I have rebuilt wallpaper-tray with the 0.5.1 tarball, and apart from the "tarball" being named "wp_tray" rather than "wallpaper_tray", it is possible to recreate the debian package using the regular commands, but the same bug is still present. ... and the fact that all the files in the 0.4.6 tarball are executable which is quite odd (and unnecessary) ... I assume that something should be placed in configure.in Yes. configure.in is incomplete. Actually, it is still incomplete after the patch but works because of indirect library dependencies [1]. wallpaper-tray has recently been adopted [2] after being orphaned, so hopefully these issues can be resolved by the new maintainer with upstream. [1] http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391406 See also: http://rerun.lefant.net/checklib -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ --- wallpaper-tray-0.4.6.orig/configure.in +++ wallpaper-tray-0.4.6/configure.in @@ -12,7 +12,7 @@ AM_PROG_CC_STDC AC_HEADER_STDC AM_PROG_LIBTOOL -PKG_CHECK_MODULES(GNOME, libgnomeui-2.0 gtk+-2.0 libglade-2.0,,exit) +PKG_CHECK_MODULES(GNOME, libgnomeui-2.0 gtk+-2.0 libglade-2.0 gmodule-2.0,,exit) AC_SUBST(GNOME_LIBS) AC_SUBST(GNOME_CFLAGS) dnl Checks for programs. pgpOGWi6Oiq2P.pgp Description: PGP signature
Bug#395877: Package lta embeds neon
On Wed, Nov 22, 2006 at 08:40:37AM +0100, Daniel Baumann wrote: > Note that this was done on purpose. Otherwise, webdav support doesn't work. > Is there a reason why dynamic linking won't work? It would be really nice to get another embedded code copy out of Debian. Neil -- [..] Debian (in the form of a large, busy, and frequently stressed organising team) has been able to organise food, accommodation and bandwidth [..] -- Anthony "AJ" Towns signature.asc Description: Digital signature
Bug#833057: /usr/bin/extlinux: extlinux --install fails to boot if the rootfs is ext4
Package: extlinux Version: 3:6.03+dfsg-14 Severity: important File: /usr/bin/extlinux With vmdebootstrap, I'm trying to maintain extlinux support but the latest package fails to make the image bootable if the rootfs is ext4. ext3 and ext2 work, so I'm going to need to prevent vmdebootstrap images building ext4 if extlinux is used until this is fixed. (Grub works fine with ext2, 3 and 4.) When building on Jessie, this problem does not occur - only when building the VM on stretch or sid. (This is a separate bug that syslinux requires the use of files which are not included in the VM and cannot be installed using only the files of the VM.) vmdebootstrap --owner neil --verbose --extlinux --roottype ext4 --distribution sid --image sid4.img - results in an image which just outputs "no such file or directory" for the kernel and initrd files (which blatantly do exist in the specified paths if the image is mounted using loopback support.) vmdebootstrap --owner neil --verbose --extlinux --roottype ext3 --distribution sid --image sid3.img - results in an image which boots normally using qemu-system-x86_64 -m 2048 -enable-kvm -drive format=raw,file=sid3.img -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages extlinux depends on: ii libc6 2.23-4 Versions of packages extlinux recommends: ii syslinux-common 3:6.03+dfsg-14 extlinux suggests no packages. -- debconf information: extlinux/install: false * extlinux/no-bootloader-integration: extlinux/title:
Bug#833057: Downgrading extlinux does not help
It's odd but verifiable - downgrading extlinux to the version in jessie (3:6.03+dfsg-5+deb8u1) does not fix the problem. Building a new image with the same options fails in exactly the same way. However, building on jessie itself, does work. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpvdD9dFvCCj.pgp Description: OpenPGP digital signature
Bug#845324: FTBFS: /bin/sh: 1: emacs: not found
severity 845324 normal
tag 845324 + unreproducible
tag 845324 + moreinfo
thanks
On Tue, 22 Nov 2016 10:52:27 -0200
Joao Eriberto Mota Filho wrote:
> Package: bhl
> Version: 1.7.3-3
> Severity: serious
> Tags: newcomer
> Justification: fails to build from source
It does build in sbuild. Build log attached.
The package also builds in the reproduciblility tests.
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/bhl.html
> Hi,
>
> The package is 'all' and always was sent already built. It needs
> emacs to build from source. Please, add 'emacs' as build dependency.
It's certainly needed as a Depends - I don't see that it needs to be
Build-Depends.
debdiff /var/cache/apt/archives/bhl_1.7.3-3_all.deb bhl_1.7.3-3_all.deb
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Installed-Size: [-243-] {+199+}
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
bhl_1.7.3-3_amd64.build
Description: Binary data
pgpuigD7Ces6k.pgp
Description: OpenPGP digital signature
Re: ampache package
On Mon, 4 Nov 2019 13:06:16 +0100 Andreas Natanael Nielsen wrote: > Hey > > I would like to know if the package: ampache is going to be available > in future releases? Probably not. https://tracker.debian.org/pkg/ampache "This package is not in any development repository. This probably means that the package has been removed (or has been renamed). Thus the information here is of little interest ... the package is going to disappear unless someone takes it over and reintroduces it." https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp4PG_QJVZja.pgp Description: OpenPGP digital signature
Re: "malicious" package in sid and testing
On Tue, 31 Jul 2018 04:27:29 +0200 Nicolai Lissner wrote: > Dear Debian QA Group, I don't see why you haven't just followed up on the bug #904699 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904699 Assume good faith. The package description covers why it has such a long list: Raw FFI bindings for all of Windows API - Rust source code https://packages.debian.org/unstable/librust-winapi-dev > > a few days ago I reported bug #904699 > as nothing happened since then, I started to hunt down the reason > for this bug, and what I found made me kind of speechless. > > As I expected the reported problem is not in cdebootstrap itself > and not even in debian-installer (it is actually reported > from a d-i library call) but in the package list and metadata instead > I've used snapshot.debian.org to find since when the problem exists, > and found it has been introduced on July 8th. https://tracker.debian.org/news/971710/accepted-rust-winapi-035-1-amd64-source-into-unstable-unstable/ > Looking at the changes I probably found the reason. > > Please have a closer look at the meta data of package > librust-winapi-dev - as this is just wrong. > The package has > Size: 744344 744344 bytes == 726kB > but > Installed-Size: 5839 > How is that even possible? Size: bytes Installed-Size: kilobytes See https://packages.debian.org/unstable/librust-winapi-dev ArchitecturePackage SizeInstalled Size Files amd64 726.9 kB5,839.0 kB [list of files] > > But it's worse, the package has a Provides: line > and quotes 1336(!) packages making that single > line more than 57 kByte length. Yes. seriously. But no, that's > insane. It's very long, yes. However, if it causes problems then it is up to the tools to adapt. There's nothing in Policy to put a maximum limit and the package was accepted by ftp-master with this list in the source package. Seeing as only certain tools have problems with the length then it would make sense that the problem is fixed in those tools, not by retrospective changes in Policy after the package has been accepted and migrated into buster. I don't use rust, I've only looked at it briefly some months back, but this does look like some of the issues reported with how rust handles dependencies. Similar things happen in the nodeJS space. There are plenty of people who don't like this kind of behaviour, plenty of developers consider it to be unpalatable or a reason not to use those languages. However, there is no reason to lay accusations of malice. > > It breaks debian-installer (you can't install testing or sid > with it right now) and it breaks cdebootstrap - and most probably > any other package that uses d-i libraries to parse the packagelist debootstrap appears fine. $ sudo debootstrap buster buster I: Base system installed successfully. Works fine. > > I'm writing you because to me - and I hope I'm terribly wrong > about this - this looks just like a malicious joke as in "look, > I can break your C code with an extra long line. It wouldn't have > happened if you used rust" - but that's just my mind trying to > find an explanation why somebody would define a >57kB line in > the package metadata. Opinions will vary but principally, that is how to express the full API which this package is trying to do. In some ways, if this one package can integrate all of those packages into itself, it is doing Rust a favour. There are other oddities in the package, e.g. it depends on both i686 and x86_64 packages which do not (yet?) exist and is built for architectures like arm64 and s390x where it seems unlikely that windows code would exist. I don't know enough about Rust to know whether those are actual problems. > > And as I just want to avoid some unnecessary fighting or insulting > or anything similar I thought it would be best to contact a third > party to have a look at this issue > > I'm not sure you are the right group to contact about this, but I'm > sure if you are not you can redirect it to whereever it should go. > You need to feed back to the cdebootstrap bug, in good faith, and go from there. Forget about "malice" and just deal with the problem at hand: As Policy is currently, cdebootstrap is failing to handle a valid Packages.gz file when other tools, like debootstrap and the archive tools themselves, do not have issues. That is a bug in the tool, not the package providing the long list. -- Neil Williams h...@codehelp.co.uk pgpNkik9lbhkK.pgp Description: OpenPGP digital signature
Bug#914104: I agree with removal
Things haven't really changed for gpdftext. It's not impossible for someone to adopt the package in Debian and the upstream at the same time, it's not a lot of code. However, it seems that this little niche was a bit too small for anyone else to want to pick it up once I stopped needing the code. -- Neil Williams h...@codehelp.co.uk pgpsosjV9ZWsw.pgp Description: OpenPGP digital signature
Bug#930693: ksh: previous versions have the info
I'm not sure this warrants being RC. It's a result of a reformatting of debian/copyright when previous versions had the information available: https://tracker.debian.org/media/packages/k/ksh/copyright-93u%2B20120801-1 "It was downloaded from http://www.research.att.com/sw/download"; It's not as if the upstream version has changed since that time. This has already been fixed in experimental: https://tracker.debian.org/media/packages/k/ksh/copyright-2020.0.0alpha1-1exp1 At this late stage of the buster release cycle when the package has already been orphaned, it does smack a bit of flogging a dead horse to potentially cause ksh to be removed from buster. I think this should be downgraded or even marked as fixed in 2020.0.0~alpha1-1~exp1 and therefore fixed once buster is released. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpIabYbTHyTd.pgp Description: OpenPGP digital signature
Re: mrxvt in Debian buster
On 28 Jun 2019 4:55 pm, Gautam Iyer wrote:Hi All, I'm not sure if this is the right place / person to report this to. I noticed mrxvt was distributed with stretch, but not in Buster. Is there a reason for this?Yes. The package was actively removed from Debian due to missing functionality compared to an abundance of alternatives. The package is simply not of a high enough standard. UTF-8 support is a glaring omission and as all the alternatives have UTF-8, mrxvt is not of sufficient quality to be included in Debian.See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869743As things stand, mrxvt will not be in any future release of Debian. I'm one of the authors of mrxvt -- it's no longer under "active development", but is being maintained / used every day me. If there's anything I can do to get mrxvt back in buster please let me know. (If I missed the freeze window, have to wait until the next RC, or until the next major release, that's not a problem. Just let me know what needs to be done.) Due to the number of alternatives available which are in much better state, I don't see any way to get this package back into Debian. It's just not worth the effort, as a volunteer. Sorry. Best, Gautam -- A topologist is a person who doesn't know the difference between a coffee cup and a doughnut.
Bug#901321: Bug#876197: Removed package(s) from unstable
On Tue, 3 Jul 2018 13:20:13 +0200 Helio Loureiro wrote: > Hi, > > I started on Debian at Ham release. At that time mpage was part of > Debian. So I've a profound relationship with mpage as great tool > along all these years. > > But if my statement is correct, that package after 20 years at Debian > was wrongly removed due a license which doesn't apply to delivered > binaries, The licensing was not the only reason that removal was requested. > do you really believe the best approach is to ask a > volunteer out of Debian developers/maintainers to join on Debian > mentors to fix it? Yes - that is the established process for all packages. > Wouldn't be > easier for you and Eriberto to just revert the removal? There is no method for doing this which does not require a volunteer to do the upload and, clearly, nobody is sufficiently interested to spend any time on that. The former maintainer(s) of this package had already orphaned it before removal. Many packages in the QA group are fixed by volunteers outside Debian using Debian mentors - the process works well. Those who care about the package are the ones motivated to do work on the package. > I guess that > any DSC from theses 20 years of Debian would work just fine. No. It will need to be updated to current Debian Standards Version and fix any lintian warnings etc. and there will need to be a new review of the licensing through the FTP process. Besides, the removal was not just for licensing: Bug 876197 > I think this package is no longer useful and can be removed. Someone needs to be sufficiently interested in the package to do this work. If that is not you, it looks like there is nobody else willing to volunteer, so the situation will not change. It seems obvious that nobody else considers the package useful. Just pinging the bug report will not suddenly produce a volunteer to do the work. Personally, I do not see merit in having mpage in Debian. I am comfortable with the removal of a package with such a small niche. -- Neil Williams = https://linux.codehelp.co.uk/ pgp2EPzKr2ScN.pgp Description: OpenPGP digital signature
Bug#993375: gtkpod: CVE-2021-37231 - stack-buffer overflow in embedded AtomicParsley code, APar_readX
Package: gtkpod Version: 2.1.5-8 Severity: important Tags: security gtkpod embeds a vulnerable version of AtomicParsley, however, the data file used to test atomicparsley upstream is not recognised by gtkpod. https://github.com/wez/atomicparsley/issues/30 https://sources.debian.org/src/gtkpod/2.1.5-8/libs/atomic-parsley/AP_AtomExtracts.cpp/#L1117 See also #993372
Bug#993376: gtkpod: CVE-2021-32732 - stack overflow in embedded AtomicParsley code APar_read64
Package: gtkpod Version: 2.1.5-6 Severity: important Tags: security https://github.com/wez/atomicparsley/issues/32 See also #993366 gtkpod embeds a vulnerable version of AtomicParsley which causes a stack overflow, however the data file used to test atomicparsley upstream is not recognised by gtkpod. Note that in #993366, the upstream fix for this CVE does not resolve the issue as described when the upstream fix is applied to atomicparsley, so more work may be needed here to identify the problem as it applies to the version of atomicparsley used by gtkpod. >From a check of the embedded source code, the vulnerable code can be found at: https://sources.debian.org/src/gtkpod/2.1.5-8/libs/atomic-parsley/AP_AtomExtracts.cpp/#L1325
Bug#993375: Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library
On Wed, 1 Sep 2021 11:05:09 +0300 Adrian Bunk wrote: > Control: tags 993378 moreinfo > > On Tue, Aug 31, 2021 at 03:49:45PM +0100, Neil Williams wrote: > > Package: ftp.debian.org > > Severity: normal > > > > gtkpod upstream has moved but has not had any activity for over 5 > > years. > > > > When investigating the two CVEs against AtomicParsley, former > > maintainer Matteo F. Vescovi reached out to me to suggest removal > > of gtkpod. > > > > The use case for this package seems to be declining / absent and 4 > > crash bugs are currently open. > > > > Fixes for these bugs and CVEs seem unlikely to appear, it would > > seem best to remove gtkpod from Debian at this point. > > As a user I am quite unhappy when a working package I am using is out > of the void getting am RM bug. > > With software for older hardware it is normal that upstream becomes > inactive, and anything other than declining usage would be a surprise. > > I am also dismayed at the CVEs. At first sight the "two CVEs" might > be for the same bug, with the fix for the first CVE not fixing the > bug. Does manually backporting the one-character change from > CVE-2021-37232 fix everything, even without the larger CVE-2021-37231 > refactoring? Hi Adrian. Sorry, No. The commit linked to CVE-2021-37232 does not even fix the problem described as being fixed by that commit in atomicparsley, at least in my testing using the data file supplied by upstream. I mentioned this in the bug report against atomicparsley - 993366 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993366#5 That atomicparsley data file cannot be used to test gtkpod, only atomicparsley itself. As mentioned already, gtkpod is now orphaned and the maintainer who orphaned it suggested removing the package. (The CVEs are not the only bugs against either atomicparsley or gtkpod). The two CVEs are not the same bug - at least not according to the commits made upstream for the two issues in atomicparsley. Orphaned packages are at risk of sudden removal - until and unless someone adopts the package. -- Neil Williams = https://linux.codehelp.co.uk/ pgpS65oDdtE2j.pgp Description: OpenPGP digital signature
Bug#993375: Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library
On Wed, 1 Sep 2021 12:08:16 +0300 Adrian Bunk wrote: > On Wed, Sep 01, 2021 at 09:32:09AM +0100, Neil Williams wrote: > >... > > Hi Adrian. > > Hi Neil, > > > Sorry, No. The commit linked to CVE-2021-37232 does not even fix the > > problem described as being fixed by that commit in atomicparsley, at > > least in my testing using the data file supplied by upstream. I > > mentioned this in the bug report against atomicparsley - 993366 > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993366#5 > > > > That atomicparsley data file cannot be used to test gtkpod, only > > atomicparsley itself. > > "atomicparsley itself" is a CLI with a copy of the code, > not much different from gtkpod. > > gtkpod at least tries (in a broken way) to share the library with > other programs. > > > As mentioned already, gtkpod is now orphaned and the maintainer who > > orphaned it suggested removing the package. (The CVEs are not the > > only bugs against either atomicparsley or gtkpod). > > > > The two CVEs are not the same bug - at least not according to the > > commits made upstream for the two issues in atomicparsley. > > > > Orphaned packages are at risk of sudden removal - until and unless > > someone adopts the package. > >... > > Why do you want to screw our users (in this case including me) > with sudden removals? > > QA maintained packages tend to be better maintained than many > packages owned by nearly-MIA maintainers, so why are you forcing > people to move packages out or QA maintainance just for preventing > random people doing sudden removals out of the void? > > I can adopt gtkpod and many other QA maintained packages if that is > the only way to stop removal requests from people like you. > This would change the Maintainer field without fixing any bugs. > > The normal approach is that people file RC bugs for RC issues > or an RC "should this package be removed?" bug against the > package first. This gives people time to react and discuss. Packages do not need to be RC buggy to be removed - indeed, many RC buggy packages remain in unstable for some time as the removal from testing is automated. RoQA and RoM are valid reasons for removal of a package from Debian which do not require any RC bugs to be present. https://ftp-master.debian.org/removals.html -- Neil Williams = https://linux.codehelp.co.uk/ pgpAOnVyJB6UO.pgp Description: OpenPGP digital signature
Bug#993957:
On Wed, 08 Sep 2021 18:27:39 +0100 "Adam D. Barratt" wrote: > On Wed, 2021-09-08 at 18:21 +0100, Adam D. Barratt wrote: > > On Wed, 2021-09-08 at 16:58 +0100, lkcl wrote: > > > schroot 1.6.10 (04 May 2014) fails with a continuous attempt to > > > read > > > a non-existent subdirectory, /run/systemd/userdb, when operating a > > > type "directory" schroot. > > > > > > > So far as I can see from the strace output you provided, that > > doesn't actually appear to be the cause of the failure. Rather, > > this does: > [...] > > i.e. it failed due to an unsuccessful attempt to allocate 128GB of > > RAM, > > rather than anything to do with systemd. > > > > and that's probably > https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1899414 > The routine reportbug questions haven't been answered for this bug and there are a few important elements: 1. What is installed in this schroot? 2. What suite is used inside the chroot? 3. What suite is the external system? 4. What exact commands were used, including options. 5. To which groups does the user running those commands belong? 6. What system is running these commands? (Information on the reporting system was removed but equivalent information about the running system was not included). -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpkIwu9kvaSQ.pgp Description: OpenPGP digital signature
Re: FTE folding text editor - SIMPLE configurable syntax parser
On Thu, 18 Dec 2014 09:10:58 + Sian Mountbatten wrote: > Dear People > > I am trying to create a new combined Algol 68/Web 68 mode for this > editor, but can make no progress at all. > > It would be very helpful if you could look at my code and tell me > what I am doing wrong. FTE is an orphaned package, so this request went to a general purpose mailing list where there isn't necessarily anyone familiar with this specific package. Upstream (http://sourceforge.net/projects/fte/) seems inactive, so there seems little prospect of help from there. So, overall, the chances of anyone being able to help with your request are slim. Sorry. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpvPlTjXRDPZ.pgp Description: OpenPGP digital signature
Bug#803530: sgmltools-lite: Please remove obsolete package from Depends
Package: sgmltools-lite Severity: normal The Depends field for sgmltools-lite contains this: Depends: ..., jade | openjade The jade package is obsolete and will be removed from Debian, so please change that to this: Depends: ..., openjade Thanks. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-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 Init: systemd (via /run/systemd/system) -- Neil Roeth
Re: glusterFS support in debian package tcmu-runner
On Thu, 30 Sep 2021 07:58:35 +0200 Andreas Kirbach wrote: > Dear Sir or Madam, > > I tried to use package tcmu-runner, but noticed that it has explicity > been build without support for GlusterFS. This would have been because the package was introduced to support a specific dependency chain and, at the time, there was no request for Gluster support. I have now orphaned the package on behalf of team+freexian (it no longer has an active maintainer), so the correct thing to do here is simply file a wishlist bug against the package. I've CC'd the QA group mailing list, where orphaned packages are handled, but the list is not the place to request this change. Report a bug against tcmu if you want anything to change. You may also choose to make the change yourself, via a sponsor if needed - https://mentors.debian.net/ & https://salsa.debian.org/debian/tcmu.git Adding this support would be easier with a volunteer available to test that it actually works, so the more you can do yourself, the more likely it is that this orphaned package can be updated. (I certainly have no ready way to test glusterfs support, for example). https://www.debian.org/Bugs/ https://www.debian.org/Bugs/Reporting It would appear that https://packages.debian.org/unstable/libgfapi0 is what is referred to for this support, via https://packages.debian.org/unstable/libglusterfs-dev (I have not tested whether tcmu compiles correctly with the version of libgfapi in Debian.) > As the package description explcitly does mention Gluster I wonder > why this was done as I also couldn't find anything in the changelog? Something like this is unlikely to be specified in the changelog unless there was a bug report to introduce it or remove it. If there was a particular reason not to support an optional part of a package, that could also appear in a README.Debian or README.source in the package. > As GlusterFS is packaged in Debian and supported by various other > packages (like tgt-glusterfs) it would be nice if this was supported > in TCMU-Runner as well. > > Kind regards, > Andreas Kirbach -- Neil Williams = https://linux.codehelp.co.uk/ pgplMz0lmddV6.pgp Description: OpenPGP digital signature
Bug#1006181: rename 1006181 to RFP: czkawka
retitle 1006181 RFP: czkawka - remove unnecessary files from your computer. reassign 1006181 wnpp noowner 1006181 thanks >* What led up to the situation? > fslint was removed from the Debian repos > >* What exactly did you do (or not do) that was effective (or > ineffective)? > Cried, that was ineffective - so I visited fslint's homepage and > foudn this. https://qarmin.github.io/czkawka/ > >* What was the outcome of this action? > Seems to be a continuation of the project... > >* What outcome did you expect instead? > I hope this program can be added to the Debian repos. > > Note: fslint was removed because it was Python2 and no Python3 version was available. To introduce a new package to replace fslint, changing 1006181 to a Request For Package bug. czkawka is written in Rust: For now, finding broken audio files is temporary disabled by default, because app crashes when audio libraries are not found on the computer. I’m waiting for ability to disable audio playback feature, so after that I will be able to re-enable by default this feature (https://github.com/RustAudio/rodio/issues/349) To enable checking for broken audio files, just add ` –all-features` https://qarmin.github.io/czkawka/instructions/Compilation.html -- Neil Williams = https://linux.codehelp.co.uk/ pgp89EfxwK6Sp.pgp Description: OpenPGP digital signature
Re: gaffitter is marked for autoremoval from testing
On Thu, 26 May 2022 13:01:23 -0300 "Douglas A. Augusto" wrote: > On 2022-05-26 at 04:51, > Debian testing autoremoval watch wrote: > > > gaffitter 0.6.0-3 is marked for autoremoval from testing on > > 2022-06-30 > > > > It (build-)depends on packages with these RC bugs: > > 1011146: nvidia-graphics-drivers-tesla-470: CVE-2022-28181, > > CVE-2022-28183, CVE-2022-28184, CVE-2022-28185, CVE-2022-28191, > > CVE-2022-28192 https://bugs.debian.org/1011146 The report is in error due to bug https://bugs.debian.org/1011268 in the script generating the marks. The bug is causing lots of other erroneous autoremoval marks too. > Hi, I'm the author of the gaffitter package. I received the message > above but I don't know why gaffitter should depend on > nvidia-graphics-drivers-tesla-470; it definitely shouldn't. By the > way, there is a newer gaffitter version available (1.0.0). > > What can I do to prevent gaffitter from being removed from testing? You do not need to do anything. > > > Best, > > -- > Douglas A. Augusto -- Neil Williams = https://linux.codehelp.co.uk/ pgpixJZri3NMS.pgp Description: OpenPGP digital signature
Bug#211617: (no subject)
tags 211617 patch
thanks
[ Copied from 210619 ]
I tracked this down to /usr/share/sgml/{sp,OpenJade}/unicode/catalog. If
either of these two is included as a catalog, then the above warnings occur.
If they are not included, only the warning "...numbers exceeding 65535..."
occurs, and that is a known jade limitation (bug 206707). Part of the problem
is that for an XML file, docbook2pdf looks for a centralized catalog called
/etc/sgml/xml-docbook.cat, but on current Debian systems, XML catalogs are
listed in the same centralized catalog as SGML catalogs, i.e.,
/etc/sgml/catalog. When it fails to find xml-docbook.cat, it just gets a list
of all catalogs under /usr/share/sgml, which includes the problematic unicode
catalogs, which apparently are not included in the centralized catalog. You
can force it to use the centralized catalog like this:
docbook2pdf -n -c /etc/sgml/catalog foo.xml
When I did that, the warnings went away. I also tried a catalog called
/etc/sgml/docbook-xml.cat, but using that as the argument for -c results in
other errors of omission that /etc/sgml/catalog resolves.
There are two steps I will take:
1) I will figure out what the problem with the unicode catalogs are (I am the
maintainer for both packages that provide them). This bug will stay open
until I resolve that.
2) It appears to be a simple change to make the docbook2pdf script look for
the /etc/sgml/catalog by default on a Debian system, for both SGML and XML
files.
This is a lot like bug 119498 against docbook-utils. I'm not sure why it
was not fixed at that time.
This is the patch to make jw default to /etc/sgml/catalog for XML as well as
SGML files. Instead of using a different name for the catalog depending on
whether it is XML or SGML, just always use the name "catalog". I intend to do
an NMU of this sometime in the next few days, since the package is orphaned.
--- frontends/docbook.in.orig 2002-11-02 12:45:10.0 -0500
+++ frontends/docbook.in2003-09-18 17:37:15.0 -0400
@@ -27,10 +27,7 @@
done
if [ -z "$SGML_CATALOG" ]
then
- if [ "${SGML_XML}" != "sgml" ]
- then SGML_CATALOG=${SGML_CATALOGS_DIR}/${SGML_XML}-docbook.cat
- else SGML_CATALOG=${SGML_CATALOGS_DIR}/catalog
- fi
+ SGML_CATALOG=${SGML_CATALOGS_DIR}/catalog
fi
echo "$SGML_CATALOG"
;;
--
Neil Roeth
Bug#250244: distributed-net: More recent distributed.net binary is available, supporting OGRp2
Package: distributed-net Version: 2.9001.478-2 Severity: important New version of binary from distributed.net is necessary for contributing towards the second phase of OGR. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.5-1-k7 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 Versions of packages distributed-net depends on: ii host2331-9 utility for querying DNS servers ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an -- no debconf information
