Re: [arch-general] sudoers file change - not much on dev list - reason for changes?
> I find it interesting that upstream made a change/addition just to > accommodate for one distribution. Usually it's the distro that patches > things for their own benefit. > > Sorry. That was me.
Re: [arch-general] sudoers file change - not much on dev list - reason for changes?
> On 9/7/2010 1:22 AM, David C. Rankin wrote: >> Guys, >> >> Got the sudo update with the new sudoers file, Noticed new %sudo group >> designation along with the traditional %wheel: >> >> ## Uncomment to allow members of group sudo to execute any command >> # %sudo ALL=(ALL) ALL >> >> >> Any reason that we would want a sudo group instead of using wheel? >> > > The change happened here: > > http://www.sudo.ws/repos/sudo/diff/387719e52d0f/plugins/sudoers/sudoers > > Relevant part of the log: "and a %sudo line for debian." > > It seems "we" don't want or use a sudo group. > I find it interesting that upstream made a change/addition just to accommodate for one distribution. Usually it's the distro that patches things for their own benefit.
Re: [arch-general] sudoers file change - not much on dev list - reason for changes?
On 9/7/2010 1:22 AM, David C. Rankin wrote: Guys, Got the sudo update with the new sudoers file, Noticed new %sudo group designation along with the traditional %wheel: ## Uncomment to allow members of group sudo to execute any command # %sudo ALL=(ALL) ALL Any reason that we would want a sudo group instead of using wheel? The change happened here: http://www.sudo.ws/repos/sudo/diff/387719e52d0f/plugins/sudoers/sudoers Relevant part of the log: "and a %sudo line for debian." It seems "we" don't want or use a sudo group.
Re: [arch-general] sudoers file change - not much on dev list - reason for changes?
On 9/7/2010 9:25 PM, Mario Figueiredo wrote: As far as users (administrators) are concerned, the wheel group can be named anything and nobody will care. Those who still want to use the name "wheel" just need to change the sudoers file. And that's why this change was so unnecessary. An historic and innocuous reference is lost to one arbitrary decision. And with it the need to rewrite manuals, tutorials, and any other reference mater It wasn't a change, it was an addition. wheel still works.
Re: [arch-general] [arch-dev-public] cairo xcb backend
>> Fair enough, if enabling the xcb backend slows things down, especially >> if it is unmaintained so not likely to improve soon, we should remove >> it. >> It's a shame that awesome has to go but I'm sure the people using >> awesome know how to handle building from AUR/ABS and create a >> xcb-enabled cairo for it. > > If it was just an optional backend, I would leave it enabled. But the > fact is that the XCB backend replaces the Xlib version, resulting in > visual bugs and crashes. Have you tried --enable-xcb and --disable-xlib-xcb - this should keep the Xlib version as is, but still support the xcb version. I'd be willing to test this configuration if there's some reliable way to invoke the fore mentioned crashes. I don't usually use Seamonkey or Thunderbird, and my Firefox is a tarball download from Mozilla.com -- damjan
Re: [arch-general] distributed bugtracking?
On Wed, Sep 8, 2010 at 12:47 PM, Dieter Plaetinck wrote: > anyone knows this? http://bugseverywhere.org/be/show/HomePage > > the concept looks great, although i don't know anything about the > implementation/usage. There's quite a few things out there with this same idea: - Ditz (http://ditz.rubyforge.org/) - TicGit (http://wiki.github.com/schacon/ticgit/) - git-issues (http://github.com/jwiegley/git-issues) ...etc. I love the idea of distributed bug tracking, but haven't really messed around with too many of them myself to offer more of an opinion. They've been around for a while though. -- Aaron "ElasticDog" Schaefer
[arch-general] [PATCH] rc.sysinit: condense calls to mkdir and chmod
---
rc.sysinit |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index f7df48c..bee4efb 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -276,8 +276,7 @@ stat_busy "Removing Leftover Files"
: >| /var/run/utmp
/bin/chmod 0664 /var/run/utmp
# Keep {x,k,g}dm happy with xorg
-/bin/mkdir /tmp/.ICE-unix && /bin/chmod 1777 /tmp/.ICE-unix
-/bin/mkdir /tmp/.X11-unix && /bin/chmod 1777 /tmp/.X11-unix
+/bin/mkdir -m1777 /tmp/.{X11,ICE}-unix
stat_done
#status "Updating Shared Library Links" /sbin/ldconfig
--
1.7.2.3
Re: [arch-general] distributed bugtracking?
On Wed, Sep 8, 2010 at 3:24 PM, Philipp Überbacher wrote: > Excerpts from Dieter Plaetinck's message of 2010-09-08 21:47:40 +0200: >> anyone knows this? http://bugseverywhere.org/be/show/HomePage >> >> the concept looks great, although i don't know anything about the >> implementation/usage. >> >> other then the advantages they list, I think something like this can be >> useful for downstream<->upstream communication. (ie someone reports a >> bug in the distro bugseverywhere, they can then more easily forward the >> bugs to upstream when needed) >> i blogged about stuff like this @ >> http://dieter.plaetinck.be/what_the_open_source_community_can_learn_from_devops >> if anyone cares. >> >> Dieter > > Hi Dieter, > just another distributed bug tracking system: > http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki > > It's also a DVCS and whatnot. What I wonder about is how it compares to > git when it comes to the DVCS part. i don't anything too valuable to add, except that i too have written about this concept, notably here: Distrib -e "Arch(org|code|pkgs|aur|forum|wiki|bugs|.*)?" -- thoughts https://bbs.archlinux.org/viewtopic.php?pid=709188 i think this is the _primary_ barrier affecting uptake of linux/GNU as a mainstream platform. we have all the source, and all the talent, but the heterogeneous nature of OSS (great, but a barrier nonetheless) means we are all using varied and incompatible tools to track/build the same upstreams. we need some unification here, not just for users, but vendors/developers too; such disconnects are a source of serious confusion and duplication of work. i think this, regardless of chosen software, would be a huge step forward. while i haven't released a prototype yet, i am attempting to realize this with work being done on aur-pyjs (https://bbs.archlinux.org/viewtopic.php?id=99839); my "cover" is a replacement for the AUR, but the real motivation behind this project is to build a distribution agnostic platform, a "framework for building linux distributions" if you will. we need to take sources, packages, bugs, software channels (vendors/distributions), and communication (forums/wiki/ML-ish) to the P2P/distributed space, so that all these exobytes of resources can be shared by _all_ communities. DSCM can solve nearly all these problems, including cryptographic verification of origin and identity. specifically, i want to rid ourselves of the notions of versions and packages, and instead move to a "tracking" scheme, ie. aggressive tracking = following HEAD/trunk, stable tracking = following certain tags. we need to eliminate the overhead in packaging, and manual cherry-picking of appropriate versions; i have many specific ideas here, but i don't want to digress too much :-) i wish i had something more tangible to share, but i'm in a bit of a financial crunch, and have only implemented bits and pieces; it is not demo-able yet. however, i am highly motivated to induce/propagate this paradigm shift, so i am responding to encourage everyone to think beyond what is now, and tune your cognitive abilities toward these alternative possibilities. closing the gaps between user/author/vendor/developer/support/etc. means more rapid, consistent, and _transparent_ progression of the entire ecosystem. C Anthony
Re: [arch-general] distributed bugtracking?
Excerpts from Dieter Plaetinck's message of 2010-09-08 21:47:40 +0200: > anyone knows this? http://bugseverywhere.org/be/show/HomePage > > the concept looks great, although i don't know anything about the > implementation/usage. > > other then the advantages they list, I think something like this can be > useful for downstream<->upstream communication. (ie someone reports a > bug in the distro bugseverywhere, they can then more easily forward the > bugs to upstream when needed) > i blogged about stuff like this @ > http://dieter.plaetinck.be/what_the_open_source_community_can_learn_from_devops > if anyone cares. > > Dieter Hi Dieter, just another distributed bug tracking system: http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki It's also a DVCS and whatnot. What I wonder about is how it compares to git when it comes to the DVCS part. -- Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
[arch-general] distributed bugtracking?
anyone knows this? http://bugseverywhere.org/be/show/HomePage the concept looks great, although i don't know anything about the implementation/usage. other then the advantages they list, I think something like this can be useful for downstream<->upstream communication. (ie someone reports a bug in the distro bugseverywhere, they can then more easily forward the bugs to upstream when needed) i blogged about stuff like this @ http://dieter.plaetinck.be/what_the_open_source_community_can_learn_from_devops if anyone cares. Dieter
Re: [arch-general] Pacman's superslow
On Wed, Sep 8, 2010 at 11:57 AM, Nilesh Govindarajan wrote: > I have an OpenVZ VPS running arch. > For some reason pacman is superslow, and I'm not allowed to create/use > loopback devices. > pacman-optimize takes nearly 5 minutes per run, no matter the last run > was just a minute ago. Unhelpful++ * Filesystem * Block device configuration * Total RAM, free -m output * uptime load avg numbers -Dan
[arch-general] Pacman's superslow
I have an OpenVZ VPS running arch. For some reason pacman is superslow, and I'm not allowed to create/use loopback devices. pacman-optimize takes nearly 5 minutes per run, no matter the last run was just a minute ago. -- 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] digital camera not showing as mass storage device
On 09/08/2010 11:57 AM, Matthew Monaco wrote: > > Thank you kindly. I could have sworn the camera used to show up as > /dev/sdX onto /media/*. But it's been so long at this point I could just > be mistaken. > Is there any configuration option in your camera that allows you to change how it identifies itself? I guess this is a good time to review the manual and check what it really is capable of doing :) -- Mauro Santos
Re: [arch-general] digital camera not showing as mass storage device
On 09/08/2010 05:37 AM, Christoffer Hirth wrote: Matthew Monaco wrote: I can get my digital camera to work with libgphoto stuff like shotwell, but for months now it simply won't show up as a mass storage device. Am I missing a kernel module or something? I loaded usb-storage. I downloaded the Ubuntu 10.10 beta live CD, plugged the camera in, and it popped up fine as a hard disk /dev/sdX... In the logs I see a load-modules.sh error. Please advise. I assume you are using gnome? In that case you should read gvfs optdepends. In particular you need gvfs-gphoto2 Christoffer Thank you kindly. I could have sworn the camera used to show up as /dev/sdX onto /media/*. But it's been so long at this point I could just be mistaken.
Re: [arch-general] Issues with SFTP and Nautilus.
Nilesh Govindarajan writes: > On 09/04/2010 10:51 AM, Ashish SHUKLA wrote: >> Hi everyone, >> >> When I connect to my remote SFTP server (running FreeBSD) using GNOME >> Nautilus, I noticed that the in the "Permissions" dialog box, instead of >> user/group names, the numeric U/G IDs are being shown, whereas when I do >> 'sftp' from terminal, and execute 'ls -l', I can see the user/group names. >> >> Any ideas what might be wrong there ? >> >> Thanks > I don't have a perfect idea about it, but probably nautilus doesn't > fetch the user-group mapping for the uid/gid you're seeing, while the > command line client does it. Sorry for the late reply. I hope you're also having similar issue, in case you tested this ? Thanks -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ Avoid Success At All Costs !! pgpuDtTt40VCT.pgp Description: PGP signature
Re: [arch-general] digital camera not showing as mass storage device
Matthew Monaco wrote: I can get my digital camera to work with libgphoto stuff like shotwell, but for months now it simply won't show up as a mass storage device. Am I missing a kernel module or something? I loaded usb-storage. I downloaded the Ubuntu 10.10 beta live CD, plugged the camera in, and it popped up fine as a hard disk /dev/sdX... In the logs I see a load-modules.sh error. Please advise. I assume you are using gnome? In that case you should read gvfs optdepends. In particular you need gvfs-gphoto2 Christoffer
Re: [arch-general] [PATCH 1/2] kill_everything: Reduce number of -f tests
Am 08.09.2010 06:16, schrieb Victor Lowther: > On Tue, Sep 7, 2010 at 10:47 PM, Dave Reisner wrote: >> Instead of checking for the existance of a file in /var/run/daemons on >> every iteration, handle the null case by setting nullglob. The shopt >> call is done inside a subshell as to not bother the environment since we >> may be going to runlevel 1 only temporarily. > > I thought about just enabling nullglobs and extglobs unconditionally > in functions, but decided that was too likely to get objections no > matter how unlikely breakage was. :) As for nullglob, I do think it is useful and enabling it might be useful in so many places - I didn't even know this option, it would have been useful for me before. I am in favor of enabling nullglob in function and dropping that subshell. Do we need extglob anywhere? I don't think so. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [PATCH 01/48] Bashification of initscripts
Am 08.09.2010 06:07, schrieb Victor Lowther: > Blame my ongoing Emacs education. I learned about > (custom-set-variables '(indent-tabs-mode nil)) after doing most of the > work, and dropped the whitespace cleanup patches due to size. > > Otherwise, I ignored the vim modelines -- 2 characters per indentation > is not really enough, and most of the preexisting code happily ignored > it anyways. Yeah, the code was very inconsistent to begin with. And whitespace cleanup patches are ugly, nobody bothered to do them so far. signature.asc Description: OpenPGP digital signature
