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
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
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 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
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
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 some
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
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
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
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
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 for
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
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 process,
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 adapt to
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
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=12t=140311
This request seems quite justified
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
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
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
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
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 desktop
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
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
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: 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
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
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 a
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 have
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
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
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
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
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) and
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,
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
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:
39 matches
Mail list logo
