Bug#300463: libpqxx-2.4.1: Newer versions available (2.4.4 the last stable)
Package: libpqxx-2.4.1 Version: 2.4.1-2 Severity: wishlist Please, update this package, the current version was released more than a year before; and the newest stable version is 2.4.4 release on February. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=pt_PT, LC_CTYPE=pt_PT (charmap=ISO-8859-1) Versions of packages libpqxx-2.4.1 depends on: ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an hi libgcc1 1:3.4.3-12 GCC support library ii libpq3 7.4.7-3 PostgreSQL C client library hi libstdc++5 1:3.3.5-12 The GNU Standard C++ Library v3 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#300463: libpqxx-2.4.1: Newer versions available (2.4.4 the last stable)
hi, I had some problems with that version 2.4.1 and libstdc++6, so I decided to use the source package. I don't know if those versions would work for me, but now that I have it installed won't change it for older versions. I submitted this at least to let you know that somebody is using this package (that's the first bug report/request, I think), and I'd like to use the debian package for this library in the future anyway :) greetings. Dom, 2005-03-20 às 01:19 +, Roger Leigh escreveu: > -BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > "Manuel A. Fernandez Montecelo" <[EMAIL PROTECTED]> writes: > > > Package: libpqxx-2.4.1 > > Version: 2.4.1-2 > > Severity: wishlist > > > > Please, update this package, the current version was released more > > than a year before; and the newest stable version is 2.4.4 release > > on February. > > 2.4.2 and 2.4.3 have been uploaded and awaiting NEW processing for > over a month now. > > 2.4.4 will not be uploaded until after the release of sarge, since new > libraries are not currently allowed. Do you specifically require > 2.4.4? > > > Regards, > Roger -- Manuel A. Fernandez Montecelo <[EMAIL PROTECTED]>
Bug#392524: I'm also interested
I'm also interested in getting the latest version in unstable. (Just to let the maintainer know that there's people using the package...). Regards. -- Manuel A. Fernandez Montecelo <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#732721: freeorion: Please upgrade OGRE dependency to 1.9 when upstream ready
2013/12/21 Markus Koschany : > Hello Manuel, > > currently freeorion fails to build from source with ogre 1.9. I will > keep an eye on upstream development for this issue. That's fine, no rush. Thanks for the quick reply and keeping an eye :-) -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708297: SDL-mixer and SDL-sound: Problem with mp3 support
Control: tag 708297 + upstream 2013/5/15 Vincent Prat : > >> I don't really know what's happening, just suggestions below. >> >> Were you using the same Debian architecture in the past, or did you >> switch from i386->amd64 between working and failing? > > The only change between working and failing is the upgrade from squeeze to > wheezy. > > >> >> And by the way, did you also try other format types (ogg, flac, wav) >> and observe any anomaly? > > I have tried all these formats without any problem. After compiling the binaries (had to use -fpermissive [1]), this is what I get: -- $ ./playsound_simple ../scream.mp3 Now playing [../scream.mp3]... Error decoding file: (null) $ ./playsound ../scream.mp3 Now playing [../scream.mp3]... Error in decoding sound file! reason: [MPGLIB: Free format not supported.]. -- So it seems that the .mp3 that you are playing is not supported by the library. From this reply of the author in the support mailing list (from 2007, but the code does not seem to have changed much since then, and indeed the code seems very fragile): -- http://icculus.org/pipermail/sdlsound/2007-January/000655.html mpglib is deeply unforgiving about file corruption...it gives up immediately when it sees data it doesn't expect, which is a problem with a lot of mp3s out there. Also, unfortunately, one of the things it doesn't expect is ID3v2 tags, so that excludes the vast majority of mp3s created in the past few years. This is fairly easy to fix, just no one ever has (for ID3v1, we just look for the struct in the last 128 bytes of the mp3, and don't pass it to mpglib if we see it. ID3v2's layout is somewhat more complicated, but something similar can still be done). In a more ideal world, someone would take the time to understand the mpglib code and make it recover from bad data. Or replace it with a different mp3 decoder, but I haven't found one that isn't GPL'd. SDL_sound's SMPEG backend is more forgiving of strange data, but has its own problems too. Use Ogg files if you control your content. :) As you can tell by my long apology here, we're sort of at the mercy of a disproportionate amount of third-party code here. -- Cheers. -- Manuel A. Fernandez Montecelo [1] g++ -fpermissive -I/usr/include/SDL -lSDL -lSDL_sound playsound_simple.c -o playsound_simple g++ -fpermissive -I/usr/include/SDL -lSDL -lSDL_sound -DHAVE_SIGNAL_H playsound.c -o playsound -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714482: [libsdl2-2.0-0] Programs fail under weston
2013/12/14 Franz Schrober : > The wayland support is now in libsdl2: > http://hg.libsdl.org/SDL/rev/4fc5f66d63cc I just uploaded 2.0.1, but I thought that this was too large to incorporate as a patch on our side for the time being -- specially because of possible incompatibilities in some parts of the rest of the code between the release of 2.0.1 and that patch. So I guess that this will be present in 2.0.2 then, in our next upload with new upstream code, unless upstream somehow disable this. Nevertheless, if somebody pings this bug by the time that a new release containing this is ready it would be great, to make sure that we enable support for it. >From what I can see in the patch, it will not need new binary packages or anything fancy, only build-depending on the appropriate -dev packages and making sure that support for it is enabled when configuring/compiling. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733015: [libsdl2-2.0-0] SDL2 X11 driver buffer overflow with large X11 file descriptor
Control: forwarded -1 https://bugzilla.libsdl.org/show_bug.cgi?id=2330 Thanks for the bug report and your efforts to improve Debian, I forwarded it upstream to the URL above. With the test case, I get: $ ./testkeys Couldn't initialize SDL: No available video device I just uploaded 2.0.1 and it compiled fine for most architectures, so you will have it available soon. If you could test whether the bug and the fix still happens and communicate with upstream to make sure that they understand it and fix it, it would be great. Cheers. -- Manuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738785: aptitude: (remote) changelogs is broken after packages.d.o move to https
Hi Raphael, Is this solved by using metadata.ftp-master.d.o instead of packages.d.o? If so, this is pending for upload, soonish. Will the workaround be kept for a few weeks? Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738933: libapt-pkg-doc: Some .xhtml files are compressed, and apparently junk around (*.md5 and *.map)
Package: libapt-pkg-doc Version: 0.9.15.2 Severity: important Hi, Compare files shipped: - https://packages.debian.org/sid/all/libapt-pkg-doc/filelist - https://packages.debian.org/jessie/all/libapt-pkg-doc/filelist In my system (in the case that the bug is triaged at a later time): $ dpkg -L libapt-pkg-doc | grep '.*\.md5$' | wc -l 357 $ dpkg -L libapt-pkg-doc | grep '.*\.xhtml\.gz$' | wc -l 482 $ dpkg -L libapt-pkg-doc | grep '.*\.map$' | wc -l 354 Versions in packages.d.o: - jessie (testing) (doc): documentation for APT development 0.9.15: all - sid (unstable) (doc): documentation for APT development 0.9.15.1: all 0.9.15.2 in my system, with same problem. Note that since the files are compressed, local navigation of documentation with a browser is not possible, thus priority "Important" -- but feel free to change it. Cheers, and keep up the good work! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738785: [Aptitude-devel] Bug#738785: aptitude: (remote) changelogs is broken after packages.d.o move to https
2014-02-13 21:07 David Kalnischkies: If so we should really get this code into libapt though as currently apt and aptitude do their own thing in this regard… I am not very familiar with that part of the code, but after a quick look I think that aptitude uses pkgAcqFile for this. So whatever works for apt should work for aptitude. Using curl or similar, as suggested by Raphael, could be an option. Currently relies on apt for both packages and changelogs, it uses the same code. Cheers. -- Manuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738893: O: cwidget -- high-level terminal interface library for C++ (runtime files)
Control: owner -1 m...@debian.org Control: retitle -1 ITA: cwidget -- terminal interface library for C++ -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738893: O: cwidget -- high-level terminal interface library for C++ (runtime files)
For the record, I tried to contact Daniel Burrows several times for more than 2 years about this project and other abandoned projects, specially aptitude. Luckily we got to salvage aptitude a while ago already, but I was going to ask again about this because cwidget is used by aptitude, and needs some love. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732539: cwidget: use dh-autoreconf instead of autotools-dev for better new-port coverage
Control: tags -1 + pending Hi, Applied in the VCS and marking the bug accordingly, thanks. I plan to upload a new release with this and other fixes/improvements soon, before the end of February. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#719893: aptitude: Colour problem in xterminal
Control: tags -1 + unreproducible + moreinfo Hi, I could not reproduce this in occasions in which restart of services failed. I've been reviewing the init script of apache2, and it went throught a lot of turmoil during the time that this bug was reported, including moving around the text mentioned in the error. There's no indication about which version you were using, so it's difficult to investigate more and try to pinpoint the problem, if it was with apache2's script. There doesn't seems bugs, archived or unarchived, complaining about this in the apache2 package (searching for "failed", "color", "colour"). So basically I think that the bug is not with aptitude, but with other programs that can make a mess in the terminal. There are other ways in which programs can mess up. I am not sure if it's sensible to try to reset the terminal every time that aptitude goes "into" and "out of" curses mode to try to prevent this problem even when programs misbehave and make a mess in the terminal. I never observed this, or perceived this as a problem; and I don't know if there will be drawbacks doing this, or even if it's possible to cover these cases properly and if the countermeasures will work in all cases. Do you have more information about this, or saw it happening again? Cheers and thanks for your bug report. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519906: aptitude: use a database like MySQL to speed things up
Control: tags 519906 + wontfix Hi, There are other bug reports where the speed issues are already recorded. On the matter of MySQL itself, it would be a bad idea for several reasons, including Daniel Burrows's and Axel's reasons. Actually, old and embedded systems lack memory more than CPU, so adding a half-full RDBMS into the mix would probably hurt performance even more. (The situation might have been a bit different in 2009, but still). And it would be a huge problem to tie aptitude's future to MySQL, because many people will say "we want a minimal set of dependencies for important packages, or to have minimal systems (think VMs)". I suspect that the usage of aptitude would drop significantly if people see that aptitude needs MySQL to run. So marking the bug as wontfix at the moment. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#285197: aptitude: Provide way to manually run apt-listchanges for pkg
Control: tags -1 + moreinfo Hi, I don't know exactly how it was the situation ~9 years ago when this bug report was submitted, but nowadays the "changelog" functionality pretty much behaves in that way, downloading the changelog of the candidate version and highlighting the changes since the installed version. So I think that it covers at least the main use case. Even if there are differences, I think that having two options in the menu side by side doing basically the same would be a bit confusing, so I don't think that this should be implemented now. I am marking this as +moreinfo in the case that somebody can provide a compelling case as for why this should be implemented. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#285197: aptitude: Provide way to manually run apt-listchanges for pkg
2014-02-20 20:08 GMT+00:00 Marc Sherman : > I have no objections to closing this issue. OK, thanks :-) But I am curious... can you recall why you made the request at the time? Perhaps the Changelog option was not highlighting the changes between installed and candidate versions? Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#719893: Re : aptitude: Colour problem in xterminal
2014-02-20 20:34 GMT+00:00 : > Le 20/02/2014 20:02:06, Manuel A. Fernandez Montecelo a écrit : > >> Control: tags -1 + unreproducible + moreinfo > > In fact, I think that it’s a bug in scripts but not in the terminal. I > even have the bug with aptitude. I don't understand... do you mean that you think that it's a bug with the apache2 scripts? That's my guess as well, what I don't know is if aptitude should try to restore the state of the terminal before continuing (if possible). What does it mean "I even have the bug with aptitude", can you please rephrase? -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#719893: Re : Re : aptitude: Colour problem in xterminal
2014-02-20 21:25 GMT+00:00 : > Le 20/02/2014 21:42:15, Manuel A. Fernandez Montecelo a écrit : > >> I don't understand... do you mean that you think that it's a bug with >> the apache2 scripts? That's my guess as well, what I don't know is >> if aptitude should try to restore the state of the terminal before >> continuing (if possible). > >> What does it mean "I even have the bug with aptitude", can you please >> rephrase? > > Every script that uses colour changes the colour of the following > lines, not only the colour of what has to be coloured. > The colour returns to its normal state when the script terminates. So "I even have the bug with aptitude" means: "It was not only in that occasion, I continue having this problem with aptitude now, and happens with every script that uses colours" Is that right? If the reply is yes, I will change the bug tags to confirmed, and in that case probably we should try to do some resetting of the terminal before continuing. I still would like to know if this happens for other people, and if it's with all terminal types, locales, etc... I personally have never seen this (or noticed it). Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#349414: aptitude: missing format string %-escape for the archive of the installed version
Control: tags -1 + moreinfo Hi, The reason why this is not straightforward, as far as I can tell, is because there's no place where this information is saved. Packages can be installed by several means, including by hand with dpkg, and in the basic information (.deb itself, or Packages files separately) there is no information about where it came from. I think that apt (and aptitude through libapt) extract this information from the content of /var/lib/apt/lists/ , that is, the set of Packages coming from whatever is enabled in your sources.list, mapping backwards the candidate version to the source of the Packages file where the version appears. For packages installed by hand or obsolete (installed through regular repositories/mirrors but not present anymore in the Packages list of the repository), this information is not present anywhere in the system at the moment (again, as far as I can tell). So I think it would not be an easy undertaking in the way in which things work at the moment. Opinions about what to do? Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670479: [aptitude] 'aptitude update' stucks at communication with /usr/lib/apt/methods/http
Control: tags -1 + moreinfo Likely a transient problem with no follow-up for almost two years. Unless more info is provided I think that this can be closed. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668544: aptitude hangs with full cpu load.
Control: tags -1 + moreinfo There were problems in past versions with the implementation of Boost.Flyweight affecting aptitude (bugs: 586429 613267 612001 599685, all before 0.6.6 I think). It shows in the backtrace but probably has nothing to do, and as Daniel says it's probably just busy in other parts. In any case, if no more info is provided, like the state bundled asked shortly after the bug was submitted (quite unlikely at this point), I would say that it's better to close the bug report and wait for a better opportunity to fix this, if still happens. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668544: [Aptitude-devel] Bug#668544: Unreproducible
2014-02-21 07:48 Raúl Sánchez Siles: Hello: Fortunately I found the bundle I created by then. I run it with: aptitude-run-state-bundle aptitude-bundle And behaviour was as expected now, no indefinite high CPU usage. Resolver just throws a solution. If you still want the bundle, let me know. Version 0.6.10-1 here. Therefore I'll be closing this one in a few days if nobody objects. From what I understood in the original report, it was happening for you all of the time. Was it doing the same operation always (e.g., safe-upgrade), or with different ones? Since this bug is somewhat recent and so the versions of all components involved didn't diverge too much, perhaps you could temporarily install 0.6.6-1 and try to run the bundle again? http://snapshot.debian.org/package/aptitude/0.6.6-1/ Or alternatively, send the bundle for inspection, with instructions about the commands that you ran and so on (if you can recall them). Thanks for the report and the quick follow-up. Cheers. -- Manuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668544: [Aptitude-devel] Bug#668544: Unreproducible
2014-02-21 21:17 GMT+00:00 Raúl Sánchez : > Hi: > > El Viernes, 21 de febrero de 2014 10:53:16 Manuel A. Fernandez Montecelo > escribió: >> From what I understood in the original report, it was happening for you >> all of the time. Was it doing the same operation always (e.g., >> safe-upgrade), or with different ones? >> >> Since this bug is somewhat recent and so the versions of all components >> involved didn't diverge too much, perhaps you could temporarily install >> 0.6.6-1 and try to run the bundle again? >> >>http://snapshot.debian.org/package/aptitude/0.6.6-1/ >> >> Or alternatively, send the bundle for inspection, with instructions >> about the commands that you ran and so on (if you can recall them). >> > >To be honest, I can't remember the exact operation, I remember it was 100% > reproducible. I somehow expected aptitude-run-bundle was enough to reproduce. > > I installed 0.6.6-1+b1 version. It was not straight forward, I had to > install libboost-iostreams1.49.0 and also manually fix [1] After that I > noticed > [2] didn't provide aptitude-run-bundle, so I took the script from current > aptitude-common package and run it (with aptitude 0.6.6-1+b1 installed). > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727694 > [2] > http://snapshot.debian.org/archive/debian/20120417T092831Z/pool/main/a/aptitude/aptitude_0.6.6-1%2Bb1_amd64.deb > > I'm not sure if with these steps I did something wrong, but unfortunately I > couldn't reproduce the problem either. I ran out of ideas, sorry. Don't worry, that was very helpul, thanks! > Nevertheless, you can find the bundle at [3] > > [3] http://trismegisto.no-ip.org/incoming/aptitude-bundle I also tried it and didn't observe any problem with it. So yeah, I would say that the bug can be closed. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679843: aptitude: Segfault in update
Control: tags -1 + moreinfo
2012-07-02 01:46 Andreas Kloeckner:
Package: aptitude
Version: 0.6.8-1
Severity: important
Dear Maintainer,
upon trying to update my package lists ('u') in aptitude, I just
received a segmentation fault with this backtrace:
Did it happen only for a few days, or for a long time, for example until
you reinstalled? Or still happening now?
I'm wondering if it was a transient problem in apt, or a corrupt file or
something, I haven't seen this in recent times. Giving the backtrace
and that segfaults in apt code, I am not sure if this can be dealt with
from aptitude.
Cheers.
--
Manuel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725280: Tag bugs as pending
tags 729329 + pending tags 728115 + pending tags 725280 + pending stop German translation update by Benjamin Weis and Holger Wansing (Closes: #729329) Japanese translation update (Closes: #728115) Russian translation update by Yuri Kozlov (Closes: #725280) -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720186: German translation confusing
Control: tags 720186 - pending Hi, I don't think that a fix for this was commited to the VCS, and it did not make it to the last release, so unmarking it as pending. If anybody can tell what's the right thing to do, either 'schl' or 'opt', we can fix it even if not knowing German ourselves :-) Cheers and thanks for the report. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720186: [Aptitude-devel] Bug#720186: German translation confusing
Hi, 2014/1/19 Axel Beckert : > Control: tag -1 + pending patch > > Hi Manuel, > > Manuel A. Fernandez Montecelo wrote: >> I don't think that a fix for this was commited to the VCS, > > It was committed but never pushed due to pending workflow questions. Oh, I see, I was wondering if that's what had happened. I thought about not unmarking it as pending because I was quite sure that you would reply within a day, but just in case, it was no big harm. > See http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=16;bug=720186 > >> and it did not make it to the last release, so unmarking it as >> pending. > > Granted. I nevertheless still have those commits (and some more :-) so > tagging again as pending, since I'm ready to push, I'm just unsure > where to push them, i.e. to which branch. > > I've got: > > + 1 upstream fix for #720186 > + 1 debian packaging fix to fix a lintian warning > + 1 debian packaging fix to fix a lintian warning, fixed in today's upload, > too > > Where can I push which one (the last one will be dropped of couse) > after rebasing on top of the current git branches? See another email that I sent about it, I think that should be "master" for the upstream fix (updating NEWS) and debian-sid for the packaging ones (updating the changelog but only for this, not the ones from "upstream" until they are merged. BTW, I updated most of the .po files (only comments I think, but if my update to the Debian translation was later than your commits...), so maybe you will experience conflicts. Perhaps it's better if you remove the local file and pull from the VCS again, to fix the one-line error/typo and commit. Also, if you want I can commit it on your behalf, but if you want to do it yourself (and fix more things) it would be great. Thanks for the fix. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727815: aptitude: spanish manpage, safe-upgrade section, translation wrong
Control: tags -1 + pending Commited and pending for next version, thanks. http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=0cc511d8c73b88eb1dd1b28e5ca53ed5ba14e014 -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735057: konqueror: Please use (also) WebKit as backend
2014/1/20 Lisandro Damián Nicanor Pérez Meyer :
>>
>> Aaron Seigo's reply (for those for whome the name does not ring a bell, he
>> is one of the most prominent upstream developers of KDE, and admin of that
>> forum):
>>
>>
>> Yes, KHTML is way behind the times. There is exactly nothing we can or will
>> do about that. Please use a webkit based browser such as Rekonq (Konqueror
>> can use the webkit part, btw), Chrome, Firefox..
>>
>> [...]
>> I repeated with Konqueror and the front page is not blank, but when
>> installing kpart-webkit package and selecting it as backend in Konqueror
>> ("General" -> "Default web browser engine"), the support for websites that
>> I generally use is much better, and the zoom of the pages much more useful
>> than with the default KHTML renderer.
>>
>> So I thought that it would be useful to pass on this information to the
>> Debian maintainers in the case that you are not aware, because if Aaron
>> recommends to use Webkit as a backend and it's possible to use Konqueror
>> with it by default, maybe we should switch the backend, or switch the
>> default, suggest/recommend kpart-webkit in the dependencies, or provide
>> alternative packages using the different backends (konqueror-khtml and
>> konqueror-webkit), for example.
>
> Hi! I think your subject confused me a little. You can use konqueror with
> webkit as you mentioned. Are you suggesting that we switch the default?
Hmm, it can be a bit confusing, yes.
What I meant is that if one of the devels behind KDE recommends to use
Webkit backend as a default for Konqueror, perhaps in Debian we should
be more proactive to make it the default. I don't know if there will
be people insisting on using the KHTML one, though.
To achieve this, probably the easiest solution would be
Require-ing|Recommend-ing kpart-webkit. The users then can still
select which backend they want from the "General" options of
Konqueror, but at least Webkit is selected as default when the package
is installed (I think).
The package konqueror currently does not even Depend|Recommend|Suggest
kpart-webkit at the moment, so I expect that most users don't even
know that Debian actually supports Webkit as renderer for Konqueror,
nor there are clear suggestions on how to achieve this (as far as I
know).
So the subject meant to say "arrange things in a way that users use
only webkit, or webkit by default, or at least as an option" without
having to fiddle with the system too much (e.g. install new packages
that are not even recommended).
Cheers.
--
Manuel A. Fernandez Montecelo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#630955: [INTL:zh_CN] Simplified Chinese translation Update 2011-06-19
Control: tags -1 + moreinfo Hi, We need a decision regarding this bug report, and better yet if possible, a full translation of the current aptitude messages (they did not change much since the provided .po files were sent). If you can help, please send a .po to include in the sources. Otherwise, if there's no reply within some weeks, I will close the bug report -- the translation can be included at any time when the .po is ready. Thanks for the work so far, in any case. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#414150: Help with missing/inaccurate screenshots in aptitude-doc-fr
Control: tags -1 + moreinfo Hello, French l10n team, These bugs have been unresolved for years in Aptitude documentation packages (french translation), without anybody stepping up to help. Obviously, without french-speaking people in the Aptitude team, it is not possible for us to fix them. So I decided to send you this request for help in the case that somebody can help us to get this fixed (and maybe update the rest of the documentation in french, if necessary). Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734801: aptitude: Wrong greek translation
Control: tags -1 + moreinfo Hi, Thanks for the report. Could you please download the .po file and fix it where necessary, then attach the file in a reply to this bug report? There are several instances of "recommend*" and "suggest*" in the package, so I am not sure which ones are bad and perhaps it would be useful to review them all anyway. Perhaps you are already used to translation tools and teams in Debian, but in the case that you are not some clues: You can use tools like "Lokalize" if you want to use something more fitting than a text editor (but emacs, vi or any GUI ones will work), and the Greek localisation team [2] can provide help if you need it. [1] http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=tree;f=po;h=5ecd6aa7ba4f80e70beaac8722d4c415ab9d0af0;hb=HEAD [2] https://lists.debian.org/debian-l10n-greek/ or debian-l10n-gr...@lists.debian.org Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#496724: aptitude-doc-en: html output fails validation
Hi, I cannot reproduce this bug now: $ validate --verbose /usr/share/doc/aptitude/html/en/index.html Checking /usr/share/doc/aptitude/html/en/index.html with HTML 4.01 Transitional document type... No errors! It seems to have been fixed in this commit, present in 0.6.8: commit 59d734c9028463c8b436851960195f8c69ef0693 Author: Daniel Hartwig Date: Fri May 11 16:54:56 2012 +0800 Add doctype headers to html docs. The "alt" part is not fixed yet, it seems. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736350: libopenscenegraph99: openscengraph sid version causes texture corruption in flightgear
2014/1/22 Alejandro Lorenzo Gallego : > Package: libopenscenegraph99 > Severity: normal > > Dear Maintainer, > > Current debian sid package 3.2.0-rc1-2 causes texture rendering in flightgear > become correupted on models. I have reproduced the bug in two different > machines. One running Intel graphics adapter (HD3000) and another running an > Nvidia GeForce GTX 560 with propietary drivers installed. > > The texture corruption issue disappeared after compiling and installing stable > upstream 3.2.0 openscenegraph. > > Please, consider upgrading sid package to upstream openscenegraph. > > Thanks for your time Thanks for your report. The problem with upgrading right now to 3.2.0 from the RC is that the packages changed ABI from our RC to the final 3.2.0, and thus require new binary package names, and they will have to wait for approval by the FTP team for an undeterminate amount of time (often weeks and sometimes months), and require binNMUs or even patches to some packages if the API also changed. We have things prepared for 3.2.1 since October, but what was available at the time was also an RC, 3.2.1RC1 I think, and we didn't want to have the same problem as with the RC of 3.2.0 (changes between RC and final in API or ABI). But the final version of 3.2.1, which was supposed to be launched shortly after that RC (both in October), hasn't been released yet. All attempts to get a date from upstream to release 3.2.1 were in vain, as far as I know, and it continues to be "any day now". Perhaps it would be easier to identify the commits fixing the problem between the RC and final in 3.2.0, and apply them. This is probably the quicker and easiest solution, unless it's the commits fixing the issues what caused the API/ABI changes. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716669: [aptitude] Wrong help for some aptitude options (es_ES locale)
Control: tags -1 + moreinfo Thanks for the report. We will need more info to fix this, or perhaps a full revision by Debian translators. The .po files can be downloaded here, if somebody wants to fix them and attach the resulting .po to this bug report. http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=tree;f=po;h=5ecd6aa7ba4f80e70beaac8722d4c415ab9d0af0;hb=HEAD Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679602: aptitude: Shows package task-spooler in Tasks hierachy despite being section misc
Control: tags -1 + pending Thanks for the report. Attempt to fix this commited to VCS, hopefully will be present in the next release. http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=f0056d948f281a879c2b4d2d1a75942b051a2fba Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#399757: aptitude: ./configure script ignores --with-package-state-loc and --with-lock-loc
Control: tags -1 + pending Thanks for the report. Attempt to fix this commited to VCS, hopefully will be present in the next release. http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=38c4c44d32e3af41b942f2e992917839baa1af31 Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736350: libopenscenegraph99: openscengraph sid version causes texture corruption in flightgear
2014/1/23 Rebecca N. Palmer : > I had a similar problem when testing FlightGear 2.12 in a Trusty (Ubuntu > 14.04) chroot, but had taken it to be a limitation of chrooting across > mesa/DRI versions rather than an actual bug. > > The textures involved (from > /usr/share/games/flightgear/Aircraft/f-14b/Models/Cockpit) are a mix of .rgb > and .png, with both formats being affected. > >> new binary package names, and they will have to wait for approval by >> the FTP team for an undeterminate amount of time (often weeks > > > The NEW-queue length dropped a lot last month > (https://ftp-master.debian.org/stat.html), and the typical wait is currently > around 1 week. And average is not a guarantee, there are plenty who have been waiting for months: https://ftp-master.debian.org/new.html The last ones that I recall, a bunch of libsdl2 modules a few months ago, it took 2 months. Even if they are processed quickly today, the queue can start to grow dramatically again, going from a week to two or three months (it happend like that at the beginning of 2013, or the year before). There are continuous spikes, see "NEW package count for the last 5 years". But other than that... is a solution to go from 3.2.0~rc to 3.2.1~rc, and will we not face the same problems? I don't think so, specially because after these many months, it's almost sure that there's breakage when 3.2.1 becomes final. > However, most of openscenegraph's reverse dependencies are currently broken, > so can't be binNMUd (patches exist for all except openwalnut, but they > haven't got around to applying them). If patches exist can be NMUed, assuming that the patches work. If the packages are unmaintained... well, they are unmaintained, somebody will step up or they wil be removed. >> Perhaps it would be easier to identify the commits fixing the problem >> between the RC and final in 3.2.0, and apply them. > > There aren't any commits between 3.2.0rc and 3.2.0 that explicitly mention > this kind of problem, but this one looks the most likely: > https://github.com/openscenegraph/osg/commit/b801ae9d499a78889a322b95fbdf9864828349bc If somebody can test the current source code from Debian applying this patch to confirm that it's working with the programs having problems, it would be great. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
After asking in #debian-ftp... 2014/1/22 Rebecca N. Palmer : > choreonoid and ossim turned out to also FTBFS (for > non-openscenegraph-related reasons); I have posted a patch for choreonoid > (#735891), and suggested that ossim (#735814) move to the already-fixed > version in the UbuntuGIS PPA. chorenoid can be NMUed, if that works, or solved by asking FTP to remove from mipsel. For OSSIM yes, it does not look good, it would probably need a major upgrade (the last upload was almost 2 years ago) or at least fix the immediate problem with libtiff5 plus other problems that might appear (I guess that it would affecting the transition libtiff5 as well). Or remove it completely, I don't know if that would be a good idea or likely to get people to agree. >> this no longer blocks anything else or needs to be handled >> as a transition. > > britney still thinks it does: "out of date on i386: libopenscenegraph80 > (from 3.0.1-4.1)". > > Given that libopenscenegraph80 is uninstallable (it depends on the > no-longer-existing libavcodec53/libavformat53/libavutil51), keeping it > around doesn't actually help its reverse dependencies; how should this be > dealt with? (request its removal? request that openscenegraph be forced to > testing anyway?) Packages from chorenoid on mipsel and OSSIM elsewhere depend on libopenscenegraph80 which is no longer built. I imagined that by removing OSG and rev-deps from testing, this would not prevent OSG to migrate to testing... but it does. Asking for removal of libopenscenegraph80 alone does not help as long as there are rev-deps... I asked for removal of src:ogre many months ago and still not done because Ember depends on it, even if it cannot build from source for almost a year. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573626: aptitude: Terrible Interactive Search Performance
Control: severity -1 wishlist Hi, As Daniel Burrows said, this behaviour is not simple to change, and it gets worse as package lists grow over time. Or maybe it will improve over time with larger CPU caches and faster memories, but still. I never noticed this as a problem in desktops or servers, even on old pieces of hardware, but it might happen that with some architectures they struggle. I also think as Daniel that it's very unlikely to be fixed soon, since the implementation to improve this needs a combination of techniques which is not trivial, and there are usually more serious or much more trivial to solve bugs and hitting many people. And also there's a workaround to avoid this situation. I think that that this will only be fixed, if ever does, as part of a large redesign and rewrite of the mentioned parts, UI and search. I will leave it in the wishlist for the time being. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716669: [aptitude] Wrong help for some aptitude options (es_ES locale)
Control: tags -1 + pending Commited, thanks. http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=8e6ffb0f8b087eda6bfcadc8ba1a3cd6f9b99094 -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#573626: [Aptitude-devel] Bug#573626: Bug#573626: aptitude: Terrible Interactive Search Performance
2014-01-23 19:34 Axel Beckert: Hi, Manuel A. Fernandez Montecelo wrote: I never noticed this as a problem in desktops or servers, even on old pieces of hardware, I agree. but it might happen that with some architectures they struggle. Even on my slowest boxes (Alix, Sparcs, PowerMac G4, cheap VMs, ARM netbook, DEC Alpha, 1st generation EeePC, etc.) I've never felt this being an issue. Startup performance is way more annoying than this, at least for me. :-) But then again, I'm also always using two non-default settings which may speed up usage, too: * I disabled Aptitude::UI::Incremental-Search as I don't want arbitrary branches to be opened during searching. * I enabled Aptitude::UI::Minibuf-Prompts as I can close that prompt with Ctrl-G as in Emacs. :-) I've just did a short test on my PowerMac G4 and I had the feeling that searching without these two options is slightly slower. So these two settings may help people who consider the interactive search to be too slugish. I agree that start-up performance and other operations are much more annoying. (Unrelatedly but similarly very noticeable and annoying for me, pdiffs in the last few years for people with even modest connections). I think that adding many repositories, e.g. Debian + Ubuntu, Mint or others (Raspbian or EmDebian, because or this ARM thing?), might also add to the problem. That's why I am not sure if it's better to leave this open or close it. Realistically, I don't think that this is going to be fixed, and in any case not because of the existence of this problem, so leaving it open will not increase the chances of it being fixed. Also it was ignored for the best part of 4 years with no "me toos". I only see it useful as a reminder, or to leave hints like what you gave above. Opinions? Cheers. -- Manuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#633788: aptitude: add "Reinstall (shortcut L)" to the package menu
Control: tags -1 + pending Commited to the VCS http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=daaa18a515f76cc6d7c59c635f4d8ec049138cf2 -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#348758: aptitude: confuses "purge" with "install" in error message
Control: tags -1 + pending Commited to VCS: http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=4ac34e9d8af9140018e2cfeb945c788af9fe8b65 -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#267162: [Aptitude-devel] Bug#267162: Bug#267162: marked as done (aptitude: "not installed" not noted upon purge)
2014-01-24 02:38 Daniel Hartwig: >> -- Forwarded message -- >> From: Dan Jacobson >> To: Debian Bug Tracking System >> Cc: >> Date: Sat, 21 Aug 2004 03:01:49 +0800 >> Subject: aptitude: "not installed" not noted upon purge > >># aptitude purge libgd2-xpm >>... >>The following packages have been kept back: >> >> You forgot the "... is not installed" line! >> > >> -- Forwarded message -- >> From: "Manuel A. Fernandez Montecelo" > >> This bug report was submitted many years ago and never handled. This >> does not seem to happen now as described in the bug report (at least >> in my system, with pretty much the stock configuration). > >In the time between the bug report and your testing, it was decided >that such output is only when --verbose is used. The inconsistency is >still there, as confirmed by examination of the code and performing >the commands with verbose enabled. That's fine, but nothing of this was explained in the bug report, so that's why I was asking for reopening or submitting a new bug report with up to date information to explain the new desired behaviour. >This issue and other inconsistencies in the command line interface >will be addressed by an extensive work I have in progress to >restructure that module, using new tools exported by apt. The >foundations of this work was in the 0.6.9 release, but that has been >reworked and will be applied once the final changes are complete. I think that it would be useful to document things like this, in bug reports or elsewhere, and use public branches to know what's going on, otherwise people will not magically know that things like this are being worked on. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674681: aptitude: Please add descriptions for recently added sections
Control: tags -1 + pending Commited to VCS. I was researching in the original posts and added more text, because we need at least short and longer descriptions. Can be changed if needed, of course. http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=639e95991ee36d31934cc3c7a47efde1c385befa -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
2014/1/23 Manuel A. Fernandez Montecelo : > 2014/1/22 Rebecca N. Palmer : >> choreonoid and ossim turned out to also FTBFS (for >> non-openscenegraph-related reasons); I have posted a patch for choreonoid >> (#735891), and suggested that ossim (#735814) move to the already-fixed >> version in the UbuntuGIS PPA. > > chorenoid can be NMUed, if that works, or solved by asking FTP to > remove from mipsel. > > For OSSIM yes, it does not look good, it would probably need a major > upgrade (the last upload was almost 2 years ago) or at least fix the > immediate problem with libtiff5 plus other problems that might appear > (I guess that it would affecting the transition libtiff5 as well). Or > remove it completely, I don't know if that would be a good idea or > likely to get people to agree. I was talking yesterday with Markus Wanner and I think that he can either update OSSIM or fix it to fix the building problems, so if this happens it will clear the way quite a bit. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#723821: aptitude: aptitude changelog segfaults
Control: tags -1 + pending
Hi,
If it was working in squeeze, the commit which likely introduced the
problem is this one:
http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=7065dcc0bf2393ca0407e863d656da67102dd396
I commited a fix which seems to solve the issue, it's simple but it
took quite a while to track it down and figure out.
Basically, the variable pkg.Name() is not valid at this point in the
code for source packages so it segfaults, so I changed to use
"p.get_package()" which is the source package name ("input" from the
command line argument also works).
http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=f9c69b920ab89861ae681959d8591d2edfc6e624
If there's no problem it will be fixed in the next release with new
"upstream" code.
Cheers.
--
Manuel A. Fernandez Montecelo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708345: aptitude: Aptitude fails to download changelogs for many packages
Control: tags -1 +pending Hi, Fix commited, marking as pending to upload. (I noticed that it was marked as "owned" only after pushing to alioth and before writing this e-mail, I hope that it's not a problem). http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=7c28d436b4ddd765aa8b9ab7b2062da5b37ee528 Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725428: aptitude: FTBFS against rebuilt libept
reassign 725428 libept1.4.12 unarchive 727540 forcemerge 727540 725428 archive 727540 stop Hi, Thanks for your bug report. This seems a duplicate of bugs reported to libept in October 2013 and fixed during that month. I try above to merge this one with the others, let's see if if I was able to create the correct incantations for control@. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#277523: aptitude: 'plus' on numeric keyboard does not work in gnome-terminal
Control: tags -1 + confirmed It still seems to happen with gnome-terminal almost 10 years later. Also happens in xterm. Works fine in konsole. gnome-terminal - 3.10.1-1 konsole - 4:4.11.3-1 xterm - 301-1 Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#360202: aptitude: misaligned output of aptitude show in ru_RU.UTF-8 locale
Control: tags -1 + confirmed
The problem seems to be here:
src/cmdline/cmdline_show.cc:
return cw::fragf("%s: %F",
title.c_str(),
indentbox(0, title.size()+2,
flowbox(cw::join_fragments(fragments, L", ";
For indenting name and contents of a field (e.g. Depends) on several
lines, it uses zero as the first parameter meaning spaces of
indentation of the first line, and the second parameter for the spaces
of indentation of the remaining lines.
Since it takes "title.size() + 2", presumably because in ru_RU.UTF-8
locale each character takes two positions in a std::string (the type
of "title" variable), the lines following the first one are indented
with roughly double of the space needed.
This should be easy to fix if one knows how many characters will
occupy when printed. But probably there should be a comprehensive
review of all this and use a solution everywhere in the code, not just
here.
Using std::wstring for all translatable strings might help, but I
don't know if it will work fine all the charsets. Probably C++11 has
better support for this, so maybe this is the way to go.
Cheers.
--
Manuel A. Fernandez Montecelo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#360202: Wrong calculations about string sizes with russial locales
I think that #610955 is related to #350202. Not merging or doing other triaging actions because I don't have time for deeper investigation at the moment. But I think that this is a general problem when languages require more than 1 byte to represent the charsets. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#538307: aptitude: package view doesn't show description for some packages
Control: tags -1 + moreinfo Hi, Can you please try to see if this happens in current versions of aptitude? Maybe the fact that "asylum" doesn't have any candidate (nor installed) version is what it's causing the problem. If you (or anybody) could verify whether this is an issue with the rest of games/packages (trying to correlate lack of description and lack of candidate or installed versions), it would be great. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676075: aptitude: sort by size change
Control: tags -1 + pending Hi, Change commited. If you want a change in the name (it's a bit cumbersome, but consistent with "installsize" and "change") or description in the documentation, please speak before it's released in an official version. http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=828363d069b70cf317fc59c9f23e9c93a49c6b08 Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539978: aptitude: "show" says an installed package is not installed
Control: tags -1 + unreproducible Control: tags -1 + moreinfo Hi, Actually I don't think that the bug happens now as stated in the original report and the issue has been fixed, but I don't know if the same problem reappears under some conditions. Looking for to the show output of the 81 upgradable packages in my system right know, it says "installed" for all of them, so I think that this has been fixed and the report can be closed. Could you please do some checks and see if you are satisfied with the result, or otherwise explain what you would like to see? # aptitude show $(aptitude search '~U' -F '%p') | grep ^State | uniq -c 81 State: installed = # apt-cache policy apt apt: Installed: 0.9.14.2 Candidate: 0.9.15 Version table: 0.9.15 0 500 http://ftp/debian/ unstable/main amd64 Packages *** 0.9.14.2 0 100 /var/lib/dpkg/status # aptitude versions '^apt$' Package apt: i 0.9.14.2100 p 0.9.15unstable 500 # aptitude show apt Package: apt Essential: yes State: installed Automatically installed: no Version: 0.9.14.2 ... Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720750: aptitude: search returns different numbers of packages depending on sort order
Control: tags -1 + confirmed Control: tags -1 + owner Thanks for your bug report. I found about this yesterterday independently, and confirmed your results above. I think that some results of the comparison make the loop stop short of processing the whole list of packages. I will try to find the problem and have a fix ready by the next release. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519893: aptitude: aptitude attempts to resolve unmet dependencies by upgrading a package with itself
Control: severity -1 wishlist Control: tags -1 + wontfix Control: retitle -1 aptitude: support for same package name and version in different repositories but different content Hi, As the maintainer said, all of the main Debian packaging tools, dpkg, apt and aptitude, decide on versions to install and what's newest based on comparing package versions (see dpkg --compare-versions). Se also #737085 for a recent example with apt of how things go wrong because of this, even with quite skilled developers very familiar with the system try to bootstrap a new architecture. So having different packages in different repositories with the same name and version is not something that the tools are designed/prepared to handle nicely, so I don't think that this request will ever be addressed. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#357542: aptitude: changelog display does not work on recent uploads
Control: owner -1 ! This can probably be fixed now by downloading the files from the target distribution, when the first attempt to get by package name and version fails, e.g.: experimental_changelog unstable_changelog http://metadata.ftp-master.debian.org/changelogs/main/m/mono/ Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729289: whatever you want to call this: openscenegraph
2014-01-31 Markus Wanner : > On 01/31/2014 07:28 PM, Niels Thykier wrote: >> On the topic of 99->100, do you know if that will happen any time soon? >> I am wondering whether we should go for finishing the 80->99 and do a >> separate 99->100 or wait and jump directly from 80->100. If 100 is >> coming soon, it is probably easiest to do 80->100 (will save us a couple >> of rebuilds and we waiting for other things right now anyway). >> On the other hand, I would hate for this transition to drag on waiting >> for a new version that isn't happening while blocking other packages >> from reaching testing. > > IIUC release 3.2.0 (as opposed to the rc) already brings SOVERSION 100. > So we could release that and transition to 100 right away. What Markus says is right. What happened was that they did some important/nasty code changes just before the the ~rc1, which we/I didn't relalise that it would be bad (because upstream didn't expect any major problems). But adapting other packages to it was not as easy/smooth as upstream expected. Then they changed 99->100 between version 3.2.0~rc1 (current package in Debian) and the final 3.2.0, so updating Debian would cause again a round of rebuilds and maybe more source changes; and while pondering whether to upgrade the package in Debian to the final upstream version, they released 3.2.1~rc1 very shortly afterwards, planning to release 3.2.1 within the same month. But that was in October, with expectations every now and then that the release would be imminent, but it didn't happen. So we wanted to jump from 3.2.0~rc1 with SOVERSION 99 to 3.2.1 final with SOVERSION ), to avoid the problems that Niels mentions (despite what Markus said later, I thought that it can be higher than 100 before 3.2.1 final). (There were other problems and the package was unbuildable for quite some time, mostly my fault, but in truth related with other pressing issues in my Debian duties and due to expecting to have the 3.2.1 upstream released and fixing everything together without more disturbances to rdeps... which didn't happen, so we recently decided to not wait any longer and fix 3.2.0~rc1). > Also note that release 3.2.1 is due as well (for quite some time now, > though. RC2 has been released, recently). However, according to their > website [1], it should be binary compatible. (And their current 3.2 > branch still has a SOVERSION of 100.) So going straight through to 100 > seems reasonable to me. Seeing that back in summer we took a similar decision based on similar premises, which later were not fulfilled and led to the situation that we have now, I am not sure that we should jump to 3.2.1, or even that it's going to be released before March or April. But I am open to any suggestion really, I just want to avoid more problems for rdeps. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#357542: aptitude: changelog display does not work on recent uploads
2014-01-31 Daniel Hartwig : > On 31 January 2014 20:32, Manuel A. Fernandez Montecelo > wrote: >> Control: owner -1 ! >> >> This can probably be fixed now by downloading the files from the >> target distribution, when the first attempt to get by package name and >> version fails, e.g.: >> >> experimental_changelog >> unstable_changelog > > Those files are updated at the same time as NAME_VERSION_changelog, so > if this is not available then DIST_changelog will be for an older > version and not contain the recent changes. I think that it would happen the contrary, the DIST_changelog would always be same or newer, and if anything NAME_VERSION+1_changelog replaced the version that aptitude asks about. Because this "metadata" central place would be always more up to date than the mirror (or the last "aptitude update"). Even if giving a newer version than expected, I think that it's a nicer fall-back than having a "404" because it cannot find the file for the exact version, and by the most recent version of the changelog one can see (if one cares about looking at the version line) that the version is not available. In general, DIST_changelog should always exist, unless the package is removed or renamed, that's why I think that it would be a good fallback. >> http://metadata.ftp-master.debian.org/changelogs/main/m/mono/ > > Does this service update more immediately than packages.d.o? If so, > then it is quite possibly this is not an issue any more. I expect that, being under control of FTP masters (gatekeepers of packages in the archive), is more up to date than packages.d.o in the past, even if only for propagation delays. But packages.d.o now is a redirection to metadata. The only real difference now is probably that aptitude would be accessing with an extra redirection that could cause problem if the redirection goes away (the lack of which caused the original bug report) or the server is down. Sysadmins also announced that metadata is serverd by a CDN now, so perhaps is a tad more efficient. > If the delay is still noticeable (I have not noticed since the > switch), then DIST_changelog may be a reasonable fallback. I presume > the user will want some notice that they have not received the most > recent changelog/changelog for the version they requested. I think that this would almost always only happen in testing or unstable (not stable), I don't think that this realistically can affect anybody in stable, or that nobody will cares enough (if anything, the newer version will contain important fixes). Personally, using mostly unstable (where this can happen more often), I am not overly worried about the versions of packages that I am about to install which maybe are not in the mirrors, because the situation in unstable can change at any moment (it's perfectly possible to have more than 1 version uploaded per day), and in testing at least once per day. In any case, perhaps is an issue for some users, and we can add the suggested warning. Is printing a warning message along with the example below enough (which cannot be seen until after the pager quits), or should it require to press a key to make sure that the user notices before seeing the changelog in the pager? Get: Changelog of libdrm Get: Changelog of libdrm2 Warning: Changelog of libdrm2 is for latest version in unstable (3.2-1 not found) Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720750: aptitude: search returns different numbers of packages depending on sort order
Control: tags -1 + pending Fix commited, it will be included in the next release if no problem is found with the fix. http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=845a868dc3a7af063c586c2b6ebf5e97daa90491 Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
2014-02-02 Niels Thykier : > On 2014-02-01 14:11, Rebecca N. Palmer wrote: >> The state of openscenegraph itself isn't the problem here: what we're >> waiting for is for simgear to clear NEW and for Release Team to give >> official permission (britney hint??) to ignore openwalnut for now. > > Actually both of those things are FTP master decisions. If openwalnut > had been in testing, then that part would need both FTP masters and the > Release Team - but since it is not, then we just need the FTP masters > approval for getting openscenegraph decrufted at the price of breaking > openwalnut (even further). > > I can ask the FTP masters to process simgear - decrufting openscenegraph > will have to wait until we have fixed all the packages that we can. > >> There is the separate question of whether you want an ~rc in an Ubuntu >> LTS (14.04 freezes 20 Feb), but they finished their transition to >> 3.2.0rc months ago (by removing openwalnut) and will sync from >> experimental if you ask them to, so that isn't tied to what we do in >> Debian. > > Based on Manuel's mail (not quoted here), I think I would prefer if we > transitioned to openscenegraph ABI 99 rather than 100. In my eyes, it > makes the whole thing simpler and means we can start working immediately > - especially considering that our best guess on a release date for the > new version is more than a week or two away (Manuel suggested March or > later). Actually, I meant to say that we (or at least I) don't have any confidence in the accuracy of our best guesses for the date when 3.2.1 final will be available (meaning: I don't have much confidence in upstream's predicitons, or their assurance to not change ABI again for 3.2.1 final). Because the estimations from upstream have been "any time now" for months (repeated every now and then), but with a delay of more than 3 months since the initial estimate. But it can also be released in the next days or weeks... nothing prevents that, AFAIK. Perhaps Alberto or Rebecca (who follow upstream mailing lists) have better guesses about the current state of mind of upstream. So we finally gave up on waiting and fixed the current version in Debian unstable in mid January without waiting any longer, trying not to continue causing disruption in Debian. From my part, and I think Alberto's, any solution minimising problems for the rest of Debian will be fine. Given that any newer upstream release (even 3.2.0 final) will have to go through the NEW queue (ABI/soname changes), even if they release tomorrow it will take a while to get to unstable anyway; and then there's the round of binNMUs and NMUs. So for the sake of rdeps, we thought that stabilising with ABI 99 is a good idea, or else we might continue in the same situation for months. Also, for the future, question to Niels: we know that multiple versions of the same library are discouraged, but maybe it would be useful in this case to accomodate to the pace of different rdeps? This library doesn't exist in Debian only (or perhaps even mainly) because the rdeps in Debian, but because of the library itself, and many people use it independently of other packages installed. That's why it is desirable to have the latest versions quickly as well. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720750: aptitude: search returns different numbers of packages depending on sort order
2014-02-03 Daniel Hartwig : > Control: tags -1 - pending > > On 3 February 2014 02:56, Manuel A. Fernandez Montecelo > wrote: >> Control: tags -1 + pending >> >> Fix commited, it will be included in the next release if no problem is >> found with the fix. >> >> http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=845a868dc3a7af063c586c2b6ebf5e97daa90491 >> > >> + >> +/* mafm: Disabled because it does not respect the 3 way comparison of >> the >> + * sort policies, so it removes from the result set any items with the >> same >> + * result for the given policy (package_results_eq with successful >> result, >> + * which means comparison result zero in policy). >> + * >> + * This is usually not noticeable in names (should be unique) or sizes >> of >> + * packages (very rare that the size is the same); but it does not work >> well >> + * on versions (repeated sometimes) and specially not in priorities, >> since >> + * they are only a few of them for all of the packages in the archive. >> + >> output.erase(std::unique(output.begin(), output.end(), >> >> aptitude::cmdline::package_results_eq(sort_policy)), >> output.end()); >> +*/ > > The search results will now include duplicate packages where there are > multiple search patterns matching the same package: > > $ ./aptitude search '?name(^emacs24)' '?name(^emacs24)' > p emacs24 - GNU Emacs editor (with GTK+ user > interface > p emacs24 - GNU Emacs editor (with GTK+ user > interface > [...] > > (That example is obviously contrived, but it is quite common for > multiple patterns to have overlapping matches.) Perhaps it has the intended effect then? ;-) > It is package_results_eq that must be corrected to properly address > this. That function should consider package equality, rather than > equality in sort_policy. > > Please revert. Note that package_results_eq no longer exists after > wip-cmdline as search results are collected in a pkgset [libapt] which > guarantees to contain only unique packages. Likewise for versions using > verset. > > If you like, feel free to submit a patch for consideration that > addresses the issue in package_results_eq. Though, as I mentioned, this > will otherwise be resolved by the pending merge of wip-cmdline. When is this going to be fixed more or less? Weeks or months? If it's weeks I can revert the one above and it's probably fine, the bug is minor and has been present since 2010 at least (feabf55d in 2010-04-16). > Also related to this is the earlier addition of installsizechange. This > is a 2-way comparison, inconsistent with the rest of the sorting module > which is 3-way. There is this comment: > >> + // mafm: if returning zero, the comparison stops for >> + // other packages > > Clearly this refers to bug #720750. Are there other areas you know > about where this is an issue? If there are, we can fix those instead of > hacking around them in the sorting module. > > Sorting module presently relies on 3-way comparisons for functionality > such as chaining (as with a sort policy of "priority, name"). At > present, installsizechange will fail to chain correctly and this should > be corrected. What do you mean? It's already fixed after I realised that the problem was elsewhere: http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=1583a5b2212ed22319b3a3b6d4d4b047c34cd71c I don't know more areas where this is an issue, no. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
2014-02-03 Rebecca N. Palmer : >> >> Also, for the future, question to Niels: we know that multiple >> versions of the same library are discouraged, but maybe it would be >> useful in this case to accomodate to the pace of different rdeps? > > That wouldn't be as useful as it might look: openwalnut have long > recommended using their own repository (in a VM if necessary) instead of > their Debian-main packages > (http://www.openwalnut.org/projects/openwalnut/wiki/Getting_OpenWalnut), and > all the other problems that were actually due to openscenegraph changes (as > opposed to other issues that would be RC bugs whether or not this transition > existed) were fixed (at least upstream) months ago. (This starts to be offtopic, so perhaps would be better to stop discussing it in the bug report). I don't understand why this would not be useful with my proposal. Having several versions is supposed to be discouraged, that's why we never tried to implement this, but at least I would be in favour of it. That means that we could have: - 3.3 or 3.4 (when available) for developers using the library directly, and stabilise that version in Debian before we ask rdeps to start to migrate, - 3.2.* for (most) debian rdeps, - and perhaps an older version 3.0.* while other rdepends (more conservative, or less actively maintained) don't migrate. So, if anything, it would help to not make rdeps to move so fast and allow them to stabilise, with larger time-frames to update their build-depends, while still providing the latest and greatest to developers and weeding out some problems before rdeps suffer them. This can only help OpenWalnut to be more stable in Debian, so I don't understand why you say that it would not be useful. If it's simply because "nobody uses OpenWalnut", well, in this case it could as well be removed from Debian. Its popcon is very low indeed (not only now, but even more so in the years before OSG was broken). But still, I don't think that low popcon is good reason to remove packages, specially when they are intended to be useful only for a relatively small population. http://qa.debian.org/popcon.php?package=openwalnut Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720750: aptitude: search returns different numbers of packages depending on sort order
2014-02-03 Daniel Hartwig : >>> The search results will now include duplicate packages where there are >>> multiple search patterns matching the same package: >>> >>> $ ./aptitude search '?name(^emacs24)' '?name(^emacs24)' >>> p emacs24 - GNU Emacs editor (with GTK+ user >>> interface >>> p emacs24 - GNU Emacs editor (with GTK+ user >>> interface >>> [...] >>> >>> (That example is obviously contrived, but it is quite common for >>> multiple patterns to have overlapping matches.) >> >> Perhaps it has the intended effect then? ;-) > > Duplicates are not desirable, even if it resolves the issue with > missing packages. Anyway, lets just have it reverted and fixed on > wip-cmdline (weeks now, see below). It was a joke, that if one puts the terms twice, having duplicated output might be the intended behaviour. I agree that this the current solution is not good in the case of overlaps (or well, trades one bug for one undesired behaviour or bug, depending on the point of view). So I will fix this within a couple of days, no problem. >>> Though, as I mentioned, this >>> will otherwise be resolved by the pending merge of wip-cmdline. >> >> When is this going to be fixed more or less? Weeks or months? > > I expect within two weeks. It would be good if you send the plans to the mailing list soonish, to see how these fixes translate in releases. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729289: transition: openscenegraph
2014-02-03 Rebecca N. Palmer : > The choreonoid maintainer has agreed to my fix. > > >> (This starts to be offtopic, so perhaps would be better to stop >> discussing it in the bug report). > > Where would you suggest: #718381 (the openwalnut breakage) or a new wishlist > bug against openscenegraph? The offtopic part was my question about having several versions at the same time, not the rest. >> I don't understand why this would not be useful with my proposal. > > I didn't say it would be useless, just less useful than the high proportion > of breakages here might suggest. > >> , and stabilise that version in Debian before we ask rdeps to >> start to migrate, > > Use experimental for that? We did that in the past, it's not very useful for feedback because almost nobody uses it, and it does not migrate automatically to unstable or testing until some period so you have to reupload, etc. In general, that's not a substitute for having several versions in unstable or in testing at the same time and be able to switch between them. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#720750: aptitude: search returns different numbers of packages depending on sort order
Control: tags -1 + pending 2014-02-03 Daniel Hartwig : > The search results will now include duplicate packages where there are > multiple search patterns matching the same package: > > $ ./aptitude search '?name(^emacs24)' '?name(^emacs24)' > p emacs24 - GNU Emacs editor (with GTK+ user > interface > p emacs24 - GNU Emacs editor (with GTK+ user > interface > [...] > > (That example is obviously contrived, but it is quite common for > multiple patterns to have overlapping matches.) Funnily enough, it also depends on how the search patterns are given, if in different argumensts or not... $ ./src/aptitude search '?name(^emacs24$) ?name(^emacs24$)' -F '%p' emacs24 emacs24:i386 $ ./src/aptitude search '?name(^emacs24$)' '?name(^emacs24$)' -F '%p' emacs24 emacs24 emacs24:i386 emacs24:i386 With overlapping patterns... $ ./src/aptitude search '?name(^emacs24$) ?and(?name(^emacs),?name(24$))' -F '%p' emacs24 emacs24:i386 $ ./src/aptitude search '?name(^emacs24$)' '?and(?name(^emacs),?name(24$))' -F '%p' emacs24 emacs24 emacs24:i386 emacs24:i386 After the fix: $ ./src/aptitude search '~n^emacs24$' '?and(~n^emacs,~n24$)' -F '%p' emacs24 emacs24:i386 $ ./src/aptitude search '~n^emacs24$ ?and(~n^emacs,~n24$)' -F '%p' emacs24 emacs24:i386 Fix: http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=435bcc75b3c2a3132ee4d6ca632346d6f8b6fa34 Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#507525: aptitude crashed
Control: reassign -1 src:cwidget Line 480 in cwidget is indeed and abort(), which raises the exception shown in the stack traces and causes the whole program (aptitude) to, well, abort. https://source.debian.net/src/cwidget/0.5.16-3/src/cwidget/widgets/menubar.cc Basically, the function tries to hide the menu bar itself or one of its elements (I'm not familiar with the internals of cwidget), with the given reference (w). The loop iterates over the active_menus, but cannot find any that matches for the given reference "w" (in which case it will do the necessary bookkeeping and return from the function). Instead, not finding any matches, ends the loop and finds the abort in the end (which I think that is a bad practice specially in libraries, but well). Given that there are threads and signals involved, I guess that this is a synchronisation issue. I am not sure if aptitude is at fault for misusing sync primitives, but in principle I think that the issue lies more with cwidget, so accordingly I am reassigning it. For the record, I tried to contact Daniel Burrows some weeks/months ago to continue with the development of cwidget, at least to not burden other developers with NMUs when needed and to try to fix problems like these when possible, but no reply from him. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#405506: aptitude cannot parse package file
Control: tags -1 + moreinfo - unreproducible Control: severity -1 wishlist Control: retitle -1 handle corrupted pkgstate more gracefully I think that if this bug is to be kept open and fixed, this proposal from Daniel Burrows is the way to go (and the only remaining useful bit from the bug report). Retitling etc. accordingly. - Maybe aptitude should offer to restore pkgstate.old or move the corrupt file out of the way. This would be a bit more graceful than going "gaaack" and dying. The basic idea (if the user asks to recover) would be (1) move pkgstates to pkgstates.broken.NUM where NUM is the first unused number (actually use link(2) to avoid clobbering existing files). (2) if pkgstates.old exists, move it to pkgstates. (3) if pkgstates exists and is not parsable, go to (1) (i.e., move pkgstates.old out of the way and start completely from scratch) -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#700072: aptitude-curses crashed with SIGSEGV in std::basic_string, std::allocator >::basic_string()
Control: tags 700072 + moreinfo I think that this is a duplicate of #723821, if so it should be fixed in the next upload, please reconfirm and close then. I am not completely sure (and thus don't merge) because, at least in my system, python-dbusmock is both the source and a binary package name, which is different from the situation that triggered #723821. $ aptitude search dbusmock -F '%p %d' python-dbusmock mock D-Bus objects for tests (Python 2) python3-dbusmockmock D-Bus objects for tests (Python 3) Then again, at the time of submitting this bug (8 Feb 2013 07:21:01 UTC) there was only the version for Python 3, so it looks likely that the underlying bug was the same. python-dbusmock (0.7.2-2) unstable; urgency=low * Build a Python 2 package. (LP: #1230141) -- Martin Pitt Wed, 25 Sep 2013 10:15:34 +0200 Binary packages from snapshots of versions prior to that: http://snapshot.debian.org/package/python-dbusmock/0.7.2-1/ Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#405907: aptitude: Bus error on sparc if a package on cmdline does not exist
Control: tags -1 + moreinfo (Axel: adding you explicitly because you have sparc machines around still in good working order and on-line, IIRC). Can somebody please confirm if this still happens in more recent versions? It's 7 years later, I think that such a basic problem must have been fixed in the meantime, in one way or another. Please close it if you cannot reproduce it. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#385784: aptitude: crash with basic_string::_S_construct NULL not valid
Control: tags -1 + moreinfo This bug needs to be reevaluated since it's quite old and the other parts involved (including dpkg and apt) must have changed significantly in these 7 years. I am not sure if this situation of "Package is in a very bad inconsistent state - you should reinstall it before attempting a removal" can be forced, which would be nice to try to reproduce and fix the problem. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#405907: [Aptitude-devel] Bug#405907: marked as done (aptitude: Bus error on sparc if a package on cmdline does not exist)
2014-02-05 22:54 Debian Bug Tracking System: Manuel A. Fernandez Montecelo wrote: (Axel: adding you explicitly because you have sparc machines around still in good working order and on-line, IIRC). Indeed. # uname -a Linux hw 2.6.32-5-sparc64-smp #1 SMP Tue Sep 24 00:00:54 UTC 2013 sparc64 GNU/Linux [...] It's 7 years later, I think that such a basic problem must have been fixed in the meantime, in one way or another. Please close it if you cannot reproduce it. Looks fine. Closing. This is sparc64, not sparc. Did you use "sparc" ones in the past few years, or only sparc64? But well, all in all I am pretty sure that if this was happening for a long time for such a basic functionality, there should have been more complaints; so I think that it's safe to close the bug report nevertheless. Cheers. -- Manuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533247: aptitude: Segmentation Fault on all attempts to access apt database
Hi, 2014-02-05 Daniel Moerner : > Thanks for looking into this, I think it's reasonable to close it. I now > longer have the core files. OK. Thanks for submitting the bug report and following up despite not having replies for the maintainer, by the way... I forgot to add this in the previous e-mail :-) Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737876: flare: menu icon entry missing
2014-02-06 Markus Koschany : > Hi Henner, > > On 06.02.2014 18:57, Jan-Hendrik Peters wrote: >> Hi Markus, >> >> which Desktop Environment do you use? I use XFCE and have a Menu entry >> under "Games" for flare which has an icon as well. > > I was referring to the Debian menu and XFCE uses the freedesktop > standard, the .desktop file. The Debian menu is an alternative menu for > window manager setups nowadays. > > The fix is trivial. Check out the link I posted. > > https://wiki.debian.org/Games/JessieReleaseGoal > > You can either convert your existing png icon for your desktop file to a > 32x32 xpm file with GIMP or mtpaint or you can build the icon from > source with imagemagick in your dh_auto_build-indep target. Then you > just have to add an icon entry to your menu file. > > That's it and your package is fully integrated in whatever desktop > environment. > > Thanks > > Markus According to recent conversations in mailing lists, I got the impression that the Debian menu is going to be killed (and if it's not, I think that it will be due to lack of enthusiasm to make the necessary changes in the policy). Either way, since the fix is easy, we can incorporate it, no problem. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#418361: aptitude: (some) aptitude colours suck
Control: tags -1 + moreinfo -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#418361: aptitude: (some) aptitude colours suck
Ops, hit send before writing the text. For me, the default colours of aptitude are not particularly eye-straining or anything like the combinations that you mention (unless they were changed since the bug was submitted, but I don't think so and I've been using aptitude for more than a decade). "white on blue is good. white on black is good", and those are the default colours for me. So unless you mean some special menus or error messages, or that it behaves differently depending on the background of the terminal (mine is black), I am not sure about what you are talking about. If you don't like "Light Blue on Orange is unreadable", just don't switch to that theme or use those colours, I think that it's the easiest solution. It might have its uses though, e.g. if you want to show aptitude running on openmoko to your friends in a rave. And in general, I think that your tone is a bit inappropriate, because no developer has to be forced to read books on design to publish software that they create in their free time, or are expect to be knowledgeable in every field. Since you seem to be interested in that field, perhaps you have suggestions of concrete things to fix, and it will be more helpful, but this bug as it is is not very useful. Here's the documentation about colours (also available installing aptitude-doc-en): http://aptitude.alioth.debian.org/doc/en/ch02s05s03.html Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#588665: aptitude: Impossible update (I think that aptitude can't find dependencys)
Control: tags -1 + moreinfo Hi, It is unclear if this is because of an infinite loop, or because for example the machine starts using swap memory and things slow down significantly after some point, or perhaps because it tries very hard to work out how to upgrade without removing packages (which is the mode of operation of "safe-upgrade"). Does this still happen in your system, and if yes with which versions of aptitude? Does it happen the same when you do "full-upgrade" (be warned that it might be more disruptive changes than "safe-upgrade", as the name implies)? >From the manual page: safe-upgrade [...] It is sometimes necessary to remove one package in order to upgrade another; this command is not able to upgrade packages in such situations. Use the full-upgrade command to upgrade as many packages as possible. full-upgrade Upgrades installed packages to their most recent version, removing or installing packages as necessary. This command is less conservative than safe-upgrade and thus more likely to perform unwanted actions. However, it is capable of upgrading packages that safe-upgrade cannot upgrade. You can perhaps also try partial upgrades to alleviate the situation: If no s are listed on the command line, aptitude will attempt to upgrade every package that can be upgraded. Otherwise, aptitude will attempt to upgrade only the packages which it is instructed to upgrade. The s can be extended with suffixes in the same manner as arguments to aptitude install, so you can also give additional instructions to aptitude here; for instance, aptitude safe-upgrade bash dash- will attempt to upgrade the bash package and remove the dash package. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#507525: aptitude: crash (SIGABRT) after a dist-upgrade
Control: forcemerge 507525 726001 Hi Paul, You submitted an almost identical bug ~5 years before that one, that I triaged yesterday, so I am merging them. As explained in the other bug report, I think that it is mostly fault of cwidget rather than aptitude. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#598485: aptitude suggests to remove unrelated packages to resolve dependencies
Control: tags 598485 + moreinfo According to the last messages, shouldn't this report have been closed long ago? -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#462393: aptitude: Internal error on reinstall of libc6 for cpu architecture change
Control: tags -1 + moreinfo Hi, Thanks for the bug report, I am doing some triaging. The message is not present in current versions of aptitude, so I guess that the code was reworked in some way and thus this would be quite difficult to investigate and fix, if not fixed yet by another means. In general, the method seems to me a bit of a brute-force approach for converting a system, I don't think that this was ever supposed to be supported. Nowadays I think that this would be handled with multi-arch, starting by adding support for it with dpkg. I think that I saw several guides or blog posts of converting between arches without much hassle (but still not straightforward either). So I don't think that it's very useful to keep this bug open now that we have more standard approaches for this, and if we don't have any means to locate the code which failed at that time with that Internal Error message. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#325015: apt: installation depending upon urgency
(CCing the aptitude bug as well, but this reply is based on the report to apt).
Hi,
For whatever is worth, I don't think that this is a matter that should
concern apt, and so I don't think that this feature should be added.
The urgency field is not intended as a documentation for the user (and
indeed, I think that it's better that would not be easily visible to
users, since it's often misleading). Maybe it was so in the past, but
even if it would be valid syntax today, the most recent use of it in
important packages was in the last century:
--
gcc (2.95.2-0pre2.0.2) unstable; urgency=HIGH (for m68k)
* Binary-only NMU for m68k as quick fix for another bug; the patch
is in CVS already, too.
* Applied another patch by Andreas Schwab to fix %a5 restauration in
some cases.
-- Roman Hodek Thu, 30 Sep
1999 16:09:15 +0200
binutils (2.7-5) unstable; urgency=low (HIGH for m68k)
* Added patch for m68k, will now compile X68 and kernel 2.1.15
-- Galen Hazelwood Tue, 31 Dec 1996 22:15:03 -0700
dpkg (1.4.0) unstable; urgency=low (HIGH for new source format)
[...]
-- Ian Jackson Thu, 12 Sep 1996 01:13:33 +0100
libjpeg6b (6b-1.2) frozen unstable; urgency=low (HIGH for m68k)
* Non-maintainer release.
* Recompile for m68k since existing djpeg binary claims all jpegs I have
are invalid (yet hamm djpeg has no problem with them).
Specifically, added "-O2 -g -Wall" to CFLAGS -- possible gcc bug?
-- Chris Lawrence Tue, 10 Nov 1998 20:57:38 -0600
ncurses (1.9.9g-8.9.1) stable; urgency=high (security fix)
* Previous upload got rejected. Set distribution to "stable" instead of
"hamm-updates".
-- J.H.M. Dassen (Ray) Wed, 29 Jul 1998
14:22:50 +0200
perl (5.004.04-3) unstable; urgency=medium (High for those upgrading from bo)
[...]
-- Darren Stalder Tue, 9 Dec 1997 12:21:48 -0800
--
Stats in my system (with repeated entries, e.g. of the several binary
packages from gcc):
--
$ grep '; urgency=.*(' /tmp/changelog-all | wc -l
172
$ grep '; urgency=.*(' /tmp/changelog-all | cut -d' ' -f1 | sort | uniq -c
1 binutils
32 dpkg
60 egcs
45 gcc
2 libjpeg6b
1 mutt
27 ncurses
4 perl
--
Currently I think that the only use of it, apart from perhaps hinting
the buildds or the FTP team somehow (but don't think so), is to decide
the time of migration from unstable to testing or similar scenarios.
That's why it's in the changelog and intended for archive tools,
instead of being a field in the package.
But even if desired to communicate with the user, it's not simple to
achieve with a single keyword. It can be perfectly possible that a
new upstream release fixes important bug fixes and provides new
functionality, thus the user would want to install it, but still have
"urgency=low" because the maintainer thinks that there should be 10
days of "quarantine" from unstable to testing (in the case that there
are RC bugs stopped, which hold the migration), instead of 5 days for
medium or only 2 for high.
In the example mentioned in the initial bug report, urgency would not
be used as in the example of the holidays, but only as a "how
important is to update it compared to the last version", which is
completely different. When one adds multiple versions to the mix, you
need "versioned" recommendations:
9.6-1 recomm: high
9.8-1 recomm: medium # only translation fixes since 9.6
9.8-2 recomm: high (<9.8), medium (>=9.8)
10.0-1 recomm: high
10.2-1 recomm: high
10.2-2 recomm: high (<10.2), low (>=10.2)
Because otherwise, if there's only a field compared to the latest
entry (and currently, urgency is a "single entry"), a person having
version 9.6 installed, and not updating the packages list until 10.2-2
is present, doesn't know if it's "recommended" to update or not unless
it interprets the whole chain between the installed version and the
most recent one.
On the other hand, the changelog entries as explanatory and intended
as a means of communication maintainer<->user, to decide if the
changes contained are worth downloading and upgrading to the new
version. But this cannot be automated by the interpretation of a
machine, the user must decide.
Summary: "urgency" is not intended as a recommendation of upgrades for
the user (even if sometimes can be interpreted as such; and often
misinterpreted), and the meaning cannot be overloaded as in the
example of the original bug report as a means of communication
maintainer<->user. The changelog entries are. So I don't think that
this feature should be implemented.
Cheers.
--
Manuel A. Fernandez Montecelo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519358: aptitude: Provide undo action.
Control: tags -1 + moreinfo Hi, I am a bit confused... Can you please explain how this new feature would be different from the current Undo action (Ctrl+U), or second entry in the top menu? Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537858: aptitude: comments on i18n
Control: tags -1 + pending Thanks for raising this up and the recommendations. Some of these things are obsolete already, but I addressed most of the rest of the things, will be present in the new releases: http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=cea7fd08e76f1be6f6069522e72c2d9fdcb7a825 Several comments: - About "no-summary", "first-package" and so on, both the original messages in english and the translated ones are accepted by the program, so yes, they should be translated Maybe it would be better to not allow translation of keywords at all, it's not allowed in other places --e.g., the why command itself--, so the way in which is done is inconsistent and generates more work for both devels and translators without much benefit for the user, I think. Suggestions/comments about this? - Then, in the error message, since both the english and the translated are accepted, I think that the translators should put both, but I don't know what's the common practice. - I marked as not translatable the ones in GTK GUI and fixed the one which was not using ngettext, but GTK is disabled since long ago and never was in good shape. Same for Qt GUI. Is there a common/easy way to disable source code directories for gettext when generating the .pot files, so at least new translators don't waste time to translate things that will possibly not be enabled again? - I didn't change the ForTranslators thing yet. Is TRANSLATORS used (virtually) everywhere? Or different projects use different conversions and it's all right? Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#412830: aptitude: Remove option to run reportbug
Control: block 412830 by 463510 Control: tags 463510 + moreinfo Hi, I was pondering about this and I am leaning towards accepting the suggestion in #463510 and remove the option to run reportbug altogether, for the reasons explained. Which would be a way to fix #412830 (thus adding the block). Opinions, please? Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#469100: aptitude: please add short version of commands
Control: tags -1 + moreinfo I am considering doing this, but even if relatively simple, it would be quite a lot of work documenting it, adding hints in --help, even deciding the best short names and solving clashes, possibly some new messages for translation... This request didn't ever receive any follow-up, for or against. Opinions, please? Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509974: aptitude: Auto-lowercase package names?
Control: tags -1 + moreinfo
Hi,
In recent versions (0.6.8.4-1), the behaviour doesn't match what is
explained in the messages of this bug report, so it looks to me that
it's already doing what you requested (lowercase and searching for
package name), even if the bug reports were not closed.
Can you please confirm if this is already doing what you expect?
# aptitude install Rcs
The following NEW packages will be installed:
rcs
0 packages upgraded, 1 newly installed, 0 to remove and 62 not upgraded.
Need to get 0 B/200 kB of archives. After unpacking 513 kB will be used.
Selecting previously unselected package rcs.
(Reading database ... 170918 files and directories currently installed.)
Preparing to unpack .../archives/rcs_5.9.2-1_amd64.deb ...
Unpacking rcs (5.9.2-1) ...
Processing triggers for man-db (2.6.6-1) ...
Processing triggers for install-info (5.2.0.dfsg.1-2) ...
Setting up rcs (5.9.2-1) ...
# aptitude purge rcs
The following packages will be REMOVED:
rcs{p}
...
# aptitude install RCS
The following NEW packages will be installed:
rcs
0 packages upgraded, 1 newly installed, 0 to remove and 62 not upgraded.
Need to get 0 B/200 kB of archives. After unpacking 513 kB will be used.
Selecting previously unselected package rcs.
(Reading database ... 170918 files and directories currently installed.)
Preparing to unpack .../archives/rcs_5.9.2-1_amd64.deb ...
Unpacking rcs (5.9.2-1) ...
Processing triggers for man-db (2.6.6-1) ...
Processing triggers for install-info (5.2.0.dfsg.1-2) ...
Setting up rcs (5.9.2-1) ...
# aptitude install amanda
No candidate version found for amanda
No candidate version found for amanda
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 62 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
# aptitude install Amanda
No candidate version found for amanda
No candidate version found for amanda
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 62 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
# aptitude install AMANDA
No candidate version found for amanda
No candidate version found for amanda
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 62 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
(removing description)
# aptitude search amanda
p amanda-client
p amanda-client:i386
p amanda-common
p amanda-common:i386
p amanda-server
p amanda-server:i386
# aptitude install Apache2
The following NEW packages will be installed:
apache2 apache2-bin{a} apache2-data{a} libaprutil1-dbd-sqlite3{a}
libaprutil1-ldap{a}
0 packages upgraded, 5 newly installed, 0 to remove and 62 not upgraded.
Need to get 1,362 kB of archives. After unpacking 4,897 kB will be used.
Do you want to continue? [Y/n/?] n
Abort.
--
Manuel A. Fernandez Montecelo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#459984: aptitude: adding bash completion
Control: tags -1 - patch Removing tag "patch" if it's not going to be applied (at least in that form). -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509974: Auto-lowercase package names?
2014-02-08 Justin B Rye : > > If I ask for "Amanda" I now get a straightforward failure with no > mention of the package descriptions matching that string... but I was > never a big fan of that feature in the first place. Seems to do a search more intelligently but with package names, and only when the match is close enough: # aptitude install amanda-c Couldn't find package "amanda-c". However, the following packages contain "amanda-c" in their name: amanda-client amanda-client:i386 amanda-common amanda-common:i386 Couldn't find package "amanda-c". However, the following packages contain "amanda-c" in their name: amanda-client amanda-client:i386 amanda-common amanda-common:i386 No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 62 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#647474: aptitude: When piping, stdout doesn't include "RECOMMENDED but will not be installed"
forcemerge 647474 720074
severity 647474 minor
owner 647474 !
tags 647474 + patch moreinfo
stop
Hi,
The problem was introduced here in 2007, after a feature request which
was previously implemented in Ubuntu:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452202
The basic problem is that showing the recommends in command line mode
depends on the option "Quiet" (which can be set by "-q" in the command
line, or "-o Quiet=integer").
It turns out that in src/main.cc, this option is set up automatically
to a positive number if the output is not a tty (the case of pipes or
redirections), even if the user didn't request it through the command
line explicitly:
int curr_quiet = aptcfg->FindI("quiet", 0);
if(seen_quiet)
aptcfg->SetNoUser("quiet", quiet);
if(quiet == 0 && !isatty(1))
aptcfg->SetNoUser("quiet", std::max(curr_quiet, 1));
The code above cannot be "fixed", since the "progress" operations
depend on this to work correctly.
I created the patch, attached. The solution is not very good for my
taste, but Daniel Burrows solved it in this way, attaching this
message to the "Quiet" option (which doesn't happen for any other
output than progress-like), so this is the quick and dirty fix chaning
behaviour minimally and fixing this problem.
I say minimally because I don't think that users will rely (and thus,
complain if changes behaviour) on something as subtle as setting the
option -q explicitly while using pipes/redirection for other reasons,
to specifically avoid printing this message.
My prefered solution would be to do like with
Suggests-Will-Not-Install, that is, only show
Recommended-Will-Not-Install if verbose>0 (as the patch from Ubuntu,
but Daniel Burrows didn't like the solution, and I don't know why).
Or alternatively, show it inconditionally (which probably users didn't
like, and that's why Ubuntu implemented a solution).
Opinions?
--
Manuel A. Fernandez Montecelo
diff --git a/src/cmdline/cmdline_prompt.cc b/src/cmdline/cmdline_prompt.cc
index 25fadaa..7f417a5 100644
--- a/src/cmdline/cmdline_prompt.cc
+++ b/src/cmdline/cmdline_prompt.cc
@@ -702,7 +702,10 @@ bool cmdline_show_preview(bool as_upgrade, pkgset &to_install,
}
}
- if(quiet == 0 && !recommended.empty())
+ // mafm: see bug #720074, assuming that if stdout is not a tty the quiet
+ // option was automatic and does not apply for silencing this message
+ bool quiet_because_of_pipe_or_redirection = (quiet != 0) && !isatty(1);
+ if((quiet == 0 || quiet_because_of_pipe_or_redirection) && !recommended.empty())
{
printf(_("The following packages are RECOMMENDED but will NOT be installed:\n"));
cmdline_show_instinfo(recommended, verbose, showvers, showdeps, showsize, false, showwhy, term_metrics);
Bug#647474: aptitude: When piping, stdout doesn't include "RECOMMENDED but will not be installed"
2014-02-09 Xiangyu Liu : > Hi, > > I personally think that the "-v" solution as you mentioned is good enough, > cause most users don't care these "recommend" or "suggestion" messages, even > "installed" things, they just want a "out of box" application. For people > want specific information, like me, "-v" would be a smart thing. > > At this moment, it seems that I have to apply this patch manually to get a > "custom aptitude". > > Thanks for your information and patch ! I hope that, in one way or another, it's included in the next "upstream" release in a few weeks. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#647474: aptitude: When piping, stdout doesn't include "RECOMMENDED but will not be installed"
2014-02-09 Daniel Hartwig : > >> I created the patch, attached. The solution is not very good for my >> taste, but Daniel Burrows solved it in this way, attaching this >> message to the "Quiet" option (which doesn't happen for any other >> output than progress-like), so this is the quick and dirty fix chaning >> behaviour minimally and fixing this problem. >> >> I say minimally because I don't think that users will rely (and thus, >> complain if changes behaviour) on something as subtle as setting the >> option -q explicitly while using pipes/redirection for other reasons, >> to specifically avoid printing this message. > > This presumes too much. It is not possible to determine this > quiet_because_of_pipe_or_redirection at the point it is introduced, > using the test it does. Yes, it presumes too much, that's what I say in the paragraphs above. To me there seems to be no other way to fix this and maintain the behaviour that Daniel Burrows wanted without changing a significant amount of code, that I don't want to do now to not get in the way of the wip-cmdline. But as I also said, I think that the way in which Daniel Burrows solved this at the time is the wrong way and that should have accepted the "(verbose > 0)" from Ubuntu. I don't understand why he didn't, but I think that that's what we should do. > In any case, resolved in wip-cmdline. I still would like to solve this for the next release 0.6.8.5, better with the "(verbose >= 0)" than with the patch above. This is an unintrusive change that should not get in the way of wip-cmdline. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738345: aptitude: [I18N] Use only original terms for command line options, arguments, etc. (do not accept translated terms)
Package: aptitude
Version: 0.6.8.4-1
Priority: minor
This bug originates from #537858. I am submitting a new one instead
of cloning because most of the issues have been resolved and the scope
of this specific part is much bigger (so most of the discussion in the
previous report is of no use).
The issue is that some strings, like "summary mode" for "why" command,
are marked for translation, and both original and translated forms are
accepted when given by the user. This is not wrong per se, albeit a
bit inconsistent, because for example the "why" command itself does
not allow translation.
The issue is that the translators are confused sometimes about what
does need to translate and what not, or if they have to leave the
originals and translate at the same time, and in general creates some
overhead (for aptitude developers and translators), without much
benefit for the users.
This is also applied inconsistently, for example in src/main.cc the
translation of the log level is allowed (original term also accepted):
// TRANSLATORS: This is a log level that the user can pass on
// the command-line or set in the configuration file.
add_level(N_("trace"), TRACE_LEVEL);
Same for the "why" command, as explained above:
if(show_why_summary_mode == "no-summary" || show_why_summary_mode ==
_("no-summary"))
why_display_mode = aptitude::why::no_summary;
But in src/generic/apt/matching/parse.cc, when parsing priorities,
dependency types and other things, only the original term is accepted.
In cmdline_versions.cc, it depends on the translators about what to do:
group_by_option parse_group_by_option(const std::string &option)
{
// TRANSLATORS: if you add synonyms to the possible values here,
// please also use the translations in your manpage and in the error
// string below.
if(option == "archive" ||
option == P_("--group-by|archive"))
return group_by_archive;
...
So according to my understanding with the discussion in #537858, it's
probably better to find all such occurrences and only allow the
original terms, deprecate the others with a warning, and then remove
the behaviour at some point in the future.
Translators then would always leave the original term and indicate
that it's the one to be given to the program, and translate for
explaining its meaning.
Cheers.
--
Manuel A. Fernandez Montecelo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738345: Acknowledgement (aptitude: [I18N] Use only original terms for command line options, arguments, etc. (do not accept translated terms))
Control: tags -1 + confirmed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537858: aptitude: comments on i18n
2014-02-09 helix84 : > On Sun, Feb 9, 2014 at 6:47 AM, Daniel Hartwig wrote: >> On 8 February 2014 23:29, Manuel A. Fernandez Montecelo >>> >>> - About "no-summary", "first-package" and so on, both the original >>> messages in english and the translated ones are accepted by the >>> program, so yes, they should be translated >>> >>> Maybe it would be better to not allow translation of keywords at all, >>> it's not allowed in other places --e.g., the why command itself--, so >>> the way in which is done is inconsistent and generates more work for >>> both devels and translators without much benefit for the user, I >>> think. Suggestions/comments about this? >>> >> >> I agree. These keywords are part of the programs configuration and >> should not be accepted in localized form. Those which currently >> accept localized forms should be deprecated with a suitable warning. I opened a new bug report for that (#738345), explaining it more clearly, since there are many such occurences in the code. >>> - Then, in the error message, since both the english and the >>> translated are accepted, I think that the translators should put both, >>> but I don't know what's the common practice. >> >> Makes sense. > > I also agree. But the translator comments should make it clear that > these should either not be translated or listed both in the original > and translated form (for use and for explanation, respectively). The > decision may be left up to individual language teams. I also fixed this, at least in the one that you mentioned: + // ForTranslators: "why" here is the aptitude command name and should not + // be translated. Both the translated and the untranslated log level + // names are accepted here. >>> - I didn't change the ForTranslators thing yet. Is TRANSLATORS used >>> (virtually) everywhere? >> >> I believe so. > > I don't have statistical evidence, but my anecdotal evidence from a > few dozens of projects says that if these comments are present then > this is the most common form. I changed them now, too. Cheers. -- Manuel A. Fernandez Montecelo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#412830: [Aptitude-devel] Bug#463510: Bug#412830: aptitude: Remove option to run reportbug
2014-02-09 14:42 Axel Beckert: Hi, Manuel A. Fernandez Montecelo wrote: I was pondering about this and I am leaning towards accepting the suggestion in #463510 and remove the option to run reportbug altogether, for the reasons explained. Same here. I ran into this issue many times, too. So everybody hates it... quick solution :-) Which would be a way to fix #412830 (thus adding the block). I agree here with Daniel that removing the reportbug feature does not fix broken cursor handling after resume. Looks to me as if one or more initial characters of the escape sequence generated by cursor down is dropped and the just the capital B is passed to aptitude's TUI -- which should be fixed independenly of #463510. What I meant is that the decision on whether to remove the "feature" of running reportbug affected the resolution of the other one. So I am going to remove reportbug and close that bug report, and then investigate the other one. I think that I saw more bug reports complaining about weirdness after suspending. It's possible even that the issue is with cwidget. Cheers. -- Manuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738350: [Aptitude-devel] Bug#738350: aptitude: "Reconfiguring" missing in Package submenu
Reorganising contents a bit... 2014-02-09 14:54 Axel Beckert: Axel Beckert wrote: In the submenu "Package" there's the Reconfigure feature (reachable via Shift-R) missing. Actually the controversial "Report Bug" feature (see #463510 for the discussion) is missing there, too. I think that "Run reportbug" is as good as dead, since we all agreed in that bug report (I think), and it can be removed in a few minutes. As I understood it, the issue with "Reportbug" is not only that it gets triggered after suspending and arrow down, but that: - aptitude is often run as root user, so reportbug complains about that, - and maybe the root user does not export useful env vars for reportbug to use, like DEBMAIL, DEBFULLNAME, REPORTBUGEMAIL, etc. So I don't think that it's a feature that anybody will miss, and that we can remove ASAP. If we add them, I think they should be clearly seperated from the other non-immediate package actions, maybe in a subsubmenu unter "Menu → Package → Immediate Action" if libcwidget supports subsubmenus. Not sure of it's supported. So I wonder if those two "immediate package actions" (and maybe some more) are missing on purpose. [...] Otherwise maybe a submenu on toplevel is an option. But I think that's may too much attention for these seldomly used features. Hrm. Another option would be to have them in after a separator, like "Information", "Cycle package information" and "Changelog". In fact, Changelog is a "immediate" action much like Reportbug, isn't it? "Information" and "Cycle" are also immediate. BTW, I think that perhaps "Reconfigure" should not be so immediate, and behave like "Reinstall" instead. Cheers. -- Manuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671780: aptitude: Please move ~/.aptitude/cache to $XDG_CACHE_HOME (default ~/.cache)
Hi,
I created the attached patch, similar to Josh's but moving the cache
if exists. I am fine with integrating Josh's patch as well.
The reason for this new stab with the modified patch is because I
think that somehow it's important to remove the litter and not leave
~/.aptitude/cache behind.
I think that this file is small enough and loosing its contents
unimportant enough that perhaps this is not needed (and the
paraphernalia to achieve this is a bit ugly, and probably not
foolproof). But in that case perhaps we should remove instead of
move?
Anyway, I think that it would be nice to fix this. Thanks Josh for
bringing this to our attention and providing the patch.
Cheers.
--
Manuel A. Fernandez Montecelo
diff --git a/src/generic/apt/apt.cc b/src/generic/apt/apt.cc
index d534b43..2dd76e3 100644
--- a/src/generic/apt/apt.cc
+++ b/src/generic/apt/apt.cc
@@ -504,19 +504,73 @@ void apt_load_cache(OpProgress *progress_bar, bool do_initselections,
LOG_TRACE(logger, "Initializing the download cache.");
// Open the download cache. By default, it goes in
- // ~/.aptitude/cache; it has 512Kb of in-memory cache and 10MB of
- // on-disk cache.
+ // $XDG_CACHE_HOME/aptitude-download-cache (typically
+ // ~/.cache/aptitude-download-cache); it has 512Kb of
+ // in-memory cache and 10MB of on-disk cache.
+ const char *XDG_CACHE_HOME = getenv("XDG_CACHE_HOME");
const char *HOME = getenv("HOME");
- if(HOME != NULL)
+
+ std::string download_cache_filename = "aptitude-download-cache";
+
+ // path for XDG
+ std::string download_cache_dir_xdg;
+ if(XDG_CACHE_HOME)
+download_cache_dir_xdg = std::string(XDG_CACHE_HOME) + "/";
+ else if(HOME)
+download_cache_dir_xdg = std::string(HOME) + "/.cache/";
+
+ // path old
+ std::string download_cache_dir_old;
+ if(HOME)
+download_cache_dir_old = std::string(HOME) + "/.aptitude/";
+
+ // move from old path to new path, if still exists
+ if(!download_cache_dir_old.empty() && !download_cache_dir_xdg.empty())
+{
+ std::string old = download_cache_dir_old + "cache";
+ std::string xdg = download_cache_dir_xdg + download_cache_filename;
+
+ // exists?
+ struct stat sb;
+ int result_stat = stat(old.c_str(), &sb);
+ if (result_stat != -1)
+{
+ // ... only then, attempt to move
+
+ // attempt to create XDG dir if it does not exist
+ int result_stat_dir = stat(download_cache_dir_xdg.c_str(), &sb);
+ if (result_stat_dir == -1)
+ {
+ int result_mkdir = mkdir(download_cache_dir_xdg.c_str(), 700);
+ if (result_mkdir != 0)
+ {
+ LOG_WARN(logger, "Could not create directory for cache file in '" << download_cache_dir_xdg << "'");
+ }
+ }
+
+ // attempt to move
+ int result_rename = rename(old.c_str(), xdg.c_str());
+ if (result_rename != 0)
+ {
+ LOG_WARN(logger, "Could not move existing cache file to new location, from '" << old << "' to '" << xdg << "'");
+ }
+ else
+ {
+ LOG_INFO(logger, "Moved cache file to new location, from '" << old << "' to '" << xdg << "'");
+ }
+ }
+}
+
+ if(!download_cache_dir_xdg.empty())
{
- std::string download_cache_file_name = string(HOME) + "/.aptitude/cache";
+ std::string download_cache_full_path = download_cache_dir_xdg + download_cache_filename;
const int download_cache_memory_size =
aptcfg->FindI(PACKAGE "::UI::DownloadCache::MemorySize", 512 * 1024);
const int download_cache_disk_size =
aptcfg->FindI(PACKAGE "::UI::DownloadCache::DiskSize", 10 * 1024 * 1024);
try
{
- download_cache = aptitude::util::file_cache::create(download_cache_file_name,
+ download_cache = aptitude::util::file_cache::create(download_cache_full_path,
download_cache_memory_size,
download_cache_disk_size);
}
@@ -524,14 +578,14 @@ void apt_load_cache(OpProgress *progress_bar, bool do_initselections,
{
LOG_WARN(logger,
"Can't open the file cache \""
- << download_cache_file_name
+ << download_cache_full_path
<< "\": " << ex.errmsg());
}
catch(std::exception &ex)
{
LOG_WARN(logger,
"Can't open the file cache \""
- << download_cache_file_name
+ << download_cache_full_path
<< "\": " << ex.what());
}
}
