Bug#821177: dpkg: please make dpkg perl libraries available on cpan
Source: dpkg Severity: wishlist Hi, as of today it's not possible to use the perl-libraries in the Dpkg:: namespace on systems other then Debian (except someone packaged them for the target system, like it has been done in Fedora). Since the perl ecosystem does have it's own platform for modules with it's own tooling (which we as a distribution happily benefit from, when packaing perl modules), it would be very nice if Debian made their own libraries available on CPAN, too. Some Debian projects already do, unfortunately dpkg is a prime example where it could be useful to other people. Best Regards, Patrick -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#698725: ITA: password-gorilla -- cross-platform password manager
Hello, I hereby acknowledge, that I agree with Alexandre adopting the package. Best Regards, Patrick signature.asc Description: Digital signature
Bug#686006: sparkleshare: build-depends on wrong version of mono
Package: sparkleshare Severity: serious Hi, today I tried rebuilding sparkleshare for my squeeze system. According to the build-depends it seemed it wouldn't be a big problem, but it turned out, that the build-dependency on mono is wrong. The corresponding line in debian/control reads: mono-devel (>= 2.4.3) However, configure and the README state that a monore version >= 2.8 is required. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#608930: Dpkg::Log - log file parsing support for dpkg log files
Hi Raphael,
thanks for sharing your opinion with me.
On Wed, Jan 25, 2012 at 11:28:35AM +0100, Raphael Hertzog wrote:
> - the patch is much too big for a simple functionality like this one, you
> have to cut some code away, there are useless checks (code will end up
> failing if users submit something that's not expected, you don't have
> to hardcode checks for all possible mistakes that user might make),
> there are too many classes and intermediary objects, etc.
> Do your best to be "concise" and "readable".
I will not comment the "en detail" critique for now, since I figure we
have different design conceivabilities. We should discus about this first.
So lets go:
When I originally designed the library (and dpkg-report) I had the following
queries in
mind:
- Which actions happened in a given logfile?
- Which actions (...) in a given timerange?
- Which actions happened to a certain package?
- What is the final state (installed, half-configured) of a package at
the end of the logfile?
- What is the installed version of a package at the end of the logfile?
- What was the installed version of the papckage at the beginning of the
logfile?
- What time range does a logfile cover?
When analysing the format of the existing logfiles of systems where I
needed this, I figured that a logfile contains several entries
describing either the status of the dpkg run at a whole, the status of
an affected package or an action happening on a given package.
To answer the queries I figured that I need a lot of information about
different entities, like entries and packages (and conffiles) with
different attributes and different methods to work with. For example,
one who wants to analyse a logfile with different queries - which I can not
know in advance - will want to work with a line-oriented module like
Dpkg::Log::Status, which will return parameterized objects of each line,
while somebody who wants to do common queries (like those above), is
better off with something already doing the tracking work this
requires.
Ulimately I think Dpkg::Log and Dpkg::Log::Analyse are logically for different
tasks (low- and high-levell) and therefore need to be separate.
You seem to have another opinion, but I'm missing a rational.
Just reducing the number of modules does not seem to cut it.
> Again, I don't see the need for this module. It's doing basic queries
> on Dpkg::Log in a way that's not generic enough to be suitable for all use
> cases that applications that might have.
I stronly disagree on this. Yes, it is doing "basic" queries (in the
sense of queries most typical use cases will involve), yet those
queries are not simple (states need to be tracked) and so applications
shouldn't have to-reinvent them everytime.
> > +if ($entry[2] eq "update-alternatives:") {
> > +next;
>
> update-alternatives no longer writes to dpkg.log.
Maybe. But older logfiles exist and might get processed for whatever
reason.
> All the handling of attributes on *::Entry could be generalized
> and stuffed into the base class if it's really only a storage
> class. Using dedicated methods like $entry->type() doesn't bring anything
> compared to $entry->attribute("type").
Well, it at least brings a well-defined API, IMHO.
-Patrick
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#637681: Please install dpkg-report as a proper program
Hi Sandro, On Wed, Oct 05, 2011 at 08:38:43AM +0200, Sandro Tosi wrote: > I'd be happy with whatever outcome there will be (either make the > program public or be merged into dpkg* pkg) but I do agree that this > perl module and its companion tool seem better fitting into the dpkg* > official packages. > > Patrick: what are your feelings about this merge? Guillem: what are > the steps needed to merge this package into some dpkg one? I already worked on merging the code into the dpkg source and a month ago or so I were almost far enough, to send it for review by the dpkg maintainers, but then I lost time for it and the process has stalled a bit. I cannot say when I'll be able to finish that, but I'll try to spend some time on it again, soonish. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#603115: Version 0.3.4 makes Checkboxes and hoisting default to 'on'
Hi, On Sun, Sep 18, 2011 at 02:42:13AM +0900, Osamu Aoki wrote: > Hi, > > I think this bug report is for 0.3.4 > > Newer upstream release made these features default on. > > Anyway, most recent is vimoutliner-0.3.6.tgz — Version 0.3.6 uh, well, I'm a bit puzzled. Last time I looked nothing let to believe, that there might happen a release or that one happened, but how should I have known that upstream silently discarded vimoutliner.org and moved to github? Do you know what happend to vimoutliner.org? It hasn't been updated since a while and led me to believe that upstream development is stalled. > There has been good amount of bug fixes. Patrick, are you still active? > You have not responded to Joey's #575142 report either. Yes, I am, but 1) I didn't notice that there is any activity because I haven't noticed that upstream change to github. Has there been an announcement, that I missed? 2) I've been a bit low on time recently, dunno, if I find time to update the package in the next time, but I'll see what I can do. 3) I did not reply to Joeys ticket, because there was nothing to reply on. He is right and I'm pretty sure there is no need to tell him that. Kept it open to fix it as soon as I do another upload. Shame on me that it did not happen yet. > PS: Since upstream uses git now, using git for Debian package seems to > make more sense. Well, my choice of version control system is not tied to whatever upstream uses, but yes I will switch to git (as I've done that for most of my packages). I'm not sure, but I think I've already converted the svn to git a while ago, but have not pushed it anywere yet. Have to check that. The system I'm used to work with for Debian work, is not around currently. Thanks for the bug report and the help to discover that upstream work is indeed going on :o) Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595227: Still an issue?
Hi, >Excerpts from Ryan Kavanagh's message of Wed Jun 22 17:43:46 +0200 2011: >I am running kernel around 2.6.39 and X around 1.10 but this has been an >issue for a long time with earlier versions as well. > >I am using XMonad window manager and I am usually running scim. I don't have much to add, I just want to note that you are not alone. I had these issues, too, but I have not seen them for a long time. Instead I have another random happening bug (#631793) which occurs more often. However there is one similarity: We both run xmonad. Maybe this has to do with our problems.. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#631793: rxvt-unicode: sometimes terminal is not properly refreshed
Package: rxvt-unicode Version: 9.11-1 Severity: important Hi, with rxvt-unicode I sometimes have a problem which seems like terminal content is not properly refreshed. I'll try to explain that a bit more understandable: Consider a terminal running an irssi. If the problem occurs the terminal won't show any changes (messages, joins/parts etc.) anymore. There is a first aid solution: If I press Strg+L everything which happened so far is shown properly and the problem is away for a while. It then reappears as soon as a certain amount of activity happend on that terminal. For that reason I could imagine that some kind of buffer could be involved.. Note that irssi is just an example to better illustrate the issue at hand. It also happens with ordinary terminals which just run a shell. Unfortunately it does happen randomly. Sometimes the problem arises and then stays for a while. In this case a restart of the terminal is not enough. Restarting X seems to help but only for a short while. Restarting the whole system basically is the best option in that case as in most cases the problem stays away for some hours.. Well.. I know its not much I can tell. The problem is not reliable reproducible. Still, it happens often enough to really nag me. It does not happen with other terminals, so I assume its a bug with rxvt-unicode or an extension. That said, I'm using the tabbed extension and the matcher extension. I wouldn't wonder if the tabbed extension is the culprit, but I don't have any idea where I could start debugging that. Below is the content of the .Xdefaults file: urxvt*background: black urxvt*foreground: grey urxvt*scrollBar: false urxvt*saveLines: 65535 URxvt*perl-ext-common: default,matcher URxvt.perl-ext: tabbed,matcher URxvt*urlLauncher: firefox URxvt.matcher.button: 1 URxvt*urgentOnBell: true Thanks in advance and best Regards Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#627913: setup-storage: please add a syntax check mode
Package: fai-setup-storage Version: 4.0~beta2+experimental51 Hi, when creating a FAI configuration it sometimes occurs to, that my disk_config contains syntax errors. Those errors currently cannot be detected without doing a test installation. In fact setup-storage does have a test mode but this one is not really suitable to test weither a given disk_config file is valid, because it basically tests all pre-requisites required to actually run the partioning (e.g. available harddisk(s), availability of tools etc.). Therefore it would be useful if setup-storage would include a test mode, which checks everything which can be checked independent from the to-be-installed-system. At a bare minimum this mode could check the syntax of the file. Thanks and best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622342: python-apt: add option to reopen cache on update
On Tue, Apr 12, 2011 at 02:08:44PM +0200, Julian Andres Klode wrote: > On Di, 2011-04-12 at 13:10 +0200, Patrick Schoenfeld wrote: > > It would be nice, if update() supported that as an argument, e.g. > > > > reopen=True > > > > The default could be False to keep backward compatibility. > No, we'd need yet another parameter for specifying the progress handler > for open() then. well, yes. And the problem about that is what? It could default to a default progress handler like everywhere else, too. Actually I don't even see the sense in having this as an argument and would prefer to always reopen the cache after updating it because I fail to see a use-case for refreshing the cache and after that using the old one. However, the idea to do it with an argument is just to keep backward compatibility and not surprise previous users of the api. > > Apart from this the documentation really needs to state > > that an open() is required after that. The info can be obtained > > from the examples, but thats probably not the right place. > > Better would be to state that requirement in update() documentation. > We can add this. Better than nothing. Regards, patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622347: python-apt: Please add a public function fetch_archives
Hi, On Tue, Apr 12, 2011 at 02:02:56PM +0200, Julian Andres Klode wrote: > On Di, 2011-04-12 at 13:20 +0200, Patrick Schoenfeld wrote: > > Package: python-apt > > Version: 0.7.100.2 > > Severity: wishlist > > > > Hi, > > > > I'm currently working on a python-apt based variant of fai-mirror, > > which uses python-apt to resolve dependencies for the packages > > and download them. Currently the only way to NOT install packages and > > download > > them only is to use an internal function _fetch_archives for example like > > this: > > > > fetch_progress = apt.progress.text.AcquireProgress() > > depcache = self.cache._depcache > > pm = apt_pkg.PackageManager(depcache) > > fetcher = apt_pkg.Acquire(fetch_progress) > > self.cache._fetch_archives(fetcher, pm) > > > > Its obvious that this is quiet unfortunate. Therefore it would be nice, > > if python-apt supported a method which allows fetching packages only. > > You can fetch single versions by using Version.fetch_binary(), or go This wouldn't work, because I need the package with their depends. > through the list of all changed packages and mark the URIs for download > (via Version.uri) Does the list of changed packages include depends? Would I need to do anything else to actually fetch the packages? > But if really wanted we could surely at a public > fetch_archives method. Well, as far as I can tell it currently seems that such a function (implemented similar to the above code) solves the problem of downloading all packages marked to be installed AND their depends. There is no need for such a function if thats easily possible with the existing API... Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622347: python-apt: Please add a public function fetch_archives
Package: python-apt Version: 0.7.100.2 Severity: wishlist Hi, I'm currently working on a python-apt based variant of fai-mirror, which uses python-apt to resolve dependencies for the packages and download them. Currently the only way to NOT install packages and download them only is to use an internal function _fetch_archives for example like this: fetch_progress = apt.progress.text.AcquireProgress() depcache = self.cache._depcache pm = apt_pkg.PackageManager(depcache) fetcher = apt_pkg.Acquire(fetch_progress) self.cache._fetch_archives(fetcher, pm) Its obvious that this is quiet unfortunate. Therefore it would be nice, if python-apt supported a method which allows fetching packages only. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#622342: python-apt: add option to reopen cache on update
Package: python-apt Version: 0.7.100.2 Severity: wishlist Hi, when using Cache().update() it is required to reopen the cache with Cache().open(), because otherwise the cache will be old or even empty if run with empty list directories. It would be nice, if update() supported that as an argument, e.g. reopen=True The default could be False to keep backward compatibility. Apart from this the documentation really needs to state that an open() is required after that. The info can be obtained from the examples, but thats probably not the right place. Better would be to state that requirement in update() documentation. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619574: python-apt: Provide access for task associated with a package
Hi Julian, On Fri, Mar 25, 2011 at 11:21:02AM +0100, Julian Andres Klode wrote: > On Fri, Mar 25, 2011 at 10:57:03AM +0100, Patrick Schoenfeld wrote: > > Package: python-apt > > Severity: wishlist > > > > Hi, > > > > currently the python-apt bindings for the apt package cache do not > > provide access to the task associated with a package. I have a use-case > > where I need it. > > > > The information can be gathered from the Packages file, > > where for each Package, which is a member of a task, a key-value pair > > "Task: foo" is stored. > > > > It would be nice if python-apt provided a method task > > in apt.packagePackage() objects. Apart from this it would be nice to > > have functions in the cache object to access list of tasks and > > associated packages.. > > Use Version.record["Task"].split(): thanks for showing me a way to get that information, as I would have never found that myself. > >>> import apt > >>> apt.Cache()["gnome"].candidate.record["Task"].split() > ['gnome-desktop'] > > The tasks are not in the cache, and this is easy enough, so > I don't think we need an extra method for it. Well, easy enough is an interesting term in that case. Maybe documentation could be improved, because its very hard to get to that information if you did not write the API yourself. >From documentation and my apt understanding I could get as far to understand that each package has a (installation) candidate with all package-version-specific informations associated to it. API doc says: "Return the candidate version of the package" It takes something to understand that formulation like you eventually meant it. I suggest the following wording to make it more accurate and better understandable: "Return the candidate of the package as a Version() object, which stores all information about the candidate version." This probably gives a hint, that it does not only return "1.0.0-1" in an object representation but all data associated to the given candidate. Now to the Version() class: The docstring reads as: "Representation of a package version" Yes, if you already know the API or if you are good at guessing, its clear what this one sentence means. A short introduction whats possible with the module would be nice though. Maybe something like: """ Representation of a package version This class representates a package version and provides access to all version-specific package attributes. """ Now, if one is so far to get to the point of having a Version() object, where to go from there? This object does have all kind of property accessors, but none for the task field of the candidate version of the package. Just as a sidenote: This would be a good point to have a "def task()" which would return the task associated to that candidate version. I know you think using records()["Task"] is "easy enough", but OTOH it would be "easy enough" to access the Priority of the given candver by this means as well. Nevertheless you provide a priority function for it. Now there is records(), which is nice, but again, by its documentation its not reall obvious that it can lead to the answer you gave: "Return a Record() object for this version" Suggestion: "Return a Record() object for this version, which provides access to the raw attributes of the candidate version" Last but not least the Record() class: """ Represent a pkgRecord It can be access liked a dict.. """ This could be easily improved by writing: "Represent a package record as stored in the Packages file" Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619574: python-apt: Provide access for task associated with a package
Package: python-apt Severity: wishlist Hi, currently the python-apt bindings for the apt package cache do not provide access to the task associated with a package. I have a use-case where I need it. The information can be gathered from the Packages file, where for each Package, which is a member of a task, a key-value pair "Task: foo" is stored. It would be nice if python-apt provided a method task in apt.packagePackage() objects. Apart from this it would be nice to have functions in the cache object to access list of tasks and associated packages.. best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#608930: Merging DPKG::Log into dpkg codebase
Hi, On Tue, Mar 01, 2011 at 09:38:24AM +0100, Raphael Hertzog wrote: > Hi, > > On Tue, 01 Mar 2011, Patrick Schoenfeld wrote: > > Well, I've written DPKG::Log because I had a need for it and thought > > it could be useful for others. Merging it into the dpkg codebase is > > probably a good idea and so I'm revisiting that idea with this mail. > > I see one problem, however. > > My library, DPKG::Log, is written purely in Perl. I didn't see a big > > need to implement it in C, because after all log processing > > isn't something you do on an embedded system, I guess. > > Now, AFAICT, it is one of the dpkg maintainers goals, to implement > > dpkg-tools in C, isn't it? > > Would this be a problem? > > It would be a problem if we target this for the "dpkg" package but > we could introduce a "dpkg-utils" package where Perl would not be > a problem. Furthermore Dpkg::Log itself has its place in libdpkg-perl. Ok, makes sense. > There's no reason for this tool to be integrated in the "dpkg" binary > package since it's not at all required to perform package installations. Agreed. > > Apart from that: I'm dependend on that tool and therefore I'd > > hate to submit and forget. So would it still be possible to > > take care for DPKG::Log/dpkg-report, if it would get merged > > into the dpkg codebase? > > Sure, you're more than welcome to take care of it! > > Now, I have not yet looked into your code. But merging it supposes > that you follow our conventions and reuse our existing Perl libraries > when it makes sense. Well, I have not looked into the coding guidelines, yet. I'll look into that. Re-Using existing libraries, where it makes sense, however is always the way to go (for that reason I'm already using Dpkg::Version ;) > I suggest you look into some of the existing Dpkg::* module, that you read > doc/coding-style.txt and that you try submitting a Dpkg::Log::Status > module (yes there could be Log modules to parse other files like the > alternatives log file so it's best to use a dedicated module from the > start). Hmm. I'm not really sure, if ::Status would be the right name, but on the OTOH you, as a dpkg maintainer, know better. Besides that: The idea in general is good. I guess I'll rewrite DPKG::Log as Dpkg::Log to be a common class, implementing the common interface for dpkg logfiles and Dpkg::Log::Status extending that. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#608930: Merging DPKG::Log into dpkg codebase
[.. Resending the mail as it seemingly did not reach the list and BTS ..] Hi dpkg maintainers, in a reply to my blog post about DPKG::Log, Raphael Hertzog, commented: > I would suggest you to submit Dpkg::Log to dpkg > itself... to be included in libdpkg-perl. > > I wonder why you did not ask in the first place. > That way we can keep the code in sync in case dpkg starts outputting > different stuff in the log file. and I must confess, the only reason why I didn't ask is: I just did not think about it. Well, I've written DPKG::Log because I had a need for it and thought it could be useful for others. Merging it into the dpkg codebase is probably a good idea and so I'm revisiting that idea with this mail. I see one problem, however. My library, DPKG::Log, is written purely in Perl. I didn't see a big need to implement it in C, because after all log processing isn't something you do on an embedded system, I guess. Now, AFAICT, it is one of the dpkg maintainers goals, to implement dpkg-tools in C, isn't it? Would this be a problem? Apart from that: I'm dependend on that tool and therefore I'd hate to submit and forget. So would it still be possible to take care for DPKG::Log/dpkg-report, if it would get merged into the dpkg codebase? Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#614803: O: xtermset -- change the characteristics of an xterm
Package: wnpp Hi, I just orphaned xtermset, because I can't bare enough time for it and haven't used it for a long long time. For the brave who wants to maintain it: There is no upstream for this package anymore. There used to be a website at least, but appearently it died recently. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#613941: /usr/bin/build-rdeps: unable to find sources files.
Hi, On Fri, Feb 18, 2011 at 01:32:45PM +0100, Mike Hommey wrote: > On Fri, Feb 18, 2011 at 12:52:56PM +0100, Patrick Schoenfeld wrote: > > Hi, > > > > On Fri, Feb 18, 2011 at 12:30:40PM +0100, Mike Hommey wrote: > > > Package: devscripts > > > Version: 2.10.70 > > > Severity: important > > > File: /usr/bin/build-rdeps > > > > > > With this /etc/apt/sources.list: > > > deb http://ftp.fr.debian.org/debian unstable main > > > deb-src http://ftp.fr.debian.org/debian unstable main > > > > > > This is what happens: > > > $ build-rdeps foo > > > build-rdeps: unable to find sources files. > > > Did you forget to run apt-get update (or add --update to this command)? > > > at /usr/bin/build-rdeps line 315. > > > > .. and did you do what the message says? build-rdeps works for me with > > your sources.list, so I guess you did not. well, I can't confirm that anything is wrong: psc@lisa ~/workspace/debian/devscripts % build-rdeps foo build-rdeps: unable to find sources files. Did you forget to run apt-get update (or add --update to this command)? at /usr/bin/build-rdeps line 315. zsh: exit 255 build-rdeps foo psc@lisa ~/workspace/debian/devscripts % sudo apt-get update Hole:1 http://ftp.fr.debian.org unstable Release.gpg [835 B] Hole:2 http://ftp.fr.debian.org/debian/ unstable/main Translation-de [1.556 kB] Ign http://ftp.fr.debian.org/debian/ unstable/main Translation-en Hole:3 http://ftp.fr.debian.org unstable Release [104 kB] Hole:4 http://ftp.fr.debian.org unstable/main Sources [4.155 kB] Hole:5 http://ftp.fr.debian.org unstable/main amd64 Packages [6.996 kB] Es wurden 12,8 MB in 14 s geholt (904 kB/s) Paketlisten werden gelesen... Fertig sudo apt-get update 4,80s user 0,78s system 35% cpu 15,781 total psc@lisa ~/workspace/debian/devscripts % build-rdeps foo Warning: Ignoring missing sources file ftp.fr.debian.org_debian_dists_unstable_contrib_source_Sources. (Missing component in sources.list?) Warning: Ignoring missing sources file ftp.fr.debian.org_debian_dists_unstable_non-free_source_Sources. (Missing component in sources.list?) Reverse Build-depends in main: -- No reverse build-depends found for foo. > Yes I did, and nope, doesn't work after update... Whats happening if you run it with the -u switch and sudo or su (depending on whats working on your system..)? Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#613941: /usr/bin/build-rdeps: unable to find sources files.
Hi, On Fri, Feb 18, 2011 at 01:32:45PM +0100, Mike Hommey wrote: > On Fri, Feb 18, 2011 at 12:52:56PM +0100, Patrick Schoenfeld wrote: > > Hi, > > > > On Fri, Feb 18, 2011 at 12:30:40PM +0100, Mike Hommey wrote: > > > Package: devscripts > > > Version: 2.10.70 > > > Severity: important > > > File: /usr/bin/build-rdeps > > > > > > With this /etc/apt/sources.list: > > > deb http://ftp.fr.debian.org/debian unstable main > > > deb-src http://ftp.fr.debian.org/debian unstable main > > > > > > This is what happens: > > > $ build-rdeps foo > > > build-rdeps: unable to find sources files. > > > Did you forget to run apt-get update (or add --update to this command)? > > > at /usr/bin/build-rdeps line 315. > > > > .. and did you do what the message says? build-rdeps works for me with > > your sources.list, so I guess you did not. > > Yes I did, and nope, doesn't work after update... thats.. odd. Used to work and works for me, probably some trouble with current perl versions. Will check again after upgrading my system. regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#613941: /usr/bin/build-rdeps: unable to find sources files.
Hi, On Fri, Feb 18, 2011 at 12:30:40PM +0100, Mike Hommey wrote: > Package: devscripts > Version: 2.10.70 > Severity: important > File: /usr/bin/build-rdeps > > With this /etc/apt/sources.list: > deb http://ftp.fr.debian.org/debian unstable main > deb-src http://ftp.fr.debian.org/debian unstable main > > This is what happens: > $ build-rdeps foo > build-rdeps: unable to find sources files. > Did you forget to run apt-get update (or add --update to this command)? at > /usr/bin/build-rdeps line 315. .. and did you do what the message says? build-rdeps works for me with your sources.list, so I guess you did not. See REQUIREMENTS in the manpage: The tool requires apt Sources files to be around for the checked components. In the default case this means that in /var/lib/apt/lists files need to be around for main, contrib and non- free. In practice this means one needs to add one deb-src line for each component, e.g. deb-src http:///debian main contrib non-free and run apt-get update afterwards or use the update option of this tool. Please note that, with this sources.list, the script will spit out warnings anyway, unless you override the list of components. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564873: libevent: breaks dnsproxy
Heya, On Mon, Jan 17, 2011 at 07:09:50PM +1100, Aníbal Monsalve Salazar wrote: > Should I close bug#564873? > > It seems to me that the issues with dnsproxy were fixed. yeah, AFAICT, you can close it. Jari Aalto made an NMU of dnsproxy to fix the issues. Thanks and best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#599796: fai-client: Please add support for different base tarballs
Package: fai-client Version: 4.0~beta2+experimental26 Hi, currently FAI uses a fixed/hard-coded location for the base tarball. This is unfortunate in multi-distribution or multi-arch setups for example. Currently such setups involve duplication of the fai configuration directory and the nfsroot, which shouldn't be neccessary (at least not in all cases). So I suggest to add support for new variable FAI_BASEFILE: This should be as simple as changing task_extrbase in /usr/lib/fai/subroutines. Instead of using a hard-coded local basefile and extracting it, if it exists, and using debootstrap otherwise do something like this: - Check if FAI_BASEFILE is defined. In this case check weither it exists and if yes, use it as basefile. If it is defined but the tarball does not exist print a warning to STDERR. - If basefile exists extract it to /target - If basefile does not exist call debootstrap Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#575804: excessive cpu usage with several applications (firefox, epiphany, etc.)
Hi, On Sat, Oct 02, 2010 at 03:15:32PM +0200, Cyril Brulebois wrote: > Hi Patrick, > > Patrick Schoenfeld (29/03/2010): > > I currently have the problem that Xorg takes 100% CPU when some > > applications are running. It appears to be mostly triggered by > > firefox and epiphany but other software (e.g. opera) also leads to > > unusual CPU usage (50-60%). This makes my system quiet unresponsive > > when working with those applications. > > still happening with 2.12 from sid, or 2.13 from experimental, with > sid's kernel? Details about versions can be read in: > http://ikibiki.org/blog/2010/10/02/October-X-update/ should have written earlier: I found the problem to be related to flash. It only happens with flashplugin-nonfree.. at least in that extent. So I switched to gnash and haven't tried anymore. Maybe this bug can be closed or reassigned. But as we don't have a working flash plugin for amd64 in contrib currently I can't try again. Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590832: [build-rdeps] doesn't handle packages with "+" in name correctly
On Thu, Jul 29, 2010 at 10:25:30AM -0400, James Vega wrote: > Patrick, do you recall why build-rdeps does extra verification of > grep-dctrl's results for the Build-Depends(-Indep) fields? Nope. Actually I'm not even sure if did in the first place or if it was added by one of the later patches. But should be easy to see weither it makes sense or not. Just no time currently. Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#582771: Wrong permissions on /var/log/smstools/smsd_stats
Version: 3.1.3-1 Hi, thanks for your bugreport. > On a clean install on Lenny smsd fails to start with the following > output in /var/log/smsd.log: Yes, there was a bug in the maintainer script which caused this. It is fixed in version 3.1.1-1 but the lenny version unfortunately needs to use a workaround. Usually the maintainer scripts would call the following command: dpkg-statoverride --update --add smsd smsd 0755 /var/log/smstools/smsd_stats That didn't happen in this case. You can either call this command or use the chown call as Kristinn suggested. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#576587: dnsproxy: diff for NMU version 1.16-0.1
Hi, On Thu, May 06, 2010 at 08:20:10PM -0700, tony mancill wrote: > tags 576587 + patch > tags 576587 + pending > thanks > > Dear maintainer, > > I've prepared an NMU for dnsproxy (versioned as 1.16-0.1) and > uploaded it to DELAYED/3. Please feel free to tell me if I > should delay it longer. I'm fine with the NMU. Thanks for it. Please feel free to keep it in DELAYED so that it can go to unstable without any extra efforts. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#575804: excessive cpu usage with several applications (firefox, epiphany, etc.)
Hello Julien, thanks for the reply. On Mon, Mar 29, 2010 at 02:48:17PM +0200, Julien Cristau wrote: > severity 575804 normal > tag 575804 moreinfo > kthxbye > > On Mon, Mar 29, 2010 at 13:40:56 +0200, Patrick Schoenfeld wrote: > > > I currently have the problem that Xorg takes 100% CPU when some > > applications are running. It appears to be mostly triggered > > by firefox and epiphany but other software (e.g. opera) also > > leads to unusual CPU usage (50-60%). This makes my system > > quiet unresponsive when working with those applications. > > > Please try to figure out where X is spending this cpu time (you could > e.g. interrupt it with gdb a few times, or use a profiler...). somewhat more information would be helpful as I'm not very experienced in that field. Any documentation pointers? Thanks and best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569218: vim-vimoutliner: vimoutliner doesn't load automatically
reopen 569218 thanks Hi, On Thu, Feb 11, 2010 at 09:40:03AM -0500, Matthew James Goins wrote: > I read that file and followed it, and that didn't work, which is why I filed > the bug. you should have written that in the first place. What you described sounded like the behaviour when this is not used. > I did the following: > > aptitude purge (all vim-related stuff) > > aptitude install vim vim-addon-manager vim-vimoutliner > > (as root) vim-addons -w install vimoutliner > > (as my user) vim-addons install vimoutliner So you installed it both as a user and as root. That does not make much sense, but that just as a side note. I'm currently wondering because it usually works like intended if you install it with either the first or the second option. > At this point, the file type was set correctly, and the syntax highlighting > worked, but vimoutliner (for example, any ",," commands) was not enabled. I > still had to run the ":source" command mentioned above in order to get > vimoutliner functionality. Strange. I cannot reproduce that so I definitely need more info. I'll get back to you once I have an idea what could help to track this down. Reopening the bug. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568248: patch creates files and directories instead of asking for the file
As noted on IRC the testcase was bogus. Attached is a proper testcase that also triggers the problem. test_directories.tgz Description: GNU Unix tar archive diff -u -Nur test1/a/b/c/xyz test2/a/b/c/xyz --- test1/a/b/c/xyz 2010-02-03 16:21:37.769640266 +0100 +++ test2/a/b/c/xyz 2010-02-03 13:54:37.886386605 +0100 @@ -1 +1 @@ -2 +1
Bug#568248: patch creates files and directories instead of asking for the file location
Package: patch Version: 2.6-2 Hi, since version 2.6 of patch it has a weird behaviour. If the specified -p parameter is wrong (and the file can therefore not be found) patch now creates the whole path to the file and some files therein. Example: - Lets say you have a directory structure as in: 1/a/b/c/xyz 2/a/b/c/xyz (where xyz is a file and both files are different) - You have a patch that was generated with diff -Nur 1 2 (so for patch -p0 you would have to apply it from the directory where the two top level directories 1 and 2 are in) - You now try to apply the patch from within of '2' with the wrong -p0 parameter. The result will be: - 2/2/a/b/c/xyz I have prepared a small test case that can be used to verify that. See the attached tarball for the filesystem hierarchy and the patch. Just enter the directory test2 and try to apply the patch with -p0. Expected result if patch would work correctly: Ask for the filename to patch as it did in 2.5.x. Best Regards, Patrick test_directories.tgz Description: GNU Unix tar archive diff -u -Nur test1/a/b/c/xyz test2/a/b/c/xyz --- test1/a/b/c/xyz 2010-02-03 13:56:38.319392924 +0100 +++ test2/a/b/c/xyz 2010-02-03 13:54:37.886386605 +0100 @@ -0,0 +1 @@ +1
Bug#566270: Bug#566264: RM: libclass-dbi-loader-relationship-perl/oldstable -- RoQA; License problems
Hi Philipp, On Mon, Jan 25, 2010 at 09:56:02PM +0100, Philipp Kern wrote: > On Fri, Jan 22, 2010 at 04:27:47PM +0100, Patrick Schoenfeld wrote: > > Its kind of unfortune that this removal will remove other packages > > as well (and affect packages which do have users) > > but I think we simply *can not* keep the packages in any suite. > > The module in question is a Perl 47 liners that only does some syntactic > "sugar" (I'd question even that) for DBI relationships. so what exactly is your point here? Might a 47 liner not need a license? > We are distributing this thing since 2004. Now you rush to remove it from > everywhere without caring about its reverse dependencies which would even > be easily fixable. If someone had dropped a bomb upon us with this it > would've exploded some time ago already. Which is, honestly speaking, a bad thing that should not have happened in the first place. Fact is: The licensing of the code is totally unclear. We do not even have the right to distribute it, because we never received a license at all. I cannot really understand how you can argue for contempt of legality just because we already did it a long time (and in fact tricked our users by writing something about GPL|Artistic in the copyright file). > I won't rush to remove this from stable and oldstable just yet. The timing > is a too unfortunate for this. Let's replace the few relationships with > sane lines and not drop packages out of stable in a hurry (i.e. 3h between > bug filing and removal from unstable are weird). Well, if the library is replaceable its a good idea to fix the reverse depends. However I'm not sure if this can keep us from removing it. But you wear the hat to decide that. I just spotted a - imho - major problem and reported it. > If the ftpmasters choose to overrule me, so be it, but I encourage them > to look at the simplicity of the package and what it does first. Yes, > there might be some regexps, but still. > > > I've checked popcon for maypole and the package itself and they > > are below 100.. > > Not everyone believes^Wsubmits to popcon. Thats known to all involved parties. But this argument does not help much if the argument is "we are doing something we must not do" and apart from that our only indication. Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557672: Fwd: Re: Bug#557672: traceroute-nanog: FHS violation: root-only program in usr/bin
Hi Daniel, the following mail needs your attention and I think Daniel missed to CC you on it. Daniel Kobras wrote: > On Mon, Nov 23, 2009 at 06:39:17PM +0100, Piotr Engelking wrote: > > FHS specifies that /bin, /usr/bin, and /usr/local/bin contains > > programs > > for use by all users. In particular, root-only programs are placed in > > /sbin, /usr/sbin, and /usr/local/sbin, instead. > > > > As traceroute-nanog works only if run by root, please do not install > > it > > or links to it (including alternatives) in /usr/bin. > > Solving this properly is actually a bit tricky as the traceroute package > that shares its alternatives with traceroute-nanog doesn't suffer from > the > root-only restriction these days, and it would be rather confusing to > handle the alternatives in /usr/sbin different from /usr/bin. I'm > tempted > to sidestep this issue by letting traceroute supersede the nanog variant > for good, and simply drop the -nanog package from Debian. Daniel, what's > the status of the nanog emulation in traceroute proper these days? Are > you > aware of any relevant features still missing? > > Regards, > > Daniel. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566264: RM: libclass-dbi-loader-relationship-perl/oldstable -- RoQA; License problems
Package: ftp.debian.org Severity: normal Hi, the above mentioned package is currently in a license unclear situation. There is already a RC bug open for this: #563519 While the copyright falsely claims that is licensed under GPL|Artistic license there is no such indication in the source. Someone already tried contacting the upstreams (although the contact is fresh) and got a bounce for one of the upstreams and no reply from the other. Its kind of unfortune that this removal will remove other packages as well (and affect packages which do have users) but I think we simply *can not* keep the packages in any suite. Packages affected: libclass-dbi-loader-relationship-perl libmaypole-perl libmaypole-plugin-authentication-usersessioncookie-perl libmaypole-plugin-upload-perl maypole maypole-authentication-usersessioncookie maypole-plugin-upload memories I've checked popcon for maypole and the package itself and they are below 100.. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565889: Please depend on build-essential too
On Tue, Jan 19, 2010 at 02:12:10PM +0100, Loïc Minier wrote: > it would be nice if mk-build-deps would also depend on build-essential; > that would help the dependency resolver and would allow skipping one > step when e.g. installing a -build-deps package in a chroot. If I understand you right you want that the packages created by mk-build-deps depend on build-essential? Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564873: libevent: breaks dnsproxy
Severity: grave Package: libevent Version: 1.4.13-stable-1 Hi, I recently took some time to investigate #560550 and noticed that an undocumented and uncommunicated change in libevent broke dnsproxy. Factual the library removed symbols which are used by other applications when the library is used as documented. It at least hits event_gotsig and event_sigcb. This change is not documented, the manpage event(3) even furthermore suggests the use of this symbols. I know that a alpha version talks about deprecation of these symbols, but this can not happen without communicating this PRIOR the deprecation. So now I'm unsure how to go on. Its not documented how to change the behaviour of a depending program (atleast I haven't found such documentation), nor is the current documentation accurate, nor is the change at all documented (ChangeLog), nor was I as a maintainer of a dependent package beeing informed. I would appreciate if you could work torwards: - updating the documentation - clarifying if that change is really intended - clarifying what needs to get changed in order to build again Thanks and best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564443: [build-rdeps] Triggers error if no Sources exist for contrib or non-free
Hi, On Sat, Jan 09, 2010 at 05:15:30PM +0200, Tommi Vainikainen wrote: > Package: devscripts > Version: 2.10.61 > Severity: normal > Tags: patch > > My /etc/apt/sources.list contains only component 'main' in deb-src line, > and when I run build-rdeps, it shows error messages "No such file or > directory" about missing Sources for components 'contrib' and > 'non-free': I can agree that the current behaviour is probably not the best, but the default behaviour of build-rdeps is to search all three components that are common for Debian systems. We could agree or disagree weither that default is sensible, as non-free and contrib are not official parts of Debian, but if we accept it as it is, your change would do more harm than doing good. Explanatories below. And after all there is a reason for --exclude-component and --only-main. > Here is a patch that adds simple check for existance of Sources files > for each component. Thanks, but I for one won't accept that patch in this way. The sources files are a requirement to fulfill the job of build-rdeps. If they are not around an error should be triggered. This patch would simply hide it. I could accept one or both of the following solutions: 1. In the manpage emphasize that the system requires sources files for each component it checks and that the default is to check the given common components. 2. Add a more speaking warning if the required files are not found, before trying to scan the files. > The latter part of patch changes conditions in such way that it works > also for unknown components if any. Not yet sure, what to say about that part. Might be sensible. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559549: [nmudiff] please include --tagpending option
Hi, On Fri, Jan 08, 2010 at 07:09:40PM +0100, gregor herrmann wrote: > On Fri, 08 Jan 2010 16:18:11 +0100, Patrick Schoenfeld wrote: > > > > Find attached a quick patch that adds "+ pending" if the bug is not > > > yet tagged pending and $NMUDIFF_DELAY != 0. > > thanks for the patch. Do you mind updating it against the latest > > svn trunk? If you do I would most likely commit it. > > I just did a `debcheckout devscripts' and took a look, the patch > applies cleanly (after changing the name of the file to patch). For > your convenience I'm attaching this version. indeed, my fault to not recognize that myself. Thanks for the patch, committed in revision 2081. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559549: [nmudiff] please include --tagpending option
Hi Gregor, On Sun, Dec 27, 2009 at 02:51:04AM +0100, gregor herrmann wrote: > Find attached a quick patch that adds "+ pending" if the bug is not > yet tagged pending and $NMUDIFF_DELAY != 0. thanks for the patch. Do you mind updating it against the latest svn trunk? If you do I would most likely commit it. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564074: /usr/sbin/ftpmirror: Segfaults on startup
Hi, On Fri, Jan 08, 2010 at 09:45:51AM +0200, Niko Tyni wrote: > I'm not going to start a severity war, we'll do our best to fix this for > the release anyway. I'll just note that `important' has traditionally > been the severity for perl bugs that crash the interpreter and don't > affect many packages. you do not have to. I was wrong, thats it. I just stretched the meaning of the critical severity to far. My reaction derives from the feeling that its somehow strange that a package that does not actually contain a bug is considered release-critical buggy while the package which causes the bug isn't. Anyway I'm pretty sure that the perl maintainers do a good job and it will be fixed until the release (hopefully more early) so its okay anyway. Thanks for your -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559746: /usr/sbin/ftpmirror: Segfaults on startup
On Thu, Jan 07, 2010 at 04:35:40PM +0200, Eugene V. Lyubimkin wrote: > severity -1 important I'm a bit surprised about your choice to downgrade the bug, because in fact it qualifies for severity 'critical' as it makes unrelated software totally unusable. Reason? Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559746: /usr/sbin/ftpmirror: Segfaults on startup
Hi, first of all: I'm CC'ing the perl maintainers as I'm somehow suspecting a bug in perl itself. OK, here is the situation: ftpmirror segfaults as soon as you start it. After spending some time with debugging I wasn't really able to find the place where the SEGFAULT happens. OK, the last function it executes (according to the backtrace) but thats all I was able to find out, yet. Apart from this: If a script language bails out with a SIGSEGV this seems a lot like a interpreter bug to me. Comments (especially from the perl maintainers :) appreciated. Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561477: [security] must not RE-add /etc/apache2/conf.d/cacti.conf link on upgrade
Tags 561339 patch
thanks
Hi,
attached is a patch that changes behaviour of postinst so,
that symlink is only created on a fresh installation.
Feel free to use it, if you wish.
Best Regards,
Patrick
diff -u -Nur cacti-0.8.7e.bak/debian/cacti.postinst cacti-0.8.7e/debian/cacti.postinst
--- cacti-0.8.7e.bak/debian/cacti.postinst 2010-01-07 13:38:39.722365167 +0100
+++ cacti-0.8.7e/debian/cacti.postinst 2010-01-07 13:41:54.609792094 +0100
@@ -54,14 +54,18 @@
webservers="" ;;
esac
-for server in $webservers; do
- if [ -d "/etc/${server}/conf.d" ]; then
- if [ ! -e "/etc/${server}/conf.d/cacti.conf" ] ; then
- ln -s ../../cacti/apache.conf "/etc/${server}/conf.d/cacti.conf"
- fi
- invoke-rc.d $server reload || true
- fi
-done
+# Only try to add a symlink on a fresh install to respect
+# changes done by the administrator
+if [ "$2" = '' ]; then
+for server in $webservers; do
+if [ -d "/etc/${server}/conf.d" ]; then
+if [ ! -e "/etc/${server}/conf.d/cacti.conf" ] ; then
+ln -s ../../cacti/apache.conf "/etc/${server}/conf.d/cacti.conf"
+fi
+invoke-rc.d $server reload || true
+fi
+done
+fi
# remove old unused config file
rm -f /etc/cacti/config.php
Bug#561477: [security] must not RE-add /etc/apache2/conf.d/cacti.conf link on upgrade
On Wed, Jan 06, 2010 at 05:44:28PM +0200, Teodor MICU wrote: > [please don't use -quiet as I didn't received the responses though I > want to contribute were I can] > > 2010/1/4 Patrick Schoenfeld : > >> I've noticed in the past that cacti RE-adds the symbolic link > >> conf.d/cacti.conf > >> on every upgrade even if the source file was *manually* removed by the > >> sysadmin. > >> This is done to restrict the access to 'cacti' on each virtual web site > >> (the > >> default behaviour in Debian). > > > >> * cacti/webserver: Apache2 > > > > The question is: Why did you ask to do this in the first place? > > (according to your debconf settings) > > Ok, now I see that this is a way of disabling that symlink. Still, I > would like to have the '/etc/cacti/apache.conf' file for reference to > update my custom config which simply restricts the access to Intranet. which should be totally unrelated. Usually the file /etc/cacti/apache.conf should be installed together with the package while the symlink is created because you asked it, to. > > So sorry for the noise, except that I still not understand why > > people answer a priority high question with "Configure my webserver: > > apache2" just for removing the symlink, it results into after, that. > > The debconf question is "Which kind of web server should be used by > cacti?" so I answered "apache2". Maybe this question should be updated > to better describe its meaning? Well, it also says "Select 'None' if you would like to configure your webserver by hand." but I agree that the wording of the question could be more clear. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548620: amule-daemon crashes with Segmentation Fault on starting
Hi, I'm writing to you because you both reported a similar bug against amuled which I stumbled upon, when looking through the list of RC bugs. > After setting AMULED_USER to "p2p", a valid user, in > /etc/default/amule-daemon, > I try to start amule-daemon. > > /etc/init.d/amule-daemon start > /etc/init.d/amule-daemon: line 37: 20398 Segmentation fault > start-stop-daemon --start --quiet --exec $WRAPPER --user > "$AMULED_USER" --chuid "$AMULED_USER" > /dev/null This is not reproducible on an amd64 or i386 machine for me. But according to your bug information you both run an arm system. Now I'm just here to remember you that it would help a lot, if you could provide a meaningful backtrace. The page [1] should help you with that. Thanks in advance and best Regards, Patrick [1] http://wiki.debian.org/HowToGetABacktrace -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554953: does not support new source formats
Hi, your following mail has the following header set: To: cont...@bugs.debian.org, 554...@bugs.debian.org > notfound 559533 0.59.0-1 > found 559553 0.59.1~rc1 > thanks > > This bug actually only affects sbuild in the git repo. So your note seems to have gone to the wrong bug. Could you verify and confirm/undermine this so that not everybody going through the list of rc bugs has to verify weither your note or the 'found' mark of the BTS are right about this RC bug? Thanks and best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554703: bind accepts any incomming zone transfers if the tsig key is not
Hi, > I does however: > Nov 6 01:10:05 kronecker named[21547]: zone example.com/IN: unable to > find key: a.example.net-b.example.net > Nov 6 01:10:05 kronecker named[21547]: zone example.com/IN: Transfer > started. could you please post the whole configuration files? Especially interesting would be whats configured for allow-transfer and which IP the master and slave resolve to. Thanks and Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562059: heimdal-kdc: creates logfiles in /var/lib/heimdal-kdc
Package: heimdal-kdc Version: 1.2.dfsg.1-2.1 Severity: serious Hi, on a fresh installation a logfile was created in /var/lib/heimdal-kdc. That seems to be a FHS violation as the path is reserved for state information, whereas the FHS explicitly states: "State information should generally remain valid after a reboot, should not be *logging output*, and should not be spooled data." JFTR: Its not a configuration problem: krb-test:/etc/bind# grep -i log /etc/heimdal-kdc/kdc.conf # See allowed values in krb5_openlog(3) man page. log_file = FILE:/var/log/heimdal-kdc.log Best Regards, Patrick -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages heimdal-kdc depends on: ii cdebconf [debconf-2.0]0.145 Debian Configuration Management Sy ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy pn heimdal-clients(no description available) ii krb5-config 2.2Configuration files for Kerberos V ii libasn1-8-heimdal 1.3.1.dfsg.1-6 Heimdal Kerberos - ASN.1 library ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libcomerr21.41.9-1 common error description library ii libdb4.8 4.8.24-2 Berkeley v4.8 Database Libraries [ ii libgssapi2-heimdal1.3.1.dfsg.1-6 Heimdal Kerberos - GSSAPI support ii libhdb9-heimdal 1.3.1.dfsg.1-6 Heimdal Kerberos - kadmin server l ii libheimntlm0-heimdal 1.3.1.dfsg.1-6 Heimdal Kerberos - NTLM support li ii libhx509-5-heimdal1.3.1.dfsg.1-6 Heimdal Kerberos - X509 support li ii libkadm5srv8-heimdal 1.3.1.dfsg.1-6 Libraries for Heimdal Kerberos pn libkdc2-heimdal(no description available) pn libkrb5-25-heimdal (no description available) ii libldap-2.4-2 2.4.17-2.1 OpenLDAP libraries ii libroken18-heimdal1.3.1.dfsg.1-6 Heimdal Kerberos - roken support l ii libsqlite3-0 3.6.21-2 SQLite 3 shared library ii libssl0.9.8 0.9.8k-7 SSL shared libraries ii libwind0-heimdal 1.3.1.dfsg.1-6 Heimdal Kerberos - NTLM support li ii logrotate 3.7.8-4Log rotation utility ii openbsd-inetd [inet-super 0.20080125-4 The OpenBSD Internet Superserver heimdal-kdc recommends no packages. Versions of packages heimdal-kdc suggests: pn heimdal-docs (no description available) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#529185: O: aiccu -- SixXS Automatic IPv6 Connectivity Client
Hi, > I'm willing to adopt the aiccu package and spoke to Martin and he's oke > with it but he also told me to speak to you. I'm happy to hear that someone wants to maintain aiccu. Please note that I'm currently working on a bigger QA upload, so if you start working on it, please contact me before. Best Regards, Patrick signature.asc Description: Digital signature
Bug#561324: aiccu: uses non-essential tools in the config script
Package: aiccu Version: 20070115-11 Severity: serious The config script of the package uses the aiccu tool itself to create a list of tunnel providers and even tries to connect the tunnel providers during config stage. This is a policy violation, because policy 3.9.1 states: "The config script might be run before the preinst script, and before the package is unpacked or any of its dependencies or pre-dependencies are satisfied. Therefore it must work using only the tools present in essential packages." As the package might get unpacked _after_ running the script, it simply cannot depend on itself to be around at that point. -Patrick -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages aiccu depends on: ii cdebconf [debconf-2.0] 0.145Debian Configuration Management Sy ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy ii iproute 20090324-1 networking and traffic control too ii iputils-ping3:20071127-2 Tools to test the reachability of ii iputils-tracepath 3:20071127-2 Tools to trace the network path to ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libgnutls26 2.8.5-2 the GNU TLS library - runtime libr ii lsb-base3.2-23 Linux Standard Base 3.2 init scrip ii ucf 3.0025 Update Configuration File: preserv Versions of packages aiccu recommends: ii ntp 1:4.2.4p7+dfsg-4 Network Time Protocol daemon and u ii ntpdate 1:4.2.4p7+dfsg-4 client for setting system time fro aiccu suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550103: pycocuma: does not save changes to file
Hi, I spent some time trying to reproduce this, but I were unable to do so. > 1. Create a new contact and fill in some details > 2. Click save on the toolbar > 3. Then use the window manager's close command >One possibility would be "wmctrl -c "PyCoCuMa" That doesn't work, because it does not kill the application. According to xprop "PyCoCuMa - http://localhost:8810"; is the right string for the client. Therefore wmctrl -c "PyCoCuMa - http://localhost:8810"; works for me. Using the window manager (xmonad in my case) close function does not produce the issue in question. > 4. Check the contacts file for changes and see none Works for me. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#356937: /usr/bin/logger: logging to facility kern doesn't work
Tags 356937 patch thanks Hi, attached is a patch for the manpage. It removes kern from the list of valid facilities and adds an additional note. Best Regards, Patrick diff -Nur util-linux-2.16.2/misc-utils/logger.1 util-linux-2.16.2.patched/misc-utils/logger.1 --- util-linux-2.16.2/misc-utils/logger.1 2009-10-16 01:16:40.0 +0200 +++ util-linux-2.16.2.patched/misc-utils/logger.1 2009-12-10 12:32:00.516656480 +0100 @@ -99,7 +99,7 @@ utility exits 0 on success, and >0 if an error occurs. .Pp Valid facility names are: auth, authpriv (for security information of -a sensitive nature), cron, daemon, ftp, kern, lpr, mail, news, +a sensitive nature), cron, daemon, ftp, lpr, mail, news, security (deprecated synonym for auth), syslog, user, uucp, and local0 to local7, inclusive. .Pp @@ -109,6 +109,8 @@ warn (deprecated synonym for warning). For the priority order and intended purposes of these levels, see .Xr syslog 3 . + +Its not possible to use the kern facility, as it is reserved for the kernel. .Sh EXAMPLES .Bd -literal -offset indent -compact logger System rebooted
Bug#350742: renice: please add option to be quiet
Hi, > Please add an option to renice (like -q) to have renice not output > anything when renicing happens succesfully. I think this is useless as redirecting output works as it should. > renice is a useful command in things like scripts (renice +19 $$), > but often one wants it to be silent then (unless, of course, there is > an error). Redirecting output to /dev/null will also silence errors, > and is not nice to do. Hu? renice writes errors to STDERR, so I don't see why redirecting the output of STDOUT to /dev/null should silence errors. A quick test reveals that renice 19 -p12315351414 > /dev/null works just expected (outputting an error), as well as renice 19 -p1 > /dev/null Adding a quiet option just for the sake of suppressing one of the two possible stdout outputs renice can produce seems overkill to me. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539146: piuparts: debconf-english false negative
Hi, FWIW: I had a quick look at the new log [1] and can confirm that this seems to be a false-positive. Indeed the removing fails, because debconf depends on debconf-i18n | debconf-english and removing debconf-english will not install debconf-i18n again. I don't really have a good idea how to fix this. Would a apt-get -f install after the first tried remove suffice? Should piuparts be more aware of depends? Should the selection derived from creating the chroot be restored? More answers as questions... Best Regards, Patrick [1] http://piuparts.debian.org/sid/fail/debconf-english_1.5.28.log -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519192: [Piuparts-devel] Bug#519192: Patch for this bug
Hi,
I've updated the patch for the current svn trunk.
As I have no running master/slave setup this is untested
from my side. It should probably be tested because piuparts-slave
changed a lot internally since the previous patch was created (as it
seems to me) unless you can tell from the review that everything is fine
;-)
Updated patch attached.
Best Regards,
Patrick
Index: piuparts-slave.py
===
--- piuparts-slave.py (Revision 550)
+++ piuparts-slave.py (Arbeitskopie)
@@ -1,6 +1,3 @@
-#!/usr/bin/python
-#
-# Copyright 2005 Lars Wirzenius (l...@iki.fi)
#
# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the
@@ -235,8 +232,8 @@
if not os.path.exists(self._config["chroot-tgz"]):
create_chroot(self._config, self._config["chroot-tgz"], self._config["distro"])
-if (self._config["upgrade-test-distros"] and not
-os.path.exists(self._config["upgrade-test-chroot-tgz"])):
+if (self._config["upgrade-test-distros"] and self._config["upgrade-test-chroot-tgz"]
+and not os.path.exists(self._config["upgrade-test-chroot-tgz"])):
create_chroot(self._config, self._config["upgrade-test-chroot-tgz"],
self._config["upgrade-test-distros"].split()[0])
@@ -286,7 +283,11 @@
time.sleep(int(self._idle_sleep))
else:
packages_files = {}
-distros = [self._config["distro"]] + self._config["upgrade-test-distros"].split()
+if self._config["upgrade-test-distros"]:
+distros = [self._config["distro"]] + self._config["upgrade-test-distros"].split()
+else:
+distros = [config["distro"]]
+
for distro in distros:
if distro not in packages_files:
packages_files[distro] = fetch_packages_file(self._config, distro)
@@ -314,14 +315,17 @@
def upgrade_testable(config, package, packages_files):
-distros = config["upgrade-test-distros"].split()
-if not distros:
-return False
-for distro in distros:
-if not package["Package"] in packages_files[distro]:
+if config["upgrade-test-distros"]:
+distros = config["upgrade-test-distros"].split()
+if not distros:
return False
-return True
+for distro in distros:
+if not package["Package"] in packages_files[distro]:
+return False
+return True
+else:
+return False
def test_package(config, package, packages_files):
logging.info("Testing package %s/%s %s" % (config.section, package["Package"], package["Version"]))
Bug#466049: piuparts: when called with -b, no policy-rc.d in second chroot
Tags 466049 patch thanks Hi, Marc Haber wrote: > I think that > piuparts -a -b piuparts.tar.gz -d etch -d lenny torrus-apache does the > following: > > (1) unpack tarball > (2) create exit 101 policy-rc.d > (3) upgrade etch > (4) dist-upgrade lenny > (5) unpack tarball a second time in a second directory > (6) do not create policy-rc.d Right. The point is, that after unpacking the tarball a second time the functions that setup a chroot for use after unpacking are not called. Thats probably because the chroot is created 'manually' instead of calling the appropriate function chroot.create(). I'm not exactly sure if replacing that code with a call for chroot.create() as I now did is the way to go. Holger, would be good if you have a look at the responding code anyway if this works out. Best Regards, Patrick Index: piuparts.py === --- piuparts.py (Revision 550) +++ piuparts.py (Arbeitskopie) @@ -1669,11 +1669,8 @@ save_meta_data(settings.saveendmeta, root_info, selections) chroot.remove() -dont_do_on_panic(id) chroot = get_chroot() -chroot.create_temp_dir() -id = do_on_panic(chroot.remove) -chroot.unpack_from_tgz(root_tgz) +chroot.create() chroot.check_for_no_processes()
Bug#466049: piuparts: when called with -b, no policy-rc.d in second chroot
Tags 466049 patch thanks Hi, Marc Haber wrote: > I think that > piuparts -a -b piuparts.tar.gz -d etch -d lenny torrus-apache does the > following: > > (1) unpack tarball > (2) create exit 101 policy-rc.d > (3) upgrade etch > (4) dist-upgrade lenny > (5) unpack tarball a second time in a second directory > (6) do not create policy-rc.d Right. The point is, that after unpacking the tarball a second time the functions that setup a chroot for use after unpacking are not called. Thats probably because the chroot is created 'manually' instead of calling the appropriate function chroot.create(). I'm not exactly sure if replacing that code with a call for chroot.create() as I now did is the way to go. Holger, would be good if you have a look at the responding code anyway if this works out. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560016: sed: please add warning about sed converting symlinks to regular files
On Tue, Dec 08, 2009 at 01:03:25PM +0100, Paolo Bonzini wrote: > On 12/08/2009 11:12 AM, Patrick Schoenfeld wrote: > >if sed is used to in-place edit a*symlink* it is replacing > >the symlink with a regular file. Thats probably okay (other tools > >like perl do it the same way) but it could cause some problems. > >For example if people who are not aware of that fact use > >it to edit files in /etc/apache2/conf.d or so. > > The existence of a --follow-symlinks option should be enough of a clue... Maybe. OTOH "Explicit is better then implicit" is a good credo to follow. But if you disagree, just close the bug. I don't have a strong opinion on this. Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#560016: sed: please add warning about sed converting symlinks to regular files
Package: sed Severity: wishlist Hi, if sed is used to in-place edit a *symlink* it is replacing the symlink with a regular file. Thats probably okay (other tools like perl do it the same way) but it could cause some problems. For example if people who are not aware of that fact use it to edit files in /etc/apache2/conf.d or so. Example: p...@lisa /tmp % ln -s x y p...@lisa /tmp % ls -ltr y lrwxrwxrwx 1 psc psc 1 8. Dez 10:58 y -> x p...@lisa /tmp % sed -i "abc" y p...@lisa /tmp % ls -l y -rw-rw-r-- 1 psc psc 0 8. Dez 10:59 y So I suggest adding a warning to the manpage and forwarding that upstream. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#312206: [PATCH] dpkg-divert deletes a file if it is diverted to itself
Tags 312206 patch
Severity 312206 grave
thanks
Hi,
> Although I cannot imagine a sane reason to divert a file to itself,
me neither.
> ... do not think there is a reason for dpkg-divert to delete the
> diverted file in that case.
I agree with this. So because no reason exists to divert a file to
itself and removing a file if one does so accidentally is a no-go
anyway, it seems more then appropriate to to bail out if src and
destination of the diversion are the same filenames.
Thats what the attached patch does.
On a side note: I raised the severity, because actually deleting
files (without the user requesting it) *is* data loss and thus severity
grave IME.
Best Regards,
Patrick
diff --git a/scripts/dpkg-divert.pl b/scripts/dpkg-divert.pl
index 012be90..7168c17 100755
--- a/scripts/dpkg-divert.pl
+++ b/scripts/dpkg-divert.pl
@@ -270,6 +270,10 @@ sub checkrename {
quit(sprintf(_g("cannot stat old name \`%s': %s"), $rsrc, $!));
(@sdest = lstat($rdest)) || $! == ENOENT ||
quit(sprintf(_g("cannot stat new name \`%s': %s"), $rdest, $!));
+if ($rsrc eq $rdest) {
+quit(sprintf(_g("will not divert %s to itself"), $rsrc));
+}
+
# Unfortunately we have to check for write access in both
# places, just having +w is not enough, since people do
# mount things RO, and we need to fail before we start
Bug#559548: [Piuparts-devel] Bug#559548: piuparts: ignore ucf files on purge after depends have been purged
Hi Holger, On Mon, Dec 07, 2009 at 12:56:07PM +0100, Holger Levsen wrote: > Hi Patrick, > > On Montag, 7. Dezember 2009, Patrick Schoenfeld wrote: > > On Sat, Dec 05, 2009 at 11:24:48AM +0100, Patrick Schoenfeld wrote: > > > if a package uses ucf it will be reported as buggy, because > > > the purge test purges all depends (including ucf) and the package > > > is therefore unable to unregister its configuration files from ucf. > > uarg, just to make that clear: I used the wrong wording. The depends > > are obviously not purged, otherwise the "problem" wouldn't exist. > > Sorry for (maybe) irritating you in this point ;) > > I think you are still irritated :-) Could be, yes. > Check eg http://piuparts.debian.org/squeeze/fail/smstools_3.1.3-3.log there > you have: Yep, that version of smstools was buggy. But I have the problem with a package where I fixed the missing if-clause. > 0m10.5s DEBUG: Starting command: > ['chroot', '/org/piuparts.debian.org/tmp/tmpeUTk5L', 'dpkg', '--purge', 'ucf'] > 0m10.7s DUMP: > (Reading database ... 8249 files and directories currently installed.) > Removing ucf ... > Purging configuration files for ucf ... > 0m10.7s DEBUG: Command ok: > ['chroot', '/org/piuparts.debian.org/tmp/tmpeUTk5L', 'dpkg', '--purge', 'ucf'] Hmm. This doesn't happen with the version of piuparts I have. See the attached log. The corresponding part in postrm is: if which ucf >/dev/null; then ucf --purge /etc/smsd.conf fi > > > So, for now, piuparts should ignore the files in /var/lib/ucf. > > This is even more true, if (as it seems) the project agrees > > that ucf database can be left altered when purging a package which altered > > the database while ucf isn't around anymore. > > No, that's not how I read the thread on -devel. /var/lib/ucf should be > deleted > when ucf is purged. If that doesn't happen, this is a bug in ucf. Exactly. But I'm not talking about *purging* /ucf/, I'm talking about removing ucf and purging a package that depends on ucf. I have a different opinion (although it seems the majority of people think I'm confused ;) about which package the registry data belongs to, therefore the conflict on -devel. Regardless of that: If piuparts purges the depends the data goes away and piuparts shouldn't complain. But it does, so it seems something is still wrong. > Thus closing this bug. Leaving it up to you to reopen the bug if appropriate. Best Regards, Patrick 0m0.0s INFO: -- 0m0.0s INFO: To quickly glance what went wrong, scroll down to the bottom of this logfile. 0m0.0s INFO: FAQ available at http://wiki.debian.org/piuparts/FAQ 0m0.0s INFO: -- 0m0.0s INFO: piuparts version __PIUPARTS_VERSION__ starting up. 0m0.0s INFO: Command line arguments: /usr/sbin/piuparts --skip-minimize --warn-on-others --lvm-volume /dev/lisa-schroot/sid smstools_3.1.6-1_amd64.deb -l smstools-3.1.6.log 0m0.0s INFO: Running on: Linux lisa 2.6.31-1-amd64 #1 SMP Sun Nov 15 22:05:44 UTC 2009 x86_64 0m0.0s DEBUG: Starting command: ['dpkg', '--info', 'smstools_3.1.6-1_amd64.deb'] 0m0.0s DUMP: new debian package, version 2.0. size 277058 bytes: control archive= 16740 bytes. 82 bytes, 3 lines conffiles 2781 bytes, 121 lines * config #!/bin/sh 1066 bytes,24 lines control 6555 bytes,81 lines md5sums 4507 bytes, 185 lines * postinst #!/bin/sh 774 bytes,32 lines * postrm #!/bin/sh 532 bytes,15 lines * preinst #!/bin/sh 272 bytes,11 lines * prerm#!/bin/sh 28732 bytes, 359 lines templates Package: smstools Version: 3.1.6-1 Architecture: amd64 Maintainer: Mark Purcell Installed-Size: 984 Depends: debconf (>= 1.4.69), ucf (>= 0.28), adduser, libc6 (>= 2.7), libmm14 (>= 1.4.0-1) Section: comm Priority: optional Homepage: http://smstools3.kekekasvi.com Description: SMS server tools for GSM modems The SMS server tools allow setting up a central SMS gateway. It sends and receives SMS messages using a simple file-based interface. It can accommodate up to 20,000 messages a month. . It supports an event-handler option that allows calling customized programs or scripts after sending or receiving SMS messages. . The SMS Server Tools use one or more (max. 32) GSM modems to send and
Bug#559548: piuparts: ignore ucf files on purge after depends have been purged
Hi, On Sat, Dec 05, 2009 at 11:24:48AM +0100, Patrick Schoenfeld wrote: > if a package uses ucf it will be reported as buggy, because > the purge test purges all depends (including ucf) and the package > is therefore unable to unregister its configuration files from ucf. uarg, just to make that clear: I used the wrong wording. The depends are obviously not purged, otherwise the "problem" wouldn't exist. Sorry for (maybe) irritating you in this point ;) > So, for now, piuparts should ignore the files in /var/lib/ucf. This is even more true, if (as it seems) the project agrees that ucf database can be left altered when purging a package which altered the database while ucf isn't around anymore. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559549: [nmudiff] please include --tagpending option
On Sat, Dec 05, 2009 at 10:15:05PM +0100, Stefano Zacchiroli wrote: > On Sat, Dec 05, 2009 at 01:39:01PM +0100, Patrick Schoenfeld wrote: > > On Sat, Dec 05, 2009 at 11:29:26AM +0100, Sandro Tosi wrote: > > > it would be nice if nmudiff had a '--tagpending' to include the needed > > > control@ > > > command to tag as pending the closed bugs in the NMU. > > I agree that it would be a good idea to support tagpending in nmudiff, > > but I disagree that nmudiff should do it on its own. > > I'm not sure I understand the concern. nmudiff is already adding +patch > tags, why can't it add also +pending upon request? For instance, when I > do DELAYED uploads, I always hand-patch the "tags +" line by adding > "pending", nmudiff can do that for me (in fact, it would even be a sane > default when --delay is passed). > > What tagpending additionally does is (I believe) checking which bugs > should not be tagged pending as they already are. nmudiff should ignore > that, as the mail is going to be sent to the BTS anyhow. Yep. That was the case I'm thinking about, but probably you are right. So no objections from my side anymore ;) Regards Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559548: [Piuparts-devel] Bug#559548: piuparts: ignore ucf files on purge after depends have been purged
On Sat, Dec 05, 2009 at 03:31:33PM +0100, Holger Levsen wrote: > Hi Patrick, > > On Samstag, 5. Dezember 2009, Patrick Schoenfeld wrote: > > if a package uses ucf it will be reported as buggy, because > > the purge test purges all depends (including ucf) and the package > > is therefore unable to unregister its configuration files from ucf. > > This will leave changed files in /var/lib/ucf. > > so $package (where $package != ucf) specific ucf files are kept > in /var/lib/ucf? Well, when doing ucfr on package installation, it modifies files in /var/lib/ucf. If you are now uninstalling a package you would normally run ucf to remove the entries in ucfs registry. This cannot happen, when ucf is beeing removed before, so the files remain changed. So in fact there is nothing buggy about $package. Its just a case that is not masked by our package management or our policy. > regards, > Holger, pondering if ucf should be requiered ;-) Yes, I was wondering about this, too. Someone said that ucf functionality might get merged back into dpkg.. eventually this would be an even better solution. But for now I think that piuparts should not consider packages buggy, just because they use ucf. Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559568: dh_auto_configure: Please support updating config.sub etc.
Package: debhelper Severity: wishlist Hi, AFAICT currently debhelper does not update autoconf files before configuring. I think it would be a good idea, if it supported it. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559549: [nmudiff] please include --tagpending option
Hi, On Sat, Dec 05, 2009 at 11:29:26AM +0100, Sandro Tosi wrote: > it would be nice if nmudiff had a '--tagpending' to include the needed > control@ > command to tag as pending the closed bugs in the NMU. I agree that it would be a good idea to support tagpending in nmudiff, but I disagree that nmudiff should do it on its own. > I know 'tagpending' exists, but the method above will have all the relevant > commands and writings about the NMU in a single mail. Yeah, but it would duplicate code, for not much of benefit. I think that calling tagpending would be a better approach. Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559548: piuparts: ignore ucf files on purge after depends have been purged
Package: piuparts Version: 0.37 Severity: normal Hi, if a package uses ucf it will be reported as buggy, because the purge test purges all depends (including ucf) and the package is therefore unable to unregister its configuration files from ucf. This will leave changed files in /var/lib/ucf. I'm more then unhappy that this is the situation, but as we are not allowed to mess with other packages files there is no possibility to workaround it. So, for now, piuparts should ignore the files in /var/lib/ucf. Best Regards, Patrick -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages piuparts depends on: ii apt0.7.24Advanced front-end for dpkg ii debootstrap1.0.20Bootstrap a basic Debian system ii lsb-release3.2-23Linux Standard Base version report ii lsof 4.81.dfsg.1-1 List open files ii python 2.5.4-2 An interactive high-level object-o ii python-debian 0.1.14Python modules to work with Debian piuparts recommends no packages. Versions of packages piuparts suggests: ii ghostscript 8.70~dfsg-2 The GPL Ghostscript PostScript/PDF pn python-rpy (no description available) -- 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#559449: [Piuparts-devel] Bug#559449: piuparts: please add LVM support [PATCH]
Hi,
On Fri, Dec 04, 2009 at 03:38:37PM +0100, Holger Levsen wrote:
> tags 559449 + confirmed
> thanks
>
> Hi Patrick,
>
> thanks for your bugreport with patch!
>
> On Freitag, 4. Dezember 2009, Patrick Schoenfeld wrote:
> > I'd like to use piuparts but neither with creating a new chroot on every
> > run, nor by unpacking a tarball on every run, but with LVM snapshots.
> > There is a bug report about adding schroot support, but I didn't see any
> > benefit of using schroot in contrast to just using LVM snapshots,
>
> less requierements (=no lvm) to use it?
I don't get that, because I don't see what benefits this would provide
over using the methods piuparts is already to.. oh wait. There is one:
With schroot piuparts could run without root permissions. Ok, I don't
care to much about it, but anyone else sureley does :)
> > so
> > I implemented the latter. My patch is attached. Feel free to apply it
> > or if you have any questions/comments get back to me.
>
> Looks good to me, will apply. Right now I just don't get how this is related:
Oops. That was an accident.
> Could you also please provide a patch for piuparts.1.txt? ;-) Extra bonus
> points for a
> debian/changelog entry ;-)
See new attached patch.
Best Regards,
Patrick
Index: debian/changelog
===
--- debian/changelog (Revision 535)
+++ debian/changelog (Arbeitskopie)
@@ -1,3 +1,11 @@
+piuparts (0.38) unstable; urgency=low
+
+ * piuparts.py:
+ - Add support for using LVM snapshots. Thanks to
+ Patrick Schoenfeld for the patch. (Closes: #559449)
+
+ -- Patrick Schoenfeld Fri, 04 Dec 2009 15:55:42 +0100
+
piuparts (0.37) unstable; urgency=low
* piuparts-report.py: report packages with update-rc.d warnings and those
Index: piuparts.1.txt
===
--- piuparts.1.txt (Revision 535)
+++ piuparts.1.txt (Arbeitskopie)
@@ -47,6 +47,15 @@
+
The tarball can be created with the '-s' option, or you can use one that *pbuilder* has created (see '-p'). If you create one manually, make sure the root of the chroot is the root of the tarball.
+*--lvm-volume*='lvm-volume'::
+ Use the specified lvm-volume as source for the chroot, instead of building a
+ new one with debootstrap. This creates a snapshot of the given LVM volume and
+ mounts it to the chroot path.
+
+*--lvm-snapshot-size*='snapshot-size'::
+ Use the specified snapshot-size as snapshot size when creating a new LVM
+ snapshot (default: 1G)
+
*-d* 'name', *--distribution*='name'::
Which Debian distribution to use: a code name (etch, lenny, sid) or experimental. The default is sid (i.e, unstable).
Index: piuparts.py
===
--- piuparts.py (Revision 535)
+++ piuparts.py (Arbeitskopie)
@@ -49,6 +49,7 @@
import subprocess
import unittest
import urllib
+import uuid
from debian_bundle import deb822
@@ -137,6 +138,7 @@
self.debian_distros = []
self.bindmounts = []
self.basetgz = None
+self.lvm_volume = None
self.savetgz = None
self.endmeta = None
self.saveendmeta = None
@@ -554,6 +556,8 @@
if settings.basetgz:
self.unpack_from_tgz(settings.basetgz)
+elif settings.lvm_volume:
+self.setup_from_lvm(settings.lvm_volume)
else:
self.setup_minimal_chroot()
@@ -585,6 +589,10 @@
if not settings.keep_tmpdir and os.path.exists(self.name):
self.unmount_proc()
self.unmount_selinux()
+if settings.lvm_volume:
+logging.debug('Unmounting and removing LVM snapshot %s' % self.lvm_snapshot_name)
+run(['umount', self.name])
+run(['lvremove', '-f', self.lvm_snapshot])
shutil.rmtree(self.name)
logging.debug("Removed directory tree at %s" % self.name)
elif settings.keep_tmpdir:
@@ -608,6 +616,18 @@
logging.debug("Unpacking %s into %s" % (tarball, self.name))
run(["tar", "-C", self.name, "-zxf", tarball])
+def setup_from_lvm(self, lvm_volume):
+"""Create a chroot by creating an LVM snapshot."""
+self.lvm_base = os.path.dirname(lvm_volume)
+self.lvm_vol_name = os.path.basename(lvm_volume)
+self.lvm_snapshot_name = self.lvm_vol_name + "-" + str(uuid.uuid1());
+self.lvm_snapshot = os.path.join(self.lvm_base, self.lvm_snapshot_name)
+
+logging.debug("Creating LVM snapshot %s from %s" % (self.lvm_snapshot, lvm_volume))
+run(['lvcreate', '-n&#
Bug#559449: piuparts: please add LVM support [PATCH]
Package: piuparts
Severity: wishlist
Tags: patch
Hi,
I'd like to use piuparts but neither with creating a new chroot on every
run, nor by unpacking a tarball on every run, but with LVM snapshots.
There is a bug report about adding schroot support, but I didn't see any
benefit of using schroot in contrast to just using LVM snapshots, so
I implemented the latter. My patch is attached. Feel free to apply it
or if you have any questions/comments get back to me.
Best Regards,
Patrick
Index: piuparts.py
===
--- piuparts.py (Revision 535)
+++ piuparts.py (Arbeitskopie)
@@ -49,6 +49,7 @@
import subprocess
import unittest
import urllib
+import uuid
from debian_bundle import deb822
@@ -137,6 +138,7 @@
self.debian_distros = []
self.bindmounts = []
self.basetgz = None
+self.lvm_volume = None
self.savetgz = None
self.endmeta = None
self.saveendmeta = None
@@ -554,6 +556,8 @@
if settings.basetgz:
self.unpack_from_tgz(settings.basetgz)
+elif settings.lvm_volume:
+self.setup_from_lvm(settings.lvm_volume)
else:
self.setup_minimal_chroot()
@@ -585,6 +589,10 @@
if not settings.keep_tmpdir and os.path.exists(self.name):
self.unmount_proc()
self.unmount_selinux()
+if settings.lvm_volume:
+logging.debug('Unmounting and removing LVM snapshot %s' % self.lvm_snapshot_name)
+run(['umount', self.name])
+run(['lvremove', '-f', self.lvm_snapshot])
shutil.rmtree(self.name)
logging.debug("Removed directory tree at %s" % self.name)
elif settings.keep_tmpdir:
@@ -608,6 +616,18 @@
logging.debug("Unpacking %s into %s" % (tarball, self.name))
run(["tar", "-C", self.name, "-zxf", tarball])
+def setup_from_lvm(self, lvm_volume):
+"""Create a chroot by creating an LVM snapshot."""
+self.lvm_base = os.path.dirname(lvm_volume)
+self.lvm_vol_name = os.path.basename(lvm_volume)
+self.lvm_snapshot_name = self.lvm_vol_name + "-" + str(uuid.uuid1());
+self.lvm_snapshot = os.path.join(self.lvm_base, self.lvm_snapshot_name)
+
+logging.debug("Creating LVM snapshot %s from %s" % (self.lvm_snapshot, lvm_volume))
+run(['lvcreate', '-n', self.lvm_snapshot, '-s', lvm_volume, '-L', settings.lvm_snapshot_size])
+logging.info("Mounting LVM snapshot to %s" % self.name);
+run(['mount', self.lvm_snapshot, self.name])
+
def run(self, command, ignore_errors=False):
return run(["chroot", self.name] + command,
ignore_errors=ignore_errors)
@@ -1712,7 +1732,6 @@
def set_basetgz_to_pbuilder(option, opt, value, parser, *args, **kwargs):
parser.values.basetgz = "/var/cache/pbuilder/base.tgz"
-
def parse_command_line():
"""Parse the command line, change global settings, return non-options."""
@@ -1731,7 +1750,16 @@
help="Use TARBALL as the contents of the initial " +
"chroot, instead of building a new one with " +
"debootstrap.")
-
+
+parser.add_option("--lvm-volume", metavar="LVM-VOL", action="store",
+ help="Use LVM-VOL as source for the chroot, instead of building " +
+ "a new one with debootstrap. This creates a snapshot of the " +
+ "given LVM volume and mounts it to the chroot path")
+
+parser.add_option("--lvm-snapshot-size", metavar="SNAPSHOT-SIZE", action="store",
+ default="1G", help="Use SNAPSHOT-SIZE as snapshot size when creating " +
+ "a new LVM snapshot (default: 1G)")
+
parser.add_option("-B", "--end-meta", metavar="FILE",
help="XXX")
@@ -1845,7 +1873,7 @@
help="No meaning anymore.")
parser.add_option("--debfoster-options",
- default="-o MaxPriority=required -o UseRecommends=no -f -n apt debfoster",
+ default="-o MaxPriority=required -o UseRecommends=no -o UseEssential=yes -f -n apt debfoster",
help="Run debfoster with different parameters (default: -o MaxPriority=required -o UseRecommends=no -f -n apt debfoster).")
@@ -1854,6 +1882,8 @@
settings.defaults = opts.defaults
settings.args_are_package_files = not opts.apt
settings.basetgz = opts.basetgz
+settings.lvm_volume = opts.lvm_volume
+settings.lvm_snapshot_size = opts.lvm_snapshot_size
settings.bindmounts += opts.bindmount
settings.debian_distros = opts.distribution
settings.ignored_files += opts.ignore
Bug#504433: smstools: Reinstallation fails to complete
Tags 504433 unreproducible thanks Hi, the issue in question is not reproducible. I can't see how any of the mentioned packages could conflict with smstools in such a way that it could cause such troubles. The only unknown variable in this case is kmobilephone, because such a package does not exit in Debian. Apart from this it seems that the installation fails, because of the override for /var/log/smstools, but this override is added conditionally only if none exists, so I don't see how this could happen. Maybe some sort of hardware problem on your site? Tagging the problem as unreproducible for now. Will close it in a while, if I don't get a reply. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#476099: Please add paste.py to post to paste.debian.net
Javier Fernández-Sanguino Peña wrote: > What use is paste.debian.net? I don't actually understand its purpose. > I've skimmed over some of the 'pasted' content and it's mostly spam. > > Could you please detail why do you think that this tool would be useful > to other Debian users? I'm surprised to read this. Actually paste.debian.net or similar services are recommended in IRC channels to paste configurations or error messages etc. when requesting support. Its even in the topics for some of our user channels. So its quiet obvious why its useful for other users. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#270370: devscripts: File checking script
Hi, I had a look at the script you submitted for devscripts inclusion some years ago. Wondering if you are still interested in having it included. The following is a list of issues, that at least would need to be cleared out: - Your script is not licensed in any way, so we cannot include it - The script expects files to be in debian/tmp, but this is not always the case. it should be able to cope with all possible cases at best. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555816: vim-vimoutliner is missing its online help
Hi, On Wed, Nov 11, 2009 at 04:02:51PM -0500, Matthew James Goins wrote: > Package: vim-vimoutliner > Version: 0.3.4-8 > > After installing this package, and opening a file ending in ".otl" (for > example, one of the example outline files), I tried the command: I guess it doesn't work either, because I think that you forgot to enable the plugin with vim-addons install, as described in README.Debian. Just noticed that README.Debian has a bug (ADDON is not substituted by vimoutliner) but this shouldn't stop from doing this ;) > :help vo After that :help vo works for me. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555703: debchange: support DEBEMAILS setting to specify more then one uploader adress
Package: devscripts Version: 2.10.55 Severity: wishlist Hi, today I had an idea how to enhance dch. Lets consider the following scenario(s): - A Debian developer works for a company where he creates packages for customers, where he'd typically use his company email adress as maintainer adress. - A Debian and Ubuntu developer uses his @debian.org adress for packages he maintains in Debian and @ubuntu.com for packages maintained in Ubuntu. For now people have to use workarounds to support this. For example chaning DEBEMAIL manually on purpose. Or teaching their shell to set the env var path-dependent. I'd propose the following: Add a new variable DEBEMAILS (notice the s, its there to not even run the risk of breaking apps that use DEBEMAIL) DEBEMAILS would be a comma-seperated list of values as they now can be in DEBEMAIL. A new heuristic in debchange would now check, if this env var is set, weither one of these values matches the maintainer field or an entry in the uploaders list. If yes, then the value is used as DEBEMAIL setting. The rationale is, that problems that arise from the current behaviour can be eliminated. For example there is no auto-NMU triggered if one forgots to change DEBEMAIL. I'm going to implement this, unless someone stops me. Comments welcome. Best Regards, Patrick -- Package-specific info: --- /etc/devscripts.conf --- --- ~/.devscripts --- Not present -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages devscripts depends on: ii dpkg-dev 1.15.4.1 Debian package development tools ii libc6 2.10.1-5 GNU C Library: Shared libraries ii perl 5.10.1-7 Larry Wall's Practical Extraction Versions of packages devscripts recommends: ii at 3.1.11-1 Delayed job execution and batch pr ii bsd-mailx [mailx] 8.1.2-0.20090911cvs-2 simple mail user agent ii bzr2.0.2-1 easy to use distributed version co ii curl 7.19.5-1.1Get a file from an HTTP, HTTPS or ii cvs1:1.12.13-12 Concurrent Versions System ii dctrl-tools2.13.1Command-line tools to process Debi ii debian-keyring [de 2009.08.27GnuPG (and obsolete PGP) keys of D ii dput 0.9.5.1 Debian package upload tool ii epiphany-browser [ 2.29.1-1 Intuitive GNOME web browser ii equivs 2.0.7-0.1 Circumvent Debian package dependen ii fakeroot 1.14.3Gives a fake root environment ii git-core 1:1.6.5.2-1 fast, scalable, distributed revisi ii gnupg 1.4.10-2 GNU privacy guard - a free PGP rep ii iceweasel [www-bro 3.0.14-1 lightweight web browser based on M ii libauthen-sasl-per 2.13-1Authen::SASL - SASL Authentication ii libcrypt-ssleay-pe 0.57-2Support for https protocol in LWP ii libparse-debcontro 2.005-2 Easy OO parsing of Debian control- ii libsoap-lite-perl 0.710.08-2Client and server side SOAP implem ii libterm-size-perl 0.2-4+b1 Perl extension for retrieving term ii libtimedate-perl 1.1900-1 Time and date functions for Perl ii liburi-perl1.37+dfsg-1 Manipulates and accesses URI strin ii libwww-perl5.833-1 Perl HTTP/WWW client/server librar ii libyaml-syck-perl 1.07-1fast, lightweight YAML loader and ii lintian2.2.17Debian package checker ii lsb-release3.2-23Linux Standard Base version report ii lzma 4.43-14 Compression method of 7z format in ii man-db 2.5.6-3 on-line manual pager ii mercurial 1.3.1-1 scalable distributed version contr ii openssh-client [ss 1:5.1p1-8 secure shell client, an rlogin/rsh ii patch 2.5.9-5 Apply a diff file to an original ii patchutils 0.3.1-2 Utilities to work with patches ii sensible-utils 0.0.1 Utilities for sensible alternative ii strace 4.5.19-1 A system call tracer ii subversion 1.6.6dfsg-1 Advanced version control system ii unzip 6.0-1 De-archiver for .zip files ii w3m [www-browser] 0.5.2-2.1 WWW browsable pager with excellent ii wdiff 0.5-19Compares two files word by word ii wget 1.12-1.1 retrieves files from the web Versions of packages d
Bug#555607: acpi-support: should support default actions for lid close/open via config options
Package: acpi-support
Version: 0.123-1
Severity: wishlist
Hi,
today I wanted to configure my laptop to suspend to RAM when
closing the lid. This is possible with the current way how configuration
is managed, but not very beauty. I'd suggest one of the following
changes:
1. Make /etc/acpi/lid.sh call /etc/acpi/lid_close.sh when closing the
lid and lid_open.sh on opening. Make these scripts call
/etc/acpi/local/lid_{open,close}.sh.{pre,post} accordingly.
The obvious advantage of this approach is, that the lid logic
(close/open?) doesn't need to be duplicated in the scripts.
Eventually lid.sh could also be replaced by two more specific scripts,
but I don't know if that would work.
2. Add configuration options to make it possible to configure common
actions via /etc/default/acpi-support. For example it would make sense
to have an option, lets say ACTION_ON_LID_CLOSE, which could be set to
either sleep (pm-suspend), or hibernate (pm-hibernate) or none (default:
as it is now). Maybe it would make sense to call it somehow different,
because with that name none is not really correct as screen locking
would still happen (unless configured otherwise).
3. My favorite choice: Combine 1 and 2, so that its possible to
configure common actions (sleep, suspend, maybe poweroff, too) and
additionaly defining specific scripts that are only handled on
open/close of the lid.
BTW. I'd be willing to realize either of these options, depending
on what the Debian ACPI Team and upstrem think is the best
choices.
Best Regards,
Patrick
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages acpi-support depends on:
ii acpi-support-base 0.123-1scripts for handling base ACPI eve
ii acpid 1.0.10-2 Utilities for using ACPI power man
ii dmidecode 2.9-1.1Dump Desktop Management Interface
ii finger0.17-13user information lookup program
ii hdparm9.15-1 tune hard disk parameters for high
ii laptop-detect 0.13.7 attempt to detect a laptop
ii libc6 2.10.1-5 GNU C Library: Shared libraries
ii lsb-base 3.2-23 Linux Standard Base 3.2 init scrip
ii pm-utils 1.2.5-4utilities and scripts for power ma
ii powermgmt-base1.30+nmu1 Common utils and configs for power
ii x11-xserver-utils 7.4+2 X server utilities
Versions of packages acpi-support recommends:
ii dbus 1.2.16-2 simple interprocess messaging syst
ii hal 0.5.13-4 Hardware Abstraction Layer
ii nvclock 0.8b4-1Allows you to overclock your nVidi
ii radeontool1.5-5 utility to control ATI Radeon back
ii toshset 1.75-1 Access much of the Toshiba laptop
Versions of packages acpi-support suggests:
pn laptop-mode-tools (no description available)
-- 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#555560: gnome-power-manager: resume on lid sleep does not work
Severity: normal Package: gnome-power-manager Hi, I have my gnome-power-manager configured to suspend on lid close. This is somewhat problematic as of #455769, but I have an additional problem. When I let my system suspend by closing the lid and later on resume it by opening it again the system resumes and immediately goes to sleep again. I previously suspected it to be the fault of acpid, but I noticed that it isn't configured to handle the lid event this way by default. So I closed gnome-power-manager and configured acpi-support accordingly and the problem went away. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555310: Upgrade of rxvt-unicode messes with my alternative installation
Hi Decklin, first, thanks for your reply. On Mon, Nov 09, 2009 at 11:10:46AM -0500, Decklin Foster wrote: > Excerpts from Patrick Schoenfeld's message of Mon Nov 09 05:28:40 -0500 2009: > > (Basically this is the german translation of "removing manually selected > > alternative - switching x-t-e to auto mode" and "using > > /usr/bin/gnome-terminal.wrapper > > to provide /usr/bin/x-terminal-emulator (x-terminal-emulator) in auto mode") > > This was done to fix #481123. urxvtcd, which I assume you had > selected, is not suitable for x-terminal-emulator (since it always > immediately returns instead of running until the terminal closes, > which I agree is a major problem), so I decided that the alternative > should be removed entirely on upgrade. The priority for /usr/bin/urxvt > is pretty low since users who don't know what they're installing > probably want the more "standard" xterm or gnome-terminal. Thus, > reverting to auto mode did not give you urxvt. I don't really understand why this is a major problem, because I have never been bitten by this, but this secondarily. However I'm still curious a) in which cases this would cause trouble b) where this requirement is defined. I've read the policy about this and didn't quiet get it from the requirements defined therein (is that part of beeing vt100 compatible?) But apart from this the handling how this change has been done is bad, because it introduced a new rc bug. According to 10.7.3 local changes to configuration files /must/ preserve local changes. As already said in my first mail, its kind of a stretch, because a symlink is not what one would call a "configuration file", but after all the alternatives are in /etc for a reason and are a tool to configure a system to the admins needs and therefore the same care should be taken for them as for configuration files IMHO. Apart from this: NEWS.Debian exists for a reason. Such a disruptive change should have been properly listed therein. > (If you did not have urxvtcd selected, or no longer have an > alternative for urxvt, then I have horribly messed something else up.) Indeed, you are right. I missed that bit, because I forgot that I configured urxvtcd (and indeed wondered why it wasn't available - which is a pity, too). > I see two solutions here: (1) update-alternatives is extended in some > way to let you rank all alternatives, or save a stack of selections, > or prioritize other alternatives from the same package on removal, or > (2) I add a special case here to manually force the selection to urxvt > if urxvtcd was selected. (I guess there is also (3) increase > /usr/bin/urxvt's alternative priority on the assumption that only > users who know they want it are going to install rxvt-unicode... but > it's hard to say that about a package that's not Priority: extra.) None seems to be right solution. 1) This one is way over-engineered, I think. Probably useful, yeah, but not neccesarily for this case. 2) This would still be messing with admins configuration choice, but maybe the less disruptive, so this could probably be considered a fallback solution. 3) Well, your package already has the wrong configuration (according to policy it should have 20) but increasing it wouldn't help much. IME the change should be to: 1. Not remove the alternative if its set to urxvtcd 2. Add a note to NEWS.Debian, telling about the problem and all its consequences In the long term a patch for rxvt-unicode should be developed to add the missing features and upstream convinced to add it, but I guess its illusionary from what I heard about the upstream. > (N.b. currently, rxvt-unicode has been dropped from testing since the > other bug was raised to RC and I didn't deal with it in time. This bug > being RC will continue to keep it out. I'd like to avoid that.) I can understand you in that point. But as long as there is a bug about messing with admins configuration without at least a note about this, the package /should not/ migrate to testing again. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#555310: Upgrade of rxvt-unicode messes with my alternative installation
Package: rxvt-unicode Version: 9.06-2 Severity: serious Hi, today I upgraded rxvt-unicode (which was set as the terminal to provide x-terminal-emulator). After that upgrade I noticed that my alternative has been switched to a gnome-terminal. I then noticed the following in the log of my upgrade: update-alternatives: Entferne manuell ausgewählte Alternative - wechsle x-terminal-emulator zu Auto-Modus update-alternatives: Verwende /usr/bin/gnome-terminal.wrapper, um /usr/bin/x-terminal-emulator (x-terminal-emulator) in Auto-Modus bereitzustellen. (Basically this is the german translation of "removing manually selected alternative - switching x-t-e to auto mode" and "using /usr/bin/gnome-terminal.wrapper to provide /usr/bin/x-terminal-emulator (x-terminal-emulator) in auto mode") Severity is kind of a stretch. Basically I'm not sure if /etc/alternatives are to be considered configuration files, but as they reflect local configuration choices I consider it to be a policy violation to mess with them, because Debian policy 10.7.3 should apply to those links to follow the policies spirit. I am, however, not sure weither the bug is in rxvt-unicode or not, so please feel free to reassign it if needed. Best Regards, Patrick -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rxvt-unicode depends on: ii base-passwd3.5.22Debian base system master password ii libafterimage0 2.2.9-4 imaging library designed for After ii libc6 2.9-27GNU C Library: Shared libraries ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra ii libfontconfig1 2.6.0-4 generic font configuration library ii libfreetype6 2.3.11-1 FreeType 2 font engine, shared lib ii libgcc11:4.4.2-1 GCC support library ii libglib2.0-0 2.22.2-2 The GLib library of C routines ii libgtk2.0-02.18.3-1 The GTK+ graphical user interface ii libice62:1.0.5-1 X11 Inter-Client Exchange library ii libjpeg62 6b-15 The Independent JPEG Group's JPEG ii libperl5.105.10.1-7 shared Perl library ii libpng12-0 1.2.40-1 PNG library - runtime ii librsvg2-2 2.26.0-1 SAX-based renderer library for SVG ii libsm6 2:1.1.1-1 X11 Session Management library ii libtiff4 3.9.2-1 Tag Image File Format (TIFF) libra ii libx11-6 2:1.2.2-1 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxft22.1.13-3 FreeType-based font drawing librar ii libxrender11:0.9.4-2 X Rendering Extension client libra ii ncurses-base 5.7+20090803-2basic terminal type definitions ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime rxvt-unicode recommends no packages. Versions of packages rxvt-unicode suggests: ii ttf-dejavu2.30-1 Metapackage to pull in ttf-dejavu- -- 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#553929: password-gorilla - a cross-platform password manager
Package: wnpp Severity: wishlist Hi, I'm hereby orphaning password-gorilla as I'm not interested in maintaing it anymore. I also lack the needed TCL knowledge to keep maintaining it and wasn't able to reach upstream for a while. If you want to be the new maintainer, please take it -- see http://www.debian.org/devel/wnpp/index.html#howto-o for detailed instructions how to adopt a package properly. Thank you, Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553346: apt-listbugs: Please support filter mechanisms
Package: apt-listbugs Version: 0.1.1 Severity: wishlist Hi, I would like it, if I could configure apt-listbugs to ignore some bugs by a user-defined filter. A possible use-case would be (for example) to ignore FTBFS bugs, which I naturally do not really care for, when installing a package on my system. Best Regards, Patrick -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apt-listbugs depends on: ii apt 0.7.24 Advanced front-end for dpkg ii libdpkg-ruby1.8 0.3.2 modules/classes for dpkg on ruby 1 ii libgettext-ruby1.8 1.93.0-1Gettext for ruby1.8 ii libhttp-access2-ruby1.8 2.1.5.2-1 HTTP accessing library for ruby (t ii libruby1.8 [libzlib-ruby1.8] 1.8.7.174-2 Libraries necessary to run Ruby 1. ii libxml-parser-ruby1.80.6.8-4 Interface of expat for the scripti ii ruby 4.2 An interpreter of object-oriented apt-listbugs recommends no packages. Versions of packages apt-listbugs suggests: ii debianutils 3.2.1 Miscellaneous utilities specific t ii epiphany-gecko [www-browser] 2.26.3-2 Intuitive GNOME web browser - Geck ii iceweasel [www-browser] 3.0.14-1 lightweight web browser based on M ii reportbug 4.8reports bugs in the Debian distrib ii w3m [www-browser] 0.5.2-2.1 WWW browsable pager with excellent -- 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#552465: r8169 does not work correctly for RTL8111
Package: linux-2.6 Version: 2.6.26-13lenny2 Severity: important Hi, Ben Hutchings suggested to report a bug for this. With lenny and its usual 2.6.26 kernel the r8169 driver is loaded for the following card: 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03) This is right, except that the version in the Lenny kernel does not work for this card. Usually it fails to detect the link properly and says that the "device is not ready" instead. From a hardware side one can say that a link exists (both by looking at the cards LED and the switch LED to which it is connected). Using the 8168 driver from Realtek is working fine. Sometimes the 8169 also works (it worked fine when I had it connected at a friends place, so probably related to the hardware to which it is attached). The problem has gone away in 2.6.31. There the driver is working fine. Sorry, but I cannot provide logs anymore, because I don't have such. I'm also not using the Lenny 2.6.26 kernel anymore, because the ath5k code in that kernel is outdated and does not support the master mode, which I need. Best Regards, Patrick -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532823: wmweather+: Linked with OpenSSL, seems to be a GPL violation
Hi, I had a quick look at the package and noticed that it does not link directly against libssl. Obviously the linking happens due to the build depend on libcurl-dev which is provided by libcurl4-gnutls-dev and libcurl4-openssl-dev. Its probably worth to test weither the package works well with libcurl4-gnutls-dev instead of libcurl4-openssl-dev. Adrian, are you a user of wmweather+? Eventually with some knowledge how to test wmweather+ so that SSL would be used? If yes, would you mind testing a version of wmweather+ linked again gnutls if I would provide you with one? Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#536321: wsjt: line 32: 10216 Segmentation fault
Tags 536321 unreproducible Severity 536321 important thanks Hi, I tried to reproduce the problem, but were unable to do so. Does the problem still exist for you? Did the depends in question stay the same in the meanwhile? (For example according to your bug report you had libc6 2.9-19 which does not exist in any suite anymore, etc.) If you still have the problems, it would help if you could post an updated information about the depends for the package wsjt depends on: libc6, libgcc1, libgfortran3, libportaudio2, librar, libsamplerate0, python-imaging, python-imaging-tk, python-numpy, python-tk, xterm Downgrading the bug, because it makes it unusable for you, but it seems to be limited to your environment, as me and Daniel were unable to reproduce the bug. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#528121: O: xml-resume-library -- A set of tools for writing a resume in XML
Hi Daniel, I've seen that you were interested to adopt the xml-resume-library package, but lost interest. But as far as I can tell from your comments you already worked on the package. Well. Now there is an open rc bug on the package because of non-free material included and I wonder if your previous work may have fixed this bug. It would be cool, if you could check that and eventually provide a fixed package if the answer is yes. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#551986: RM: xpmumon -- RoQA, unmaintained, unused, rc bug(s)
Package: ftp.debian.org Severity: normal Hi, I hereby request to remove the package xpmumon from the archive for the following reasons: 1. RC bug #526457 and all the RC bugs that could be reported, because the package hasn't seen any maintenance since 2003 (missing upstream documentation, standards version _very_ old, etc.) 2. Popcon is low. It has 3 installations with no new installation. 3. Upstream is not determinable, therefore it cannot be checked, weither upstream is active and alive. Most likely upstream development is abandoned. 4. According to the description it requires a 2.4 kernel. Unknown if it still works with 2.6. Probably not. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535261: RFA: xpdf -- Portable Document Format (PDF) suite
Hi, in July 2009 you said that you intend to adopt xpdf. Are you still interested in that? Because currently it has several release-critical bugs, which should be addressed. So if your interest to maintain xpdf is still there, then you should work on this RC bugs or if not, then you should retitle the wnpp bug again. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#551757: usbmount: should support mounting by UUID
Package: usbmount
Version: 0.0.17.1
Severity: wishlist
Tags: patch
Hi,
it would be very handy if usbmount supported mounting devices
by its UUID, if an appropriate fstab entry exists. This way
static mount points can be defined by something more meaningful
as the device node. I've attached a patch against the latest
source package.
Best Regards,
Patrick
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages usbmount depends on:
ii lockfile-progs0.1.13 Programs for locking and unlocking
ii udev 146-3 /dev/ and hotplug management daemo
usbmount recommends no packages.
usbmount suggests no packages.
-- no debconf information
--
Patrick Schönfeld
Tel.: +49 (0)21 61 / 46 43-170
credativ GmbH, HRB Mönchengladbach 12080
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz
--- usbmount 2009-10-20 14:50:22.0 +0200
+++ ../usbmount.new 2009-10-20 15:16:47.348793236 +0200
@@ -93,7 +93,7 @@
exit 1
fi
-log debug "$DEVNAME"
+UUID="`/sbin/blkid $DEVNAME|sed 's/.*UUID="\([^"]*\)".*/\1/g'`"
# Test if the device has an /etc/fstab entry. In that case, we will
# mount it using the regular mount command.
if grep -q "^[ ]*$DEVNAME" /etc/fstab; then
@@ -103,6 +103,14 @@
log info "executing command: mount $DEVNAME"
mount "$DEVNAME"
+# Test if the device has an /etc/fstab entry with its UUID, in this
+# case we will mount it with a mount command on the mount point
+elif grep -q $UUID /etc/fstab; then
+log debug "$DEVNAME has an /etc/fstab entry, with its UUID $UUID, using that"
+
+MOUNT_POINT="`grep $UUID /etc/fstab|awk '{print $2}'`"
+log info "executing command: mount $MOUNT_POINT"
+
# Test if the device contains a filesystem. If it doesn't, no
# further action is required, but calling vol_id has the side effect
# that the partition table is read and partition devices are created.
Bug#471094: ITA: mantis
Hi, > Hi Olivier and Patrick, > > I'm interesting to ITA mantis cause I think it's a good application (I > used it from a very long time) and when I saw Patrick O request I feel > that it was important to continue with his hard work.. just saw your ITA on mantis. I'm happy to hear someone is interested in taking it over. Feel free to work on it as you like. But don't expect me to do something in the near future anyway ;) Just some hints to get you started: The current packaging is in git. The SVN repository is out-of-date and has just been kept there, because debcheckout would otherwise fail on non-sid/testing machines. > BTW, if you are asking for my personal skills, I'm a programmer and I'm > sure I would not have problems with the source code :-) Cool. What I suggest to you is to work close with Gianluca Sforna, who is working upstream and is also the package maintainer for Fedora. He might have similar problems as you and it might be possible to use synergy effects. Basically he is good to work with, so :) You should subscribe to the mantisbt-dev list, because important discussions are taking place there and it doesn't accept mails from unsubscribed persons, unfortunately. Its also wise to get an account for the bug tracker and ask the mantis developers to get you developer access, because this way you can keep track on not-yet-disclosed-security-bugs. Have fun with the package.. best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550712: ifupdown: kill running dhclients when switching to static adressing
Package: ifupdown Severity: wishlist Hi, I just stumbled across a unfortunate circumstance with ifupdown. If a host is configured to DHCP adressing and you then change it to static adressing the dhclient will still be running. This will lead to an address-change on the given interface, once the lease expires, because dhclient will reconfigure the interface. Therefore I would request to kill a DHCP-client, if the interface for which it was started, is reconfigured to static adressing. I don't know if this is possible, because I don't know if ifupdown is doing some state tracking, but if not a possible solution could eventually look like that: Interface eth0 is brought up, which uses static addressing. Therefore we check if any dhclient is running which watches eth0 (Don't know how this works for other dhclients, but dhclient3 gets the interface as argument, so this should be fairly easy to determine) and kill it. Any drawbacks with that suggestion? Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546213: severity of 546213 is normal
On Fri, Sep 25, 2009 at 04:19:52AM -0400, Andres Salomon wrote: > On Fri, 25 Sep 2009 10:12:06 +0200 > Patrick Schoenfeld wrote: > > > On Thu, Sep 24, 2009 at 11:01:45PM -0400, Andres Salomon wrote: > > > This sounds an awful lot like a firmware bug, as well (for which we > > > don't have the source code for). > > > > > > Perhaps you could try downgrading your firmware-iwlwifi package and > > > let us know whether that fixes the issue? It sounds like the > > > driver itself is doing the right thing by detecting a firmware > > > problem and reloading. > > > > Hmm. No, I haven't yet considered this. The thing is: The driver and > > the firmware work flawless in 2.6.29, so I guess that this might be a > > firmware problem, but more likely the driver changed since then and > > doesn't work with the firmware anymore. But AFAICT there were new > > release.. > > So you've verified that you were using the same version of > firmware-iwlwifi with 2.6.29 and 2.6.30 then, yes? I thought so, but currently I don't have a working kernel image (as I reinstalled for some other reasons a while ago) for 2.6.29 to verify that my memory is correct. However I found that bug #548749, which suggests that it might be a firmware bug nevertheless, so I'll give *that* a try. Should have tried that first. Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546213: severity of 546213 is normal
On Thu, Sep 24, 2009 at 11:01:45PM -0400, Andres Salomon wrote: > This sounds an awful lot like a firmware bug, as well (for which we > don't have the source code for). > > Perhaps you could try downgrading your firmware-iwlwifi package and let > us know whether that fixes the issue? It sounds like the driver itself > is doing the right thing by detecting a firmware problem and reloading. Hmm. No, I haven't yet considered this. The thing is: The driver and the firmware work flawless in 2.6.29, so I guess that this might be a firmware problem, but more likely the driver changed since then and doesn't work with the firmware anymore. But AFAICT there were new release.. Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547948: cupt: Fails to download translation filenames
On Wed, Sep 23, 2009 at 05:32:16PM +0300, Eugene V. Lyubimkin wrote: > > Hmm. Good point. Wouldn't it make sense to take the HTTP Response Code > > into account, then? > HTTP is not only source. It can be FTP, or file://, or maybe someone will > write pet p2p download module for cupt. Too much guessings... Right, didn't consider this. As you speak from modules. Does that mean that cupt uses plugins/modules for each protocol? If so, it would probably make sense to define an abstraction layer for error messages. So that the FTP protocol handler can still say: "Hey, I haven't found the file, but everything else is ok". Depending on weither you get "File not found" or "Some other error" you could then decide with the metric I've described. > > Something like: > > - File not found (404), but de_DE found => No warning > > - Access forbidden (403) or any other response code, but de can be > > downloaded => Warning > > > > So, if you still insist you want this get fixed nevertheless, I will convert a > bug to wishlist then. Well, I don't insist on anything, but I think it would improve your software. I somehow learned that a lot of useless warnings reduce the usefulness of *every* warning, because over time people get trained to ignore warnings at all. Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547948: cupt: Fails to download translation filenames
On Wed, Sep 23, 2009 at 04:53:13PM +0300, Eugene V. Lyubimkin wrote: > Patrick Schoenfeld wrote: > > Indeed. The second download is sucessful. Wouldn't it make sense to > > not print a warning in this case? Because actually thats the most > > common case (at least now). > > > Hm. This makes some sense, but. What if download failed not because de_DE > didn't exist, but some download error? The warning in this case would be good > to print. Hmm. Good point. Wouldn't it make sense to take the HTTP Response Code into account, then? Something like: - File not found (404), but de_DE found => No warning - Access forbidden (403) or any other response code, but de can be downloaded => Warning > For a kind of 'workaround', you can explicitly specify language code without > country specification, e.g. 'apt::acquire::translation=de'. Yeah. Just thinking about a no-workaround-solution :-) Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548010: cupt: shell prints wrong error messages on unknown commands
On Wed, Sep 23, 2009 at 05:05:59PM +0300, Eugene V. Lyubimkin wrote: > Unreproducible for me (regardless libterm-readline-gnu-perl installed or not): > > $ cupt shell > This is an interactive shell of the cupt package manager. > Building the package cache... [done] > cupt>xyz > E: unrecognized command 'xyz' > cupt>uiop > E: unrecognized command 'uiop' > cupt> Hmm. I just noticed that xyz, etc. work fine, but ? doesn't. So my assumption from before wasn't true. > Can you post the full shell session log? > Do you have some other Perl shell helper module installed (i.e. p...@lisa ~ % sudo cupt shell W: attempt to set wrong option 'apt::periodic::update-package-lists' W: attempt to set wrong option 'apt::periodic::download-upgradeable-packages' W: attempt to set wrong option 'apt::periodic::autocleaninterval' E: bad config in file '/etc/apt/apt.conf.d/15update-stamp' W: skipped configuration file '/etc/apt/apt.conf.d/15update-stamp' W: attempt to set wrong option 'apt::archives::maxage' W: attempt to set wrong option 'apt::archives::minage' W: attempt to set wrong option 'apt::archives::maxsize' This is an interactive shell of the cupt package manager. Building the package cache... [done] cupt>bla E: unrecognized command 'bla' cupt>? E: unrecognized command 'x' cupt> > 'dpkg -l | grep "libterm.*perl"'?) ii libterm-readkey-perl 2.30-4 A perl module for simple terminal control ii libterm-readline-perl-perl 1.0302-1 Perl implementation of Readline libraries ii libterm-size-perl0.2-4+b1 Perl extension for retrieving terminal size Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548010: cupt: shell prints wrong error messages on unknown commands
On Wed, Sep 23, 2009 at 04:38:03PM +0300, Eugene V. Lyubimkin wrote: > Hi, > > Patrick Schoenfeld wrote: > > Package: cupt > > Version: 1.0.0~beta1 > > Severity: minor > > > > Hi, > > > > when someone enters an unknown command into the cupt shell it says: > > > > cupt>? > > > > E: unrecognized command 'x' > > > > It should probably say which command is unknown instead. > > > Sorry, I didn't understand. What you suggest cupt to print when user entered > '?'? Help output? Thats also a good idea, but no, what I suggested is that if I enter xyz that it prints E: unrecognized command 'xyz' and not E: unrecognized command 'x' x is not a placeholder here. It is always printed, regardless of what the user enters. For the above example this would mean to print E: unrecognized command '?' Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547948: cupt: Fails to download translation filenames
On Tue, Sep 22, 2009 at 10:26:55PM +0300, Eugene V. Lyubimkin wrote: > Patrick Schoenfeld wrote: > > Hi, > > > > On Tue, Sep 22, 2009 at 09:50:02PM +0300, Eugene V. Lyubimkin wrote: > >>> That is, because it searches for files, which indeed do not exist. > >> In case of failure, cupt should try 'de' version and success with it. Can > >> you > >> show me full output of that cupt run? Indeed. The second download is sucessful. Wouldn't it make sense to not print a warning in this case? Because actually thats the most common case (at least now). Full output: p...@lisa ~ % sudo cupt update [sudo] password for psc: W: attempt to set wrong option 'apt::periodic::update-package-lists' W: attempt to set wrong option 'apt::periodic::download-upgradeable-packages' W: attempt to set wrong option 'apt::periodic::autocleaninterval' E: bad config in file '/etc/apt/apt.conf.d/15update-stamp' W: skipped configuration file '/etc/apt/apt.conf.d/15update-stamp' W: attempt to set wrong option 'apt::archives::maxage' W: attempt to set wrong option 'apt::archives::minage' W: attempt to set wrong option 'apt::archives::maxsize' Get:1 http://ftp.de.debian.org/debian/ testing Release Get:2 http://ftp.de.debian.org/debian sid Release Get:3 http://ftp.de.debian.org/debian/ sid Release Get:4 http://ftp.de.debian.org/debian sid Release.gpg Get:5 http://ftp.de.debian.org/debian sid/contrib Packages.bz2 [60.2KiB] Get:6 http://ftp.de.debian.org/debian/ testing Release.gpg Get:7 http://ftp.de.debian.org/debian/ sid Release.gpg Get:8 http://ftp.de.debian.org/debian/ sid/contrib Sources.bz2 [35.1KiB] Get:9 http://ftp.de.debian.org/debian sid/main Packages.bz2 [6124KiB] Get:10 http://ftp.de.debian.org/debian sid/contrib Translation-de_DE.bz2 6% [9 sid/main Packages.bz2 12.4KiB/6124KiB 0%][10 sid/contrib Translation-de_DE.bz2| 103KiB/s | ETA: 15sW: downloading http://ftp.de.debian.org/debian/dists/sid/contrib/i18n/Translation-de_DE.bz2 failed: HTTP response code said error: 404 Get:11 http://ftp.de.debian.org/debian/ sid/main Sources.bz2 [3198KiB] Get:12 http://ftp.de.debian.org/debian sid/contrib Translation-de.bz2 98% [9 sid/main Packages.bz2 5891KiB/6124KiB 96%][12 sid/contrib Translation-de.bz2 | 1727KiB/s | ETA: 0sW: downloading http://ftp.de.debian.org/debian/dists/sid/contrib/i18n/Translation-de.bz2 failed: HTTP response code said error: 404 Get:13 http://ftp.de.debian.org/debian sid/main Translation-de_DE.bz2 100% [13 sid/main Translation-de_DE.bz2 0B] | 1772KiB/s | ETA: 0sW: downloading http://ftp.de.debian.org/debian/dists/sid/main/i18n/Translation-de_DE.bz2 failed: HTTP response code said error: 404 Get:14 http://ftp.de.debian.org/debian sid/main Translation-de.bz2 Fetched 10.8MiB in 10s. sudo cupt update 7,33s user 1,03s system 57% cpu 14,454 total Best Regards, Patrick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548008: cupt: cosmetic change to the cupt shell
Package: cupt Version: 1.0.0~beta1 Severity: wishlist Hi, this is a ultra-ultra-low-severity bug, but I think the cupt shell should be like this cupt> instead of cupt> Best Regards, Patrick -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cupt depends on: ii libcupt-perl 1.0.0~beta1 alternative front-end for dpkg -- ii perl 5.10.0-25 Larry Wall's Practical Extraction ii sensible-utils 0.0.1 Utilities for sensible alternative cupt recommends no packages. Versions of packages cupt suggests: pn libterm-readline-gnu-perl (no description available) -- 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#548010: cupt: shell prints wrong error messages on unknown commands
Package: cupt Version: 1.0.0~beta1 Severity: minor Hi, when someone enters an unknown command into the cupt shell it says: cupt>? E: unrecognized command 'x' It should probably say which command is unknown instead. Best Regards, Patrick -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cupt depends on: ii libcupt-perl 1.0.0~beta1 alternative front-end for dpkg -- ii perl 5.10.0-25 Larry Wall's Practical Extraction ii sensible-utils 0.0.1 Utilities for sensible alternative cupt recommends no packages. Versions of packages cupt suggests: pn libterm-readline-gnu-perl (no description available) -- 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#548002: xrdp: fails to login if system uses LDAP authentication
Package: xrdp Version: 0.4.0~dfsg-9 Severity: normal Hola, when the system is set to use LDAP authentication, users are unable to login. xrdp simply states "Login failed" with no more reasoning. That has a higher severity as the new upstream release, as it effectively breaks xrdp in LDAP setups. But it is fixed in the new upstream version.. Best Regards, Patrick -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#548001: xrdp: connection log is confusing
Package: xrdp Version: 0.4.0~dfsg-9 Severity: minor Hi, this is probably an upstream bug, I'm anywhere report it here, so please forward it upstream if you think this is appropriate. After choosing a session and entering your user data a connection log is shown. It has an OK button which is active. One systems where I tested it, it shows 2 messages and then "hangs" for a while. That is, it does not show any visible progress, but thats just because it needs some seconds at this moment. In this situation people could be tempted to press OK, because they might think this might cause it to continue. But this causes the connection to drop. So either the OK button should be shaded out as long as xrdp tries to login or it should be named Abort. Probably it would also be good if the message would actually indicate that it is something doing and that it takes some seconds. Best Regards, Patrick -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
