With udev rules that call a script to applies the apm_on_ac or apm_on_battery
settings accordingly,
the systemd resume could be handled with a unit file like this:
[Unit]
Description=Trigger all block device udev rules on resume to re-apply
non-permanent device settings (e.g. smartctl and hdpar
Package: hdparm
Severity: serious
The apm/pm-utils suspend/resume functionalities, provided by shipping the
files 20hdparm and 95hdparm-apm scripts, do not work with systemd.
(missing systemd unit files)
To allow setting defaults I would suggest to support wildcards in hdparm.conf.
And ship with
Control: reopen 744753
Please ship a working systemd unit file as given in the last comments.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Control: reopen 725284
Udev rules are only trigged when devices appear/disapper,
but not when the kernel suspends (with the device staying
present and only entering a low power state)
A systemd unit file is required to recover all hdparm settings that
devices wrongly initialize back to factory d
Thank you for the kind response and information.
Looking forward to it.
With "auto-assembly support" you have a much better
description then my "using udev rules".
Basicly, I think it is about moving the assembly functionality from the
startup scripts to event driven rules, and leaving only so
Package: mdadm
Wondering about why nothing happened when hot-plugging a
raid member drive, I found the following answer in the changelog:
* disabled the incremental assembly upstream turned on in 3.1.3 for
now, this will have to wait until after the squeeze release.
And saw the Maintainer c
Package: gdm
I noticed lmt was again not properly setting the hdparm values on resume.
Turning on the verbose output revealed many
"Couldn't acquire prelim lock on descriptor" errors.
I have no idea about the real cause for this. But stopping lmt before suspend
in a /etc/pm/sleep.d/99laptop_mode
Michael, somehow I misread your response, as if you wanted me to patch other
packages,
but reconsidering I think you have rather expressed you'd consider a patch from
me.
Thanks for being willing to accept an improvement. I would certainly send a
patch if I were able to. So please leave the bu
> If you believe in that solution, please feel free to provide a patch.
> Complaints without action tend to be counter-productive time wasters.
Exactly. That would surely be the answer if filing this for packages that
depend on wine.
Exept, wine-party is resposible for a package that currently
> > Thus, the idea of letting the packet managment script provide the
> message.
>
> Or having the front end fix their assumptions. Please consider filing
> a bug against q4wine.
Please sleep over this. This sounds funny to me.
The debian wine package maintainers want upstream software
to ada
> Which front end are you using?
It was q4wine
> message should pop up via
> xmessage, and if not it will be dumped to stdout. So if your front
> end is preventing that, the issue should be fixed there.
Unfortunately, missing files already cause errors during the frontend
configuration proces
> Are you saying that the following message was never displayed to you?
Correct, the message was never displayed.
As reported, I installed a frontend that depends on wine, and strange error
messages popped up instead, caused by all kinds of missing files.
Thus my suggestion you use a high prio
Hello,
thanks for your answer.
> It is impossible for a package to install another from its postinst;
> dpkg has a lock to prevent multiple simultaneous invocations, and
> postinst scripts are run under the dpkg lock. Perhaps the postinst
> could enable i386 multiarch,
If selecting a package fo
reopen: 707226
> If you install the wine package instead of wine-bin, you will get the
> wine64-bin package,
Yes, that is also what the bug title says and exaclty what happened by
installing a package that depends on wine.
> which will present the above helpful info to the
> user.
Unfortunately
Package: wine
Severity: grave
On a freshly installed Debian stable (wheezy) on amd64, installing a frontend
like q4wine and wine seems to succeed, but running it produces strange errors.
The reason: Actually, no wine binaries or libs were installed.
Please add some debconf script to the wine-bin
Package: release-notes
Hello,
after seaching a lot, it finaly turned up not only questions
but also a solution on how to upgrade a squeeze gnome
system to a wheezy xfce system.
Found at the end of this thread:
debianforum.de/forum/viewtopic.php?f=12&t=140311
This request seems quite justified
For the sake of completeness for users that are bitten by this bug and search
for instructions:
The filesystem permissions of a fully publicly shared directory (i.e. ~/public)
has to be drwxrwsrwx.
chmod a+rwx ~/public
chmod g+s ~/public
And /etc/samba/smb.conf has to contain the line
The experience after a couple of months showed that the solution that sets
"inherit permissions = yes" as default works very well.
I'd suggest to implement that change as a fix. (Either in the default config
file shipped, or better, by adjusting the fallback value that samba uses if the
option
Tools like gnome-system-tools or accountservice allow to add the user to the
nopasswdlogin group. You might adopt that, to avoid the sudo breakage with
empty passwords.
A description of the method:
https://wiki.archlinux.org/index.php/GDM#Passwordless_login
--
To UNSUBSCRIBE, email to debian
Am Wed, 10 Oct 2012 21:09:05 +
schrieb ow...@bugs.debian.org (Debian Bug Tracking System):
> wheezy-updates does now exist.
Thanks! Is the creation of the dir now included in the script/procedure
for post wheezy releases?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.or
Package: gdm
Hello,
in contrast to slim, kdm, or startx, gdm breaks the central
umask configuration.
This is in debian stable (squeeze).
GDM sets the default umask to an explicit value (0022),
however, it should leave it as set by the system's default settings.
(The default umask is set with pam
Hello,
thank you very much for your help.
The umask returned in the .xsession xterm is 0022.
Does this mean gdm is wrongly setting the umask?
Could you then please reassign this bug to gdm?
> > Package: xfce4
> >
> > Hello,
> > this is in debian stable (squeeze).
> >
> > Something in the desk
Package: xfce4
Hello,
this is in debian stable (squeeze).
Something in the desktop environment sets the default umask
to an explicit value (0022), instead of leaving it as set according
to the system's default settings.
(The default umask is set with pam_umask according to
http://wiki.debian.o
Package: ftp.debian.org
Currently it does not seem possible to set up a sources.list for
the next-stable release (i.e. now wheezy) such that
it will remain fully appropriate after the release.
>From what I gathered, wheezy-updates is missing.
Could you please add symlinks, empty dirs (whatever
The three alternatives I found:
(also a workaround without samba adjustments) chmod publicly writable shares
to be setguid dirs and add the samba option "inherit permissions = yes" (x bits
are still mapped to archive,hidden,system)
(should works in all cases) let samba guests create files
Package: samba
Collaboration with guests is broken, and a truel solution is needed.
Sleeping over it, the idea I proposed in #678616 (a different "guest account"
definition)
really isn't solving the problem in general. Its way too static, to be right
for everybody.
For net usershares at least
> But the samba package doesn't create any file belonging to "nobody",
> and doesn't even allow doing so, as it doesn't create any writable
> public share.
If you have local users on the machine, it is a typical scenario that
a usershare is created (More often through the filemanger features
than
Package: samba
The default user used by samba to create files of guest users currently
is "nobody", however the filesystem should never contain anything
belonging to the nobody/nogroup. (see Bug #290623)
Other reasons to rethink the impersonation of nobody, are practical
problems in accessing fi
Package: adduser
Version: 3.59
The default adduser.conf now has all ADD_EXTRA_GROUPS
settings disabled.
However, as the debian default is to use user(private)groups,
this leaves the general "users" group unpopulated.
Please enable the standard "users" group as a default extra group,
to ensure it
> we don't break existing setups and we
> provide additional functionality.
Yes, it should be fine to adjust the compile time defaults,
to avoid config file handling, and to require to set as few options
as possible explicitly in the default config in debian and in the
installations.
Thanks agai
Good run! :)
Really, thank you for your consideration.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Package: rsync
Tags: patch
Please build the package with the --drop-cache option (patch should be available
in the tarball). It should allow to avoid filling up the io cache with the
copied data.
The current behavior pushes the cached data of other process out of the memory
and slows down the s
> My concern is that "map to guest" not only affects user shares but
> also regular shares.
Let's see. This may mostly only be the case with the "map to guest =
bad user" option.
(Because "usershare allow guests = yes" is usershare specific.)
What happens without the bad user mapping?
Clients h
> I'm less convinced. Debian is meant for being upgraded easily, so
> dooing a "clean reinstall" is not really that a benefit. But, still,
Right, once, you have a clean debian install sure you just upgrade.
Yet, "preserve /home" (or rather del sys-files) provides a nice
way to get to the point of
Just found out you could adopt this available package:
http://packages.linuxmint.com/pool/import/t/thunar-shares-plugin/
https://bugs.launchpad.net/ubuntu/+bug/329873
https://launchpad.net/~danielmorales/+archive/ppa
It still seems to be in need of the newer branch though:
https://bugs.launchpad.
Package: wnpp
X-Debbugs-CC: pkg-xfce-de...@lists.alioth.debian.org
The thunar-shares-plugin allows to set up samba usershares in the properties
dialog of directories of the thunar file manager.
The thunarx-2 branch at
http://git.xfce.org/thunar-plugins/thunar-shares-plugin/
is said to work with r
> samba package settings to diverge from upstream defaults
I understand that the usershares option was already a deviation from
the upstream default, to enable usershares. The public share options
might just have been forgotten at that time.
BTW for ad-hock shares II prefer public shares, beca
Package: debian-installer
Downstream, I have found the possibility to do a clean re-install "over" an
exitising
installation very useful, and I think it may also be useful with debian.
For example, if you need to upgrade laptops that have rather small (thus
only a swap+root partition setup) an
Package: samba
The default samba configuration in debian allows regular users to
create shares with "net usershare" and its (filemanager) GUI frontends.
(as of #443230)
However, users are not able to make their shares public.
(e.g. nautilus-shares option is grayed out)
To enabling this funtiona
39 matches
Mail list logo
