Re: [arch-general] Totem leaves dvd mounted after quitting
Excerpts from David C. Rankin's message of 2010-06-29 07:05:04 +0200: Guys, This may be normal, but I thought we had moved beyond having to manually unmount CD/DVDs after use -- so I have either messed something up or there is a lingering problem. The setup - new i686 install updated through today. I never watch DVDs on the computer, but my son wanted to watch one and his sister had my laptop watching another movie on it, so I set his box up to watch DVDs using totem in gnome. After gathering all the dvdread/nav/etc.. all played just fine on his nvidia 9600 card and the nvidia 256.35-1 module. The problem occurred after I stopped the dvd and then exited totem. When I tried to eject the DVD, it wouldn't -- the drive was still mounted (confirmed with mount). Unmounting the drive fixed the problem, but I was left wondering -- surely we shouldn't be still stuck with manually unmounting DVDs in Gnome?? This being the first DVD I've tried to play, I didn't know, so I thought I would put it out to the community for a quick answer and try to figure out if this was something that needs reporting. Bug? Wow, even after quitting? I know at least one app that behaves badly in a similar way, aqualung, which prevents you from ejecting CDs or anything else in the drive while the app is running, even if you don't access it. So what I'd look for is some totem, or related, process that keeps running, despite you quitting totem. I've had this problem with a couple of apps in the past, but usually with no, or the consequence of not being able to restart the app, because it's still 'running'. HTH -- Regards, Philipp -- Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen. Bertolt Brecht, Der gute Mensch von Sezuan
Re: [arch-general] Finally found a solution to slow USB on HAL
Excerpts from Nilesh Govindarajan's message of 2010-06-29 05:27:42 +0200: On 06/29/2010 05:44 AM, Ross wrote: On 29/06/10 08:52, Philipp Überbacher wrote: Excerpts from Denis A. Altoé Falqueto's message of 2010-06-28 18:33:30 +0200: On Mon, Jun 28, 2010 at 1:21 PM, Pálffy András Gergely pagesai...@gmail.com wrote: Works here too. Great, thanks. On Mon, Jun 28, 2010 at 1:25 PM, Nilesh Govindarajanli...@itech7.comwrote: I have made a patch for /usr/share/hal/fdi/20-storage-methods.fdi to force async file transfer for vfat filesystems by commenting out flush and sync as valid options from the list. I checked the thing, now I'm getting the old high speed USB transfer. Do take a look at it, and comment. Yes, but you should keep in mind that you'll spend extra time when you want to unmount your USB stick. So I prefer a slow transfer and a fast unmount, because usually I'm in hurry for taking off the USB drive and the unmounting visualizations are not very smart (only in KDE SC 4.4 it is really usable). Actually I was recently wondering a bit about the unmounting part, especially with USB sticks. I do have udev rules, taken from the wiki, in place that handle automatic mounting. There's also a unmounting part, which afair removes created dirs, but I guess this is only called after the usb drive is removed. It did happen more than once to me that a file transfer seemed to be complete, but when I just removed the drive, the data was gone. Is there a way to provide automatic safe removal? Manual unmounting is a bit of a PITA, as you need to have a terminal ready, guess sdN and type a line, where the device guessing part is the most problematic. I tend to use /dev/sdN to make sure that I remove the device from all mount points. Thanks for any advice. I am no expert and am probably missing something here, but it should be simple to create a desktop icon and/or menu option to issue the sync command. That way you could have the speed of asynchronous mount and clicking the icon or menu option before removing the drive will write any buffered data to the device to prevent data loss if removing the device without umounting. As the sync command syncs all mounted drives you don't need to provide the /dev/sdN. Ross. Yeah exactly ! After copy your data to the drive, run the sync command or setup a keyboard shortcut for it :-) This will give you high speed transfer along with no data loss \m/ But if you're very forgetful to remove the drive without pressing the keyboard shortcut for sync, then you're in trouble and this patch is not for you. Alternatively, you could write a bash daemon as per this tutorial: http://j.mp/9DRWOF which will check for a usb stick's existence and if its mounted, sync every 15-30 seconds. Heh, I didn't even know about the sync command and not about the difference between sync/async either. Guess I'll have to check my mount options and udev rules. The bash daemon tutorial thing looks handy and simple enough too, so thanks! -- Regards, Philipp -- Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen. Bertolt Brecht, Der gute Mensch von Sezuan
Re: [arch-general] Last Updates w/kernel 2.6.33.4-1 - 2.6.34-2 broke radeon driver for RS690M cards
On Tue, Jun 29, 2010 at 1:15 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: On 06/28/2010 04:44 AM, Damien Churchill wrote: On 28 June 2010 10:35, Paul Ezvanp...@ezvan.fr wrote: Le dimanche 27 juin 2010 à 13:19 -0500, David C. Rankin a écrit : Guys, Just updated my laptop's spare drive and something in the last set up updates, which included the kernel, really affected the radeon driver badly. It's almost like I am back running in framebuffer mode. I'm not quite sure where to start troubleshooting as I am not familiar at all with the changes kms introduced into the radeon driver soup, but I suspect that may be where the problem lies. I have no xorg.conf, so if there are config issues, it's with the default config. [...] [ 37.526] is imortant (WW) RADEON(0): Direct rendering disabled [ 37.526] (II) RADEON(0): Acceleration disabled Last time I had this problem with a radeon card, it was because of a missing firmware (R700rlc in my case). Maybe you should search in this direction ? The linux-firmware package now contains all the required firmware for drivers now, IIRC. Thanks Paul, Damien C. Anthony: At least we have narrowed it down some. I'll look for some stray firmware, but for the past 1.5 years with the same laptop, I have never needed any additional firmware for this ATI x1200 card (RS690M chip). I don't put it past being a problem with the firmware in the kernel or somewhere in the new packages. As part of the troubleshooting, I will probably need to downgrade to the last set of packages and kernel. What's the best way to downgrade the kernel? Is this a 'pacman -Sf' issue or a 'pacman -Uf' issue? I still have the old kernel packages on my box that I can reinstall locally if that changes the equation any. Thanks for any help you can give. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com So do i!BUMP
Re: [arch-general] Bashification of initscripts for moderate speedup
Le lundi 28 juin 2010 à 17:55 +0200, Lukáš Jirkovský a écrit : Actually I see the point of doing this. Arch is a modern distribution with the newest software around so why stuck with shell constructs which are probably dozens of years old? Lukas Yes. I definitely agree. We have to pray that a dev is interested in the patch now ;-) @Victor: You last commit that is supposed to fix whitespace mess in fact create a mess with whitespace. Also it changes all the modelines for vim: for example from # vim: set ft=sh sw=2 ts=2 et: to # vim: set ft=sh sw=4 ts=4 et: in fact, I would suggest that you revert your commit 59c7059e78491988c5d8d495c731fb66fe8f7224. It does not fix anything. check for yourself with git checkout bashification git diff master but git diff master HEAD~1 is clearly better
[arch-general] ffmpeg-23619-1-x86_64 corrupted?
Hi, I've been updating my ArchLinux system and have getting the following: f...@babili ~ % sudo reflector -l 6 -r -o /etc/pacman.d/mirrorlist sudo clyde -Syyu -a :: Synchronizing package databases... core 35,4K 80,9K/s 00:00:00 [##] 100% extra452,9K 79,4K/s 00:00:06 [##] 100% community377,3K 81,8K/s 00:00:05 [##] 100% :: Starting full system upgrade... :: Synchronizing AUR database... aur 33/ 33 [#] 100% resolving dependencies... looking for inter-conflicts... Targets (1): ffmpeg-23619-1 Total Download Size:0,00 MB Total Installed Size: 16,35 MB == Proceed with installation? [Y/n] y checking package integrity... :: File ffmpeg-23619-1-x86_64.pkg.tar.xz is corrupted. Do you want to delete it? [Y/n] Is there any problem with it?
Re: [arch-general] ffmpeg-23619-1-x86_64 corrupted?
ti., 29.06.2010 kl. 13.05 +0200, skrev F. Gr.: Hi, I've been updating my ArchLinux system and have getting the following: f...@babili ~ % sudo reflector -l 6 -r -o /etc/pacman.d/mirrorlist sudo clyde -Syyu -a :: Synchronizing package databases... core 35,4K 80,9K/s 00:00:00 [##] 100% extra452,9K 79,4K/s 00:00:06 [##] 100% community377,3K 81,8K/s 00:00:05 [##] 100% :: Starting full system upgrade... :: Synchronizing AUR database... aur 33/ 33 [#] 100% resolving dependencies... looking for inter-conflicts... Targets (1): ffmpeg-23619-1 Total Download Size:0,00 MB Total Installed Size: 16,35 MB == Proceed with installation? [Y/n] y checking package integrity... :: File ffmpeg-23619-1-x86_64.pkg.tar.xz is corrupted. Do you want to delete it? [Y/n] Is there any problem with it? I had the same problem. Redownloading solved it. Christoffer
Re: [arch-general] ffmpeg-23619-1-x86_64 corrupted?
On 06/29/2010 02:05 PM, F. Gr. wrote: Hi, I've been updating my ArchLinux system and have getting the following: f...@babili ~ % sudo reflector -l 6 -r -o /etc/pacman.d/mirrorlist sudo clyde -Syyu -a :: Synchronizing package databases... core 35,4K 80,9K/s 00:00:00 [##] 100% extra452,9K 79,4K/s 00:00:06 [##] 100% community377,3K 81,8K/s 00:00:05 [##] 100% :: Starting full system upgrade... :: Synchronizing AUR database... aur 33/ 33 [#] 100% resolving dependencies... looking for inter-conflicts... Targets (1): ffmpeg-23619-1 Total Download Size:0,00 MB Total Installed Size: 16,35 MB == Proceed with installation? [Y/n] y checking package integrity... :: File ffmpeg-23619-1-x86_64.pkg.tar.xz is corrupted. Do you want to delete it? [Y/n] Is there any problem with it? hmm i guess is my fault. i downgraded to the latest working version but i didn't bumped pkgrel. deleting and re-download it should do the job -- Ionuț
Re: [arch-general] Bashification of initscripts for moderate speedup
On Jun 29, 2010, at 5:55 AM, solsTiCe d'Hiver solstice.dhi...@gmail.com wrote: Le lundi 28 juin 2010 à 17:55 +0200, Lukáš Jirkovský a écrit : Actually I see the point of doing this. Arch is a modern distribution with the newest software around so why stuck with shell constructs which are probably dozens of years old? Lukas Yes. I definitely agree. We have to pray that a dev is interested in the patch now ;-) Thomas seemed moderatly interested. @Victor: You last commit that is supposed to fix whitespace mess in fact create a mess with whitespace. Also it changes all the modelines for vim: for example from # vim: set ft=sh sw=2 ts=2 et: to # vim: set ft=sh sw=4 ts=4 et: When it comes to whitespace, I do whatever indent-region and whitespace-cleanup tell me to. in fact, I would suggest that you revert your commit 59c7059e78491988c5d8d495c731fb66fe8f7224. It does not fix anything. check for yourself with git checkout bashification git diff master but git diff master HEAD~1 is clearly better
Re: [arch-general] Bashification of initscripts for moderate speedup
I have uploaded some shiny bootchart runs from booting with and without bashification on my laptop to http://bugs.archlinux.org/20006
Re: [arch-general] Bashification of initscripts for moderate speedup
On Tue, Jun 29, 2010 at 8:20 AM, Victor Lowther victor.lowt...@gmail.com wrote: On Jun 29, 2010, at 5:55 AM, solsTiCe d'Hiver solstice.dhi...@gmail.com wrote: Le lundi 28 juin 2010 à 17:55 +0200, Lukáš Jirkovský a écrit : Actually I see the point of doing this. Arch is a modern distribution with the newest software around so why stuck with shell constructs which are probably dozens of years old? Lukas Yes. I definitely agree. We have to pray that a dev is interested in the patch now ;-) Thomas seemed moderatly interested. @Victor: You last commit that is supposed to fix whitespace mess in fact create a mess with whitespace. Also it changes all the modelines for vim: for example from # vim: set ft=sh sw=2 ts=2 et: to # vim: set ft=sh sw=4 ts=4 et: When it comes to whitespace, I do whatever indent-region and whitespace-cleanup tell me to. Which is change the modelines? No thanks. http://wiki.archlinux.org/index.php/DeveloperWiki:Bash_Coding_Style -Dan
Re: [arch-general] Bashification of initscripts for moderate speedup
On Jun 29, 2010, at 9:27 AM, Dan McGee dpmc...@gmail.com wrote: On Tue, Jun 29, 2010 at 8:20 AM, Victor Lowther victor.lowt...@gmail.com wrote: On Jun 29, 2010, at 5:55 AM, solsTiCe d'Hiver solstice.dhi...@gmail.com wrote: Le lundi 28 juin 2010 à 17:55 +0200, Lukáš Jirkovský a écrit : Actually I see the point of doing this. Arch is a modern distribution with the newest software around so why stuck with shell constructs which are probably dozens of years old? Lukas Yes. I definitely agree. We have to pray that a dev is interested in the patch now ;-) Thomas seemed moderatly interested. @Victor: You last commit that is supposed to fix whitespace mess in fact create a mess with whitespace. Also it changes all the modelines for vim: for example from # vim: set ft=sh sw=2 ts=2 et: to # vim: set ft=sh sw=4 ts=4 et: When it comes to whitespace, I do whatever indent-region and whitespace-cleanup tell me to. Which is change the modelines? No thanks. http://wiki.archlinux.org/index.php/DeveloperWiki:Bash_Coding_Style I know we are getting into holy war territory here, but: Overall, they are sane, except for using tabs vs. spaces (at least with spaces it is never ambiguous how far you wanted a given indent to be in a world where tab does not always map to a set number of spaces), and 8 character indentation (leads to excessive horizontal scrolling in any moderatly complex nested flow control situation. I prefer 4 space indentation, it tends to align nicely with most flow control statements), and using the source keyword instead of . to source files (personal preference from also maintaining a package written in posix sh). We might want to steal some content from http://mywiki.wooledge.org/BashGuide/Practices to update the Arch bash coding page. -Dan
Re: [arch-general] Bashification of initscripts for moderate speedup
On Jun 28, 2010, at 11:36 AM, Isaac Dupree m...@isaac.cedarswampstudios.org wrote: On 06/28/10 09:35, Victor Lowther wrote: On Jun 28, 2010, at 7:42 AM, Caleb Cushing xenoterrac...@gmail.com wrote: On Sun, Jun 27, 2010 at 11:10 PM, Victor Lowther victor.lowt...@gmail.com wrote: Questions, comments, flames, etc. welcome. why go this way instead of the other? (clarification why go deeper into bash instead of trying to posix-ify the scripts) ...and the main source of slowdowns in the boot sequence is I/O based -- mounting filesystems and launching programs. IIRC, Busybox shell can get notable speed boost by incorporating versions of tools like sed into the same busybox executable, such that it often doesn't have to fork and load other short-lived programs. You can eliminate a fair number of trivial uses of grep, awk, and sed by using all of the parameter expansion modifiers that bash offers, and by using the native regex support from bash 3 and above. I made these changes wherever it seemed appropriate in my changes. (I believe it doesn't do bash-array-syntax.) -Isaac
Re: [arch-general] makepkg creates symlink to the package file
On Sat, Jun 26, 2010 at 2:29 AM, Attila vodoo0...@sonnenkinder.org wrote: At Samstag, 26. Juni 2010 07:38 Ray Rashif wrote: [1] http://www.mail-archive.com/pacman-...@archlinux.org/msg03794.html Thanks for this information. It seems that at no point it was thought about a config variable and therefore we have to live with it. this is all fine and dandy to me. however one little bug: PKGDEST=. makepkg will fail due the the fact that the real package will be overridden by the symlink. result is a circular symbolic link. makepkg should check for this [corner] case, and simply not create the link. i needed this for a script that automatically builds a package with the option to install and/or push to AUR. i wanted to sandbox it so it would not be affected by the user's makepkg.conf settings. workaround by making a dummy folder called out and sending the package there instead. C Anthony
Re: [arch-general] makepkg creates symlink to the package file
On Tue, Jun 29, 2010 at 1:20 PM, C Anthony Risinger anth...@extof.me wrote: On Sat, Jun 26, 2010 at 2:29 AM, Attila vodoo0...@sonnenkinder.org wrote: At Samstag, 26. Juni 2010 07:38 Ray Rashif wrote: [1] http://www.mail-archive.com/pacman-...@archlinux.org/msg03794.html Thanks for this information. It seems that at no point it was thought about a config variable and therefore we have to live with it. this is all fine and dandy to me. however one little bug: PKGDEST=. makepkg will fail due the the fact that the real package will be overridden by the symlink. result is a circular symbolic link. makepkg should check for this [corner] case, and simply not create the link. i needed this for a script that automatically builds a package with the option to install and/or push to AUR. i wanted to sandbox it so it would not be affected by the user's makepkg.conf settings. workaround by making a dummy folder called out and sending the package there instead. Wouldn't just setting PKGDEST to nothing instead of . cover this?
Re: [arch-general] Why no phonon in Qt
2010/6/29 Shridhar Daithankar ghodech...@ghodechhap.net: chromium 5 suppport h264 and 6 (if you want to go there) supports webm... I've read KDE 4.5 is supposed to have webkit support in konqueror so maybe that will work too. Why do I need yet another GTK browser when I am already tolerating firefox ? :) I also have kde-webkitpart installed so my konqueror and rekonq are at same level of webkit support, i.e. what is supported by Qt4.6. So that path is not a gain for now. You have to enable html5 by clicking the apropriate link in http://www.youtube.com/html5. I can see (some) Youtube videos in Chromium that way (Damjan is right, it is not available for all videos).
Re: [arch-general] makepkg creates symlink to the package file
On Tue, Jun 29, 2010 at 12:26 PM, Ray Kohler ataraxia...@gmail.com wrote: On Tue, Jun 29, 2010 at 1:20 PM, C Anthony Risinger anth...@extof.me wrote: On Sat, Jun 26, 2010 at 2:29 AM, Attila vodoo0...@sonnenkinder.org wrote: At Samstag, 26. Juni 2010 07:38 Ray Rashif wrote: [1] http://www.mail-archive.com/pacman-...@archlinux.org/msg03794.html Thanks for this information. It seems that at no point it was thought about a config variable and therefore we have to live with it. this is all fine and dandy to me. however one little bug: PKGDEST=. makepkg will fail due the the fact that the real package will be overridden by the symlink. result is a circular symbolic link. makepkg should check for this [corner] case, and simply not create the link. i needed this for a script that automatically builds a package with the option to install and/or push to AUR. i wanted to sandbox it so it would not be affected by the user's makepkg.conf settings. workaround by making a dummy folder called out and sending the package there instead. Wouldn't just setting PKGDEST to nothing instead of . cover this? beh, i thought you were onto something... i didn't look at the makepkg sources, but it is treating PKGDEST=' as if it was never set. so, no dice :-( however, if i use an absolute path (instead of .) it works alright. in fact, i seem to have general problems with trying to use relative paths as PKGDEST: == ERROR: You do not have write permission to store packages in ./pkg/out. Aborting... but i do of course. C Anthony
Re: [arch-general] Bashification of initscripts for moderate speedup
On Tue 29 Jun 2010 09:27 -0500, Dan McGee wrote: Which is change the modelines? No thanks. http://wiki.archlinux.org/index.php/DeveloperWiki:Bash_Coding_Style Neat. Where does the 132 columns come from?
Re: [arch-general] Bashification of initscripts for moderate speedup
On Tue, Jun 29, 2010 at 12:47 PM, Loui Chang louipc@gmail.com wrote: On Tue 29 Jun 2010 09:27 -0500, Dan McGee wrote: Which is change the modelines? No thanks. http://wiki.archlinux.org/index.php/DeveloperWiki:Bash_Coding_Style Neat. Where does the 132 columns come from? Back in the day of real physical terminals, they were typically made to display 80 columns on the screen. At some point, wide terminals came out, supporting 132 columns. I have no idea where the number came from, but both 80 and 132 are standard column widths used for normal and wide terminals.
Re: [arch-general] makepkg creates symlink to the package file
On 30 June 2010 01:38, C Anthony Risinger anth...@extof.me wrote: On Tue, Jun 29, 2010 at 12:26 PM, Ray Kohler ataraxia...@gmail.com wrote: On Tue, Jun 29, 2010 at 1:20 PM, C Anthony Risinger anth...@extof.me wrote: On Sat, Jun 26, 2010 at 2:29 AM, Attila vodoo0...@sonnenkinder.org wrote: At Samstag, 26. Juni 2010 07:38 Ray Rashif wrote: [1] http://www.mail-archive.com/pacman-...@archlinux.org/msg03794.html Thanks for this information. It seems that at no point it was thought about a config variable and therefore we have to live with it. this is all fine and dandy to me. however one little bug: PKGDEST=. makepkg will fail due the the fact that the real package will be overridden by the symlink. result is a circular symbolic link. makepkg should check for this [corner] case, and simply not create the link. i needed this for a script that automatically builds a package with the option to install and/or push to AUR. i wanted to sandbox it so it would not be affected by the user's makepkg.conf settings. workaround by making a dummy folder called out and sending the package there instead. Wouldn't just setting PKGDEST to nothing instead of . cover this? beh, i thought you were onto something... i didn't look at the makepkg sources, but it is treating PKGDEST=' as if it was never set. so, no dice :-( however, if i use an absolute path (instead of .) it works alright. in fact, i seem to have general problems with trying to use relative paths as PKGDEST: == ERROR: You do not have write permission to store packages in ./pkg/out. Aborting... but i do of course. PKGDEST=`pwd` makepkg I do that all the time. -- GPG/PGP ID: B42DDCAD
Re: [arch-general] makepkg creates symlink to the package file
C Anthony Risinger anth...@extof.me a écrit : beh, i thought you were onto something... i didn't look at the makepkg sources, but it is treating PKGDEST=' as if it was never set. so, no dice :-( however, if i use an absolute path (instead of .) it works alright. in fact, i seem to have general problems with trying to use relative paths as PKGDEST: == ERROR: You do not have write permission to store packages in ./pkg/out. Aborting... but i do of course. Maybe you could use PKGDEST=$(pwd) as a workaround? -- catwell
Re: [arch-general] Why no phonon in Qt
On Tuesday 29 June 2010 04:53:19 Shridhar Daithankar wrote: In general I use firefox only when I have to, because it does not integrate well with KDE and I really don't like GTK looks. try qtcurve... Bye...Frank
Re: [arch-general] makepkg creates symlink to the package file
On Tue, Jun 29, 2010 at 1:18 PM, Pierre Chapuis catw...@archlinux.us wrote: C Anthony Risinger anth...@extof.me a écrit : beh, i thought you were onto something... i didn't look at the makepkg sources, but it is treating PKGDEST=' as if it was never set. so, no dice :-( however, if i use an absolute path (instead of .) it works alright. in fact, i seem to have general problems with trying to use relative paths as PKGDEST: == ERROR: You do not have write permission to store packages in ./pkg/out. Aborting... but i do of course. Maybe you could use PKGDEST=$(pwd) as a workaround? yes this is what i did, thanks. just bringing up the fact that makepkg totally bombs with relative PKGDEST... with a permission error... makepkg must be changing the cwd internally. C Anthony
Re: [arch-general] makepkg creates symlink to the package file
On 30/06/10 06:08, C Anthony Risinger wrote: On Tue, Jun 29, 2010 at 1:18 PM, Pierre Chapuiscatw...@archlinux.us wrote: C Anthony Risingeranth...@extof.me a écrit : beh, i thought you were onto something... i didn't look at the makepkg sources, but it is treating PKGDEST=' as if it was never set. so, no dice :-( however, if i use an absolute path (instead of .) it works alright. in fact, i seem to have general problems with trying to use relative paths as PKGDEST: == ERROR: You do not have write permission to store packages in ./pkg/out. Aborting... but i do of course. Maybe you could use PKGDEST=$(pwd) as a workaround? yes this is what i did, thanks. just bringing up the fact that makepkg totally bombs with relative PKGDEST... with a permission error... makepkg must be changing the cwd internally. Use the bug tracker if you want that fixed.
Re: [arch-general] Licensing of Arch Wiki content
On Thu, 17 Jun 2010 23:19:09 +0200 Linas linas...@ymail.com wrote: I assume this ask to have GFDL CC-BY-SA content coexist at the wiki. The existing content can only be relicensed by its authors. The GFDL 1.3 gateway expired on August 1, 2009. I really need an answer on this as soon as possible. For new Wiki articles would it be OK to add a footer in the article stating that it is licensed under a CC license and not the GFDL? Any official word on this please from the Arch wiki admins or developers. If you're not willing to officially allow CC licenses could the 'override' paragraph I'm suggesting for new content only be all right? thanks, Ananda signature.asc Description: PGP signature
Re: [arch-general] Licensing of Arch Wiki content
On Tue, Jun 29, 2010 at 5:09 PM, Ananda Samaddar ana...@samaddar.co.uk wrote: On Thu, 17 Jun 2010 23:19:09 +0200 Linas linas...@ymail.com wrote: I assume this ask to have GFDL CC-BY-SA content coexist at the wiki. The existing content can only be relicensed by its authors. The GFDL 1.3 gateway expired on August 1, 2009. I really need an answer on this as soon as possible. For new Wiki articles would it be OK to add a footer in the article stating that it is licensed under a CC license and not the GFDL? Any official word on this please from the Arch wiki admins or developers. If you're not willing to officially allow CC licenses could the 'override' paragraph I'm suggesting for new content only be all right? I honestly don't know who is going to reply to you. If you were to just change the license I also don't think you'd have anyone come after you anytime soon. Who is in charge of the wiki these days I'm not sure, but I'd try to get someone's attention besides mine- maybe Pierre or Aaron would be the right guys. -Dan
Re: [arch-general] Licensing of Arch Wiki content
On Tue, Jun 29, 2010 at 5:30 PM, Dan McGee dpmc...@gmail.com wrote: On Tue, Jun 29, 2010 at 5:09 PM, Ananda Samaddar ana...@samaddar.co.uk wrote: On Thu, 17 Jun 2010 23:19:09 +0200 Linas linas...@ymail.com wrote: I assume this ask to have GFDL CC-BY-SA content coexist at the wiki. The existing content can only be relicensed by its authors. The GFDL 1.3 gateway expired on August 1, 2009. I really need an answer on this as soon as possible. For new Wiki articles would it be OK to add a footer in the article stating that it is licensed under a CC license and not the GFDL? Any official word on this please from the Arch wiki admins or developers. If you're not willing to officially allow CC licenses could the 'override' paragraph I'm suggesting for new content only be all right? I honestly don't know who is going to reply to you. If you were to just change the license I also don't think you'd have anyone come after you anytime soon. Who is in charge of the wiki these days I'm not sure, but I'd try to get someone's attention besides mine- maybe Pierre or Aaron would be the right guys. I was also waiting for someone more knowledgeable with regards to the wiki. If it's my say-so you want, I don't see a problem with adding *additional* content under CC. But switching all *existing* content to CC might be a problem. Is this sufficient?
Re: [arch-general] Licensing of Arch Wiki content
On Tue, 29 Jun 2010 17:56:39 -0500 Aaron Griffin aaronmgrif...@gmail.com wrote: I was also waiting for someone more knowledgeable with regards to the wiki. If it's my say-so you want, I don't see a problem with adding *additional* content under CC. But switching all *existing* content to CC might be a problem. Is this sufficient? Not really, I'm wanting to adapt a Gentoo document to Arch's needs. This document is CC by SA attribution licensed. The whole Wiki article would have to be under the same license and not the GFDL. The CC and GFDL licenses are not compatible. Would it be ok to add a footer paragraph to the Wiki article stating that the WHOLE article is CC licensed and to disregard the GFDL footer at the bottom? This would only be for new Wiki articles. I am not proposing re-licensing existing Wiki articles. thanks, Ananda signature.asc Description: PGP signature
Re: [arch-general] Licensing of Arch Wiki content
On Wed 30 Jun 2010 00:15 +0100, Ananda Samaddar wrote: On Tue, 29 Jun 2010 17:56:39 -0500 Aaron Griffin aaronmgrif...@gmail.com wrote: I was also waiting for someone more knowledgeable with regards to the wiki. If it's my say-so you want, I don't see a problem with adding *additional* content under CC. But switching all *existing* content to CC might be a problem. Not really, I'm wanting to adapt a Gentoo document to Arch's needs. This document is CC by SA attribution licensed. The whole Wiki article would have to be under the same license and not the GFDL. The CC and GFDL licenses are not compatible. Would it be ok to add a footer paragraph to the Wiki article stating that the WHOLE article is CC licensed and to disregard the GFDL footer at the bottom? This would only be for new Wiki articles. I am not proposing re-licensing existing Wiki articles. Just do it.
