[arch-general] BTRFS, a good choice for /?
Hi, After true multilib support came for arch, I reformatted / as jfs to install arch64. But somehow, I feel my system is slow (in spite of regular fscks on every ten mounts and using deadline scheduler) as compared to arch32 & ext4. I'm thinking of using btrfs on /, is it stable to the extent that I can use it on /? I guess a lot of you guys are using it here? -- Regards, Nilesh Govindarajan Facebook: http://www.facebook.com/nilesh.gr Twitter: http://twitter.com/nileshgr Website: http://www.itech7.com VPS Hosting: http://www.itech7.com/a/vps
Re: [arch-general] Old "news"
On Wed, Sep 22, 2010 at 12:05 PM, 甘露(Gan Lu) wrote: > On Wed, Sep 22, 2010 at 2:31 PM, Mike Sampson wrote: >> On Wed, Sep 22, 2010 at 4:28 PM, jesse jaara wrote: >>> Did anyone else revice some old maiöing list messages i got few about >>> xorg1.8 miving to extra and announment if 2010.5 install meedia and some >>> others >>> >> >> Yeah, me too. > My RSS reader listed 10 new "old" news too. >> >> Mike >> > I got all of them in mail from arch-announce :/ -- Regards, Nilesh Govindarajan Facebook: http://www.facebook.com/nilesh.gr Twitter: http://twitter.com/nileshgr Website: http://www.itech7.com VPS Hosting: http://www.itech7.com/a/vps
Re: [arch-general] Old "news"
On Wed, Sep 22, 2010 at 2:31 PM, Mike Sampson wrote: > On Wed, Sep 22, 2010 at 4:28 PM, jesse jaara wrote: >> Did anyone else revice some old maiöing list messages i got few about >> xorg1.8 miving to extra and announment if 2010.5 install meedia and some >> others >> > > Yeah, me too. My RSS reader listed 10 new "old" news too. > > Mike >
Re: [arch-general] Old "news"
On Wed, Sep 22, 2010 at 4:28 PM, jesse jaara wrote: > Did anyone else revice some old maiöing list messages i got few about > xorg1.8 miving to extra and announment if 2010.5 install meedia and some > others > Yeah, me too. Mike
[arch-general] Old "news"
Did anyone else revice some old maiöing list messages i got few about xorg1.8 miving to extra and announment if 2010.5 install meedia and some others
[arch-general] speeding up udev (from wiki)
Are a lot of you using (or not using) the suggestions from the "Speeding up Udev" article? I just tried it by replacing all occurrences of load-modules.sh in /etc/udev/rules.d/*.rules and /lib/udev/rules.d/*.rules with modprobe itself, and implemented blacklisting by adding install MODNAME /bin/false to modprobe.conf. This has sped up boot for me considerably. Has anyone had a bad experience with this method?
Re: [arch-general] How do AUR packages get new maintainers?
On 21-09-2010 23:17, Matthew Gyurgyik wrote: On 09/21/2010 04:53 PM, David C. Rankin wrote: Guys, I've seen recent "Request to Ophan package XYZ" posts, and I've found some fairly large AUR packages that are orphaned (like RPM5). But, how do AUR packages get new maintainers? Does somebody monitor the orphans and then divvy them out among those with write privileges in AUR or does somebody have to say I'll take package X on? http://wiki.archlinux.org/index.php/AUR Really dude? You've been using arch for how long and still have these elementary questions? Think about you questions and try to find answer before you post to the list. Alternatively hire an arch tutor. And who on earth are you?
Re: [arch-general] How do AUR packages get new maintainers?
>> http://wiki.archlinux.org/index.php/AUR >> >> Really dude? You've been using arch for how long and still have these >> elementary questions? I think that was not the OP question (considering his long time participation in the community), but something like "Is there any policy to take care of orphaned packages?" (i.e., periodic cleanups and such...). -- == Ivan Sichmann Freitas Engenharia de Computação 2009 UNICAMP http://identi.ca/ivansichmann Grupo Pró Software Livre UNICAMP - GPSL ==
Re: [arch-general] Any special reason for /etc/shadow.pacnew, or just normal pacman behavior.
On 09/21/2010 04:02 PM, David C. Rankin wrote: Guys, I always diff any new .pacnew files when they are created during an update. Today I got /etc/shadow.pacnew which was a little surprising given that replacing shadow would be bad. The diff showed that the .pacnew entries were already in shadow (except for the root password of course) So this is just normal expected behavior by pacman right? shadow was there, pacman new it, so the new file was just installed as .pacnew. Anything else there I need to look at? Thanks. It's nothing major, the last modified date for each password was set from the future (99) to the past...
Re: [arch-general] How do AUR packages get new maintainers?
On 09/21/2010 06:17 PM, Matthew Gyurgyik wrote: On 09/21/2010 04:53 PM, David C. Rankin wrote: Guys, I've seen recent "Request to Ophan package XYZ" posts, and I've found some fairly large AUR packages that are orphaned (like RPM5). But, how do AUR packages get new maintainers? Does somebody monitor the orphans and then divvy them out among those with write privileges in AUR or does somebody have to say I'll take package X on? http://wiki.archlinux.org/index.php/AUR Really dude? You've been using arch for how long and still have these elementary questions? Think about you questions and try to find answer before you post to the list. Alternatively hire an arch tutor. EDIT: Think about your questions and try to find an answer before you post to the list.
Re: [arch-general] How do AUR packages get new maintainers?
On 09/21/2010 04:53 PM, David C. Rankin wrote: Guys, I've seen recent "Request to Ophan package XYZ" posts, and I've found some fairly large AUR packages that are orphaned (like RPM5). But, how do AUR packages get new maintainers? Does somebody monitor the orphans and then divvy them out among those with write privileges in AUR or does somebody have to say I'll take package X on? http://wiki.archlinux.org/index.php/AUR Really dude? You've been using arch for how long and still have these elementary questions? Think about you questions and try to find answer before you post to the list. Alternatively hire an arch tutor.
Re: [arch-general] How do AUR packages get new maintainers?
Hello David, If you're logged in to the AUR, any package with an orphan status will have an "Adopt Packages" button on its page. 2010/9/21 David C. Rankin : > Guys, > > I've seen recent "Request to Ophan package XYZ" posts, and I've found > some > fairly large AUR packages that are orphaned (like RPM5). But, how do AUR > packages get new maintainers? Does somebody monitor the orphans and then divvy > them out among those with write privileges in AUR or does somebody have to say > I'll take package X on? > > -- > 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 > -- msn: stefan_wilk...@hotmail.com e-mail: stefanwilk...@gmail.com blog: http://www.stefanwilkens.eu/ adres: Lipperkerkstraat 14 7511 DA Enschede
[arch-general] How do AUR packages get new maintainers?
Guys, I've seen recent "Request to Ophan package XYZ" posts, and I've found some fairly large AUR packages that are orphaned (like RPM5). But, how do AUR packages get new maintainers? Does somebody monitor the orphans and then divvy them out among those with write privileges in AUR or does somebody have to say I'll take package X on? -- 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
Re: [arch-general] Any special reason for /etc/shadow.pacnew, or just normal pacman behavior.
On Tue, Sep 21, 2010 at 16:02, David C. Rankin wrote: > Guys, > > I always diff any new .pacnew files when they are created during an > update. See "man pacman", under HANDLING CONFIG FILES. It explains the behavior in detail.
Re: [arch-general] [signoff] kernel26 2.6.35.5-1
On Tue, 21 Sep 2010 15:44:52 +0200 Tobias Powalowski wrote: > Latest kernel is in testing, > please signoff for both arches. > > greetings > tpowa Signoff i686 lvm/encrypt this kernel fixes Alan's[1] big sata_sil breakage, making my system boot again. ( see https://bugzilla.kernel.org/show_bug.cgi?id=16606 ) Dieter [1] Alan (Cox) broke it.
[arch-general] Any special reason for /etc/shadow.pacnew, or just normal pacman behavior.
Guys, I always diff any new .pacnew files when they are created during an update. Today I got /etc/shadow.pacnew which was a little surprising given that replacing shadow would be bad. The diff showed that the .pacnew entries were already in shadow (except for the root password of course) So this is just normal expected behavior by pacman right? shadow was there, pacman new it, so the new file was just installed as .pacnew. Anything else there I need to look at? Thanks. -- 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
Re: [arch-general] [signoff] kernel26 2.6.35.5-1
On 09/21/2010 04:44 PM, Tobias Powalowski wrote: Latest kernel is in testing, please signoff for both arches. greetings tpowa signoff x86_64 -- Ionuț
Re: [arch-general] [signoff] kernel26 2.6.35.5-1
On 09/21/10 at 03:44pm, Tobias Powalowski wrote: > Latest kernel is in testing, > please signoff for both arches. > > greetings > tpowa > -- > Tobias > Powalowski > Archlinux Developer & Package Maintainer > (tpowa) > http://www.archlinux.org > tp...@archlinux.org > Sign off x84_64 w/ Encrypted/LVM
[arch-general] [signoff] kernel26 2.6.35.5-1
Latest kernel is in testing, please signoff for both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
[arch-general] [signoff] kernel26-lts 2.6.32.22-1
Latest kernel is in testing, please signoff for both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
[arch-general] Local Mirror - Wiki Article
Since the other thread is huge and hard to follow, I am creating a new
thread.
I would like to use this thread to talk strictly about the Local Mirror
wiki article.
I have updated the wiki article to reflect the new pool directory.
Currently there are some packages that are in pool/ while others are still
in {$repo}/os/${arch}. Those in pool have symlinks to {$repo}/os/${arch}
>From my understanding, eventually, all packages will be in pool/
http://wiki.archlinux.org/index.php/Local_Mirror
I am hoping someone who runs a Local Mirror can try this out. I do not
have a need for a local mirror nor do I want to pull Gigs of data from a
mirror to test this. However, I have done dry runs on the rsync command.
@Devs: Maybe someone can update the Mirror Section in the NewMirrors wiki
article
http://wiki.archlinux.org/index.php/DeveloperWiki:NewMirrors#Mirror_size
Re: [arch-general] Repo Structure - Pool Dir
On 09/21/2010 01:31 PM, Matthew Gyurgyik wrote: Hello. Currently I see that there are some packages in /archlinux/extra/os/i686/ and some symlinks to ../../../pool/packages/. I was hoping a dev would be able to answer the following the questions? Eventually, will all packages (from core/extra/community) end up in pool? Repos like multilib, gnome-unstable, kde-unstable will not end up, right? Thanks, ~pyther this is the new layout. all new packages are copied in pool directory to avoid synchronizing again the mirrors once they are moved from a repo to another. this way, when packages are moved, mirrors have to synchronize only the new symlinks location pool/packages contain packages for core/extra/testing/gnome-unstable/kde-unstable/staging and pool/community the other repos available -- Ionuț
[arch-general] Repo Structure - Pool Dir
Hello. Currently I see that there are some packages in /archlinux/extra/os/i686/ and some symlinks to ../../../pool/packages/. I was hoping a dev would be able to answer the following the questions? Eventually, will all packages (from core/extra/community) end up in pool? Repos like multilib, gnome-unstable, kde-unstable will not end up, right? Thanks, ~pyther
