Re: [arch-general] Is there a burning tool able to replace K3b?
On Tue, Jan 21, 2014 at 11:43 AM, Ralf Mardorf wrote: > Hi, > To stop a green drive spinning up and down again and again I removed > gvfs from my machine, but each time I used K3b seemingly a KDE thingy > makes my drive spin up and down again and again until I reboot. You can check whether k3b is starting some KDE4 service in the Service Manager in KDE System Settings [1]. If some service starts, you should be able to stop it there, too. Lukas [1] http://userbase.kde.org/System_Settings/Startup_and_Shutdown
Re: [arch-general] Is there a burning tool able to replace K3b?
Hussam Al-Tayeb wrote: > On Tuesday 21 January 2014 12:28:35 Joerg Schilling wrote: > > cdrtools- last release: yesterday ;-) > > Speaking of cdrtools, do you have some git or svn or something similar > repository of cdrtools so people can monitor development or do you > simply do release tarballs every so often? Development is done with SCCS. Once I have added network support for SCCS, there will be a public repository. Currently there is a tar archive every time a useful and consistent state has been reached. This is something that might be a problem with a public version control as there will be commits when a group of files are consistent but not necessarily the whole project. During the past 7 years, there was aprox. one tarball per month. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] Is there a burning tool able to replace K3b?
On Tuesday 21 January 2014 12:28:35 Joerg Schilling wrote: > cdrtools - last release: yesterday ;-) Speaking of cdrtools, do you have some git or svn or something similar repository of cdrtools so people can monitor development or do you simply do release tarballs every so often? signature.asc Description: This is a digitally signed message part.
Re: [arch-general] Is there a burning tool able to replace K3b?
On 01/21/2014 10:43 AM, Ralf Mardorf wrote: Hi, a short question but a long story, perhaps somebody could give some hints. To stop a green drive spinning up and down again and again I removed gvfs from my machine, but each time I used K3b seemingly a KDE thingy makes my drive spin up and down again and again until I reboot. Is anybody aware if developers of desktop environments care about things like green drives, optional vs hard dependencies? I also noticed that if using a desktop environment's GUI editor as root this could cause serious issues nowadays. Am I the only one who tries to get rid of desktop environments and the software, such as the desktop environment's editors? I'm experimenting with getting rid of Xfce and I'm testing Jwm at the moment, but generating the menu is PITA and to find good replacements for editors, file browsers etc. isn't easy. Does anybody know burning software that is nearly as comfortable as K3b is, but that doesn't need GNOME or KDE dependencies? Regards, Ralf Ralf... I've got an off the wall possible solution: The only thing that comes close to K3b is a program called "imgburn." The only bad news is that it is only available for Windows. The good news is that it works perfectly well in Wine. Just thouoght I'd throw that out there. I understand your position on installing libraries for desktops you have no intention of using. You should really re-consider though. KDE has some of the best open-source software out there, and in terms of disk space, it's really not a big deal. I've tried every disk burner out there. K3b is the only useful one that doesn't ruin several blank disks before finally getting it right. (brasero), and opens iso's directly through double clicks unlike some others (xfburn) All that being said, There is an option but there again...give it another consideration. Bill
Re: [arch-general] python-dbus upgrade 1.20-2 fails
On Tue, Jan 21, 2014 at 1:30 PM, Mark Lee wrote: > Salutations, > > Upgrading from python-dbus-1.20-1 to 1.20-2 on Arch Linux 64 bit fails > with the following error: > -- > error: failed to commit transaction (conflicting files) > python-dbus: > /usr/lib/python3.3/site-packages/dbus/__pycache__/__init__.cpython-33.pyc > exists in filesystem > python-dbus: > /usr/lib/python3.3/site-packages/dbus/__pycache__/_compat.cpython-33.pyc > exists in filesystem > python-dbus: > /usr/lib/python3.3/site-packages/dbus/__pycache__/_dbus.cpython-33.pyc > exists in filesystem > python-dbus: > /usr/lib/python3.3/site-packages/dbus/__pycache__/_expat_introspect_parser.cpython-33.pyc > exists in filesystem > python-dbus: > /usr/lib/python3.3/site-packages/dbus/__pycache__/_version.cpython-33.pyc > exists in filesystem > python-dbus: > /usr/lib/python3.3/site-packages/dbus/__pycache__/bus.cpython-33.pyc exists > in filesystem > python-dbus: > /usr/lib/python3.3/site-packages/dbus/__pycache__/connection.cpython-33.pyc > exists in filesystem > python-dbus: > /usr/lib/python3.3/site-packages/dbus/__pycache__/decorators.cpython-33.pyc > exists in filesystem > python-dbus: > /usr/lib/python3.3/site-packages/dbus/__pycache__/exceptions.cpython-33.pyc > exists in filesystem > python-dbus: > /usr/lib/python3.3/site-packages/dbus/__pycache__/lowlevel.cpython-33.pyc > exists in filesystem > python-dbus: > /usr/lib/python3.3/site-packages/dbus/__pycache__/proxies.cpython-33.pyc > exists in filesystem > python-dbus: > /usr/lib/python3.3/site-packages/dbus/__pycache__/service.cpython-33.pyc > exists in filesystem > python-dbus: > /usr/lib/python3.3/site-packages/dbus/__pycache__/types.cpython-33.pyc > exists in filesystem > python-dbus: > /usr/lib/python3.3/site-packages/dbus/mainloop/__pycache__/__init__.cpython-33.pyc > exists in filesystem > python-dbus: > /usr/lib/python3.3/site-packages/dbus/mainloop/__pycache__/glib.cpython-33.pyc > exists in filesystem > Errors occurred, no packages were upgraded. > -- > > Regards, > Mark > > -- > Mark Lee > > Same here, they were probably missing from the previous python-dbus package and were generated afterwards. These are now part of python-dbus, you can safely force the install: "sudo pacman -S --force python-dbus". Cheers, -- Maxime
[arch-general] python-dbus upgrade 1.20-2 fails
Salutations, Upgrading from python-dbus-1.20-1 to 1.20-2 on Arch Linux 64 bit fails with the following error: -- error: failed to commit transaction (conflicting files) python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/__init__.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/_compat.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/_dbus.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/_expat_introspect_parser.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/_version.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/bus.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/connection.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/decorators.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/exceptions.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/lowlevel.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/proxies.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/service.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/__pycache__/types.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/mainloop/__pycache__/__init__.cpython-33.pyc exists in filesystem python-dbus: /usr/lib/python3.3/site-packages/dbus/mainloop/__pycache__/glib.cpython-33.pyc exists in filesystem Errors occurred, no packages were upgraded. -- Regards, Mark -- Mark Lee
Re: [arch-general] Is there a burning tool able to replace K3b?
Simon Hanna wrote: > you can check the list of applications in the wiki [1] > No, you are not the only one who doesn't like GNOME, KDE, XFCE, ... > have you tried i3? > about replacement software: > try using command line tools, just search the link below for all sorts of > applications... > > cheers, > simon > > [1]: > https://wiki.archlinux.org/index.php/List_of_Applications#CD.2FDVD_burning_tools In general, it depends on what people like to do... xcdroast needs GNOME libraries and did not evolve since a while, but I added support for hidden audio tracks, when I added support for hidden tracks to cdrtools in January 2010. In general, one big problem is that _all_ GUIs for UNIX seem to have stopped development with respect to adding new features to support related features from cdrtools. It seems that Debian was very successfull when they started to attack cdrtools 10 years ago. I use cdrtools from command line... k3b may be the most actively developed GUI (with respect to features) besides the russion GUI that only works on Win-DOS. GUIs: k3b - no new version since January 2011 xcdroast- no new version since February 2010 brasero - insists in running as root thus insecure (GUIs should not have enhanced privileges) even though cdrtools manage priv separation Seems to have less features than xcdroast writing software: cdrkit - > 100 open bugs, no development since May 2007 cdrdao - no bugfix since 2009, no development since May 2005 dvd+rw-tools- no bugfix since Mach 2008, no development since Jan 2007 cdrskin - not ready for general use (no UDF, no DVD-video, audio deficient) cdrtools- last release: yesterday ;-) The question in general is: are people still interested in optical disks? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Re: [arch-general] Is there a burning tool able to replace K3b?
you can check the list of applications in the wiki [1] No, you are not the only one who doesn't like GNOME, KDE, XFCE, ... have you tried i3? about replacement software: try using command line tools, just search the link below for all sorts of applications... cheers, simon [1]: https://wiki.archlinux.org/index.php/List_of_Applications#CD.2FDVD_burning_tools 2014/1/21 Ralf Mardorf > Hi, > > a short question but a long story, perhaps somebody could give some > hints. > > To stop a green drive spinning up and down again and again I removed > gvfs from my machine, but each time I used K3b seemingly a KDE thingy > makes my drive spin up and down again and again until I reboot. > > Is anybody aware if developers of desktop environments care about things > like green drives, optional vs hard dependencies? > > I also noticed that if using a desktop environment's GUI editor as root > this could cause serious issues nowadays. > > Am I the only one who tries to get rid of desktop environments and the > software, such as the desktop environment's editors? > > I'm experimenting with getting rid of Xfce and I'm testing Jwm at the > moment, but generating the menu is PITA and to find good replacements > for editors, file browsers etc. isn't easy. > > Does anybody know burning software that is nearly as comfortable as K3b > is, but that doesn't need GNOME or KDE dependencies? > > Regards, > Ralf > >
[arch-general] Is there a burning tool able to replace K3b?
Hi, a short question but a long story, perhaps somebody could give some hints. To stop a green drive spinning up and down again and again I removed gvfs from my machine, but each time I used K3b seemingly a KDE thingy makes my drive spin up and down again and again until I reboot. Is anybody aware if developers of desktop environments care about things like green drives, optional vs hard dependencies? I also noticed that if using a desktop environment's GUI editor as root this could cause serious issues nowadays. Am I the only one who tries to get rid of desktop environments and the software, such as the desktop environment's editors? I'm experimenting with getting rid of Xfce and I'm testing Jwm at the moment, but generating the menu is PITA and to find good replacements for editors, file browsers etc. isn't easy. Does anybody know burning software that is nearly as comfortable as K3b is, but that doesn't need GNOME or KDE dependencies? Regards, Ralf
