Bug#725284:
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 defaults after suspend. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744753: Fix for anacron (running on resume under systemd)
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
Bug#779370: hdparm + systemd: old apm/pm-utils hooks not working/migrated
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 visible defaults like this:
# avoid excessive hard disk load-cycling
ata-* {
apm = 254
}
Maybe apm_on_battery and apm_on_ac settings?
And have those defaults switched on state changes.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779370:
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 hdparm rules). After=suspend.target After=hibernate.target After=hybrid-sleep.target [Service] Type=oneshot ExecStart=/sbin/udevadm trigger --action=change --subsystem-match=block [Install] WantedBy=suspend.target WantedBy=hibernate.target WantedBy=hybrid-sleep.target -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726390: switch to upstream udev rules
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 changed. Many thanks to all for maintaining the package in the past and ongoing! Maybe it is possible to shed some light about the current state and the intentions of enabling upsteam's incremental/hotplug code (udev rules) in Debian? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726390: switch to upstream udev rules
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 watchdog functionality in the initramfs and regular startup scripts that degrades the arrays if they are not getting assembled. I found a related page that lists some points and pseudo code: https://wiki.ubuntu.com/ReliableRaid -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718217: lmt fails to run on resume from sleep, suspend, standby
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 file with something like this ... hibernate|suspend) if [ -e /etc/init.d/laptop-mode ] ; then invoke-rc.d laptop-mode stop fi ... works around the problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707226: [pkg-wine-party] package wine does not install wine on amd64
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 suffers from not being able to fulfill the dependency and simply hasn't put the workaround's (hello world message) in the right place yet. Sorry, I won't bother other packages' devs that are not in the position to throw in a debconf question in the right place, to make sure all *admins* are getting informed properly. Nevermind, as an admin I reported the issue after having gone through troubles, and it is the pkg-wine-party decision to appreciate it or not. The thing is as simple as package wine does not install wine on amd64. Install time informations would surely be appreciated if only an incomplete installation happened. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707226: [pkg-wine-party] package wine does not install wine on amd64
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 bug open, to reflect the status and point other admins and users to the solution. Have a nice weekend. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707226: package wine does not insall wine on amd64)
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 not, and it was't helpfull. It seems rather misleading have a package that seems to be installed correctly but executing it will not produce its functionality. The dependecy is actually only fullfilled by providing the true wine functionality. Thus the suggestion to let the wine64-bin package execute a post-inst script or similar, to install the 32bit version, instead of pretending to be wine and delivering only a string. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707226: package wine does not insall wine on amd64)
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 later install would be possible (maybe through PackageKit), purposely triggering a failure and retry may be enough. but that is an intrusive change and it would be hard to ensure it would work (e.g. if the user has configured architecture-specific mirrors for apt); it seems better to me to just tell the user what to do, until i386 multiarch becomes the default for amd64... It isn't? Will this resolve the deps correctly instead of installing a fake wine64-bin? Since wine64-bin does not ensure wine will work at all, I would at least suggest to use a high priority debconf question to draw attention to it, if no automated solution is possible. (My reopen attempt did not work out. I think it wold be good to let the report open. When trying to figure out what the problem was I came accross a closed bug that mentioned this, but I was lead on, because it suggested wine64-bin fixed it.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707226: package wine does not insall wine on amd64)
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 priority debconf question/action/message, if the cross-arch dependecy can not yet be defined and fulfilled properly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707226: [pkg-wine-party] package wine does not install wine on amd64
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, before any actual attempt to execute the wine binary. Thus, the idea of letting the packet managment script provide the message. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707226: [pkg-wine-party] package wine does not install wine on amd64
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 a debian wine package that does not install the files that the package claims to fulfill the dependency for? Pushing patches upstream instead of providing a package with a fixed workaround until the cross-arch dependecy can be properly resolved? With humor it can give a good laugh. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707226: package wine does not insall wine on amd64
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:amd64 package that does actually pull in wine-bin:i386 package. If i386 is not enabled, these are the steps such a script needs to perform: dpkg --add-architecture i386 apt-get update apt-get install wine-bin:i386 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702996: please mention/provide upgrade path from gnome to xfce
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 especially for people in the world where only older hardware is available. The method: * removing gnome aptitude purge `dpkg --get-selections | grep gnome | cut -f 1` aptitude -f install aptitude purge `dpkg --get-selections | grep deinstall | cut -f 1` aptitude -f install * dist-upgrade * installing xfce4 aptitude install xfce4 (or xfce4-desktop) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678834: permission fix for public shares
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 is not defined in the configuraiton.) Adjusting a default in this way also seems to be the easiest of the options. I did not experience interference with manually defined shares, but if there is a possibility to define it as a default that applies only to usershares (maybe a template file?) that might be an option as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678834: permissions of shared directory
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 inherit permissions = yes in the [global] section. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661230: use nopasswdlogin group (empty passwords break things)
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683058: closed by Ansgar Burchardt ans...@debian.org (Re: ftp.debian.org: please create an empty wheezy-updates repository)
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.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683765: [Pkg-xfce-devel] Bug#683765: default umask gets overidden
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 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.org/DebianDesktopHowTo) Executed in an xfce-terminal or xterm: ~$ umask 0022 while a text console gives a correct: ~$ umask 0002 (as set by pam_umask.so usergroups) How do you start Xfce? Can you try to put an xterm in .xsession and see what umask you get there? Regards, -- Yves-Alexis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683815: gdm overrides system's default umask
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_umask according to http://wiki.debian.org/DebianDesktopHowTo) Executed in an xterm called directly from ~/.xsession ~$ umask 0022 while a text console gives a correct: ~$ umask 0002 (as set by pam_umask.so usergroups) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683765: default umask gets overidden
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.org/DebianDesktopHowTo) Executed in an xfce-terminal or xterm: ~$ umask 0022 while a text console gives a correct: ~$ umask 0002 (as set by pam_umask.so usergroups) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683058: codename urls that enable proper next-stable sources.list
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 may be appropriate) for the next-stable codename (wheezy), and include this step into the release cycling procedure? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678834: usable configurations for guest-writable public samba shares
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 as sambaguest and belonging to the users group (rw for all users if they have local access to the path) (should work for usershares) let samba guests create files in the name of the user who created the user share (and belonging to the sambaguest group) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678834: guest users create locally inaccessible files owned by nobody
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, samba has the information who created the share, thus it could use that when samba guests are creating files. Ideally, the file could still be identifiable to the samba guest with its group ownership set to samba-guest. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678616: [Pkg-samba-maint] Bug#678616: default guest user nobody
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 using net usershare directly.) To avoid permission hassle and giving out of passwords, guest write access may be granted. (Could be in a temporary setup or in a secure environment.) What happens now is, the samba guest saves a file in the public share, and no user (but the literal nobody) has access to the file (not even the user that created the share). However, not providing a proper default guest mapping probably breaks all default installs quite into pieces, not only usershare setups. As the nobody user and nogroup should by definition not contain any real members, I don't think the old default serves anybody. Just because the default is not well chosen everybody has to stumble over the problem, find a guest mapping and adjust the smb.conf, that is otherwise working very well for out of the box usershare creation now, thanks to your latest adaption! IMHO dropping privileges to, and becoming nobody may make sense for part of (network) deamons that don't create files, to shield real data from them, but not for a file server with the objective to write files on behalf of users. Any admin is entitled to do whatever customization suits his|her needs and, Of course, but it does not mean that debian should not come with a solid default configuration. I believe we have come a long way towards a robust default already, please think about tacking the last thing as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678615: users group is empty
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 has the same consistent setup and meaning whether user(private)groups are used or not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678616: default guest user nobody
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 files created by samba guest users. May I suggest to introduce a proper samba-guest user and default to create files of guests on the local filesystem as samba-guest and the (general) users group. (with the default umask 002) As all real users are supposed to be in the users group this should give users full access to the files locally just as through samba. While at the same time the files are still inaccessible to potentially vulnerable (system user) deamon processes. NB: Bug #678615 (users group is empty) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672523: please include preserve /home functionality
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 clean debian install, from another distro, an unsupported release, or otherwise unclean or corrpted system in a single filesystem setup (those getting more common with btrfs?). And this even seems to suggest there might already exist debian-installer patches: https://wiki.edubuntu.org/komputes/HowToDebianInstallerPreserveHome I don't really see where this page suggests this. It gives a step by step method, using the manual partitioning methodwhich I think is logical for such purpose. Yes, as the spec stated the UI difference is rather subtle. The debian-installer message one can see on that page is: The file system on /dev/sda1 assigned to / has not been marked for formatting. Directories containing system files (/boot, /etc, /usr, /var, ...) that already exist under any defined mountpoint will be deleted during the install. However, when I tried this with the squeeze debian-installer, it told me the targed is unclean and warned about possible conflicts, which will of course occur if the old system files are not deleted. (Clearly a different behavior.) What exactly would you like to see changed? I would like to see the same system files will be deleted behavior in debian. From the screen shots it seems some patches should already exist for the debian-installer to support this, but my tests showed they are not applied in debian. I have looked for a repo where the patches may be available, but could not locate them. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672497: [Pkg-samba-maint] Bug#672497: Bug#672497: full support for usershares (public shares)
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 problems to connect, even if a share is explicitly set to be public. The bad user mapping seems needed to make public shares work effectively in all setups I know. (Of course no no public shares are set up by default.) Map to guest should introduce no new risk vector, because clients could always just try the nobody account directly. Do we really want to change upstream defaults for our default installs to make it easier to enable a functionality that makes sense mostly for desktop users? Many server setups may not use local user accounts at all. Nevertheless, it should be safer to run processes and shares under a restricted user account than with root permissions. Also note that, in order for a local user to be able to create a share at all, the user must first be added to the sambashare group. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672614: please include --drop-cache option
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 system as the ram gets filled up. http://insights.oetiker.ch/linux/fadvise.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672497: [Pkg-samba-maint] Bug#672497: full support for usershares (public shares)
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
Bug#672497: [Pkg-samba-maint] Bug#672497: full support for usershares (public shares)
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 again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672497: full support for usershares (public shares)
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 funtionality, one still needs to add the following settings manually: usershare allow guests = yes map to guest = bad user As the system shares defined in the default config have explicit guest ok = no lines, it looks to me that it should not produce a problem to add these settings to the default global section, or define them at compile time. Nevertheless, to limit the sharing to files owned by the creator of a share, the following may be a suitable default: usershare owner only = yes Please, adjust the defaults for full support for usershares. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672523: please include preserve /home functionality
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 full harddisks to the next release. (Especially if you will also need to change the desktop environment, to maintain the uability. Then you can get rid of the old DE by only installing the new one.) The preserve /home functionallity has been used with ubuntu for quite some time now. The spec can be found here: https://wiki.ubuntu.com/UbiquityPreserveHome And this even seems to suggest there might already exist debian-installer patches: https://wiki.edubuntu.org/komputes/HowToDebianInstallerPreserveHome -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672497: [Pkg-samba-maint] Bug#672497: full support for usershares (public shares)
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, because it does not require to enter my valid userdata into unknown computers. (I found the owner only option I mentioned is already the upstream default, so no change there.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672539: RFP: thunar-shares-plugin -- samba usershare support for thunar filemanager (XFCE)
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 recent versions. http://comments.gmane.org/gmane.comp.desktop.xfce.devel.version4/19650 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672539: RFP: thunar-shares-plugin -- samba usershare support for thunar filemanager (XFCE)
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.net/linuxmint/+bug/997594 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
