RFH: two base wheezy bugs
Hi,
I'm at loss with what to do with #710047. (random freeze since wheezy)
And just closing #708158 ("desktop becomes slower once plugged into power")
saying "you didnt supply more info" also is not really my prefered move but
I'm a bit hesistant to just reassign to the tracker package. Maybe I should,
other ideas welcome.
cheers,
Holger - all our base belongs to us!
signature.asc
Description: This is a digitally signed message part.
Re: RFH: two base wheezy bugs
On Du, 16 iun 13, 09:49:41, Holger Levsen wrote:
> Hi,
>
> I'm at loss with what to do with #710047. (random freeze since wheezy)
More information would be nice, redirect to debian-user?
> And just closing #708158 ("desktop becomes slower once plugged into power")
> saying "you didnt supply more info" also is not really my prefered move but
> I'm a bit hesistant to just reassign to the tracker package. Maybe I should,
> other ideas welcome.
The submitter has posted a workaround ('options drm_kms_helper poll=N'
in a file under /etc/modprobe.d/). Reassign to src:linux?
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
signature.asc
Description: Digital signature
Re: RFH: two base wheezy bugs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16/06/13 10:05, Andrei POPESCU wrote:
> On Du, 16 iun 13, 09:49:41, Holger Levsen wrote:
>> Hi,
>>
>> I'm at loss with what to do with #710047. (random freeze since
>> wheezy)
>
> More information would be nice, redirect to debian-user?
>
>> And just closing #708158 ("desktop becomes slower once plugged
>> into power") saying "you didnt supply more info" also is not
>> really my prefered move but I'm a bit hesistant to just reassign
>> to the tracker package. Maybe I should, other ideas welcome.
>
> The submitter has posted a workaround ('options drm_kms_helper
> poll=N' in a file under /etc/modprobe.d/). Reassign to src:linux?
>
I think there are more opportunities to enhance the bug tracker
708158 is probably serious or critical for anybody with that hardware
and may be a non-issue, impossible to reproduce for anybody else. It
is lucky that it has been observed elsewhere. Being able to
systematically link bugs to hardware would be useful, then other
owners of the same hardware would (a) be able to check for outstanding
bugs before upgrading (b) try to reproduce and confirm bugs
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJRvYPqAAoJEOm1uwJp1aqDh1cQAJCAgQ6G0CAjAzLKkx+yaC8Q
be1MUVtijKSbqA9M7PPqjjDP239oaHJVHlFhgPvVZm83d7UQBJg79GqpFA8lGXBb
BT4Afi41/3wdr/wUD0IMMPqBlHrb7KekaE/frqZVy0sf6IUwi1/p8qB7MTiexG3B
uM69RQwFDPZAmWU8xCrLQ4Kf0ScOBGvySw2qmQALxL1gOeTmQZum2WvFjSe9NoVq
2v8G5Hu8k9VEeXxabHWBk2CfwYJxVazmk8tMBlx4g2jSKsBEvUgr1eQ/r/QFlnOI
GNKOWBwvF8gbOim/V8oPz9rpSjlHhzhBIQf6bYtkQmYtDoYHtteuzv88m+I8JRMT
Zr3zk+cX9E8Mwv1MMGygH9XOf2DffSklpftAmHu5jR4QkULDGcfXE2xyJEnSLQ46
k7gQhQicN5V0M0x8Ajvm8oqYsaDbajCWVN7vGIOmVGrFMCfmkhymjJc0fgox3Or7
WOyuVOG7emTMuy0EzwSWGfS5CciqjcW0fNAAavrOHQrVvIaMeK/l+TlXt1lruAwm
bQwCgPujlc7XY4EZOi+U40EMIBNvUOtwj7b6x2TIiz3eIM987TshRIfUC1eaSK4c
f4qtMHACJ+vp1pKWdW7qCiTMP1wV2qPxHgRt/sll7iBwG2D8eBiwbeuZ2y6Anh3Y
mnz+zbPlTIUZX19WoQlf
=nbF4
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51bd83ea.60...@pocock.com.au
Bug#712478: ITP: gnome-shell-extension-icon-hider -- GNOME Shell's status area icons manager
Package: wnpp Severity: wishlist Owner: Igor Kalnitsky * Package name: gnome-shell-extension-icon-hider Version : 10-1 Upstream Author : Name * URL : https://github.com/ikalnitsky/gnome-shell-extension-icon-hider * License : GPL Programming Lang: JavaScript Description : GNOME Shell's status area icons manager Icon Hider for GNOME Shell is a simple extension for managing visibility of status area icons. For example, you can hide unnecessary icons such as a11y or battery. The extension already available on http://extensions.gnome.org, but I want to build debian package too. More information can be found on my GitHub (https://github.com/ikalnitsky/gnome-shell-extension-icon-hider). Sincerely, Igor. signature.asc Description: Digital signature
Re: how to deal with "not yet built" / "missing binaries" on autobuilders, requesting transition needed?
Hi, Thanks for your reply, and thanks Adam D. Barratt and Ansgar Burchardt for helping out on IRC. On Sun, Jun 16, 2013 at 09:35:46AM +0800, Paul Wise wrote: > On Sun, Jun 16, 2013 at 12:35 AM, Joost van Baal-Ilić wrote: > > > 1) Prepare a better ticcutils 0.4-4 package, which builds libticcutils2 > > and unversioned libticcutils-dev (which Conflicts: libticcutils1-dev, > > libticcutils2-dev and Replaces: libticcutils1-dev, libticcutils2-dev). > > 2) Submit a bug to release.debian.org, requesting "transition tracking" > > (as per http://release.debian.org/transitions/), apologising for previous > > mistake and requesting an ACK for uploading ticcutils 0.4-4. Using http://ftp-master.debian.org/cruft-report-daily.txt for inspiration. > > 3) Once ACK'd, upload and keep an eye on autobuilders > > > > Correct? > > Indeed. > > Please ensure that you test the upgrade path using piuparts though. Working on that now. Bye, Joost -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130616101223.gr...@beskar.mdcc.cx
Re: jessie release goal: verbose build logs
On Fri, Jun 14, 2013 at 14:14:39 +0200, Jakub Wilk wrote: > Debian X Strike Force [long list] Working on fixing these (adding --disable-silent-rules) as I update them. Will take a while though... Cheers, Julien signature.asc Description: Digital signature
Re: default MTA
On 15/06/13 13:04, David Weinehall wrote: > On Thu, May 30, 2013 at 12:15:03PM +0200, Bjørn Mork wrote: >> The issue that worries me most about these desktop notification plans is >> the possibility that some package may decide to unnecessarily drop >> support for non-desktop systems, adding dependencies on the desktop >> notification system. I believe we already have had a few examples of >> such unnecessary dependencies on services which are "nice to have", like >> GNOME depending on NetworkManager for example. > > I'm having a hard time understanding this particular gripe. If you're > running a non-desktop system (by this I take it to mean that you're not > using a GUI), why would you worry about GNOME's dependencies anyhow? > > If you're using a desktop system it doesn't feel like a stretch to use > functionality that fits in with the desktop system. And vice versa, > obviously. This concern could be put another way: that if the mailer is not present, developers will no longer assume it is present and will choose other dependencies (maybe just syslog or maybe a GUI) as a way of raising alerts I prefer to look at it the other way though: how can we make mail integration so effective that developers will want to use it for everything and it works more seamlessly with or without a GUI? I agree that mail works, but in a default deployment, it does little to prioritize or de-duplicate alerts from applications and the OS. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51bdbc98.5040...@pocock.com.au
Bug#712518: ITP: libcatalyst-action-serialize-data-serializer-perl -- serializing module for Catalyst::Action::REST using Data::Serializer
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libcatalyst-action-serialize-data-serializer-perl Version : 1.08 Upstream Author : Tomas Doran * URL : https://metacpan.org/release/Catalyst-Action-Serialize-Data-Serializer/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : serializing module for Catalyst::Action::REST using Data::Serializer Catalyst::Action::Serialize::Data::Serializer implements a serializer for use with "Data::Dumper" and others. It was factored out of Catalyst::Action::REST because it is unlikely to be widely used and tends to break tests, be insecure, and is generally weird. Use at your own risk. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130616175543.ga21...@jadzia.comodo.priv.at
wrong configuration in daemon
Hello, I have a question concerning a bugreport I got, but that could be quite general. Let's say a daemon provides POP and IMAP, and is configured to provide both, in a pop.conf and imap.conf. How should the daemon ideally fail in case one of the two configuration files is incorrect but the other is fine? Should it log the situation and start the service that it's able to start? Or should it just not start at all? -- Salvo Tomaselli http://web.student.chalmers.se/~saltom/ signature.asc Description: This is a digitally signed message part.
Re: wrong configuration in daemon
On Sun, Jun 16, 2013 at 08:28:18PM +0200, Salvo Tomaselli wrote: > Hello, > > I have a question concerning a bugreport I got, but that could be quite > general. > > Let's say a daemon provides POP and IMAP, and is configured to provide both, > in a pop.conf and imap.conf. > > How should the daemon ideally fail in case one of the two configuration files > is incorrect but the other is fine? > > Should it log the situation and start the service that it's able to start? Or > should it just not start at all? This is dependent on the exact daemon and the potential repercussions of not starting one of the services. * If it is actually providing both POP and IMAP, it should probably start the service with the working config file, and log an error for the other one. However, if that is hard to achieve, not starting either service is a valid option. * If it is actually the control system for a nuclear power station, and the config files are for the "add more uranium" and "prevent meltdown" services, it should probably do an emergency shutdown of the reactor and then prevent anything from starting until the problem is fixed. -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130616183606.GC4278@havelock
Re: wrong configuration in daemon
On Sun, Jun 16, 2013 at 08:28:18PM +0200, Salvo Tomaselli wrote: > I have a question concerning a bugreport I got, but that could be quite > general. > > Let's say a daemon provides POP and IMAP, and is configured to provide both, > in a pop.conf and imap.conf. > > How should the daemon ideally fail in case one of the two configuration files > is incorrect but the other is fine? > > Should it log the situation and start the service that it's able to start? Or > should it just not start at all? If it's a single process that listens on two ports (POP & IMAP) then I would not start at all. A system administrator is likely to interpret that a running process indicates success start. What would trigger him to check that the process is listening on both ports. Also, in the start up script, how would you indicate that the daemon is 'half started'. Hope this helps, Luca -- Luca Filipozzi http://www.crowdrise.com/SupportDebian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130616183946.ga4...@emyr.net
Bug#712539: ITP: encuentro -- Access the content of the Encuentro channel, and others
Package: wnpp Severity: wishlist Owner: Maximiliano Curia * Package name: encuentro Version : 1.0 Upstream Author : Facundo Batista * URL : http://encuentro.taniquetil.com.ar/ * License : GPL-3 Programming Lang: Python Description : Access the content of the Encuentro channel, and others Encuentro is a small program that allows you to search, download and watch videos from the Encuentro argentinian channel. Since the content of the channel is completely in Spanish, so is this program. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130616225734.18218.86632.report...@amadeus.maxy.com.ar
Re: wrong configuration in daemon
If the daemon is configured to restart the service, then it will fail to execute. What daemon is servicing both POP and IMAP? On Jun 16, 2013 2:40 PM, "Luca Filipozzi" wrote: > On Sun, Jun 16, 2013 at 08:28:18PM +0200, Salvo Tomaselli wrote: > > I have a question concerning a bugreport I got, but that could be quite > > general. > > > > Let's say a daemon provides POP and IMAP, and is configured to provide > both, > > in a pop.conf and imap.conf. > > > > How should the daemon ideally fail in case one of the two configuration > files > > is incorrect but the other is fine? > > > > Should it log the situation and start the service that it's able to > start? Or > > should it just not start at all? > > If it's a single process that listens on two ports (POP & IMAP) then I > would > not start at all. > > A system administrator is likely to interpret that a running process > indicates > success start. What would trigger him to check that the process is > listening > on both ports. > > Also, in the start up script, how would you indicate that the daemon is > 'half > started'. > > Hope this helps, > > Luca > > -- > Luca Filipozzi > http://www.crowdrise.com/SupportDebian > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/20130616183946.ga4...@emyr.net > >
Re: default MTA
David Weinehall wrote: > Bjørn Mork wrote: > > The issue that worries me most about these desktop notification plans is > > the possibility that some package may decide to unnecessarily drop > > support for non-desktop systems, adding dependencies on the desktop > > notification system. I believe we already have had a few examples of > > such unnecessary dependencies on services which are "nice to have", like > > GNOME depending on NetworkManager for example. > > I'm having a hard time understanding this particular gripe. If you're > running a non-desktop system (by this I take it to mean that you're not > using a GUI), why would you worry about GNOME's dependencies anyhow? Here is an example: The emacs24-nox package, a typical headless server package for many of us, depends upon dbus. Feature creep. Bob signature.asc Description: Digital signature
Re: default MTA
Le 17/06/2013 06:12, Bob Proulx a écrit : > David Weinehall wrote: >> Bjørn Mork wrote: >>> The issue that worries me most about these desktop notification plans is >>> the possibility that some package may decide to unnecessarily drop >>> support for non-desktop systems, adding dependencies on the desktop >>> notification system. I believe we already have had a few examples of >>> such unnecessary dependencies on services which are "nice to have", like >>> GNOME depending on NetworkManager for example. >> >> I'm having a hard time understanding this particular gripe. If you're >> running a non-desktop system (by this I take it to mean that you're not >> using a GUI), why would you worry about GNOME's dependencies anyhow? > > Here is an example: The emacs24-nox package, a typical headless server > package for many of us, depends upon dbus. Feature creep. > Putting emacs (which I use as my primary editor) and feature creep in the same sentence is quite funny: "You are at a dead end of a dirt road. The road goes to the east. In the distance you can see that it will eventually fork off. The trees here are very tall royal palms, and they are spaced equidistant from each other. There is a shovel here." Please remarke that there is libasound2 in there, too. I can see why notifications (and not desktop notifications) are useful on a headless server. Much less for sound. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
