Re: [arch-general] Keyboard (special funcs) in Gnome3

[Loui Chang]

On Wed 24 Oct 2012 09:31 -0300, Héctor Herrera wrote:
> Well, I have installed the package you suggested, but sadly I still don't
> control the volume with my multimedia keys. And I dunno what to do. I
> assume that I'll have to configure by my hand in /usr/include/X11, isn't
> it?
> 
> For the record, I'm using an HP g4 1271-la notebook
> 
> Oh, and anyway, thanks for the responses!

Does ~./xbindkeysrc not work? That's what I do. However, not in Gnome.

Example:
> "mpc toggle"
>   XF86AudioPlay
>
> "mpc stop"
>   XF86AudioStop
>
> "mpc next"
>   XF86AudioNext
>
> "mpc prev"
>   XF86AudioPrev

Re: [arch-general] [arch-dev-public] testing/systemd 191-1 failed to boot

[Loui Chang]

On Sat 22 Sep 2012 15:06 +0200, Thomas Bächler wrote:
> Am 22.09.2012 10:07, schrieb Heiko Baums:
> > Am Sat, 22 Sep 2012 15:09:02 +0900
> > schrieb Zhengyu Xu :
> > 
> >> After updating systemd to 191-1 in testing repo, I had following
> >> messages during booting and the process was stuck (crashed).
> >>
> >> [   10.539416] systemd[1]: segfault at 7d ip b75a97b7 sp bfb0ece8
> >> error 4 in libc-2.16.so[b752a000+1a4000]
> >> [   10.539700] systemd[1]: Caught , core dump failed.
> >>
> >> Downgrade to 189-4 can solve this problem. I want to know if this
> >> is a personal problem or a general bug affecting others as well.
> > 
> > Why am I not surprised?
> > 
> > Yes, binary init system is so much better than a script based init
> > system. And Poetterix is so damn good, so advanced, such an evolution
> > and so much better than the common and over 40 years well tested
> > sysvinit.
> > 
> > Come on systemd fanboys, here you have the first example. There's more
> > to come. I'll get my popcorn.
> 
> After the recent outbreaks, we have been discussing banning people from
> arch-general. At the time, the people we talked about had calmed down
> and everything went back to normal, so there was no point in going
> forward with it. However, your name just made top of the list.
> 
> If I see you interrupting one more technical discussion with trolls and
> flames, you will be banned indefinitely without further notice. I will
> not see another one week flamewar on this list.
> 
> You are a grown man (at least you look like one), so you should know
> that this kind of post adds nothing to the discussion, but starts yet
> another flamewar. Start acting like a grown man and keep it to yourself,
> unless you have something to say that's worth saying.
> 
> I am completely against banning people, but at this point, it is either
> banning people or shutting down this list entirely.

I would petition that he be fully banned from all arch lists, forum,
irc, etc.

Re: [arch-general] Country Name (ISO-3116) Issues

[Loui Chang]

On Mon 02 Jul 2012 19:28 +1200, Jason Ryan wrote:
> On 02/07/12 at 07:20am, Zero Cho wrote:
> > 
> > Thanks for your support. You're right. This is not intended to be a
> > political debate, so I have been using a neutral word, Taiwan, rather than
> > other more official but sensitive, less common name. It's the fact that ISO
> > is not reflecting how most of the world see it. ISO does not have authority
> > over the country name. ISO does not obligate to reflect how world sees
> > things too. I'm not asking for special treatments. I'm just asking you to
> > follow the convention created from previous experience to prevent the
> > misunderstanding and debates.
>
> As the ISO page clearly states, the country names are sourced from the United
> Nations:
> 
> “The country names in ISO 3166 come from United Nations sources. New names and
> codes are added automatically when the United Nations publishes new names in
> either the Terminology Bulletin Country Names or in the Country and Region 
> Codes
> for Statistical Use maintained by the United Nations Statistics Divisions.”
> http://www.iso.org/iso/country_codes/country_codes
> 
> Asking Arch to modify the standard *is* a political act. The whole point of
> using a standard for what is an extremely fraught topic (geography and naming
> conventions) is to avoid these sorts of issues.
> 
> If you have an alternative standard that can be used, please suggest it.

An alternative has already been suggested. There's no reason we need to
keep coming back to ISO/UN. I'm not sure what the issue is anymore and
why this can't be fixed. This is silly.

At any rate someone should write to whoever maintains django-countries
and have them fix things on their end. These things could have been
mentioned from the very get-go in the original bug report in discussion
instead of closing the report with zero discussion.

Incidentally the forum post is now closed and hidden from the public.
Great work.

Re: [arch-general] Country Name (ISO-3116) Issues

[Loui Chang]

On Sun 01 Jul 2012 21:23 +0200, Tom Gundersen wrote:
> On Sun, Jul 1, 2012 at 7:28 PM, Loui Chang  wrote:
> > On Sun 01 Jul 2012 23:08 +0800, Zero, Chien-An Cho wrote:
> >> Hello,
> >>
> >> First of all, I am sorry to bring political issues to here. I have
> >> been using ArchLinux for years, deployed on many servers, though I'm
> >> not joining the community until now. The recent changes to the
> >> ArchLinux webpages (ex. Downloads, Mirror Status) is really offending
> >> Taiwanese people. I would like to bring up this issue, and preferably
> >> to resolve this issue.
> >>
> >> I have posted this message on the forum:
> >> https://bbs.archlinux.org/viewtopic.php?id=144315 . The moderator
> >> suggested me to post on arch-general, so here it is. :)
> >> There is also a bug tracking issue submitted by other Taiwanese user
> >> that I'm requesting for reopen here:
> >> https://bugs.archlinux.org/task/30444
> >>
> >> The following text is the same as the post on forum, except a few
> >> modification to make text smoother.
> >>
> >> The recent changes on the download page named Taiwan as Taiwan,
> >> Province of China, which is not reflecting the truth that Taiwan is a
> >> independent country which having its own government. I think this
> >> might be caused by following the ISO-3166 country name list standard.
> >> However, I don't think ISO-3166 is a good list when it comes to the
> >> country name.
> >>
> >> Many open source communities have encountered this problem before.
> >> Most of them understand that ISO-3166 is not really a neutral list
> >> that we all hope for, and thus made switch to a separate maintained
> >> country list. For example, FreeBSD[1], Rails[2], Debian[3]. Many big
> >> commercial entities also opt not to use "Taiwan, PRC" in their country
> >> list, like: Apple[4], IBM[5], also try Google, Facebook, Twitter, et
> >> cetra. A possible solution might be using the country name list from
> >> ICU[6].
> >>
> >> I believed the ArchLinux is trying to expand its user-base around the
> >> world, so a neutral country name list would be the best for the
> >> benefit of all of us, ArchLinux developers and users. As a Taiwanese
> >> ArchLinux user, I'm really happy to see that user base of ArchLinux is
> >> growing in Taiwan. Some educational institutions provide mirrors site
> >> in Taiwan, Wiki localized in Traditional Chinese in the recent years.
> >> I sincerely hope this issue can be resolved as soon as possible. Let's
> >> keep the issue simple and not flaming it, thanks.
> >>
> >> References:
> >>
> >> [1] FreeBSD: http://www.freebsd.org/cgi/query-pr.cgi?pr=138672
> >> [2] Rails: 
> >> http://www.koziarski.net/archives/2008/9/24/countries-and-controversies/
> >> [3] Debian: http://lists.debian.org/debian-devel/2004/04/msg00798.html
> >> [4] Apple: http://www.apple.com/choose-your-country/
> >> [5] IBM: http://www.ibm.com/planetwide/select/selector.html
> >> [6] ICU: 
> >> http://source.icu-project.org/repos/icu/icu/trunk/source/data/region/en.txt
> >
> > I agree. I'm very disappointed by the response of Dave Reisner on that
> > bug report. The reality is that the PRC does not have jurisdiction or
> > claim over Taiwan. When standards are false they should not be followed.
> >
> > Dave: Can you educate yourself a little about the Republic of China and
> > Taiwan vs the People's Republic of China, before making a final
> > decision? Thank you.
> 
> This has been discussed a number of times. While no one has so far
> questioned the validity of the bug, the consensus seems to be that
> this should be taken upstream [0].
> 
> I hope it is clear that no offense is intended, and that we do not
> want to make any political judgments (and hence defer to the UN).
> 
> [0]: <http://www.iso.org/iso/updates_on_iso_3166.html>.

Gimme a break. These kind of political issues aren't solved by "taking
it upstream". Since when are politicians or people under the influence
of politics known for their outstanding adherence to logic and reason?
It's not such a simple technical thing that you can "take it upstream."
If you have any idea how the ISO works you will wake up to the fact of
how ridiculous that suggestion is. If Taiwan (ROC) can't get it to
happen, what do you expect of us?

But as has been suggested maybe Arch should choose a different upstream
for this kind of information. Please open your mind a little, a false
standard is no standard at all.

Re: [arch-general] Country Name (ISO-3116) Issues

[Loui Chang]

On Sun 01 Jul 2012 23:08 +0800, Zero, Chien-An Cho wrote:
> Hello,
> 
> First of all, I am sorry to bring political issues to here. I have
> been using ArchLinux for years, deployed on many servers, though I'm
> not joining the community until now. The recent changes to the
> ArchLinux webpages (ex. Downloads, Mirror Status) is really offending
> Taiwanese people. I would like to bring up this issue, and preferably
> to resolve this issue.
> 
> I have posted this message on the forum:
> https://bbs.archlinux.org/viewtopic.php?id=144315 . The moderator
> suggested me to post on arch-general, so here it is. :)
> There is also a bug tracking issue submitted by other Taiwanese user
> that I'm requesting for reopen here:
> https://bugs.archlinux.org/task/30444
> 
> The following text is the same as the post on forum, except a few
> modification to make text smoother.
> 
> The recent changes on the download page named Taiwan as Taiwan,
> Province of China, which is not reflecting the truth that Taiwan is a
> independent country which having its own government. I think this
> might be caused by following the ISO-3166 country name list standard.
> However, I don't think ISO-3166 is a good list when it comes to the
> country name.
> 
> Many open source communities have encountered this problem before.
> Most of them understand that ISO-3166 is not really a neutral list
> that we all hope for, and thus made switch to a separate maintained
> country list. For example, FreeBSD[1], Rails[2], Debian[3]. Many big
> commercial entities also opt not to use "Taiwan, PRC" in their country
> list, like: Apple[4], IBM[5], also try Google, Facebook, Twitter, et
> cetra. A possible solution might be using the country name list from
> ICU[6].
> 
> I believed the ArchLinux is trying to expand its user-base around the
> world, so a neutral country name list would be the best for the
> benefit of all of us, ArchLinux developers and users. As a Taiwanese
> ArchLinux user, I'm really happy to see that user base of ArchLinux is
> growing in Taiwan. Some educational institutions provide mirrors site
> in Taiwan, Wiki localized in Traditional Chinese in the recent years.
> I sincerely hope this issue can be resolved as soon as possible. Let's
> keep the issue simple and not flaming it, thanks.
> 
> References:
> 
> [1] FreeBSD: http://www.freebsd.org/cgi/query-pr.cgi?pr=138672
> [2] Rails: 
> http://www.koziarski.net/archives/2008/9/24/countries-and-controversies/
> [3] Debian: http://lists.debian.org/debian-devel/2004/04/msg00798.html
> [4] Apple: http://www.apple.com/choose-your-country/
> [5] IBM: http://www.ibm.com/planetwide/select/selector.html
> [6] ICU: 
> http://source.icu-project.org/repos/icu/icu/trunk/source/data/region/en.txt

I agree. I'm very disappointed by the response of Dave Reisner on that
bug report. The reality is that the PRC does not have jurisdiction or
claim over Taiwan. When standards are false they should not be followed.

Dave: Can you educate yourself a little about the Republic of China and
Taiwan vs the People's Republic of China, before making a final
decision? Thank you.

Re: [arch-general] NAS drive revisited

[Loui Chang]

On Sun 20 May 2012 21:58 +0100, P .NIKOLIC wrote:
> I am still not able to write to my external NAS drive an iomega home
> media drive

You just can't write? If you can mount but can't write, then you have
the wrong permissions on the drive and/or uid/gid mixups, depending on
how you want it set up.

> So lets approach it from a different angle  
> 
> we will say i have not done anything yet just plugged it into the
> network 
> 
> What packages am i looking to install and what configuration changes
> do i need to make .

See the Arch wiki. The ball's in your court here. What you read depends
on how you want to access the drive. SMB? NFS?

> I am trying this way round as i am chasing my tail up somewhere dark
> and nasty right now .
>
> I know the drive works perfectly i have just tried it with an old Suse
> distro  on the Laptop and instant read/write no problem now if it can
> work on there why wont it work on Arch ..

Your description of the problem is much too vague. If you want help, you
ought to describe more specifically what you're trying to do, and what
is going wrong.

Re: [arch-general] problem with pulseaudio when resuming from pm-suspend

[Loui Chang]

On Fri 09 Mar 2012 11:45 +, Tom Gundersen wrote:
> On Fri, Mar 9, 2012 at 10:27 AM, XeCycle  wrote:
> > I use pulseaudio on my laptop.  I start it by
> > `start-pulseaudio-x11` in something like .xinitrc (I use a
> > standalone wm with lxdm).  When I resume from pm-suspend, the
> > system beeper issues several beeps; when I open a urxvt, a bash
> > completion failure will issue a beep too.  However when any
> > program that talks to pulseaudio starts (or try again to talk to
> > it), e.g. start pavucontrol, everything is normal again.
>
> My guess is that what happens is that pulseaudio blocks the sound
> device, and that's the reason you don't hear the beep when it is
> running (i.e. when sounds play). Disabling PA as Ralf suggests would
> in this case not help at all, and likely just make it worse (I wish
> people would stop suggesting to disable PA regardless of what the
> problem is, in most cases this is not going to make things easier).

I'm confused. Why is pulseaudio so necessary? I just use alsa for sound
and have no problems whatsoever. Granted, I don't use one of them fancy
shmancy desktop environments.

Re: [arch-general] People that depend on Arch, etc deserve to die? - Allan McRae - Clarifications

[Loui Chang]

On Fri 23 Dec 2011 10:42 +, Paul Gideon Dann wrote:
> On Friday 23 Dec 2011 05:32:25 Jonathan Vasquez wrote:
> > I wanted to know what was he trying to say? Is he saying that Arch and
> > other Arch-like distros aren't serious distros that aren't meant for
> > production? I mean I understand that Arch is rolling release and all
> > that, but it's packages are marked stable by their corresponding
> > upstreams.
> 
> I think the point is that it can be dangerous to use ArchLinux for
> critical applications, because there are occasional breakages during
> updates.  That's simply because Arch doesn't have a development cycle
> including a QA phase.  Distributions such as Debian can make certain
> guarantees about the stability of their software, because they only
> use older and thoroughly-tested software by default.

QA like when Debian broke SSL? I would rather trust Arch Linux for
critical applications.

Re: [arch-general] Automatic File Associations Alloting

[Loui Chang]

On Mon 21 Nov 2011 22:36 +0100, Philipp Überbacher wrote:
> Excerpts from Bernardo Barros's message of 2011-11-20 00:06:05 +0100:
> > text files opening automatically with wine is really a VERY annoying 
> > thing...
> 
> This is pretty clearly a DE issue. Are you all using the same DE or is
> this common behavior in all popular DEs? I rarely have any of those
> issues since I usually call my programs by name and ROX uses manual
> file association. Only firefox is sometimes hard to convince, but it
> uses gconf or some other DE stuff underneath. It's somewhat nice to see
> that DE users also have problems with that kind of stuff. Maybe this
> stuff can be changed using regedit or however that great program to
> change gconf settings is called. I'm sorry, somehow this ended up as
> another DE flame instead of being helpful. Oh well...
> 
> So how is this stuff controlled these days? Those funky desktop files?
> gconf? dconf? Something else entirely?

I'm thinking that this (the culprit) should be removed from all install
scriptlets: update-desktop-database -q

It's caused me headaches too. And I don't use any DE.

Re: [arch-general] system slowing down when copying files.

[Loui Chang]

On Sat 27 Aug 2011 09:12 +0530, Madhurya Kakati wrote:
> Hi,
> My system tends to slow down a lot when I copy files to and from a pen
> drive or even from one hard disk to another. Even my mouse cursor
> slows down. The system becomes almost unusable. I more than enough RAM
> and I am using a tiling window manager. So I am not even using a lot
> of RAM. Why is this happening? I can't work on my system if I run any
> large file copy/move operation. Please help.
> Thanks.

Your hard drive might be dying. Back up your files now.

Re: [arch-general] replacement for clyde

[Loui Chang]

On Fri 19 Aug 2011 10:43 -0500, Thomas Dziedzic wrote:
> 2011/8/19 Cédric Girard :
> > On Fri, Aug 19, 2011 at 3:11 PM, Thomas Dziedzic  wrote:
> >
> >> I've used yaourt for a couple of years now.
> >> It has always worked for me for the most part, and having a common
> >> command for everything is very convenient for me. alias y=yaourt and
> >> you have one of the simplest ways to do a complete update of your
> >> system, y -Syua
> >>
> >
> > I understand this may seems convenient to some. For me it is just useless
> > and just abstract things from the user.
>
> Definitely a valid opinion, as abstraction might be convenient or
> inexpedience to different audiences, which is why there really isn't a
> right answer.
> Programming also has this quality.

The problem that I've seen is that some users start treating yaourt as
THE package manager and start making bug reports, when the bug exists in
yaourt rather than pacman.

Re: [arch-general] [arch-dev-public] dropping tcp_wrapper support

[Loui Chang]

On Sat 16 Jul 2011 15:47 -0500, Peggy Wilkins wrote:
> On Sat, Jul 16, 2011 at 3:23 PM, Ionut Biru  wrote:
> > On 07/16/2011 08:06 PM, Peggy Wilkins wrote:
> >>
> >> The annoucement suggests that a major reason for dropping support is
> >> that it is "confusing" to end users.  An easy solution to that is to
> >> make a default hosts.allow file that says "ALL : ALL : ALLOW"  out of
> >> the box.  Then those of use wanting to simply restrict access (useful
> >> in many scenarios) can change that default as needed.
> >
> > i read the news entry couples of times and I don't get it how you
> > reach this conclusion. Really, this is not the reason and I found
> > your comment hilarious.
> 
> I was referring to this:
> 
> "Additionally, newer daemons and applications are inconsistent in
> their support for libwrap, leading to confusion as to whether an
> application supports the library."
> 
> This is true, it is confusing.  My response was to say, well, change
> the default config then, and that criticism won't carry the same
> impact.  (To be honest I have no idea what Arch's default config is
> for /etc/hosts.{allow|deny} because I edit it within minutes of a new
> install, but it seems that if it were default allow for ALL then it
> wouldn't cause as much trouble for people who wonder why sshd or
> whatever isn't working...)
> 
> > users who want this feature can as well recompile the desire services with
> > this support.
> 
> I will again say I chose Arch because I don't have to spend my time
> doing that (for a desktop OS); I very much appreciate the people who
> put the time into compiling things so I don't have to.  I spend a fair
> amount of time compiling software at work, and I don't want a larger
> list of things to recompile regularly.
> 
> I am not intending on continuing to bore everyone with my opinion here...
> 
> I still wish support would stay, but it's not my decision, I just
> wanted to speak up in case anyone but me cared (and apparently I
> really am the only one...).

I think it makes sense to have only one place to control traffic, makes
things a little simpler. tcp_wrappers is like a helper program for
beginner users to control traffic, but you can most likely find a
program that would help beginners to create iptable rules. I don't use
them so I can't advocate any particular program though.

Cheers.

Re: [arch-general] netcfg 2.6 release

[Loui Chang]

On Mon 20 Jun 2011 03:34 +0200, Rémy Oudompheng wrote:
> On 2011/6/20 Loui Chang  wrote:
> > On Sun 19 Jun 2011 23:23 +0200, Rémy Oudompheng wrote:
> >>
> >> netcfg 2.6 has been released and pushed in [testing].
> >>
> >> - /etc/conf.d/netcfg is a new configuration file, currently only used
> >> by net-auto-wireless: it is used to configure the name of the wireless
> >> interface you want to use (also possible in /etc/rc.conf, but
> >> discouraged), and to configure a list of preferred networks you want
> >> wpa_actiond to manage (FS#23169)
> >
> > Should the syntax for this documented in the package somewhere?
> 
> I try to keep the docs/ syntax as updated as possible. Are there
> official webpages for projects? other than projects.archlinux.org?

There's a page for pacman [1], but I don't know if there's any specific
infrastructure for project pages. You will probably have to ask the
admins for a space to put pages.

[1] http://www.archlinux.org/pacman/

Re: [arch-general] netcfg 2.6 release

[Loui Chang]

On Sun 19 Jun 2011 23:23 +0200, Rémy Oudompheng wrote:
> 
> netcfg 2.6 has been released and pushed in [testing].
> 
> - /etc/conf.d/netcfg is a new configuration file, currently only used
> by net-auto-wireless: it is used to configure the name of the wireless
> interface you want to use (also possible in /etc/rc.conf, but
> discouraged), and to configure a list of preferred networks you want
> wpa_actiond to manage (FS#23169)

Should the syntax for this documented in the package somewhere?

Re: [arch-general] Drop non-free ?! (Was: Commit in ffmpeg/trunk)

[Loui Chang]

On Sat 07 May 2011 11:24 -0500, C Anthony Risinger wrote:
> a bit of a divergence ... but as i think about next-gen packaging
> quite a bit i've often considered if a most advanced distribution
> system would negate issues like this ... for example, what if a
> nonfree package _knew_ it was nonfree, and therefore would only be
> distributed from servers in countries that do not deem it an issue?
> when user went to to sync it, their IP would be geolocated (or just a
> setting, eg. RESIDENT) and if need be the user would be warned that
> the package they are synced may have unknown legal implications.
>
> would something like that work?

Maybe not completely. At least it would relieve mirrors of possible
infringement which is good for them. Arch might still be found guilty
though.

Re: [arch-general] Drop non-free ?! (Was: Commit in ffmpeg/trunk)

[Loui Chang]

On Sat 07 May 2011 18:18 +0200, Pierre Schmitz wrote:
> On Sat, 7 May 2011 12:05:21 -0400, Loui Chang wrote:
> > On Sat 07 May 2011 18:32 +0300, Ionut Biru wrote:
> >> On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
> >> >Is faac support in ffmpeg causing trouble to other applications or was
> >> >changed for licensing reasons?
> >>
> >> licensing. if you need faac you should use abs to recompile it
> > 
> > Gah. All this licensing stuff is starting to get really annoying.
> > Did Arch receive a patent license violation notice or something?
> > 
> > What is Arch's official policies when it comes to patents?
> > It could have some widespread implications for the distro.
> > 
> > Or the distro could purchase or otherwise aquire licenses to all claimed
> > patents...  ha...  ha...
> 
> Licenses and patents are different things. Some stuff cannot legally
> distributed and we respect that. This is usually proprietary/non-free
> software or packages like the Microsoft fonts. (Wasn't there also some
> mplayer codec pack that included some Windows dlls?)
>
> On the other hand there are software patents valid in some countries
> which apply also to a completely free implementation. This means there
> are a bunch of packages which you are not allowed to use in the US for
> example even though they are licensed under e.g. the GPL.

Ah yeah I'm making some assumptions. It would be nice to understand the
exact reasons that the support was removed.

I'm assuming that faac support was removed because of patent issues, and
that ffmpeg does conform to the MPEG-2 NBC/MPEG-4 Audio standards.

The license of the code itself [1] would not seem to necessarily forbid
binary distribution. The reason that it is incompatible with LGPL is
because the original license allows free license only to products which
conform to the MPEG-2 NBC/MPEG-4 Audio standards. Relicensing all of the
code as LGPL would nullify that requirement which is not allowed.

[1] http://faac.cvs.sourceforge.net/viewvc/faac/faac/README?revision=1.7

Re: [arch-general] Drop non-free ?! (Was: Commit in ffmpeg/trunk)

[Loui Chang]

On Sat 07 May 2011 18:32 +0300, Ionut Biru wrote:
> On 05/07/2011 06:28 PM, Grigorios Bouzakis wrote:
> >Ionut Biru wrote:
> >>
> >>drop nonfree stuff, fix headers
> >>
> >>Modified: PKGBUILD
> >>===
> >>--- PKGBUILD2011-05-07 11:29:11 UTC (rev 122937)
> >>+++ PKGBUILD2011-05-07 11:51:04 UTC (rev 122938)
> >>@@ -5,26 +5,28 @@
> >>
> >>-depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'faac' 'xvidcore' 'zlib' 'x264' 
> >>'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 
> >>'libvpx' 'libva' 'openjpeg')
> >>+depends=('bzip2' 'lame' 'sdl' 'libvorbis' 'xvidcore' 'zlib' 'x264' 
> >>'libtheora' 'opencore-amr' 'alsa-lib' 'libvdpau' 'libxfixes' 'schroedinger' 
> >>'libvpx' 'libva' 'openjpeg')
> >>---enable-libfaac \
> >>---enable-nonfree \
> >
> >Is faac support in ffmpeg causing trouble to other applications or was
> >changed for licensing reasons?
>
> licensing. if you need faac you should use abs to recompile it

Gah. All this licensing stuff is starting to get really annoying.
Did Arch receive a patent license violation notice or something?

What is Arch's official policies when it comes to patents?
It could have some widespread implications for the distro.

Or the distro could purchase or otherwise aquire licenses to all claimed
patents...  ha...  ha...

Re: [arch-general] [arch-dev-public] [signoff] initscripts-2011.04.1-2

[Loui Chang]

On Fri 29 Apr 2011 23:00 +0200, Tom Gundersen wrote:
> On Fri, Apr 29, 2011 at 8:41 PM, David Rosenstrauch  wrote:
> > Can someone pls clarify what exactly is broken about localtime?  I've been
> > using it for years without any (noticable) issue.  I'll be happy to switch
> > over if I need to, but I'd like to understand the problem(s) first.
> 
> There are some implementational problems and some conceptual ones.
> Please have a look at the link I gave to the systemd page for a brief
> description as well as
>  for the very
> interested.

Sounds like a hardware problem then. Maybe the bios should tell the OS
if the clock is in localtime or UTC. ;)

Re: [arch-general] Printer driver

[Loui Chang]

On Thu 28 Apr 2011 22:50 +0200, Maciej Sobkowski wrote:
> I want to install driver for my Brother DCP-J315W printer. I've downloaded
> driver files from brother's site, since there is no package, neither in repo
> nor in aur. It was in deb format, also rpm available. The driver is split
> into two packages: dcpj315wlpr and dcpj315wcupswrapper. I converted them to
> tar.gz archive with deb2targz, extracted and I don't know where to put the
> files to get the driver working.

> Hierarchy in cupswrapper:  /usr/local/Brother/Printer/dcpj315w/cupswrapper/,
> and there are
> brcupsconfpt1  brdcpj315w.ppd  cupswrapperdcpj315w files.
>
> In lpr there is /usr/local/Brother/Printer/dcpj315w/lpd/ where are
> brdcpj315wfilter  filterdcpj315w  psconvertij2,
>
> and /usr/local/Brother/Printer/dcpj315w/inf/ where are
>  brdcpj315wfunc  brio08ba.bcm  brio08bc.bcm  brio08bf.bcm  brio08bk.bcm
>  paperinfij2
> brdcpj315wrcbrio08bb.bcm  brio08be.bcm  brio08bg.bcm  ImagingArea
> setupPrintcapij

I would recommend using the rpm because there is only one extraction
step. Also you don't need any special tools to convert or extract rpms
or debs. makepkg will automatically extract those archives via bsdtar
(part of libarchive).

I would move /usr/local/Brother stuff to /usr/share/Brother
You might have to edit some of those scripts and wrappers with sed to
get the proper paths.

If you're using cups you need to remember to add your printer to the
cups server for it to work.

Please see this wiki page for some tips:
https://wiki.archlinux.org/index.php/Creating_packages_for_Brother_drivers

Re: [arch-general] Change Arch's default crond

[Loui Chang]

On Thu 21 Apr 2011 10:46 +0200, Lukas Fleischer wrote:
> On Thu, Apr 21, 2011 at 02:32:42AM -0400, Kaiting Chen wrote:
> > So what's the status here? I pulled cronie into [community-testing]
> > a couple of days ago and will probably merge it into [community]
> > soon. So that's the one I vote.
> > 
> > But regardless of which one we choose in my opinion the sooner we
> > get rid of dcron the better. --Kaiting.
> 
> I don't want to be pedantic, but what's the point of that? Moving
> arbitrary cron daemons that no one uses to [community] is nonsense
> (according to the TU guidelines, you shouldn't even have moved it
> without prior discussion and consensus on aur-general at all - but as I
> said before, I don't want to be pedantic here...)

This is supposed to be a rule, not just a guideline.
The rule doesn't exactly apply to [community-testing].
Perhaps it should?

https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#Rules_for_Packages_Entering_the_.5Bcommunity.5D_Repo

Re: [arch-general] [arch-dev-public] [signoff] ncurses-5.8-1

[Loui Chang]

On Sun 27 Feb 2011 12:01 -0600, Dan McGee wrote:
> On Sat, Feb 26, 2011 at 7:55 PM, Allan McRae  wrote:
> > On 27/02/11 10:40, Allan McRae wrote:
> >>
> >> Major upstream update.
> >>
> >> Test well. There is no soname bump, but experience tells me that some
> >> rebuilds will probably be required to fix minor issues.
> >>
> >
> > I have rebuilt community/stfl to fix a crash (used by newsbeuter).
> >
> > I will start a TODO list to keep track of packages that require moved with
> > ncurses.  If you do any rebuilds, please add the package to the list.
> 
> $ tig
> tig: Failed to create status window
> 
> I added it to the list (but didn't rebuild it).

Rebuild won't do it. tig wants to create zero sized windows which
newwin() doesn't allow anymore. We could patch it with some arbitrary
size which kind of works, but I emailed the developer to ask how he
would deal with it.

Re: [arch-general] [arch-dev-public] Vi package

[Loui Chang]

On Wed 09 Feb 2011 11:23 -0500, Stéphane Gaudreault wrote:
> Hi,
> 
> I was looking at FS#20778 and was wondering what we should do with it.
> 
> While it is true that the "traditional vi" is buggy and not user
> friendly. It does not seems that BusyBox is a good alternative.
> 
> There are options here:
> 
> 1) Statu quo
> Pro : 
>* Support for multi-byte character encodings like UTF-8
>* Small size
> Cons :
>* Did I said that it is buggy ?
>* Use of this old software in the installer may give a strange
>impression to new users as they are faced with an editor from the
>'70 on a distro where everything is up to date.
>* Appears to be no longer be updated upstream.
> 
> Opinions?

I'd say stick with the status quo.
I don't find anything too wrong with the traditional vi. There's the
file size and line length limit and those aren't really that bad.
The wide terminal issue has been worked around by changing the config
header.

If you want to do heavy editing other programs are more appropriate in
our modern age. Vi is more appropriate for light editing like when doing
installation or configuration. Are other bugs that you mention
documented somewhere? I'm interested in learning about them.

If you can use vim you probably should be able to use vi without too
much difficulty.

I guess you could argue that having two basic editors (vi and nano) is
unnecessary, vi is usually expected to be on a basic system, and nano
just bugs me. :D

Re: [arch-general] Rail Model font for coders

[Loui Chang]

On Sat 22 Jan 2011 06:23 -0500, 
hare_krsna_hare_krsna_krsna_krsna_hare_hare_hare_rama_hare_rama_rama_rama_hare_h...@lavabit.com
 wrote:
> 
> > Can someone stop him from spamming our inboxes ?
> 
> Meeku:  "our" means the whole mailing list.  You should have used the word
> "my" and if you are a closet racist by condemning me from participating on
> this open mailing list then it does not do Arch Linux's reputation any
> good.

Well I refrained from saying anything until now.
I'll be honest. I found your original mail to be a bit obnoxious and a
bit spammish.

I have nothing against your race or religion, but I think your email
address is ridiculous. If you want to spread your message, at least put
it in an email signature for God/Allah/Yaweh/Buddha/Guanyin/Vishnu's
sake. Also the Arch mailing lists are not a place for religious
preaching or discussion. Thanks for participating.

Namaste.

Re: [arch-general] unable to install anything via yaourt

[Loui Chang]

On Sun 02 Jan 2011 04:51 +0100, Heiko Baums wrote:
> Am Sat, 1 Jan 2011 22:17:11 -0500
> schrieb Loui Chang :
> 
> > If you're having problems using yaourt to try to install from
> > [unsupported], or any repo, then you're probably having a problem with
> > yaourt, not the repos.
> > 
> > The AUR itself seems to be operating generally fine right now.
> > So, best to ask the yaourt folks for some advice, since they know that
> > program the best.
> 
> But he wrote that he gets the same error also if he executes xz directly
> in a terminal without yaourt and if he installs AUR packages manually
> with makepkg. So this is probably not yaourt related.

Aaah Crap hah. My bad. I guess I'm having trouble reading today.
It's been a long couple of days hehe.

Re: [arch-general] unable to install anything via yaourt

[Loui Chang]

On Sun 02 Jan 2011 08:12 +0530, Madhurya Kakati wrote:
> On Sun, Jan 2, 2011 at 8:09 AM, Loui Chang  wrote:
> 
> > On Sun 02 Jan 2011 08:00 +0530, Madhurya Kakati wrote:
> > > On Sun, Jan 2, 2011 at 7:53 AM, jesse jaara 
> > wrote:
> > >
> > > > Does xz work alone?
> > > > On 2.1.2011 4.21, "Madhurya Kakati"  wrote:
> > > > > i ran pacman -Syu and system is fully updated.
> > > > >
> > > > > On Sun, Jan 2, 2011 at 7:42 AM, jesse jaara 
> > > > wrote:
> > > > >
> > > > >> Your pacman or libarchive is outofdate or you dont have xz installed
> > >
> > > when i run the command xz in terminal it prints out the same error.
> >
> > Best to ask the yaourt folks directly via their channels.
> > http://archlinux.fr/yaourt-en
> >
> > no. its not a problem of yaourt anymore guys. I have realized that I
> > can't install anything from aur.

If you're having problems using yaourt to try to install from
[unsupported], or any repo, then you're probably having a problem with
yaourt, not the repos.

The AUR itself seems to be operating generally fine right now.
So, best to ask the yaourt folks for some advice, since they know that
program the best.

Re: [arch-general] unable to install anything via yaourt

[Loui Chang]

On Sun 02 Jan 2011 08:00 +0530, Madhurya Kakati wrote:
> On Sun, Jan 2, 2011 at 7:53 AM, jesse jaara  wrote:
> 
> > Does xz work alone?
> > On 2.1.2011 4.21, "Madhurya Kakati"  wrote:
> > > i ran pacman -Syu and system is fully updated.
> > >
> > > On Sun, Jan 2, 2011 at 7:42 AM, jesse jaara 
> > wrote:
> > >
> > >> Your pacman or libarchive is outofdate or you dont have xz installed
> 
> when i run the command xz in terminal it prints out the same error.

Best to ask the yaourt folks directly via their channels.
http://archlinux.fr/yaourt-en

Re: [arch-general] We want to help

[Loui Chang]

On Tue 14 Dec 2010 09:54 -0200, Tomás Acauan Schertel wrote:
> The Brazilian Arch Linux Community wants to help Arch Linux project,
> working on bug reports and feature requests.
> As first task, we plan to help conclude the development of AUR version 2.
> 
> We don't have lots of developers, but we really want to help. And
> maybe others join us on this effort.
> 
> To accomplish this, we need to enlighten some points:
> 
> 1 - where should we look for feature requests?
>  * bugs.archlinux.org?
>  * AUR2 wiki page?
> 
> 2 - what code repository should we take as start point?
>  * git://gitorious.org/aur2/aur2.git -- the "central" repository with
>  the stable branch
>  * git://github.com/sebnow/aur2.git -- Xilon's repository
>  * git://ius.student.utwente.nl/aur2 -- Thralas's repository
>  * git://git.berlios.de/aur2 -- Djszapi's repository
>  * git://github.com/SpeedVin/aur2.git -- SpeedVin's AUR2 forked repo
>  with some patches and translation's.
> 
> 3 - How Feature Requests / Bug Reports will be closed on flyspray?
>  * Maybe a TU can do the job.
> 
> Maybe things get easier if just one (maybe two) TU`s leads us on work.

Well, the AUR2 is a completely independent project. I don't think that
it should be tracked on the bugtracker for the current AUR - that's
unless the Trusted Users decide to adopt it instead of the current
codebase.

So the answer to question 1 would be the wiki page.

2. I believe you should follow the "central" repo if you decide to
   develop on AUR2.

3. I think it's best if AUR2 had a separate tracker.

Finally, I'd like to honestly say I don't see AUR2 as really being a
worthwhile investment for the next generation of the AUR. It's just
another web app like the current AUR, it might have a couple extra
frills, but I don't think it makes sense to rewrite the whole thing just
for that sake. They can probably added easily enough to the current
code.

As I see it I agree totally with Anthony's vision of what the future
of the AUR should look like. I've actually thought about this for a
few years, but I lack the talent to start any implementation.
I'm not sure if we will be able to jump right into it though. It might
take a couple of generations of the system. A first step would be to
take the interface out of the server and have the client deal with that.

I think you should take a look at Eli Janssen's AUR json daemon.
https://github.com/cactus/spew

and C Anthony Risinger's aur-pyjs
https://github.com/extofme/aur-pyjs

Cheers.

Re: [arch-general] [arch-dev-public] nilfs-utils moving in core

[Loui Chang]

On Tue 07 Dec 2010 18:30 +0100, Heiko Baums wrote:
> Am Tue, 07 Dec 2010 16:26:00 +0100
> schrieb Pierre Schmitz :
> 
> > I second this. If the reason for moving a package to core is that the
> > installer cannot handle it otherwise the installer needs to be fixed.
> 
> The question is not that the installer can't handle it if it's not in
> [core]. The question is that if the installer creates a filesystem on
> the harddisk the appropriate tools need to be installed on the system,
> too. And this is only possible if those packages are in [core] because
> the core iso only contains the [core] repo and not [extra] and
> [community]. Also the netinstall iso can only install from [core] as
> far as I know. So if AIF supports nilfs or another filesystem, those
> tools have to be moved to [core].
> 
> > That's why I would vote against moving it to core. I'd even say we
> > should have a look at those packages in core with low usage and see
> > if we should move them to extra. There are already packages for
> > which we don't get any sign-offs which shows that those are no
> > longer needed to be in core.
> 
> That's definitely not the definition of [core]. [core] is not for
> supporting the most used and most popular packages. [core] is for
> providing system relevant packages which are necessary to build a
> minimal system.
> 
> And it's not the dev's task to decide how a user wants to partition
> and format his harddisk.
> 
> If it's done like you're suggesting than you would force a user to
> only format his harddisk with e.g. ext4, because you think that ext4
> is the one and only and most popular filesystem and every other
> filesystem has to be moved to [extra], because they are not necessary
> or not as popular as ext4.
> 
> It's all about choice - the user's, not the dev's choice.

Man this stuff is hard to read.
Anyways, I would like to consider the installer as something separate
from the core system. Sure it can help you install the core system, and
any extras you may want. That shouldn't mean that the core needs to
conform to what the installer enables you to do.


> Instead every filesystem - probably except for dosfsutils - has to be
> moved to [core] and be supported by AIF, because a filesystem is the
> most basic and necessary part of a system which has to be chosen, used
> and installed during installation. You simply can't reformat or
> repartition a harddisk after the installation. Well, it's possible but
> not without having a second harddisk onto which the installed system
> had first to be copied. But that's not the way a system should be
> installed.

Bull.

> So every filesystem - regardless of how much it is used and how popular
> it is - has definitely to be moved to [core] and supported by AIF.
> 
> And, no, ext2 is not the only filesystem which can be used for /boot
> and /.
> 
> But on the other hand every filesystem related package has to be
> removed from (base), while AIF should then be able to recognize which
> filesystems are created on the harddisk and install the appropriate
> filesystem tools automagically.
> 
> > The idea of core was to provide a minimal set of packages that are
> > needed by nearly all users to set up a base system. Our sign-off
> > procedure ensures that we don't put broken packages by accident there.
> 
> But filesystems - all of them - belong to the very minimal set of
> packages that are needed to set up a base system. But every user needs
> a different filesystem for a reason, because every user has different
> requirements.
> 
> experimental != broken
> 
> Just because a filesystem is marked as experimental doesn't mean that
> it's broken. Btrfs e.g. is missing a fsck, yet, but it shall be pretty
> stable until the harddisk gets too cluttered. At least it's said by
> many people in the web. So there are several people who like to use and
> to test it.
> 
> As soon as there's a first stable version of a package it should of
> course not be updated anymore to newer, unstable versions.
> 
> Of course, those experimental packages should explicitly be marked as
> experimental in AIF.
> 
> There have been, btw., several kernel modules in the vanilla kernel
> which have been marked as experimental for many years even if they
> haven been really stable in the meantime. So the word experimental is
> quite relative.
> 
> > I don't think that nilfs matches the criteria needed for inclusion in
> > core. (side note: it has 1.38% usage according to pkgstats)
> 
> Why does it only have 1.38% usage? Just because it's not in [core] and
> not supported by AIF, just because a filesystem is usually chose at
> install time.

And poppycock.
Ask Microsoft to support every filesystem in existence on their standard
install CD and core system and maybe us poor Archers with our limited
time and budget can also rise to your stratospheric expectations.

Re: [arch-general] [arch-dev-public] nilfs-utils moving in core

[Loui Chang]

On Tue 07 Dec 2010 20:12 +0100, Heiko Baums wrote:
> Am Tue, 7 Dec 2010 19:12:05 +0100
> schrieb Tobias Powalowski :
> 
> > This is a proper solution without making core a big monster again.
> > greetings
> 
> Adding all filesystem tools to [core] won't make it a big monster. ;-)

I'm not so sure about that. There are probably more filesystems than I
can imagine. I wouldn't be too thrilled if all of that was in core.

Re: [arch-general] Changing subject line - Was: Python 3 Rationale?

[Loui Chang]

On Mon 06 Dec 2010 23:24 -0500, Kaiting Chen wrote:
> On Mon, Dec 6, 2010 at 9:12 PM, Allan McRae  wrote:
> 
> > Top posting vs. going off topic without changing subject lines. I'm not
> > sure which is worse...
> 
> Bottom posting in Gmail is a pain in the ass. --Kaiting.

Get a better mail client.

Re: [arch-general] Python 3 Rationale?

[Loui Chang]

On Mon 06 Dec 2010 10:27 -0700, Steve Holmes wrote:
> Scroll CLEAR down to the bottom for my response.
> 
> On Wed, Oct 20, 2010 at 12:02:27PM -0400, Matthew Gyurgyik wrote:
> > Really please, please don't top post.
> > http://www.river.com/users/share/etiquette/
> 
> Who cares! it takes too long to scroll down through the past fifteen
> generations to get to the relevant part of the message.

Well, it takes me one keystroke. Get a better mail client.

Re: [arch-general] what happened to nut (network-ups-tools)?

[Loui Chang]

On Mon 29 Nov 2010 22:31 -0600, David C. Rankin wrote:
> On 11/29/2010 09:11 PM, Loui Chang wrote:
> > David, is it really that hard to do a few searches before asking?
> 
> No, I did search for the package on the web-site. I just didn't think
> to search AUR. I hadn't heard of packages getting kicked out of the
> package list before, so it never occurred to me to look in AUR.

I'd like to encourage you to perform several searches in different
places before asking any question on the mailing list. Ideally, such
trivial questions should never be asked on the list.

There's a really handy search engine called google (http://google.com)
that has phenomenal indexing and will actually help you search multiple
sites at once (Arch Linux packages, the AUR, forums, mailing lists,
upstream, etc)

There may be other search engines as well, but that's the one I've found
to be most useful. Cheers.

Re: [arch-general] what happened to nut (network-ups-tools)?

[Loui Chang]

On Mon 29 Nov 2010 20:03 -0600, David C. Rankin wrote:
> Where did nut go? I just checked and network-ups-tools is no longer
> available.  Did it change names? I must have missed it. Thanks.

David, is it really that hard to do a few searches before asking?

Re: [arch-general] [arch-dev-public] [extra] repository cleanup

[Loui Chang]

On Sat 13 Nov 2010 15:23 +0100, Heiko Baums wrote:
> Am Sat, 13 Nov 2010 14:46:30 +0100
> schrieb Andrea Scarpino :
> 
> > On Thursday 11 November 2010 22:54:36 Roman Kyrylych wrote:
> > > I adopted some (and edited the page).
> > Nice, today we have 291 orphans packages in [extra] (they were 352
> > three days ago). 62 will be moved to [community]. 127 to AUR.
> > 
> > I didn't expect this success. I can start moving them today if you
> > agree.
> 
> Nice, then I would need to install 110 packages from AUR and compile
> them manually. When I switched to Arch Linux about 3 years ago it was
> less than 50.
> 
> When will the so called "binary distribution" Arch Linux become a
> second Gentoo, a pure source based distribution, because "no developer
> is interested in maintaining" anything anymore? Btw., PKGBUILDs also in
> AUR need to be maintained.
> 
> Really sad this progress and this massive and pointless cleanup.
> 
> You really should reconsider this cleanup. You should consider that
> such a distribution - and Arch Linux isn't a small and unimportant
> distro anymore - is not only about some personal preferences of the
> developers. Developers of such a binary distro should also maintain
> packages which they are not using themselves.

Sorry, Heiko. I don't think you properly understand Arch culture here.
If you want something done you are expected to contribute and put forth
your own effort to make it happen. The TUs and Devs cannot be expected
to be your personal support team and maintain hundreds of packages that
you're particularly interested in unless you're willing to compensate
them for their time. Their time is much more valuable than that.

Just like your time is too valuable to do it yourself.

I'd rather maintainers be forthcoming and allow users to maintain
packages that they can't properly support rather than carrying a burden
that may be harmful or stressful.

> I wouldn't say anything if you would cleanup the official repos from
> unnecessary, unimportant and unused or hardly used packages like some
> ttf fonts, GTK1 themes, etc. But there are too many, too important
> packages in your list which definitely belong into the official binary
> repos and which are in the official binary repos of every other binary
> distribution.

Arch is not just 'another binary distro'. It's a distro for those who
contribute. If other people can benefit from that work - that's great!

Cheers

Re: [arch-general] Replace dcron once again?

[Loui Chang]

On Fri 12 Nov 2010 10:26 +0900, Alex Matviychuk wrote:
> Thanks to this thread I decided to look at both dcron and fcron. First
> google result for dcron led me to this:
>
> This is from a Linux From Scratch readme here:
> http://www.linuxfromscratch.org/hints/downloads/files/dcron.txt

Nice. The guy who wrote that article is an Archer and former TU.
It's also from 7 years ago. I'm sure a good deal has changed since.

> From my naive point of view, it seems like dcron is more in line with
> the Arch Way.
>
> In response to the initial concern about a bug in dcron, don't we have
> anyone in our userbase that could take a look at the dcron code? As
> far as updates, I wouldn't expect a basic mature package to be updated
> more than once or twice a year. Update frequency alone says nothing
> about the quality of the code.

> My vote would be to focus efforts on fixing the bug and to keep Arch
> as small and lightweight as possible at its base. One of the best
> parts of Arch for me is that it starts out minimalistic and you can
> extend it to make it fit your needs. Trying to make our favorite
> packages defaults instead of minimal, stable, small packages, is a
> mistake imho.

The only problem is finding someone who can do the work to maintain
dcron. It's pretty damning to have a scheduler that can't schedule
properly installed by default - that's what people seem to be concerned
about mostly. I'd like to keep the simpler package too, but if it ain't
working chuck it.

Re: [arch-general] Te agregué como amigo en Faceboo k

[Loui Chang]

On Mon 27 Sep 2010 22:12 +0100, Mauro Santos wrote:
> This is a message that will probably show up at least one more time
> because facebook will remind everyone that didn't create an account that
> they have been invited.

Well, I followed the opt out links. Hopefully that works.

Re: [arch-general] Singapore Citizen Mr. Teo En Ming (Zhang Enming) wants to become the next person after U.S. Senator Ernie Chambers to sue God

[Loui Chang]

On Wed 22 Sep 2010 23:18 -0600, Gary Wright wrote:
> 
> ,.-'"...``~.,
> .,.-"..."-.,
> .,/...":,
> .,?..,
> .../...,}
> ./..,:`^`..}
> .../...,:"./
> ..?.__.:`.../
> ./__.(."~-,_..,:`../
> .../(_"~,_"~,_,:`_/
> ..{.._$;_.."=,_..."-,_...,.-~-,},.~";/}
> ...((.*~_..."=-._..";,,./`/"../
> ...,,,___.`~,.."~.,`.}../
> (`=-,,...`(..;_,,-"
> /.`~,..`-./
> .`~.*-,.|,./.,__
> ,,_..}.>-._...|..`=~-,
> .`=~-,__..`,.
> ...`=~-,,.,...
> `:,,...`..__
> .`=-,...,%`>--==``
> _..._,-%...`
> ...,

Yes Captain Picard.

Re: [arch-general] Adobe Releases New 64-bit Flash Plugin For Linux

[Loui Chang]

On Thu 16 Sep 2010 16:53 +0200, Linus Eklöf wrote:
> What's kind of sad is that people support and use adobes flash. Gnash might
> not work that well, but at least you'll kind of show support for free
> software.

What's really sad is that so many sites rely on flash in the first place.

Re: [arch-general] [arch-dev-public] inkscape finding a maintainer

[Loui Chang]

On Tue 31 Aug 2010 08:27 +0200, Gaetan Bisson wrote:
> [2010-08-31 01:32:21 -0400] Loui Chang:
> > On Mon 30 Aug 2010 19:24 +0200, Gaetan Bisson wrote:
> > > [2010-08-30 19:54:44 +0300] Ionuț Bîru:
> > > > Does anyone in our dev team uses inkscape like a daily bases and
> > > > wants to maintain it?
> > > 
> > > I use it about once a week or so; if you want inkscape to stay in
> > > [extra] I could maintain it. Now if Laurent wants it, I'm also happy to
> > > have it go to [community].
> > 
> > Hey... Did we gain some new developers that went unannounced?
> 
> Indeed, I don't think we've been introduced. :)
> 
> I'm a junior dev, mentored by Allan.

Cheers!

Re: [arch-general] [arch-dev-public] inkscape finding a maintainer

[Loui Chang]

On Mon 30 Aug 2010 19:24 +0200, Gaetan Bisson wrote:
> [2010-08-30 19:54:44 +0300] Ionuț Bîru:
> > Does anyone in our dev team uses inkscape like a daily bases and
> > wants to maintain it?
> 
> I use it about once a week or so; if you want inkscape to stay in
> [extra] I could maintain it. Now if Laurent wants it, I'm also happy to
> have it go to [community].

Hey... Did we gain some new developers that went unannounced?

Re: [arch-general] 3 minutes and 12 seconds Youtube video of My Arch Linux

[Loui Chang]

On Sun 29 Aug 2010 18:03 +0600, reflexing wrote:
> On Sun, Aug 29, 2010 at 5:56 PM, Mr. Teo En Ming (Zhang Enming) of Singapore
>  wrote:
> 
> > I have just uploaded a Youtube video of my Arch Linux which was installed
> > on an external 2.5" USB harddrive December last year (2009). The length of
> > the video is only 3 mins and 12 secs.
> >
> > My Arch Linux is essentially a Linux from Scratch (LFS) 6.5 which I have
> > compiled and installed from scratch, following the LFS 6.5 Handbook very
> > closely. After finishing the basic LFS 6.5 installation, I have installed
> > the pacman package manager from Arch Linux, essentially making the LFS 6.5
> > installation an Arch Linux installation. With the pacman package manager in
> > place, I was able to install the X.org X Windowing Server and the GNOME
> > Desktop Environment with ease.
> >
> > Please check out my Youtube video at the following link:
> >
> > http://www.youtube.com/watch?v=If9TifbQVmQ
> >
> > At the time of this writing, there are 23 uploaded videos in my Youtube
> > account.
> 
> You're fucking sick, please stop sending your shit to this list.

Hey don't be so mean. This is the first remotely relevant thing he's
sent to the list. Seems like he's trying to do better. Heheh.

Re: [arch-general] Referencing $srcdir in PKGBUILD?

[Loui Chang]

On Tue 17 Aug 2010 13:01 +0200, Philipp Überbacher wrote:
> Excerpts from Loui Chang's message of 2010-08-17 12:35:41 +0200:
> > On Tue 17 Aug 2010 12:09 +0200, Heiko Baums wrote:
> > > Am Tue, 17 Aug 2010 19:15:34 +1000
> > > schrieb Allan McRae :
> > > 
> > > > grep your files in your package for $srcdir (the actual value...).
> > > > If it is not in a config file or RPATH or the like, you can probably
> > > > ignore it.
> > > 
> > > I'm not quite sure if this is not a bug in makepkg, because I
> > > have this problem with almost all of my packages in AUR since the latest
> > > update to pacman 3.4.0. I never got this message before and I haven't
> > > changed such elementary parts of the packages. And if I'm right this
> > > problem appears with almost every package which I install from AUR.
> > > 
> > > But I need to watch it more narrowly.
> > 
> > You'll get that with any package that contains debugging symbols.
> 
> So it isn't about the usual 'cd $srcdir/${pkgname}-${pkgver}' ?

No, it's about build directories being referenced in the finished
package, not the PKGBUILD.

Re: [arch-general] Referencing $srcdir in PKGBUILD?

[Loui Chang]

On Tue 17 Aug 2010 12:09 +0200, Heiko Baums wrote:
> Am Tue, 17 Aug 2010 19:15:34 +1000
> schrieb Allan McRae :
> 
> > grep your files in your package for $srcdir (the actual value...).
> > If it is not in a config file or RPATH or the like, you can probably
> > ignore it.
> 
> I'm not quite sure if this is not a bug in makepkg, because I
> have this problem with almost all of my packages in AUR since the latest
> update to pacman 3.4.0. I never got this message before and I haven't
> changed such elementary parts of the packages. And if I'm right this
> problem appears with almost every package which I install from AUR.
> 
> But I need to watch it more narrowly.

You'll get that with any package that contains debugging symbols.

Re: [arch-general] /etc/profile PATH variable wrong

[Loui Chang]

On Sun 15 Aug 2010 07:08 -0700, mike rosset wrote:
> > Someone unaware of dotfiles might miss them, but others (blind or
> > sighted) should be able to access them without issue.
> 
> And all of this has nothing to do with the orignal issue /usr/local. I
> only suggested using something in $HOME for "user" based scripts which
> can be anything it does not matter.

> It only serves to deflect from why is /usr/local/{bin,sbin} not part
> of the default search PATH? when its a FHS standard and has always
> been used for custom system wide installs? Obviously a competent
> system administrator can add this. However does this mean we should
> remove /usr/bin now to? since any competent admin can add that also.

Haha. Don't be so aggressive against discussion on an issue that you
brought up in the first place. We're just trying to help put things in
their proper place. But yeah I agree there are too many silly tangents
on this issue. So let somebody submit a patch and get it over with.

Re: [arch-general] /etc/profile PATH variable wrong

[Loui Chang]

On Sun 15 Aug 2010 06:33 -0700, mike rosset wrote:
> > I use ~/.local/bin for user specific applications and scripts. ~/bin would
> > create visible clutter to the home folder.
> >
> > --
> > Ape 
> 
> That might work for you however in Jude's case being a blind user I
> would think he would want something that is very visible in a braille
> terminal. Either way I'm sure he can find something that works for
> him.
> 
> But this also derails from the topic of /usr/local which is still a
> valid point.

Someone unaware of dotfiles might miss them, but others (blind or
sighted) should be able to access them without issue.

Re: [arch-general] Shouldn't pacman restart dovecot after update?

[Loui Chang]

On Sat 07 Aug 2010 20:04 -0600, Gary Wright wrote:
> On Sat, Aug 7, 2010 at 3:31 PM, Loui Chang  wrote:
> > On Sat 07 Aug 2010 01:26 +0200, Guus Snijders wrote:
> >> HTH, HAND
> >
> > What?
> >
> >
> 
> HTH[1] HAND[2]
> 
> [1] http://www.acronymfinder.com/HtH.html
> [2] http://www.acronymfinder.com/HAND.html

Bah thanks.
Bloody Hell. Can we not write in English?
I think that sort of thing is more appropriate on AOL chat.

Re: [arch-general] Shouldn't pacman restart dovecot after update?

[Loui Chang]

On Sat 07 Aug 2010 01:26 +0200, Guus Snijders wrote:
> HTH, HAND

What?

Re: [arch-general] script to reformat 'pacman -Ss' output into 2 readable columns (prevents blindness)

[Loui Chang]

On Thu 05 Aug 2010 22:51 -0500, David C. Rankin wrote:
> Guys,

You got a script for the gals too? :D

>   I developed a script to help me read the output of pacman -Ss in 2
> nicely formatted columns. The output of 'pacman -Ss srchterm' drives
> me nuts trying to read down the package names and descriptions with
> all the tab indented and wrapped text -- so I fixed it. Download the
> script here:
> 
> http://www.3111skyline.com/dl/Archlinux/scripts/srch2list.sh
> 
>   or with the '-d' option for semi-doublespace:

This should definitely be the default. Otherwise I may go walleyed.

>   The script needs 1 input. That is a filename 'srchfile' that
> contains the output from 'pacman -Ss srchterm > srchfile' There are
> 2 options, '-h or --help' gives a brief description and '-d' which
> causes the output to be essentially double-spaced. (each package
> description remains single spaced if it requires multiple lines, but
> a blank line is included between package descriptions) On the todo
> list is having the script take the input from stdin and eliminate
> the srchfile.

Cheers.

Re: [arch-general] makepkg patch - generate .SRCINFO file when running "--source"

[Loui Chang]

On Mon 02 Aug 2010 17:03 +0200, vlad wrote:
> On Mon, Aug 02, 2010 at 08:49:11AM -0400, Loui Chang wrote:
> > On Tue 27 Jul 2010 15:25 +0200, vlad wrote:
> > > Here is a patch against makepkg from git which introduces a new
> > > function "write_srcinfo()". This generates a file .SRCINFO - like
> > > the .PKGINFO one - when "makepkg --source" is run and then it is
> > > added to the src.tar.gz archive. 

> > > I think having such a file is an important step for getting split
> > > packages to the AUR. It is also useful for third party applications.
> > > Since this file is generated during making the source archive, there
> > > is no need for parsing/sourcing the PKGBUILD everytime meta infos are
> > > needed afterwards.
> > > This is also a way of standardizing the source archive.
> > > 
> > > .SRCINFO looks like (generated for gcc from core):
> > 
> > Nice. :D This is something that I had been brainstorming too.

> Hehe, that's why I did it. I wanted to give this a push.

> > You should submit it to the pacman-dev list and/or the pacman bug
> > tracker.

> Is pacman-dev public or open for non-devs?

Yes. It's open to anybody. Just subscribe first.

Re: [arch-general] makepkg patch - generate .SRCINFO file when running "--source"

[Loui Chang]

On Tue 27 Jul 2010 15:25 +0200, vlad wrote:
> Here is a patch against makepkg from git which introduces a new function
> "write_srcinfo()". This generates a file .SRCINFO - like the .PKGINFO
> one - when "makepkg --source" is run and then it is added to the src.tar.gz
> archive. 
> I think having such a file is an important step for getting split
> packages to the AUR. It is also useful for third party applications.
> Since this file is generated during making the source archive, there
> is no need for parsing/sourcing the PKGBUILD everytime meta infos are
> needed afterwards.
> This is also a way of standardizing the source archive.
> 
> .SRCINFO looks like (generated for gcc from core):

Nice. :D This is something that I had been brainstorming too.
You should submit it to the pacman-dev list and/or the pacman bug
tracker.

Re: [arch-general] mandriva beat us to a new version

[Loui Chang]

On Thu 29 Jul 2010 10:05 -0400, Caleb Cushing wrote:
> of perl 
> http://jquelin.blogspot.com/2010/07/perls-state-in-mandriva-cooker.html
> how embarrassing.

Congrats to them! How's that embarrassing?

Re: [arch-general] perl-authen-sasl: local (2.1401-1) is newer than community (2.15-1)

[Loui Chang]

On Tue 20 Jul 2010 17:14 +0200, Damjan Georgievski wrote:
> This is what happens to me now
> # pacman -Syu
> ...
> :: Starting full system upgrade...
> warning: perl-authen-sasl: local (2.1401-1) is newer than community (2.15-1)
> 
> I guess this happens because I have installed something from testing
> at one point, and anyway, I know how to override this warningm but..
> 
> The question is, should pacman think that 2.1401 is newer than 2.15 ?

I would hope so. 1401 > 15

Re: [arch-general] Keep older kernel intact while upgrading to new kernel

[Loui Chang]

On Sat 17 Jul 2010 12:15 -0500, C Anthony Risinger wrote:
> On Jul 17, 2010, at 11:42 AM, Loui Chang  wrote:
> 
> > On Sat 17 Jul 2010 11:06 -0500, Victor Lowther wrote:
> >> Oh, I do.  I would just prefer to work with the package management
> >> framework, not work around it.
> >
> > I think this is something that hooks could do. It's a feature that's
> > in brainstorming. Maybe you could help implement it.
> >
> > http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks
> 
> As a heads up, this (kernel rollbacks) is a planned feature of the
> mkinitcpio-btrfs hook in AUR.  It will be implemented in one or more
> of about three ways:
> 
> https://bbs.archlinux.org/viewtopic.php?pid=778395#p778395
> 
> You must be using btrfs for / of course.

So, that's not something that would work within the package management
framework, is it?

Re: [arch-general] Keep older kernel intact while upgrading to new kernel

[Loui Chang]

On Sat 17 Jul 2010 11:06 -0500, Victor Lowther wrote:
> On Sat, 2010-07-17 at 10:42 -0500, Thomas Dziedzic wrote:
> > On Sat, Jul 17, 2010 at 10:38 AM, Victor Lowther
> >  wrote:
> > > On Sat, 2010-07-17 at 23:10 +0800, Ng Oon-Ee wrote:
> > >> On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote:
> > >> > On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote:
> > >> > > I think it's a bad idea, because the directory 
> > >> > > /lib/modules/$oldVersion$
> > >> > > will be removed when the package is upgraded kernel. Trivial 
> > >> > > solution not
> > >> > > exists.
> > >> >
> > >> > My solution is to hand-roll my own kernels and initramfs'es after
> > >> > removing the kernel and mkinitcpio packages.  The way Arch handles its
> > >> > kernel packages is a weak point -- Fedora and Ubuntu get this bit 
> > >> > right.
> > >>
> > >> Yeah, why not keep all previous kernels and headers around. We could
> > >> automatically extend menu.lst too!
> > >
> > > It wold be better than updating to a new kernel, rebooting, and having
> > > to boot to a LiveCD to get back into your system because the new kernel
> > > fscked things up.
> > >
> > > Keeping versioned header files also comes in handy -- I take it you heve
> > > never tried any sort of testing with out-of-tree drivers or kernel
> > > subsystems? Using DKMS on arch is a pointless waste of time because
> > > older kernel headers are not kept around.
> > >
> > >> I'm not sure what you like about Fedora and Ubuntu handling of kernels,
> > >> but I found it very annoying to have all that stuff hanging around.
> > >> Would be worse with rolling release I'm sure.
> > >
> > > I like knowing that I will not have to hunt for a LiveCD or a rescue USB
> > > drive if a kernel update renders the system unbootable.
> > >
> > >
> > 
> > This wouldn't be a problem if you have a backup kernel :)
> 
> Oh, I do.  I would just prefer to work with the package management
> framework, not work around it.

I think this is something that hooks could do. It's a feature that's in
brainstorming. Maybe you could help implement it.

http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks

Cheers!

Re: [arch-general] Bashification of initscripts for moderate speedup

[Loui Chang]

On Wed 30 Jun 2010 18:48 +0200, Philipp Überbacher wrote:
> Excerpts from Aaron Griffin's message of 2010-06-30 17:55:40 +0200:
> > On Wed, Jun 30, 2010 at 10:00 AM, Caleb Cushing  
> > wrote:
> > > On Tue, Jun 29, 2010 at 1:57 PM, Aaron Griffin  
> > > wrote:
> > >> I have no idea where the number came from, but both 80 and 132 are
> > >> standard column widths used for normal and wide terminals.
> > >
> > > should be 78 columns I do believe that's the standard for kernel/git
> > > it allows for email comments more easily apparently.
> > 
> > No, physical terminals went to 80 columns. The 78 number was likely
> > related to editor chrome, such as line numbering... I'm not sure of
> > the details.
> > 
> > I believe email typically has 78 width due to the fact that "> " is
> > expected for replies.
> 
> I also read about 72, and it's my current setting for vim when editing
> mails, but I have no idea where that comes from...

Yeah I generally use 72 for emails.

Re: [arch-general] Licensing of Arch Wiki content

[Loui Chang]

On Wed 30 Jun 2010 00:15 +0100, Ananda Samaddar wrote:
> On Tue, 29 Jun 2010 17:56:39 -0500
> Aaron Griffin  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.

Re: [arch-general] Bashification of initscripts for moderate speedup

[Loui Chang]

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

[Loui Chang]

On Mon 28 Jun 2010 10:03 -0500, Victor Lowther wrote:
> On Jun 28, 2010, at 9:49 AM, Loui Chang  wrote:
> >Depends on what you define as Arch.
> >I've heard that Arch is what you make of it. Hehe.
> >I don't know if you could disqualify it from a difference of one file.
>
> For me, part of it is that bash is used pretty ubiquitously as the
> configuration and scripting language of choice. Changing that to
> posix sh in one of the main config files would be a big shift.

Ah. For me Arch is much more than bash configs or scripts.
They could all become POSIX compatible and I'd still see it as Arch.

If Arch started to require python, or more I might start to see it
differently - it would be harder to maintain a slimmer system.

Re: [arch-general] Bashification of initscripts for moderate speedup

[Loui Chang]

On Mon 28 Jun 2010 09:13 -0500, Victor Lowther wrote:
> On Jun 28, 2010, at 8:59 AM, Loui Chang  wrote:
> 
> >On Mon 28 Jun 2010 08:04 -0500, Dan McGee wrote:
> >>On Mon, Jun 28, 2010 at 7:42 AM, Caleb Cushing
> >> wrote:
> >>>On Sun, Jun 27, 2010 at 11:10 PM, Victor Lowther
> >>> 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)
> >>
> >>Because we are never going to eliminate arrays from rc.conf.
> >
> >Well, it may still be beneficial to some. The scripts could be used
> >with a different style rc.conf in other environments.
> 
> Then it will not be Arch.

Depends on what you define as Arch.
I've heard that Arch is what you make of it. Hehe.
I don't know if you could disqualify it from a difference of one file.

Re: [arch-general] Bashification of initscripts for moderate speedup

[Loui Chang]

On Mon 28 Jun 2010 08:04 -0500, Dan McGee wrote:
> On Mon, Jun 28, 2010 at 7:42 AM, Caleb Cushing  
> wrote:
> > On Sun, Jun 27, 2010 at 11:10 PM, Victor Lowther
> >  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)
> 
> Because we are never going to eliminate arrays from rc.conf.

Well, it may still be beneficial to some. The scripts could be used with
a different style rc.conf in other environments.

Re: [arch-general] Boost

[Loui Chang]

On Fri 18 Jun 2010 11:52 +0200, Sven-Hendrik Haase wrote:
> On 18.06.2010 11:38, Ionuț Bîru wrote:
> > On 06/18/2010 09:30 AM, Allan McRae wrote:
> >> On 18/06/10 16:24, Daniel Bumke wrote:
> >>> Does anyone know what's going on with boost? It seems it was downgraded
> >>> from 1.42.0 to 1.41.0 a while back, and hasn't been updated to the
> >>> latest 1.43.0.
> >>>
> >>> I was going to build the latest on my machine, but if there's something
> >>> wrong with it I might hold off or go with the older version. I know
> >>> there was some talk about splitting it up; is that the reason?
> >>
> >>  From memory 1.42 broke encfs. The encfs developers blame boost, the
> >> boost developers blame encfs, so nothing was done in recent updates from
> >> either side.
> >>
> >> So we either update boost or break encfs...
> >
> > encfs devs released a new version which works with > 1.41.
> >
> > yesterday i built 1.43 but the splitting is holding me back. It has a
> > very annoying build system and until now we have in the bugtracker one
> > which is copying files around from a directory to another. FS#19749
>
> What's the issue here though? We have a working split package and
> everyone is happy? Bjam is a crappy build system but until CMake is more
> actively maintained by Boost (last boost-cmake release was 1.41) it'll
> have to do. Boost is an important part of C++ development, it should not
> go without update in Arch.

Wow, this is kind of depressing. Why would some package in community
block an established library from being upgraded in extra?

Re: [arch-general] Licensing of Arch Wiki content

[Loui Chang]

On Thu 17 Jun 2010 21:42 +0100, Ananda Samaddar wrote:
> I notice it's all under GFDL 1.2.  I'm wanting to use a Gentoo doc
> for the Arch Security stuff but it's under a CC-SA attribution license
> which is incompatible with GFDL. Would it be possible to allow Wiki
> content under a CC licenses? I can't see it being too controversial a
> choice, as in CC licenses are now widely accepted.  Even the venerable
> RMS uses CC licenses for his personal stuff as does a lot of the
> FSF/GNU stuff.

I don't think anyone would sue you for it.

Re: [arch-general] What should the Arch Security Team be called?

[Loui Chang]

On Thu 17 Jun 2010 21:19 +0100, Dave Morgan wrote:
> On 17/06/10 at 08:46pm, Ananda Samaddar wrote:
> > On to the first order of business. As the subject says, what should
> > security team be called.  Hopefully we can get a few suggestions and
> > then reach a consensus. Arch Linux Security Task Force just sounds like
> > too much of a mouthful to me.
> > 
> > I was brooding over this and I thought some sort of acronym that's an
> > actual word would sound better, so I came up with this:
> > 
> > 'Arch Response Team for Security' or ARTS.  It's a bit cheesy and
> > cheats a bit to get the acronym but is instantly memorable.  I'm aware
> > arts was also a KDE technology but it has long since been deprecated.
> > 
> > Ideas?
> 
> Arch Response Security Engineers?

HAHA YES!

Re: [arch-general] [arch-dev-public] dropping flashplugin x86_64

[Loui Chang]

On Tue 15 Jun 2010 18:23 +0200, Thomas Bächler wrote:
> Am 15.06.2010 18:22, schrieb Andreas Radke:
> > Am Tue, 15 Jun 2010 19:12:38 +0300
> > schrieb Ionuț Bîru :
> >> the current x86_64 version of flashplugin has security problems and 
> >> adobe dropped/temporally closed x86_64 releases.
> >>
> >> How do we manage this situation?
> >> Only dropping from repo?
> >> Should we submit an empty package?
> >> Suggest our users to remove their package if they consider security 
> >> important?
> > 
> > We should post a news item about this so the users may decide to remove
> > it or keep it. Another option could be shipping a dummy empty -1.1 pkg
> > for x86_64 with a small post.install msg.
> 
> I'll keep this installed despite the security problem. Combined with
> flashblock, I can at least watch youtube this way. Force-removing it by
> a dummy update is something I don't want.

Yeah forced removal is not the Arch Way.
An announcement would be much better.

Re: [arch-general] Cannot install shaman from AUR

[Loui Chang]

On Sat 05 Jun 2010 23:05 +0200, Xavier Chantry wrote:
> On Sat, Jun 5, 2010 at 7:36 AM, xenof0nt  wrote:
> > Arch will never provide a graphical tool for pacman.
> > So if you can't live with this, then change to another distro
> 
> Never say never.
> Just curious, where does that come from ?
> Why couldn't a sufficiently motivated developer write a GUI frontend
> to libalpm good enough to get it packaged ?

At least it'll never be in core. Good enough for me!

Re: [arch-general] change user and group in env in PKGBUILD

[Loui Chang]

On Thu 03 Jun 2010 01:48 -0400, Caleb Cushing wrote:
> so i'm trying to update the oracle pkgbuild on AUR. oracle's installer
> won't run as root, but it thinks that it's running as root. how can I
> change this? I believe it is supposed to be run as the user and group
> that it gets installed as what's the best way to add those in the
> pkgbuild?

Try adding a trivial package function:
package() {return 0}

or you might be able to manipulate BUILDENV and add !fakeroot.

Re: [arch-general] Games for Linux !

[Loui Chang]

On Fri 28 May 2010 23:00 +0530, Madhurya Kakati wrote:
> This mailing list is only for discussing problems. Besides we use
> arch-games repo ;)
> 
> On 5/28/10, Nilesh Govindarajan  wrote:
> > It seems there are lot of games for Linux we're not aware of because
> > most of the times we stick to our distribution's repository.
> > I remembered mario that I used to play on console about 8 years ago,
> > so a Google search revealed megamario.
> > All who wish to play games for entertainment check this -
> > http://linux.softpedia.com/get/GAMES-ENTERTAINMENT/
> > This should suffice for normal gamers. For hard core gamers, it won't.

I don't think there's anything wrong with discussing games.
But the top posting is.

Re: [arch-general] dualboot?

[Loui Chang]

On Thu 27 May 2010 16:42 -0400, David Rosenstrauch wrote:
> On 05/27/2010 04:21 PM, Stefan Husmann wrote:
> >python is no requirement for Arch Linux itself. If you do not like it,
> >just do not install it.
> 
> Isn't pacman written in python?  That would make python a
> requirement for Arch then, right?

No, it's written in C.

Re: [arch-general] cdrtools again... yay! - Was: Burning From Command Line

[Loui Chang]

On Thu 27 May 2010 14:41 -0500, C Anthony Risinger wrote:
> On Thu, May 27, 2010 at 2:29 PM, Loui Chang  wrote:
> > http://mailman.archlinux.org/pipermail/arch-general/2010-January/010357.html
> > http://mailman.archlinux.org/pipermail/arch-general/2010-May/013557.html
> 
> eh? more circles?

What the hell do circles have to do with anything?
The first link seems to show there's no problem with the license.

The second link states:
"And the license of cdrtools is not even the reason that cdrtools is not
packaged in Arch."

Re: [arch-general] cdrtools again... yay! - Was: Burning From Command Line

[Loui Chang]

On Thu 27 May 2010 19:11 +0200, Thomas Bächler wrote:
> Am 27.05.2010 17:52, schrieb Loui Chang:
> > Anyways, it's been stated that
> > licensing isn't really the issue any more. The fact is no Dev or TU is
> > interested in maintaining cdrtools. Jörg has something to learn about
> > how to deal with people, but he's too stubborn to take any advice.
> 
> When has that happened? I would gladly package cdrtools. I know from
> many users that it is superior to cdrkit (although I never had any
> trouble with either of them). However, I fear that some of my fellow
> developers would stop me from doing that due to the questionable license
> situation.

http://mailman.archlinux.org/pipermail/arch-general/2010-January/010357.html
http://mailman.archlinux.org/pipermail/arch-general/2010-May/013557.html

Re: [arch-general] cdrtools again... yay! - Was: Burning From Command Line

[Loui Chang]

On Thu 27 May 2010 18:32 +0200, Joerg Schilling wrote:
> Loui Chang  wrote:
> > That would be nice and useful if people actually believed that there
> > would be an end to this discussion. Anyways, it's been stated that
> > licensing isn't really the issue any more. The fact is no Dev or TU is
> > interested in maintaining cdrtools. Jörg has something to learn about
> 
> I am not sure whether you realized that cdrtools is well maintained
> and without known bugs.

Sorry I wasn't completely clear, by maintaining I meant maintaining the
binary Arch Linux package. No one is interested in it, and you really
can't force interest.

Re: [arch-general] cdrtools again... yay! - Was: Burning From Command Line

[Loui Chang]

On Thu 27 May 2010 14:43 +0200, Xavier Chantry wrote:
> Dozens of people have contributed to the discussion, but no one
> actually cares about getting some clarifications ?
> I just don't get it.
> I feel like I did my part of the work already by getting a report from
> Eben, just to see Joerg accusing him of lying in return.
> Now it would be very nice and useful if someone could continue that
> work by getting in touch with other competent people.

That would be nice and useful if people actually believed that there
would be an end to this discussion. Anyways, it's been stated that
licensing isn't really the issue any more. The fact is no Dev or TU is
interested in maintaining cdrtools. Jörg has something to learn about
how to deal with people, but he's too stubborn to take any advice.

Re: [arch-general] cdrtools again... yay!

[Loui Chang]

On Wed 26 May 2010 21:59 +0530, Piyush P Kurur wrote:
> On Wed, May 26, 2010 at 10:06:36AM -0500, Aaron Griffin wrote:
> > On Wed, May 26, 2010 at 9:41 AM, Allan McRae  wrote:
> > > I do not speak for the other Arch developers, but the reason why I
> > > will not officially package cdrtools for Arch is you.  My
> > > impression of you is that you are very, very annoying and
> > > irritating.  If there was a bug report made about the cdrtools
> > > package in Arch, then I would have to deal with you.  I do not
> > > particularly want to do that, so I will not package cdrtools.  I
> > > have heard similar opinions expressed by developers from various
> > > other distributions while at Linux meetings, so I am not alone
> > > here, even though I might be the only one blunt enough to say it
> > > directly.
> > 
> > I agree. Deficient upstream is a completely valid reason for
> > excluding things. i.e. Ion3
> 
> I like this thread. Burning CD on command line looks like a long
> ``burning'' issue.

Ba dum, ting!

Re: [arch-general] PKGBUILD parser

[Loui Chang]

On Mon 10 May 2010 09:23 +1000, Allan McRae wrote:
> On 10/05/10 02:06, Loui Chang wrote:
> >On Sun 09 May 2010 16:21 +0200, Xavier Chantry wrote:
> >>But I just had an idea now, if we're thinking about AUR use case :
> >>makepkg --source could generate a suitable and parsable file providing
> >>all information that AUR needs, and ships that next to the PKGBUILD in
> >>the source tarball. Does that sound crazy ?
> >>This would not fix the problem now, but it could fix it eventually,
> >>when most pkgbuilds are re-submitted. Or this parsable file could be
> >>generated for all pkgbuilds in a row, just for the conversion, in a
> >>chroot/jail on a machine not in production.
> >
> >Yeah I've thought about this as well. Source packages could have a
> >similar format as binary packages with a .PKGINFO file to present the
> >metadata in an easily parsable format.
> >
> >You can read some of my incomplete brainstormings here:
> >http://louipc.mine.nu/arch/%5BRFC%5D-PKGINFO-in-srctargz
>
> I am told I like to be really negative anytime this is bought up...
> it is not deliberate, I just see the barriers to this working.  So
> here we go!  I know you have pointed out some problems already and
> this is related.

No problem. I didn't really share this before because I hadn't even
thought of a real solution. Since it was mentioned though, I thought I'd
share my thoughts. There are definitely many barriers to sort out.

> makepkg does not actually parse any of the splitpkg overrides until
> build time. How do we get the packaging variable overrides without
> actually making the package (and on every architecture)?  We would
> need to extract the needed fields from the package functions somehow.
> So that brings us back to needing to hack a bash parser in makepkg or
> to actually require the package building to take place before you can
> create a source package.  And this is not restricted to package
> splitting...
>
> e.g.
>
> pkgname=foo
> ...
> # depends not needed at make time
> # depends=('bar')
> ...
> package() {
>   depends=('bar')
> }
>
> Welcome to the world of makepkg hacks...   And do not think such
> hacks are not used.  The old klibc PKGBUILD generated a provides
> array in the build function on the basis of a file name only
> available at the end of the build process.

Yeah there'd have to be some kind of standard constructs for all these
kinds of hacks like platform specific dependencies, etc. That would
probably mean changing or expanding the PKGBUILD spec. I wouldn't be
afraid to do that, but it might not sit well with compatibility or with
Arch principles.

> The joy of PKGBUILDs is that they are so flexible.  The problem with
> PKGBUILDs is that they are so flexible.

Indeed.

Re: [arch-general] PKGBUILD parser

[Loui Chang]

On Sun 09 May 2010 16:21 +0200, Xavier Chantry wrote:
> On Sun, May 9, 2010 at 2:44 PM, Allan McRae  wrote:
> > Sourcing is dangerous if the PKGBUILD is from an untrusted source.  It also
> > fails with package splitting...

> But I just had an idea now, if we're thinking about AUR use case :
> makepkg --source could generate a suitable and parsable file providing
> all information that AUR needs, and ships that next to the PKGBUILD in
> the source tarball. Does that sound crazy ?
> This would not fix the problem now, but it could fix it eventually,
> when most pkgbuilds are re-submitted. Or this parsable file could be
> generated for all pkgbuilds in a row, just for the conversion, in a
> chroot/jail on a machine not in production.

Yeah I've thought about this as well. Source packages could have a
similar format as binary packages with a .PKGINFO file to present the
metadata in an easily parsable format.

You can read some of my incomplete brainstormings here:
http://louipc.mine.nu/arch/%5BRFC%5D-PKGINFO-in-srctargz

Re: [arch-general] [arch-dev-public] Redefining [testing] and a new [staging] repo

[Loui Chang]

On Fri 07 May 2010 13:12 -0400, Ray Kohler wrote:
> Even though I'm just a user, I'd like to add my support to this idea.
> I even considered proposing it myself less than a month ago. I run
> [testing], since I want to contribute to finding problems before they
> reach [core] and [extra], but I don't like having to deal with
> [testing] having rebuilds in it. I have never broken my systems by a
> bad package in [testing] but have unfortunately pulled incomplete
> rebuilds a few times now.

I tend to disable [testing] when there are huge rebuilds as well.
I really don't want to deal with potential breakage.

Re: [arch-general] Err... Why is gvim now conflicting with vim?

[Loui Chang]

On Fri 07 May 2010 10:01 -0500, Burlynn Corlew Jr wrote:
> On Fri, May 7, 2010 at 9:57 AM, David C. Rankin <
> drankina...@suddenlinkmail.com> wrote:
> 
> > On 05/07/2010 09:48 AM, Burlynn Corlew Jr wrote:
> > > On Fri, May 7, 2010 at 4:04 AM, Johannes Held  wrote:
> > >
> > >> http://www.archlinux.org/news/495/
> > >>
> > >> * If you have gvim installed, the update will inform you that vim
> > >> conflicts with gvim. This is the expected behavior. Installation
> > >> of vim and gvim separately is no longer required, the gvim
> > >> package now installs vim as well.
> > >
> > > This is a rolling release, not an LTS. There is no excuse to not
> > > be updating regularly and reading the news. If its a production
> > > machine and you are worried about breakage maybe you shouldnt be
> > > running arch on it. The ML, forums, and irc are full of people who
> > > refuse to read the news or update regularly, and we all waste time
> > > answering questions that with proper arch maintenance would ensure
> > > that they never come up.
> >
> > It's people like you that give arch a bad reputation. Grow up.
> 
> Saying you were wrong would be the more mature avenue. I did not bash
> or call names, I stated the obvious. This is not the first time the ML
> has been posted with your obvious questions.

Yeah. If you notice something odd on your system please take the time to
read the news before asking a question. If you have some more time maybe
check the forum and wiki as well.

Cheers.

Re: [arch-general] about arch

[Loui Chang]

On Thu 06 May 2010 18:08 +0900, Juan Diego Tascón wrote:
> I was reading the "about" page (http://www.archlinux.org/about/) in
> the archlinux website and I noticed that this line is a little
> outdated: "Arch also offers an [unsupported] section in the Arch Linux
> User Repository (AUR), which contains over 9,000 build scripts" It
> should say "over 21.000 build scripts".

WHAT?! NINE THOUSAND?!

Re: [arch-general] Raising identical task against multiple packages?

[Loui Chang]

On Sat 24 Apr 2010 20:21 +0100, Magnus Therning wrote:
> On 24/04/10 15:47, Loui Chang wrote:
> > On Sat 24 Apr 2010 11:06 +0100, Magnus Therning wrote:
> >> Is there a way to raise an identical task against multiple packages in
> >> FlySpray?
> >>
> >> I'd like to raise a task against all binary haskell-* packages, but I'd
> >> rather like to avoid wearing out my mouse doing it ;-)
> > 
> > Open one task and list all the packages in the details.
> 
> Is that just a suggestion from you, or the official Arch way of doing it?
> 
> The reason I'm asking is that I just don't see how raising a single
> task would make sure that it gets done.  There are more than one
> maintainer of the haskell-* packages in [extra] and [community].  Who
> would the task be assigned to?

I don't know if there's any 'official' way to do it, but other tasks
with multiple packages have been handled like this, and this is the most
logical way to handle it if you give it a moment's thought.

Assign it to everyone that maintains a haskell-* package.

Re: [arch-general] Raising identical task against multiple packages?

[Loui Chang]

On Sat 24 Apr 2010 11:06 +0100, Magnus Therning wrote:
> Is there a way to raise an identical task against multiple packages in
> FlySpray?
>
> I'd like to raise a task against all binary haskell-* packages, but
> I'd rather like to avoid wearing out my mouse doing it ;-)

Open one task and list all the packages in the details.

Re: [arch-general] what is this supposed to mean ?

[Loui Chang]

On Wed 21 Apr 2010 23:49 +0200, Matěj Týč wrote:
> On Thu, 2010-04-22 at 00:28 +0300, Evangelos Foutras wrote:
> > Please see the front page news. There are instructions regarding the
> > CUPS update. :)
>
> And I also think that it is not feasible to have to take a look at the
> frontpage if you upgrade like once a month, but the package creator can
> include a message in the PKGBUILD itself, so it doesn't seem to be a
> pacman flaw.

Yeah it would be nice if the warnings and notes could be included in the
pacman sync database somehow. Tying those messages directly to the
packages makes a lot of sense to me. As far as I know, this isn't
currently possible though.

Re: [arch-general] Java and/or MySQL geeks required

[Loui Chang]

On Tue 20 Apr 2010 17:32 +0530, Nilesh Govindarajan wrote:
> Me and my friend are doing a project to write a simplified ebook for
> students of high school in India. The syllabus has been changed a lot
> and the students have been introduced to the world of FOSS. The
> current physical book authors are completely Windows centered, so
> students will not have any examples, screenshots in Linux. At
> present, there are no contributors.
> 
> So, all those who are Java and/or MySQL experts and are willing to
> share their knowledge under CC-By-SA or CC-SA (Creative Commons)
> license without any royalty are humbly requested to reply to
> nilesh.3892 at gmail dot com
> 
> The project page is located at http://cbse065.eduvid.in/

This is awesome. I'm all for free and open texts.

Re: [arch-general] kaffeine [sigh] is there an alternative that:...

[Loui Chang]

On Tue 30 Mar 2010 19:26 +0200, Heiko Baums wrote:
> schrieb Xavier Chantry :
> 
> > Heh cmus is probably my preferred player now so I ought to defend it.
> > 
> > Too complicated, seriously ? The only command I ever need is the
> > initial one to add my music directory :
> >   # add files, short for ':add ~/music'
> >   :a ~/music
> 
> :add command: As I said complicated vi like commands.

I don't know what planet you come from, but that seems pretty simple and
straightforward to my inferior human brain.

Re: [arch-general] on rolling release / reinstallation

[Loui Chang]

On Wed 17 Mar 2010 16:01 -0400, Joe(theWordy)Philbrook wrote:
> So I'm guessing that these "workarounds" happen whenever a "pacman
> -Syu" leads to breaking something... (Which means that I probably
> should only do an "pacman -Syu" when A) I've got time to test all my
> stuff.  AND B) I've got time to look for a workaround that I hope
> someone else already figured out...)
> 
> My question is how often would you recommend doing a "pacman -Syu" to
> avoid having so many "workarounds" that you feel like it might have
> been easier to reinstall

It really depends on what happens during development.
I'd say once a month is a good frequency, but always remember to read
the announcements on archlinux.org.

You can also subscribe to the announcements mailing list:
http://mailman.archlinux.org/mailman/listinfo/arch-announce

Cheers.

Re: [arch-general] Something really wrong with yum-createrepo from AUR - doesn't work. [Solved - sort of]

[Loui Chang]

> On 03/13/2010 01:57 PM, David C. Rankin wrote:
> > The yum-createrepo package seems not to be the same as the
> > createrepo package that you normally see. Specifically executing
> > the yum-createrepo script with the help option discloses:
> > 

It's better if these things are documented on the package's AUR page.

Re: [arch-general] Bad attitude in flyspray again!

[Loui Chang]

On Fri 12 Mar 2010 14:11 -0600, Aaron Griffin wrote:
> On Fri, Mar 12, 2010 at 2:12 PM, Loui Chang  wrote:
> > On Fri 12 Mar 2010 13:28 -0600, Dan McGee wrote:
> >> On Fri, Mar 12, 2010 at 1:17 PM, Heiko Baums  wrote:
> >> > But just closing a bug should not be done. There's usually a reason why
> >> > a bug is reported even if it's invalid.
> >>
> >> Seriously, present some examples here, this talking in the abstract is
> >> stupid. We're all grown ups, no one is going to have their feelings
> >> hurt. Without them I'm sick of the back and forth on this- most devs
> >> leave bugs open for more than long enough to get feedback (and don't
> >> get it!), and we would all rather have bugs be either fixed or closed
> >> than hang around forever.
> >
> > I think another problem is that the bug wranglers aren't necessarily
> > involved in development and don't communicate with the developers before
> > taking action on a bug. That's no fault of the developer, but is a fault
> > with the bug wrangler.
> 
> Err? This sounds like quite a broad generalization without specific
> examples. Do *you* have any examples you'd like to share?

Sure. On occasion Paul Mattal will close or edit bugs in the AUR bug
tracker. He's no longer involved in development and hasn't communicated
with me about any of the tickets he touches.

Re: [arch-general] Bad attitude in flyspray again!

[Loui Chang]

On Fri 12 Mar 2010 13:28 -0600, Dan McGee wrote:
> On Fri, Mar 12, 2010 at 1:17 PM, Heiko Baums  wrote:
> > But just closing a bug should not be done. There's usually a reason why
> > a bug is reported even if it's invalid.
> 
> Seriously, present some examples here, this talking in the abstract is
> stupid. We're all grown ups, no one is going to have their feelings
> hurt. Without them I'm sick of the back and forth on this- most devs
> leave bugs open for more than long enough to get feedback (and don't
> get it!), and we would all rather have bugs be either fixed or closed
> than hang around forever.

I think another problem is that the bug wranglers aren't necessarily
involved in development and don't communicate with the developers before
taking action on a bug. That's no fault of the developer, but is a fault
with the bug wrangler.

Re: [arch-general] Bad attitude in flyspray again!

[Loui Chang]

On Fri 12 Mar 2010 09:34 -0600, Aaron Griffin wrote:
> Commenting on closed bugs is not doable in Flyspray.
> 
> More-over, I think it is a bad idea. The only reason people want
> commenting on closed bugs is so that they can argue with the
> developers - give reasons why the bug shouldn't be closed. That's what
> a reopen request is for. If that fails, then it's time to discuss it
> directly with the developer in question

That's not always true. There have been instances where I've commented
on closed bugs to point at an alternative solution or note where the bug
had been fixed where the developer neglected to.

Re: [arch-general] what is the procedure when your find an out-of-date package in AUR?

[Loui Chang]

On Thu 11 Mar 2010 11:50 -0600, Burlynn Corlew Jr wrote:
> On Thu, Mar 11, 2010 at 11:44 AM, Xavier Chantry
> wrote:
> > 2010/3/11 David C. Rankin :
> > > I just posted the new PKGBUILD files as 'comments' to the AUR
> > > package and sent Chris (the maintainer) an email telling him what
> > > I'd done.  Hopefully he can move cut and paste the new package
> > > versions and md5sums into the official PKGBUILD files and remove
> > > the out-of-date flag.
> >
> > You should probably have done the opposite :
> > - in AUR comments, just quickly state what needs to be changed / fixed
> > - in the email , include the proper attachments
> >
> > Pasting a pkgbuild in aur comments is ugly, takes a lot of space and
> > usually screws up the formatting enough to make it unusable in a very
> > confusing way.
>
> Sometimes pasting the pkgbuild in comments is the only solution, especially
> with lazy maintainers. :/ I've used a share posted that way, and a copy and
> paste seemed to work fine. Not that it will always work though, I still
> agree its bad practice, but short of another solution it is necessary at
> times.

Use a pastebin or something instead.

Re: [arch-general] [arch-dev-public] Clean up the base group

[Loui Chang]

On Sun 28 Feb 2010 01:59 +0530, Gaurish Sharma wrote:
> rp-pppoe should not be removed, Its very handy and easy to use tool.
> It was using it this tool I was able to connect the internet in
> ArchLinux. without it I won't be able to install arch. the alternative
> ppp is hard to configure.

Rp-pppoe doesn't need to stay in base to remain in core though. It
should be available to install via CD-ROM if it's in core.

Re: [arch-general] How to obtain development headers for package

[Loui Chang]

On Tue 23 Feb 2010 23:11 +, Michishige Kaito wrote:
> Maybe I'm just not understanding how Arch works, so please forgive my
> ignorance. I come from ubuntu, and there you get development headers for
> most packages by following the naming convention, which is package-dev. A
> quick apt-cache search package | grep dev would yield the right package.
> Now, I'm trying to obtain these on my fresh arch, but can't seem to find
> anything through pacman search or google. Anyone could hint me in the right
> direction?
> 
> If it's useful, I need the dev headers for sqlite3.

The standard practice in Arch is to keep development headers in the
package, so they should be included in the sqlite3 package. Contact the
package maintainer if anything is missing. Enjoy!

Re: [arch-general] [patch] AIF, discover repos on iso.

[Loui Chang]

On Fri 19 Feb 2010 22:26 +0100, Mark Pustjens wrote:
> The attached patch fixes a TODO in lib-pacman of aif.
> Instead of hardcoding that `core' is always available locally and
> falling back to net for others, it now checks /src/ for repos.
> 
> It assumes repos are stored at /src/$repo/pkg/. All these repos are
> added as cache dirs.
> 
> While preparing pacman, a number of repo names are provided to be
> prepared.
> 
> All those repos which were requested are added as actual repo. If
> this repo is available locally, the url points to disk. Otherwise it
> falls back to the mirrorlist.
> 
> Please let me know what you think.

Nice. You probably should send that to the arch-releng mailing list.

Re: [arch-general] An old, tiresome discussion: cdrtools vs cdrkit

[Loui Chang]

On Mon 25 Jan 2010 16:28 +0100, Joerg Schilling wrote:
> Heiko Baums wrote:
> 
> >I don't know anything about the technical differences between cdrkit
> >and cdrtools but http://cdrkit.org says:
> >News
> >2009/10/11
> >Cdrkit 1.1.10 has been released.
> 
> >So the last stable release was not a year but only three months ago.
> >This looks like an active development for me.
> 
> Please have a closer look on _what_ was changed in this "release".
> This have been mainly single char typo corrections but the > 100 well
> known bugs that exist as long as the fork exists have never been
> fixed. 
> 
> On the original software, you see more changes (enhancements and
> fixes) in a lazy week than the "cdrkit project" did get since May 6th
> 2007 in total.
> 
> In the fork, problems are ignored. In the original software, problems
> are fixed very soon; typically within hours. This is why there are no
> known problems in the original software.
> 
> The fork did not publish a single version that was known to be without
> bugs at the time of publishing. The original cdrtools project did
> publish more than 70 releases in the same time and more than 60 of
> them did have not a single bug when they have been published.

Maintainers of packages in Arch Linux may decide to package any software
whether it's a fork of an existing package or not.

If there are outstanding licensing or legal issues they may decide to
avoid that particular software.

The issue isn't really about bugs vs. no bugs. So let's stay on topic.
It's more about licenses and the legal ramifications that may come with
improper usage. I think Arch followed Debian because they seem to know a
lot more than we do. On the other hand, maybe we should be using debs
rather than .pkg.tar.gz if that's the case. (hah)

It is important to respect the caution that the devs are taking.
Personally, if it was my decision, I'd encourage any Arch dev or
TU who is interested in maintaining cdrtools to go ahead with it. I
don't have the same faith in Debian that a lot of others might.

Anyways, this package could easily be made available in an unofficial
repository until everyone is comfortable with the licensing. Don't rely
on the devs to do everything for you.

Re: [arch-general] Quoting of E-mails

[Loui Chang]

On Tue 12 Jan 2010 19:28 +0100, Guus Snijders wrote:
> On 12-01-10 06:27, Loui Chang wrote:
> >I think part of the problem is that some email clients like gmail
> >webmail help persist the bad behaviour. They default with top posting
> >replies and sending HTML emails. I have requested that they change the
> >defaults, but haven't gotten any response. It isn't a big surprise
> >though.
> 
> Actually, it /is/ configurable in gmail.

It may be configurable, but the defaults persist bad behaviour. They
really should be changed.

Re: [arch-general] Quoting of E-mails

[Loui Chang]

On Mon 11 Jan 2010 21:33 -0700, Steve Holmes wrote:
> re-read the old stuff over and over again.  Nothing annoys me more
> than haveing to page through five generations of past messages in a
> single thread to get all the way to the bottom just to have a single
> line of text say something like "Thank you" or "I agree" or whatever.

Fortunately I find that sort of thing isn't too common on the mailing
lists. Usually more interesting or useful commentary is added to the
discussion.

> The only thing that makes bottom-posting, like this bareable to me at
> all is Mutt's 'S' command which takes the cursor down to the unquoted
> text for much quicker reading.

I also find mutt's 'T' helps. It hides the quoted text.

> If bottom-posting is so passionately desirable, then may I suggest
> people trim down the history of a thread to the most recent 1 or 2
> generations back.  Or maybe even better, just reply with no quoting
> and and briefly summarize the quoted context.  Yeah, I realize quoting
> past context is more work.  I just find that when people top-post, I
> can seem to get through the mud a lot faster.

Indeed trimming quotes is part of proper email ettiquette along with
bottom posting. Sometimes I think people should pass a quiz before
they're allowed to post to the mailing list.

I think part of the problem is that some email clients like gmail
webmail help persist the bad behaviour. They default with top posting
replies and sending HTML emails. I have requested that they change the
defaults, but haven't gotten any response. It isn't a big surprise
though.

Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2

[Loui Chang]

On Mon 11 Jan 2010 13:54 -0500, Daenyth Blank wrote:
> On Mon, Jan 11, 2010 at 13:38, Aaron Griffin  wrote:
> > If you modify it, you should add it to the NoUpgrade line in
> > /etc/pacman.conf. The backup array is for what we INTEND to be
> > modified. Users are more than welcome to do what we don't intend, but
> > you need to control whether of not pacman mucks with those files
> > yourself
> 
> +1

I appreciate that you've added to the discussion.
I hope that we may reach a large sum total.
+100

Cheers!

Re: [arch-general] Looks like an AUR (web interface) bug?

[Loui Chang]

On Mon 04 Jan 2010 05:46 +0800, talki walki wrote:
> The following page of msort in AUR says "Package details could not be
> found."
> http://aur.archlinux.org/packages.php?ID=33319
>
> While one can fetch the package info using the rpc interface:
>
> wget 'http://aur.archlinux.org/rpc.php?type=search&arg=msort' -q -O-

Hmm that's very odd. Somehow the CategoryID was set at 0, which has no
value in the categories list.

I manually changed the ID.
The package should appear on the web site now.

How did you upload your package?

Re: [arch-general] Good press at distrowatch.com

[Loui Chang]

On Fri 18 Dec 2009 17:54 +0100, Dieter Plaetinck wrote:
> > I agree with Dieter, that the install should be measured by speed and
> > automation -- but long ago I realized that there a whole lot of other
> > people out there that just don't think like me :p
> 
> Don't misunderstand me.  An interactive hold-your-hand-a-bit
> installation processes is a good thing for many use cases (if
> implemented correctly).  There are many ways to judge
> installations by.  I'm only saying: if one chooses to judge an
> installation system by the criterion of speed, then (s)he better gets
> his/her facts right before calling our approach slow[er].

It's probably considered slower because there is a lot of prior
knowledge that is required. It may be easier (and faster) for someone
who has no computer background to install Ubuntu than to install Arch.

With Arch that person would have to do a lot more reading and learning,
which would take a lot more time.

Re: [arch-general] Single Person ISP?

[Loui Chang]

On Thu 19 Nov 2009 00:44 -0700, Brendan Long wrote:
> So recently Verizon has stopped letting me do free tethering and I've
> been looking for a replacement. Apparently all of the free ISPs I can
> find all require that you use their shitty Windows program to connect,
> so I decided, "I have a phone line, a modem and an internet connection,
> maybe I can make my own ISP".

There are probably ways around that windows program requirement for the
free ISPs. Years ago I was able to connect to AOL using a program called
penggy.

Re: [arch-general] Arch Linux Magazine

[Loui Chang]

On Mon 02 Nov 2009 19:26 -0600, Daniel J Griffiths wrote:
> Loui Chang wrote:
> >Hey guys. I'm just curious. What's going on with the magazine?
> >Is there any intent to revive it?
> >
> >I know that I'd look forward to news/forum summaries at least if there
> >isn't time for all the other stuff.
> >
> >Cheers.
> >
> I received the above email from Loui on the 31st and have been
> putting a good deal of thought into the current magazine/newsletter
> situation. As many of you know, Kensai recently moved and got married
> and I recently moved and have been trying to find a job. Shortly
> before receiving this email, Kensai and I had discussed the issue,
> but we didn't come to any real decisions. Hence, I'm sending my
> thoughts to the community and letting you in on the discussion.
> 
> One of the possibilities that was brought up was separating the
> newsletter and magazine, much as it was when I first started AUM. I
> do not believe this is a good course of action due to one of the main
> reasons for the merger: the licensing rights to the Arch name and
> logo. While the magazine did well on its own, I simply can't afford
> to maintain the domain and server for it without help from the
> community, but I can't accept financial contributions for said
> project as long as it is using Arch branding.
> 
> On the other hand, leaving it the way it is is proving difficult. I
> don't know Kensai's current situation, but I'm seeing less and less
> of him online which makes submission of any completed
> magazine/newsletter issues difficult as he is the only one with
> upload rights to the server currently on staff. My situation has
> settled down enough that I am now able to dedicate the time necessary
> to continue production of the magazine/newsletter as I used to. In
> fact, I have a good bit of content ready for the next release,
> whenever that becomes possible.
> 
> I would like to see the magazine/newsletter make a comeback to where
> we were when we left off and then some. I want to see more community
> contributions, writers, I'd like to get the Schwag report back
> (Dusty, that's you if you're still up to it), etc. This is a big
> project that has greatly benefited our community and I hate to see it
> in it's current state. Please let me know what you all think so that
> we can expedite the release of another issue!
> 
> @Kensai: Let me know what your current situation is (I know how being
> a newlywed is, been there a few times now...), and either way, best
> of luck (hopefully your luck is better than my first attempt was).

My solution would be to give you full news editor permissions making you
the defacto editor. If the current editor doesn't come back into the
picture then you can officially be declared Boss of the Magazine.