Re: [arch-general] Automatic File Associations Alloting

[Jayesh Badwaik]

ohk... I will see that...
i was thinking something very simple
I was thinking more along the lines of a utility to create a mimeinfo.list
from a description file. (XML or something like that)
That description file can be provided by the package and then whenever
it gets updated. There are certain parameters in the description file
which will allow for easy parsing and processing. The program will read the
the mimeinfo.xml file on system and one with the package. Then,
will check for conflicts and ask the user to resolve them using some sort of
interface (plain text or ncurses). That way, there is a clean interface
on what to do. It will be compatible with the current DE and does not
present any special requirements.

However, I will see the program. I never heard of it before to tell the truth.
I'll see it and then get back to you.

Bye!

--
Cheers and Regards
Jayesh Vinay Badwaik
Electronics and Communication Engineering
VNIT, INDIA
-





On Wed, Nov 23, 2011 at 7:38 AM, Oon-Ee Ng  wrote:
> On Tue, Nov 22, 2011 at 6:15 PM, Jayesh Badwaik
>  wrote:
> 
>>
>> I am thinking of writing a small program to do so. I'll let you know
>> how I am progressing. Right
>> now I only have a design in my mind and I have some exams coming up in
>> three-four days.
>> So after I am done with them, I would put my plans into action. I can
>> post my plans
>> and if they are any good, we can try developing something. I haven't
>> got time right now
>> so I cannot even make the docs.
>
> xdg-open? Xyne wrote mimeo to help manage mime-types, been using that
> with xdg-utils-mimeo from the AUR for a while now...
>

Re: [arch-general] Automatic File Associations Alloting

[Oon-Ee Ng]

On Tue, Nov 22, 2011 at 6:15 PM, Jayesh Badwaik
 wrote:

>
> I am thinking of writing a small program to do so. I'll let you know
> how I am progressing. Right
> now I only have a design in my mind and I have some exams coming up in
> three-four days.
> So after I am done with them, I would put my plans into action. I can
> post my plans
> and if they are any good, we can try developing something. I haven't
> got time right now
> so I cannot even make the docs.

xdg-open? Xyne wrote mimeo to help manage mime-types, been using that
with xdg-utils-mimeo from the AUR for a while now...

[arch-general] libgphoto2 2.4.10.1-2 udev rules not matching

[Ruslan Nabioullin]

I am trying to access a camera using the gphoto2 frontend to x86_64 libgphoto2 
2.4.10.1-2, which installs a udev rules file to 
/lib/udev/rules.d/40-gphoto.rules.


40-gphoto.rules (abridged):

# udev rules file for libgphoto2 devices (for udev 136 version)
# Created from this library:
#   libgphoto2  2.4.10.1   gcc, ltdl, EXIF
#   libgphoto2_port 0.8.0  gcc, ltdl, USB, serial without locking
#
# this file is autogenerated, local changes will be LOST on upgrades
ACTION!="add", GOTO="libgphoto2_rules_end"
SUBSYSTEM!="usb", GOTO="libgphoto2_usb_end"
ENV{DEVTYPE}!="usb_device", GOTO="libgphoto2_usb_end"

ENV{ID_USB_INTERFACES}=="", IMPORT{program}="usb_id --export %p"
ENV{ID_USB_INTERFACES}=="*:08*:*", GOTO="libgphoto2_usb_end"
ENV{ID_USB_INTERFACES}=="*:060101:*", ENV{ID_GPHOTO2}="1", 
ENV{GPHOTO2_DRIVER}="PTP", GOTO="libgphoto2_usb_end"
...
ATTRS{idVendor}=="04a9", ATTRS{idProduct}=="315d", ENV{ID_GPHOTO2}="1", 
ENV{GPHOTO2_DRIVER}="proprietary", MODE="0660", GROUP="camera"
...
LABEL="libgphoto2_usb_end"

...
LABEL="libgphoto2_rules_end"


When I connect a camera (which is listed as supported by the libgphoto2 
webpages), udevadm reports the following event:


UDEV  [18908.43] add  /devices/pci:00/:00:1d.7/usb2/2-2 (usb)
ACTION=add
BUSNUM=002
COLORD_DEVICE=1
COLORD_KIND=camera
DEVICE=/proc/bus/usb/002/017
DEVNAME=/dev/bus/usb/002/017
DEVNUM=017
DEVPATH=/devices/pci:00/:00:1d.7/usb2/2-2
DEVTYPE=usb_device
GPHOTO2_DRIVER=PTP
ID_BUS=usb
ID_GPHOTO2=1
ID_MODEL=Canon_Digital_Camera
ID_MODEL_ENC=Canon\x20Digital\x20Camera
ID_MODEL_ID=315d
ID_REVISION=0002
ID_SERIAL=Canon_Inc._Canon_Digital_Camera_3DEABCB4221D4B9A8677BD305FF7A362
ID_SERIAL_SHORT=3DEABCB4221D4B9A8677BD305FF7A362
ID_USB_INTERFACES=:060101:
ID_VENDOR=Canon_Inc.
ID_VENDOR_ENC=Canon\x20Inc.
ID_VENDOR_ID=04a9
MAJOR=189
MINOR=144
PRODUCT=4a9/315d/2
SEQNUM=1971
SUBSYSTEM=usb
TAGS=:udev-acl:
TYPE=0/0/0
UDEV_LOG=3
USEC_INITIALIZED=18907744211


ID_VENDOR_ID, ID_MODEL_ID, and ID_GPHOTO2 matches, but GPHOTO2_DRIVER does not 
("PTP" does not match "proprietary").
As a result, /dev/bus/usb/002/017 is owned by the "root" group, instead of the 
"camera" group, thus preventing the use of gphoto2 due to no write permissions:


crw-rw-r-- 1 root root 189, 144 Nov 22 18:23 017


In fact, I have tried chgrp'ing the aforementioned device file to "camera", and 
gphoto2 successfully functioned inasmuch as I tested it (except for an error 
when gphoto2 tried accessing some other USB device file as well for some 
reason, but this did not impact functionality).

Any ideas why the udev rules file was written under the assumption that the 
camera vendor and model ("Canon:PowerShot A720 IS (PTP mode)",  0x04a9, 0x315d) 
uses a "proprietary" driver instead of "PTP"? I have found a possible solution 
(https://wiki.archlinux.org/index.php/Digital_Cameras#Permission_issues) but I 
have not tested it since I see no reason why the libgphoto2 package should not 
work with this camera vendor and model by default.

Thanks in advance,
-Ruslan

-- 
Ruslan Nabioullin
rnabioul...@gmail.com

Re: [arch-general] pacman new generation

[Leonid Isaev]

On (11/22/11 11:30), Bernardo Barros wrote:
-~> If I still may:
-~> 
-~> roll-back and reproducible configuration was already proposed in the past?
-~> 
-~> The idea raised by Nix devs was the a purely functional approach was a
-~> way to implement it. Of course people can have similar ideas with
-~> other techniques.
-~> 
-~> If it a very practical question because I'm sure all Arch users in
-~> some point or another had to do a roll-back after a complex system
-~> update, and then they find themselves in a difficult situation to
-~> figure out how to revert all those changes.
-~> 
-~> Pro Audio users, for instance, might want to have their system
-~> configuration in a state just before the change that broke lv2 support
-~> on Ardour.
-~> 
-~> Nix approach may be not the only one, but their ideas let people see
-~> the difference between same packages build with different libs, or
-~> know to set a exact system configuration more easily.

But config files are always preserved, and severe breakage is avoided by using
testing. Where does the roll-back fit in here?

Next, it is OK to have /nix/store/-gcc, but what about
/nix/store/-libpng? Even a minor upgrade requires relinking? 

IMHO, somebody needed to write a phd thesis, so this problem came up. As a
research project NixOS is fine. But as a sustainable distro it's not. Another
example that is unlikely to lift off is Qubes OS which is probably the most
secure linux distro, but highly unpractical.

The question which I always have in such cases is why not bring your ideas to
something already mature like dpkg/rpm? Probably they did ask on respective ML
and got rejected after being unable to address the above and similar questions.

-- 
Leonid Isaev
GnuPG key ID: 164B5A6D
Key fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D


pgpmKuWCfxfcY.pgp
Description: PGP signature

Re: [arch-general] pacman new generation

[Buce]

On Tue, Nov 22, 2011 at 2:05 PM, Isaac Dupree <
m...@isaac.cedarswampstudios.org> wrote:

> On 11/22/2011 02:41 PM, Karol Blazewicz wrote:
>
>> I using testing / staging repos does this already: you try out
>> [testing], if it doesn't work, you disable it and run 'pacman -Suu'.
>> Would using different sync dbs and a separate cache turned into a
>> local repo make it easy enough to be practical?
>>
>
> Also, pacsnap[1] does a good enough job for me.  Which is to take maybe
> 70% of the risk out of upgrading -- sure, a reversion won't work all the
> time, but I need it rarely enough that the low overhead of pacsnap is more
> convenient for me than the risk of living with a partly-broken system until
> it's fixed upstream is bad.
>
> That being said, if someone polishes btrfs snapshots, I might use that
> instead.  (Once I switch to btrfs, that is.)
>
> [1] 
> http://aur.archlinux.org/**packages.php?ID=34290
>

People keep bringing up btrfs snapshots but no one's mentioned LVM
snapshots. Is it not worthwhile? I've been meaning to try it out for a
while now.

Re: [arch-general] pacman new generation

[Isaac Dupree]

On 11/22/2011 02:41 PM, Karol Blazewicz wrote:

I using testing / staging repos does this already: you try out
[testing], if it doesn't work, you disable it and run 'pacman -Suu'.
Would using different sync dbs and a separate cache turned into a
local repo make it easy enough to be practical?


Also, pacsnap[1] does a good enough job for me.  Which is to take maybe 
70% of the risk out of upgrading -- sure, a reversion won't work all the 
time, but I need it rarely enough that the low overhead of pacsnap is 
more convenient for me than the risk of living with a partly-broken 
system until it's fixed upstream is bad.


That being said, if someone polishes btrfs snapshots, I might use that 
instead.  (Once I switch to btrfs, that is.)


[1] http://aur.archlinux.org/packages.php?ID=34290

Re: [arch-general] uname26 - Where is it?

[Norbert Zeh]

Thomas Bächler [2011.11.22 2045 +0100]:
> Am 22.11.2011 20:17, schrieb Karol Babioch:
> > Hi,
> > 
> > Am 22.11.2011 19:24, schrieb Thomas Bächler:
> >> $ setarch $(arch) --uname-2.6 uname -a
> >> Linux evey 2.6.41-1-ARCH #1 SMP PREEMPT Fri Nov 11 22:28:29 CET 2011
> >> x86_64 Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz GenuineIntel GNU/Linux
> > 
> > So this seems to mean that setarch makes uname26 quite useless. I
> > haven't realized that, so I'm sorry for my request in the first place.
> > 
> > Thanks for the fast replay anyway.
> 
> 'setarch' also makes 'linux32' useless, yet it exists. Anyway, 'setarch'
> can do it all.

Actually, I just checked: linux32 *is* setarch, at least now:

$ ls -l /usr/bin/linux32 
lrwxrwxrwx 1 root root 7 Oct 20 07:55 /usr/bin/linux32 -> setarch

Cheers,
Norbert

Re: [arch-general] pacman new generation

[Karol Blazewicz]

On Tue, Nov 22, 2011 at 9:01 PM, Bernardo Barros
 wrote:
> A layer above pacman taking advantage of ARM?

ARM is limited to official repos, but you don't need another layer,
just use http://arm.konnichi.com/2011/11/21/ as your server and run
'pacman -Suu' to downgrade.

Re: [arch-general] pacman new generation

[Bernardo Barros]

A layer above pacman taking advantage of ARM?

Re: [arch-general] pacman new generation

[Calvin Morrison]

On 22 November 2011 14:42, C Anthony Risinger  wrote:

> On Nov 22, 2011 1:30 PM, "Bernardo Barros" 
> wrote:
> >
> > If I still may:
> >
> > roll-back and reproducible configuration was already proposed in the
> past?
> >
> > The idea raised by Nix devs was the a purely functional approach was a
> > way to implement it. Of course people can have similar ideas with
> > other techniques.
> >
> > If it a very practical question because I'm sure all Arch users in
> > some point or another had to do a roll-back after a complex system
> > update, and then they find themselves in a difficult situation to
> > figure out how to revert all those changes.
> >
> > Pro Audio users, for instance, might want to have their system
> > configuration in a state just before the change that broke lv2 support
> > on Ardour.
> >
> > Nix approach may be not the only one, but their ideas let people see
> > the difference between same packages build with different libs, or
> > know to set a exact system configuration more easily.
>
> The only clear way to achieve clean rollbacks is to snapshot at the FS
> level ... otherwise things get real complicated, real fast.
>
> Some packages are one-way only, eg. Pacman 3.5 upgrade to DB, and
> "rollback" means saving the original, etc ...
>
> As already touched in the thread, btrfs makes this trivial.
> `mkinitcpio-btrfs` will provide 95% of what's needed already.  The hook
> could definitely use some love but it fulfills the suggested use case
> nicely, and also allows for comparison between snapshots.
>
> C Anthony
>

Honestly I don't know how this topic got so off-topic so quickly!

I think it is obvious that pacman will not get rewritten in Haskell, so
lets just stop talking about that - arguing over languages is like arguing
over window mangers, cmon people!

Secondly, I agree that snapshots must be done at a system level. It does
not make sense to re-implement something that is already being done better
by the file system. I think the OP had some ideas about rolling changes
back, I don't think he was really familiar with ARM which handles most of
that he was worried about.

Remember, you gotta KISS it or else you'll miss it!

:-)

Re: [arch-general] uname26 - Where is it?

[Thomas Bächler]

Am 22.11.2011 20:17, schrieb Karol Babioch:
> Hi,
> 
> Am 22.11.2011 19:24, schrieb Thomas Bächler:
>> $ setarch $(arch) --uname-2.6 uname -a
>> Linux evey 2.6.41-1-ARCH #1 SMP PREEMPT Fri Nov 11 22:28:29 CET 2011
>> x86_64 Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz GenuineIntel GNU/Linux
> 
> So this seems to mean that setarch makes uname26 quite useless. I
> haven't realized that, so I'm sorry for my request in the first place.
> 
> Thanks for the fast replay anyway.

'setarch' also makes 'linux32' useless, yet it exists. Anyway, 'setarch'
can do it all.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] pacman new generation

[C Anthony Risinger]

On Nov 22, 2011 1:30 PM, "Bernardo Barros" 
wrote:
>
> If I still may:
>
> roll-back and reproducible configuration was already proposed in the past?
>
> The idea raised by Nix devs was the a purely functional approach was a
> way to implement it. Of course people can have similar ideas with
> other techniques.
>
> If it a very practical question because I'm sure all Arch users in
> some point or another had to do a roll-back after a complex system
> update, and then they find themselves in a difficult situation to
> figure out how to revert all those changes.
>
> Pro Audio users, for instance, might want to have their system
> configuration in a state just before the change that broke lv2 support
> on Ardour.
>
> Nix approach may be not the only one, but their ideas let people see
> the difference between same packages build with different libs, or
> know to set a exact system configuration more easily.

The only clear way to achieve clean rollbacks is to snapshot at the FS
level ... otherwise things get real complicated, real fast.

Some packages are one-way only, eg. Pacman 3.5 upgrade to DB, and
"rollback" means saving the original, etc ...

As already touched in the thread, btrfs makes this trivial.
`mkinitcpio-btrfs` will provide 95% of what's needed already.  The hook
could definitely use some love but it fulfills the suggested use case
nicely, and also allows for comparison between snapshots.

C Anthony

Re: [arch-general] pacman new generation

[Karol Blazewicz]

On Tue, Nov 22, 2011 at 8:30 PM, Bernardo Barros
 wrote:
> If I still may:
>
> roll-back and reproducible configuration was already proposed in the past?
>
> The idea raised by Nix devs was the a purely functional approach was a
> way to implement it. Of course people can have similar ideas with
> other techniques.
>
> If it a very practical question because I'm sure all Arch users in
> some point or another had to do a roll-back after a complex system
> update, and then they find themselves in a difficult situation to
> figure out how to revert all those changes.
>
> Pro Audio users, for instance, might want to have their system
> configuration in a state just before the change that broke lv2 support
> on Ardour.
>
> Nix approach may be not the only one, but their ideas let people see
> the difference between same packages build with different libs, or
> know to set a exact system configuration more easily.
>

I using testing / staging repos does this already: you try out
[testing], if it doesn't work, you disable it and run 'pacman -Suu'.
Would using different sync dbs and a separate cache turned into a
local repo make it easy enough to be practical?

Re: [arch-general] pacman new generation

[Bernardo Barros]

If I still may:

roll-back and reproducible configuration was already proposed in the past?

The idea raised by Nix devs was the a purely functional approach was a
way to implement it. Of course people can have similar ideas with
other techniques.

If it a very practical question because I'm sure all Arch users in
some point or another had to do a roll-back after a complex system
update, and then they find themselves in a difficult situation to
figure out how to revert all those changes.

Pro Audio users, for instance, might want to have their system
configuration in a state just before the change that broke lv2 support
on Ardour.

Nix approach may be not the only one, but their ideas let people see
the difference between same packages build with different libs, or
know to set a exact system configuration more easily.

Re: [arch-general] uname26 - Where is it?

[Karol Babioch]

Hi,

Am 22.11.2011 19:24, schrieb Thomas Bächler:
> $ setarch $(arch) --uname-2.6 uname -a
> Linux evey 2.6.41-1-ARCH #1 SMP PREEMPT Fri Nov 11 22:28:29 CET 2011
> x86_64 Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz GenuineIntel GNU/Linux

So this seems to mean that setarch makes uname26 quite useless. I
haven't realized that, so I'm sorry for my request in the first place.

Thanks for the fast replay anyway.

Best regards,
Karol Babioch



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] uname26 - Where is it?

[Karol Blazewicz]

On Tue, Nov 22, 2011 at 7:12 PM, Karol Babioch  wrote:
> Hi,
>
> I've looked around for the last couple of weeks for a package providing
> uname26 [1]. However I couldn't find such and in the mean time compiled
> it for myself.
>
> I've also searched for the appearance of uname26 in the forums and the
> mailing lists and couldn't find that much about it.
>
> So I'm wondering whether nobody of you was (and/or is) affected by the
> kernel version scheme change, so that there is no need for you to have
> this package?
>
> As it is quite simple to get and compile this code, it wouldn't be that
> much of a hassle to package it. However I'm not that much into
> packaging, so I wouldn't like to do it, unless I have to.
>
> I'm not asking anyone of you to do the packaging, and considering myself
> to get into it (the whole Arch Build System), but I'm wondering why
> nobody of you seems to have a need for it ;)?
>
> Best regards,
> Karol Babioch
>
>

https://bugs.archlinux.org/task/25747 <- people complained
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=be27425dcc516fd08245b047ea57f83b8f6f0903
<- uname26 commit

Re: [arch-general] uname26 - Where is it?

[Thomas Bächler]

Am 22.11.2011 19:12, schrieb Karol Babioch:
> Hi,
> 
> I've looked around for the last couple of weeks for a package providing
> uname26 [1]. However I couldn't find such and in the mean time compiled
> it for myself.

$ setarch $(arch) --uname-2.6 uname -a
Linux evey 2.6.41-1-ARCH #1 SMP PREEMPT Fri Nov 11 22:28:29 CET 2011
x86_64 Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz GenuineIntel GNU/Linux



signature.asc
Description: OpenPGP digital signature

[arch-general] uname26 - Where is it?

[Karol Babioch]

Hi,

I've looked around for the last couple of weeks for a package providing
uname26 [1]. However I couldn't find such and in the mean time compiled
it for myself.

I've also searched for the appearance of uname26 in the forums and the
mailing lists and couldn't find that much about it.

So I'm wondering whether nobody of you was (and/or is) affected by the
kernel version scheme change, so that there is no need for you to have
this package?

As it is quite simple to get and compile this code, it wouldn't be that
much of a hassle to package it. However I'm not that much into
packaging, so I wouldn't like to do it, unless I have to.

I'm not asking anyone of you to do the packaging, and considering myself
to get into it (the whole Arch Build System), but I'm wondering why
nobody of you seems to have a need for it ;)?

Best regards,
Karol Babioch



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] pacman new generation

[Norbert Zeh]

Taylor Hedberg [2011.11.22 1036 -0500]:
> Nicolas Sebrecht, Tue 2011-11-22 @ 16:24:02+0100:
> > I don't think, so. IMHO, the pool of contributors is bigger with a
> > high-level language than for C, simply because the learning curve of a
> > good high-level language is much shorter.
> 
> You can't seriously be suggesting that switching to Haskell would
> increase the size of the pacman developer pool. I think Haskell is
> great too, but if you think it's bigger than C just because it's
> high-level, you're delusional. Even on a distro like Arch, where there
> seems to be a disproportionate number of Haskell users, I'd wager that
> there are still far more people here that know C.
> 
> The learning curve of Haskell is widely regarded as one of the steepest
> in programming. There are plenty of arguments to be made in its favor,
> but that is not one of them.
> 
> C is the lingua franca of Unix, practically everyone knows it, or at
> least enough of it to be moderately competent. It makes sense to keep
> community-developed projects like pacman in a widely-known and used
> language so that more people can understand the code and contribute. I
> don't think there's any compelling reason to rewrite pacman in another
> language.

I think this discussion has dragged on for too long and the points that should
have been made have been made already - so I was reluctant to respond.  However,
I felt I needed to chime in here to say that I think that Taylor hit the nail on
the head.  I am a big proponent of Haskell - it's pretty much the only language
I use nowadays for any of my toy projects - but it's not an easy language to
learn to use effectively.  For that reason, the pool of Haskell developers out
there is much smaller than the pool of C programmers.  Furthermore, from my own
experience I know that writing good Haskell code poses its own set of challenges
exactly *because* the language is so expressive, not unlike writing Perl code,
which in the areas it was designed for is also highly expressive.  I sometimes
step into the trap of expressing my computation as succinctly as possible...and
the result is write-only code where I, being the author of the code, need 5
minutes to figure out what a cleverly crafted 2-line function does when looking
at the code 3 months after I wrote it.

So, given that the current team behind pacman is using C to develop it and
manages to churn out very high-quality code with it, the only reasonable
approach to convince people that Haskell would indeed be a better choice is to
demonstrate that there exists a group of Haskell-savvy arch users/developers out
there that can first reimplement pacman in Haskell, in a way that matches or
comes close to the performance of the current C implementation, and can then
capitalize on the expressiveness of Haskell to add new features more quickly
than would have been possible using the current C implementation, without
sacrificing performance, stability or readability of the code.

Cheers,
Norbert

Re: [arch-general] pacman new generation

[Piyush P Kurur]

On Tue, Nov 22, 2011 at 05:16:27PM +0100, Nicolas Sebrecht wrote:
> The 22/11/11, Piyush P Kurur wrote:
> 

> Notice I'm not the OP show suggested porting pacman to Haskell. I came
> into this thread after the facts and tried hard to make the original
> suggestion as a part of the larger POV in favor of high-level languages.
> 

Writing system managing tools in Haskell is not a bad suggestion at
all. You might have read about Linspire/Freespire which is a debian
based distro having a substantial part written in Haskell (I have not
used it so I dont know how much of a success it was).


> Also, I don't want to flame and rather keep the discussion out of free
> attacks against the current team of developers. I took part of this
> thread only because I've already been faced to pacman limitations in its
> current form.
> 

NixOS uses a radically differnet and, in my opinion, brilliant idea to
support Rollbacks (again I have not used NixOS but have read about
them). It keeps all the packages in a different directory called
/store if I remember right.  Each package is installed in a
directory of its own like 

/store/firefox-version-sha1-hash

where the hash will depend on the package source and config options.

This kind of architecture allows lots of interesting stuff like user
installation and secure sharing of installations by users, multiple
versions of the same file, automatic shared library dependency besides
atomic rollbacks of course. Overall it is a very promising idea which
is also working well (I think) in practice. There are drawbacks of
course like large harddisk space for example.

Now how much of this will fit with Arch. Very little. Arch has a very
different structure. Pacman was not written with this kind of a goal.
So I dont see an easy way all this can be achieved with a structure
like Arch.

Having a great package management is only one part of the story, one
still needs the good quality packages. And that is the really hard
part.

Regards

ppk

[arch-general] Re: pacman new generation

[Nicolas Sebrecht]

The 22/11/11, Piyush P Kurur wrote:

> Many here will agree to almost all the points that you raised about
> Haskell. However the way the you introdued might have irked some.

I'm sorry about that. Poor circumstances might give this wrong
impression.

> Here is how one would go about suggesting such a changes:
> 
> "Hi folks I was interested to know whether implementing rollbacks like
> NixOS is interesting for people here. Since I feel that C is too low
> level as a first step  I am attempting a port of pacman to Haskell.
> The code is available under darcs at http://somewhere.org/me/
> Patches are welcome. The current version does nothign but prints
> package meta info.
> 
> Regards
> 
> me"

Notice I'm not the OP show suggested porting pacman to Haskell. I came
into this thread after the facts and tried hard to make the original
suggestion as a part of the larger POV in favor of high-level languages.

Also, I don't want to flame and rather keep the discussion out of free
attacks against the current team of developers. I took part of this
thread only because I've already been faced to pacman limitations in its
current form.

-- 
Nicolas Sebrecht

Re: [arch-general] pacman new generation

[Piyush P Kurur]

On Tue, Nov 22, 2011 at 04:53:53PM +0100, Nicolas Sebrecht wrote:
> The 22/11/11, Rodrigo Amorim Bahiense wrote:
> > On 11/22/2011 13:36, Taylor Hedberg wrote:
> 
> > >You can't seriously be suggesting that switching to Haskell would
> > >increase the size of the pacman developer pool.
> 
> Notice I didn't support Haskell. I'm talking about high-level languages
> in general. Not all of these languages are widely used nor very scalable
> for a package manager.

Many here will agree to almost all the points that you raised about
Haskell. However the way the you introdued might have irked some.

Here is how one would go about suggesting such a changes:

"Hi folks I was interested to know whether implementing rollbacks like
NixOS is interesting for people here. Since I feel that C is too low
level as a first step  I am attempting a port of pacman to Haskell.
The code is available under darcs at http://somewhere.org/me/
Patches are welcome. The current version does nothign but prints
package meta info.

Regards

me"

[arch-general] Re: pacman new generation

[Nicolas Sebrecht]

The 22/11/11, Taylor Hedberg wrote:

> Maybe not, but the person I was replying to was making the specific
> argument that higher-level languages like Haskell would be more suitable
> for a tool like pacman because a larger number of people would be able
> to contribute. I was simply pointing out the fact that that is certainly
> not the case for Haskell in particular.
> 
> I don't think popularity is irrelevant, either, assuming you are
> interested in increasing the volume of contributions to your project. If
> you pick a relatively obscure language to work in, you are just creating
> another barrier that makes it harder for new people to become acquainted
> with the codebase.

Here is a very good resume of this aspect of the discussion and we fully
agree, here.

-- 
Nicolas Sebrecht

[arch-general] Re: pacman new generation

[Nicolas Sebrecht]

The 22/11/11, Rodrigo Amorim Bahiense wrote:
> On 11/22/2011 13:36, Taylor Hedberg wrote:

> >You can't seriously be suggesting that switching to Haskell would
> >increase the size of the pacman developer pool.

Notice I didn't support Haskell. I'm talking about high-level languages
in general. Not all of these languages are widely used nor very scalable
for a package manager.

> > I
> >don't think there's any compelling reason to rewrite pacman in another
> >language.

I already gave some good reasons in this thread, though.

> Code language should not be chosen based on popularity. C is used in
> most unix-like software because of its quality and not as a
> consequence of the available developer pool for it.

I tend to agree.

-- 
Nicolas Sebrecht

Re: [arch-general] pacman new generation

[Taylor Hedberg]

Rodrigo Amorim Bahiense, Tue 2011-11-22 @ 13:43:58-0200:
> Code language should not be chosen based on popularity. C is used in
> most unix-like software because of its quality and not as a
> consequence of the available developer pool for it.

Maybe not, but the person I was replying to was making the specific
argument that higher-level languages like Haskell would be more suitable
for a tool like pacman because a larger number of people would be able
to contribute. I was simply pointing out the fact that that is certainly
not the case for Haskell in particular.

I don't think popularity is irrelevant, either, assuming you are
interested in increasing the volume of contributions to your project. If
you pick a relatively obscure language to work in, you are just creating
another barrier that makes it harder for new people to become acquainted
with the codebase.


pgpU19bezaOpT.pgp
Description: PGP signature

Re: [arch-general] pacman new generation

[Rodrigo Amorim Bahiense]

On 11/22/2011 13:36, Taylor Hedberg wrote:

Nicolas Sebrecht, Tue 2011-11-22 @ 16:24:02+0100:

I don't think, so. IMHO, the pool of contributors is bigger with a
high-level language than for C, simply because the learning curve of a
good high-level language is much shorter.

You can't seriously be suggesting that switching to Haskell would
increase the size of the pacman developer pool. I think Haskell is
great too, but if you think it's bigger than C just because it's
high-level, you're delusional. Even on a distro like Arch, where there
seems to be a disproportionate number of Haskell users, I'd wager that
there are still far more people here that know C.

The learning curve of Haskell is widely regarded as one of the steepest
in programming. There are plenty of arguments to be made in its favor,
but that is not one of them.

C is the lingua franca of Unix, practically everyone knows it, or at
least enough of it to be moderately competent. It makes sense to keep
community-developed projects like pacman in a widely-known and used
language so that more people can understand the code and contribute. I
don't think there's any compelling reason to rewrite pacman in another
language.


Code language should not be chosen based on popularity. C is used in 
most unix-like software because of its quality and not as a consequence 
of the available developer pool for it.


--
Rodrigo

Re: [arch-general] pacman new generation

[Taylor Hedberg]

Nicolas Sebrecht, Tue 2011-11-22 @ 16:24:02+0100:
> I don't think, so. IMHO, the pool of contributors is bigger with a
> high-level language than for C, simply because the learning curve of a
> good high-level language is much shorter.

You can't seriously be suggesting that switching to Haskell would
increase the size of the pacman developer pool. I think Haskell is
great too, but if you think it's bigger than C just because it's
high-level, you're delusional. Even on a distro like Arch, where there
seems to be a disproportionate number of Haskell users, I'd wager that
there are still far more people here that know C.

The learning curve of Haskell is widely regarded as one of the steepest
in programming. There are plenty of arguments to be made in its favor,
but that is not one of them.

C is the lingua franca of Unix, practically everyone knows it, or at
least enough of it to be moderately competent. It makes sense to keep
community-developed projects like pacman in a widely-known and used
language so that more people can understand the code and contribute. I
don't think there's any compelling reason to rewrite pacman in another
language.


pgpCYh19RHE36.pgp
Description: PGP signature

[arch-general] Re: pacman new generation

[Nicolas Sebrecht]

The 22/11/11, Magnus Therning wrote:
> On Tue, Nov 22, 2011 at 13:02, Nicolas Sebrecht  wrote:

> > But it's missing advanced features.
> >
> > OP raised rollbacks, I'd rather talk about simultaneous/concurrency
> > pacman calls and mutli-threading to handle packages installation where
> > applicable (handling pools of per-package fetch, uncompress & install
> > processes), for example. Or even a _three-way merge_ tool for
> > configuration files (think of dispatch-conf), /etc snapshoting, check
> > for conflicting path namespaces of files over packages at installation
> > time (not sure this check is already done for every file), or whatever
> > smart thing could be implemented.
> >
> > I'm not saying all of this should be implemented. At least, allowing
> > wide contributions (from the technical POV, with a more simple language)
> > permits nicer discussions and by the end, interesting features to be
> > implemented.
> 
> "Simple language"?

I admit it's not the best words. I should rather say

  "language with a higher level of abstraction letting us to express
  more complex ideas in fewer lines of code, sometime relying on very
  small and atomic units of a more low-level language like C for critical
  pieces of code, giving us the advantages we all know for software
  maintenance, scalability and adaptability, even for less experienced
  programmers such as advanced admins"

but this is not very concise.

> Even if there was such a thing you'd find that the
> problem is essentially difficult.

Trying to solve a difficult problem, say ones that would need a good
level of abstraction, is harder with a language like C than with a
high-level language. ,-)

> Indeed.  It's correct (well tested, has stood the test of time, etc)
> and reliable.  That's what I expect of a package manager.  Re-writing
> it in another language would mean starting over with something that's
> essentially difficult with something a tool that reduces accidental
> difficulty.

It's a bit in contradiction with your previous statements. As you said,
code source is changing, pacman is moving. Playing with C makes no help
to reduce accidental difficulty; it's the exact opposite.

Reliability is managed with good software development practices such as
development cycle and keep control on too much stressed pieces of code.

Starting with another language doesn't mean it should not be well tested.

> You can't possibly misunderstand me to that extent.  What I'm trying
> to say is that you are suggesting something that you haven't thought
> through properly, if you were to stop and ponder a little you would
> realise that your suggestion would have the _unintended_ consequences
> of
> 
>  1. reduce the pool of possible contributors

I don't think, so. IMHO, the pool of contributors is bigger with a
high-level language than for C, simply because the learning curve of
a good high-level language is much shorter.

>  2. push away the current contributors who don't know language X and
> don't want to learn it

With statements like that, even C language would not have become what it
is today and we were all running of softwares in B language alone, or so.

-- 
Nicolas Sebrecht

[arch-general] 2011.11-1 archboot "2k11-R7" ISO hybrid image released

[Tobias Powalowski]

Hi Arch community,

Arch Linux (archboot creation tool) 2011.11-1, "2k11-R7" has been released.
To avoid confusion, this is not an official arch linux iso release!

Homepage and for more information on archboot:
http://wiki.archlinux.org/index.php/Archboot

Forum:
https://bbs.archlinux.org/viewtopic.php?id=130747

Summary:
- Plain bugfix release.

Hybrid image file and torrent is provided, which include
i686 and x86_64 core repository. Please check md5sum before using it.

Hybrid image file is a standard CD-burnable image and also a raw disk image.
- Can be burned to CD(RW) media using most CD-burning utilities.
- Can be raw-written to a drive using 'dd' or similar utilities.
  This method is intended for use with USB thumb drives.

Please get it from your favorite arch linux mirror:
- https://downloads.archlinux.de/iso/archboot/2011.11/
- /iso/archboot/2011.11/

Have fun,
greetings
tpowa
-- 
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tp...@archlinux.org









signature.asc
Description: OpenPGP digital signature

Re: [arch-general] pacman new generation

[Magnus Therning]

On Tue, Nov 22, 2011 at 13:02, Nicolas Sebrecht  wrote:
> The 22/11/11, Magnus Therning wrote:
>
>> I am somewhat allergic to the kind of statements you make.
>
> Don't be. We are only _discussing_ the advantages/disadvantages of the
> current language, aren't we?
>
> Please, don't be allergic from talking.

I'm allergic to often-repeated statements that are born out of naivite ;)

>>                                                             It sounds
>> like you are alluding to Haskell (and other hi-level languages,
>> whatever _that_ means) as some sort of magic pixie dust that can be
>> taken out in order to spray good-ness on a software project.  There
>> are dozens of other things to consider.  In this particular case these
>> are the most pertinent IMNSHO:
>>
>> - Many of these languages improve the ability to reason about the
>> behaviour of the program.  This _can_ improve quality. HOWEVER, pacman
>> doesn't strike as a tool that suffers from bad quality,
>
> But it's missing advanced features.
>
> OP raised rollbacks, I'd rather talk about simultaneous/concurrency
> pacman calls and mutli-threading to handle packages installation where
> applicable (handling pools of per-package fetch, uncompress & install
> processes), for example. Or even a _three-way merge_ tool for
> configuration files (think of dispatch-conf), /etc snapshoting, check
> for conflicting path namespaces of files over packages at installation
> time (not sure this check is already done for every file), or whatever
> smart thing could be implemented.
>
> I'm not saying all of this should be implemented. At least, allowing
> wide contributions (from the technical POV, with a more simple language)
> permits nicer discussions and by the end, interesting features to be
> implemented.

"Simple language"?  Even if there was such a thing you'd find that the
problem is essentially difficult.

>>                                                         there seems to
>> be a development team that fully understand the crucial role that
>> pacman plays in Arch and they behave accordingly in relation to
>> rolling out updates.
>>
>> - Many of these languages allow for quicker development; by raising
>> the abstraction level it's possible to express more complex ideas in
>> fewer lines of code and given that the lines/hour written by a
>> developer is fairly static across languages it leads to quicker
>> development.  HOWEVER, pacman doesn't suffer from slow development,
>> there are new releases with new features fairly frequently (probably
>> as frequently as the community can stand them).
>
> According to what _you_ expect from a package manager to do.

Indeed.  It's correct (well tested, has stood the test of time, etc)
and reliable.  That's what I expect of a package manager.  Re-writing
it in another language would mean starting over with something that's
essentially difficult with something a tool that reduces accidental
difficulty.

>> - Finally with each language comes a pool of possible contributors,
>> the group of people who already know, or are willing to learn the
>> language.  For C this pool is huge, for most of these hi-level
>> languages not so.
>>
>> So my conclusion is that when you say "I do think pacman could much
>> better if rewritten in one of these languages", then I say that you
>> most likely are completely wrong.  The more likely effect of rewriting
>> pacman in one of these languages is that the current development team
>> would disperse, there wouldn't be as large a pool of programmers to
>> recruit from to replace them, and in the end pacman would turn out to
>> be worse.
>
> Oh, come on. You're kidding me, right? Did anyone talked about spreading
> in the wild the current team?

You can't possibly misunderstand me to that extent.  What I'm trying
to say is that you are suggesting something that you haven't thought
through properly, if you were to stop and ponder a little you would
realise that your suggestion would have the _unintended_ consequences
of

 1. reduce the pool of possible contributors
 2. push away the current contributors who don't know language X and
don't want to learn it

In other words, the current team would be dispersed.

Please read Brook's No Silver Bullet and then return to the
discussion. http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe               http://therning.org/magnus

[arch-general] Re: pacman new generation

[Nicolas Sebrecht]

The 22/11/11, Magnus Therning wrote:

> I am somewhat allergic to the kind of statements you make.

Don't be. We are only _discussing_ the advantages/disadvantages of the
current language, aren't we?

Please, don't be allergic from talking.

> It sounds
> like you are alluding to Haskell (and other hi-level languages,
> whatever _that_ means) as some sort of magic pixie dust that can be
> taken out in order to spray good-ness on a software project.  There
> are dozens of other things to consider.  In this particular case these
> are the most pertinent IMNSHO:
> 
> - Many of these languages improve the ability to reason about the
> behaviour of the program.  This _can_ improve quality. HOWEVER, pacman
> doesn't strike as a tool that suffers from bad quality,

But it's missing advanced features.

OP raised rollbacks, I'd rather talk about simultaneous/concurrency
pacman calls and mutli-threading to handle packages installation where
applicable (handling pools of per-package fetch, uncompress & install
processes), for example. Or even a _three-way merge_ tool for
configuration files (think of dispatch-conf), /etc snapshoting, check
for conflicting path namespaces of files over packages at installation
time (not sure this check is already done for every file), or whatever
smart thing could be implemented.

I'm not saying all of this should be implemented. At least, allowing
wide contributions (from the technical POV, with a more simple language)
permits nicer discussions and by the end, interesting features to be
implemented.

> there seems to
> be a development team that fully understand the crucial role that
> pacman plays in Arch and they behave accordingly in relation to
> rolling out updates.
>
> - Many of these languages allow for quicker development; by raising
> the abstraction level it's possible to express more complex ideas in
> fewer lines of code and given that the lines/hour written by a
> developer is fairly static across languages it leads to quicker
> development.  HOWEVER, pacman doesn't suffer from slow development,
> there are new releases with new features fairly frequently (probably
> as frequently as the community can stand them).

According to what _you_ expect from a package manager to do.

> - Finally with each language comes a pool of possible contributors,
> the group of people who already know, or are willing to learn the
> language.  For C this pool is huge, for most of these hi-level
> languages not so.
> 
> So my conclusion is that when you say "I do think pacman could much
> better if rewritten in one of these languages", then I say that you
> most likely are completely wrong.  The more likely effect of rewriting
> pacman in one of these languages is that the current development team
> would disperse, there wouldn't be as large a pool of programmers to
> recruit from to replace them, and in the end pacman would turn out to
> be worse.

Oh, come on. You're kidding me, right? Did anyone talked about spreading
in the wild the current team?

-- 
Nicolas Sebrecht

Re: [arch-general] pacman new generation

[Clive Cooper]

On 22 November 2011 11:20, Magnus Therning  wrote:
> So my conclusion is that when you say "I do think pacman could much
> better if rewritten in one of these languages", then I say that you
> most likely are completely wrong.  The more likely effect of rewriting
> pacman in one of these languages is that the current development team
> would disperse, there wouldn't be as large a pool of programmers to
> recruit from to replace them, and in the end pacman would turn out to
> be worse.

Spot on. I agree 100% with this, well said.

Clive
-- 
Infinity: A concept for those who cannot comprehend the big picture.

() Arch Linux - For movers and shakers. ()

Re: [arch-general] pacman new generation

[Paul Gideon Dann]

On Tuesday 22 Nov 2011 12:20:25 Magnus Therning wrote:
> - Many of these languages improve the ability to reason about the
> behaviour of the program.  This _can_ improve quality. HOWEVER, pacman
> doesn't strike as a tool that suffers from bad quality, there seems to
> be a development team that fully understand the crucial role that
> pacman plays in Arch and they behave accordingly in relation to
> rolling out updates.

We should also bear in mind that most of what Pacman does is speed-critical 
database-like operations.  I'm a huge Ruby fan, but I'm happy to admit that 
it's crazy slow compared to C.  It simply doesn't make sense to rewrite it in 
another language; C is just about as fast as you can get.

However, it *does* make sense to move most of the performance-critical 
sections into a shared library, for which bindings can be written for other 
languages.  That way, you can quickly play with some concepts and write tools 
in easier languages on top on the library.  That's actually pretty much what 
has been done already.

Paul

Re: [arch-general] pacman new generation

[Magnus Therning]

On Tue, Nov 22, 2011 at 12:02, Nicolas Sebrecht  wrote:
> The 22/11/11, Karol Blazewicz wrote:
>> On Tue, Nov 22, 2011 at 10:50 AM, Nicolas Sebrecht  
>> wrote:
>
>> > OP raised one or two benefits of Haskell over shell scripting. He is
>> > right even if it's somewhat partial: many of high-level languages have
>> > very good advantages over shell scripting. I do think pacman could be
>> > much better if rewritten in one of these languages.
>>
>> Isn't pacman written in C?
>
> Yep, sorry.
>
>  s/shell scripting/low-level progrmming languages like C/g
>
> :-)

I am somewhat allergic to the kind of statements you make.  It sounds
like you are alluding to Haskell (and other hi-level languages,
whatever _that_ means) as some sort of magic pixie dust that can be
taken out in order to spray good-ness on a software project.  There
are dozens of other things to consider.  In this particular case these
are the most pertinent IMNSHO:

- Many of these languages improve the ability to reason about the
behaviour of the program.  This _can_ improve quality. HOWEVER, pacman
doesn't strike as a tool that suffers from bad quality, there seems to
be a development team that fully understand the crucial role that
pacman plays in Arch and they behave accordingly in relation to
rolling out updates.

- Many of these languages allow for quicker development; by raising
the abstraction level it's possible to express more complex ideas in
fewer lines of code and given that the lines/hour written by a
developer is fairly static across languages it leads to quicker
development.  HOWEVER, pacman doesn't suffer from slow development,
there are new releases with new features fairly frequently (probably
as frequently as the community can stand them).

- Finally with each language comes a pool of possible contributors,
the group of people who already know, or are willing to learn the
language.  For C this pool is huge, for most of these hi-level
languages not so.

So my conclusion is that when you say "I do think pacman could much
better if rewritten in one of these languages", then I say that you
most likely are completely wrong.  The more likely effect of rewriting
pacman in one of these languages is that the current development team
would disperse, there wouldn't be as large a pool of programmers to
recruit from to replace them, and in the end pacman would turn out to
be worse.

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe               http://therning.org/magnus

Re: [arch-general] pacman new generation

[Karol Blazewicz]

On Tue, Nov 22, 2011 at 12:06 PM, Jelle van der Waa  wrote:
> On 22/11/11 12:02, Nicolas Sebrecht wrote:
>>
>> The 22/11/11, Karol Blazewicz wrote:
>>>
>>> On Tue, Nov 22, 2011 at 10:50 AM, Nicolas Sebrecht
>>>  wrote:
>>
 OP raised one or two benefits of Haskell over shell scripting. He is
 right even if it's somewhat partial: many of high-level languages have
 very good advantages over shell scripting. I do think pacman could be
 much better if rewritten in one of these languages.
>>>
>>> Isn't pacman written in C?
>>
>> Yep, sorry.
>>
>>   s/shell scripting/low-level progrmming languages like C/g
>>
>> :-)
>>
> Pacman devs appreciatie patches, or in case you want to port pacman to
> haskell, just do it. ( look for example at how the 64 bit port became
> official )
>
> as wise phrik tells me:
>
> 11:05           jelly1 | !toofishes
> 11:05            phrik | patches welcome
>
>
> --
> Jelle van der Waa
>


In case you (ML subscribers) didn't know / forgot, phrik is an IRC bot :-)
https://wiki.archlinux.org/index.php/IRC_Channel#.23archlinux_rules

Re: [arch-general] pacman new generation

[Jelle van der Waa]

On 22/11/11 12:02, Nicolas Sebrecht wrote:

The 22/11/11, Karol Blazewicz wrote:

On Tue, Nov 22, 2011 at 10:50 AM, Nicolas Sebrecht  wrote:



OP raised one or two benefits of Haskell over shell scripting. He is
right even if it's somewhat partial: many of high-level languages have
very good advantages over shell scripting. I do think pacman could be
much better if rewritten in one of these languages.


Isn't pacman written in C?


Yep, sorry.

   s/shell scripting/low-level progrmming languages like C/g

:-)

Pacman devs appreciatie patches, or in case you want to port pacman to 
haskell, just do it. ( look for example at how the 64 bit port became 
official )


as wise phrik tells me:

11:05   jelly1 | !toofishes
11:05phrik | patches welcome


--
Jelle van der Waa

[arch-general] Re: pacman new generation

[Nicolas Sebrecht]

The 22/11/11, Karol Blazewicz wrote:
> On Tue, Nov 22, 2011 at 10:50 AM, Nicolas Sebrecht  wrote:

> > OP raised one or two benefits of Haskell over shell scripting. He is
> > right even if it's somewhat partial: many of high-level languages have
> > very good advantages over shell scripting. I do think pacman could be
> > much better if rewritten in one of these languages.
> 
> Isn't pacman written in C?

Yep, sorry. 

  s/shell scripting/low-level progrmming languages like C/g

:-)

-- 
Nicolas Sebrecht

Re: [arch-general] Fwd: [aur-general] Dropping tango-icon-theme{, -extras}

[Lukas Fleischer]

On Tue, Nov 22, 2011 at 11:43:17AM +0200, Ionut Biru wrote:
> On 11/22/2011 11:23 AM, Lukas Fleischer wrote:
> > Forwarding this to arch-general to get some developers' attention on
> > this (I failed at entering the mail address the first time).
> > 
> > - Forwarded message from Lukas Fleischer  
> > -
> > 
> > Date: Tue, 22 Nov 2011 10:17:47 +0100
> > From: Lukas Fleischer 
> > To: arch-general@archlinux, aur-gene...@archlinux.org
> > Subject: [aur-general] Dropping tango-icon-theme{,-extras}
> > User-Agent: Mutt/1.5.21 (2010-09-15)
> > 
> > Hi!
> > 
> > All sources hosted at tango.freedesktop.org became inaccessible [1] a
> > couple of days ago, probably due to some software upgrade on
> > freedesktop.org.
> > 
> > I contacted upstream yesterday and was told that tango-icon-theme,
> > tango-icon-theme-extras and icon-naming-utils are dead and that we
> > shouldn't rely on upstream sources being available (they even mentioned
> > they probably won't care about the 404). It has been suggested to use
> > gnome-icon-theme and gnome-icon-theme-extras instead.
> > 
> > Given that xfce4-settings seems to be the only package depending on
> > tango-icon-theme, I'd suggest to:
> > 
> > * Remove the "tango-icon-theme" dependency from xfce4-settings (this
> >   shouldn't break anything, does it?)
> > 
> 
> is broken from the time we remove the icon theme. Xfce is going to miss
> all those icons until somebody installs a new icon theme. We have to
> replace with something.

Well, xfce4-settings already depends on gnome-icon-theme and
uninstalling tango-icon-theme (`pacman -Rdd tango-icon-theme`) didn't
break xfce4-settings for me. Not sure if it uses a few icons specific to
tango-icon-theme, though. I doubt so.

Debian lists tango-icon-theme as a recommendation for xfce4-settings
also, so it probably only is a matter of having one or another icon
theme.

> 
> did somebody talked with xfce about this or at least with xfce maintainers?
> 
> > * Move both tango-icon-theme and tango-icon-theme-extras to
> >   [unsupported].
> > 
> > * Think about what to do with icon-naming-utils. We seem to need those
> >   for gnome-icon-theme and gnome-icon-theme-symbolic, so putting the
> >   source tarball on our source mirror might be the best thing to do
> >   (unless there's a proper alternative, of course).
> > 
> 
> 
> gentoo distfiles are useful for something. I'll take care of
> icon-naming-utils.

Thanks!

> 
> 
> > Objections and other suggestions welcome.
> > 
> > Cheers,
> > Lukas
> > 
> > [1] http://tango.freedesktop.org/Tango_Icon_Library#Download
> > 
> > - End forwarded message -
> 
> 
> -- 
> Ionuț
> 

P.S.: The related bug report I created yesterday [1] has just been
reopened by Ionut. Thanks for that.

[1] https://bugs.archlinux.org/task/27208

Re: [arch-general] Automatic File Associations Alloting

[Jayesh Badwaik]

One can use defaults.list file in /usr/share/applications to associate.
But it is one hell of a job.  Especially when C header is different from c
source.

The problem is mainly that for the application to overwrite 100s of file
association wrongly take no time. For me to restore them back is a hell of
a time. That being said, I tried to keep a list of my custom file associations
but then I install some other app, which then does it again. But this time, it
also adds new associatiosn which I actually need, and then I have to
run a script
to filter out what I want and what I don't. Should it be that difficult?

Also, the defaults are I guess quiet wrong.

> Also, looking at this file, in both Debian and Ubuntu, I found out that
> is not what I'd want on my system, since I don't have some of the
> applications associated with some files in these distros. What worked
> great for me, was to take the files from both distros, compare them and
> come up with my own defaults.list [2].

Right on. A bigger problem with the defaults is as such.
For all images file, the default is GIMP if it is installed. I mean
really?? Everyone
 wants to edit the images? And again, it would have been no problem. But
gimp just takes so long to load as compared to some other app such as
gwenview etc

Then for folder/directory, konqueror is the app. Again really??? Why
the hell was dolphin invented for?
For pdf files guess who? GIMP again!! What the hell!!! Who uses gimp
to read  a PDF anyway?
Give me evince. Or okular or even XPDF but Gimp?? Why Arch Why??

Emacs for all text files is what I have found on other distros too..
Its somewhat sad (myself being a vim user ;) ) but i guess that is emacs fault
and is packaging problem.

What I was thinking was that there should be something out of this mess.
I install a new text editor to try out and I am left with a default mess???
This situation is quiet unavoidable on other distributions as they install
a lot of things automatically. However, in Arch, we install minimalistic things
and hence, I guess, we can find a solution within the philosophy.

And I believe, it is as follows.
1. Get the defaults right for the DE. I guess they are and other apps
invade their space.
but still this should be the first checklist. It is highly subjective.
So, doesn't
really matter but seriously, konqueror for folder/directory is too much.

2. Here we assume that a Archer (the one who uses Arch) installs only
what he wants.
So, the package can only add to the file association table. It cannot
change already existing entries
in it. I guess its a simple script. Its just that instead of me using
it everytime, the package does it for me.

3. Sometimes though, you might want the new application to actually
take over all the things.
In which case, we can have some sort of program which manages file
associations and kind of runs either
during the package installation or can be run manually after it. Just
like ld is run.

I am thinking of writing a small program to do so. I'll let you know
how I am progressing. Right
now I only have a design in my mind and I have some exams coming up in
three-four days.
So after I am done with them, I would put my plans into action. I can
post my plans
and if they are any good, we can try developing something. I haven't
got time right now
so I cannot even make the docs.


--
Cheers and Regards
Jayesh Vinay Badwaik
Electronics and Communication Engineering
VNIT, INDIA

Re: [arch-general] pacman new generation

[Karol Blazewicz]

On Tue, Nov 22, 2011 at 10:50 AM, Nicolas Sebrecht  wrote:
> The 21/11/11, Thorsten Töpper wrote:
>
>> Seriously, it's probably meant like this but your mail reads like a
>> "Hey why don't you learn $INSERT_LANG_HERE and rewrite your whole
>> system."
>>
>> I've not participated in pacman development myself so I guess I should
>> stfu myself, but for me this proposal just reads like a kick into the
>> faces of Allan, Dan and all the other people who did so.
>
> I don't think, so. Or nothing could be discussed because some others did
> another choice some time ago.
>
> OP raised one or two benefits of Haskell over shell scripting. He is
> right even if it's somewhat partial: many of high-level languages have
> very good advantages over shell scripting. I do think pacman could be
> much better if rewritten in one of these languages.
>
> --
> Nicolas Sebrecht
>

Isn't pacman written in C?

[arch-general] Re: pacman new generation

[Nicolas Sebrecht]

The 21/11/11, Thorsten Töpper wrote:

> Seriously, it's probably meant like this but your mail reads like a
> "Hey why don't you learn $INSERT_LANG_HERE and rewrite your whole
> system."
> 
> I've not participated in pacman development myself so I guess I should
> stfu myself, but for me this proposal just reads like a kick into the
> faces of Allan, Dan and all the other people who did so.

I don't think, so. Or nothing could be discussed because some others did
another choice some time ago.

OP raised one or two benefits of Haskell over shell scripting. He is
right even if it's somewhat partial: many of high-level languages have
very good advantages over shell scripting. I do think pacman could be
much better if rewritten in one of these languages.

-- 
Nicolas Sebrecht

Re: [arch-general] Fwd: [aur-general] Dropping tango-icon-theme{, -extras}

[Ionut Biru]

On 11/22/2011 11:23 AM, Lukas Fleischer wrote:
> Forwarding this to arch-general to get some developers' attention on
> this (I failed at entering the mail address the first time).
> 
> - Forwarded message from Lukas Fleischer  -
> 
> Date: Tue, 22 Nov 2011 10:17:47 +0100
> From: Lukas Fleischer 
> To: arch-general@archlinux, aur-gene...@archlinux.org
> Subject: [aur-general] Dropping tango-icon-theme{,-extras}
> User-Agent: Mutt/1.5.21 (2010-09-15)
> 
> Hi!
> 
> All sources hosted at tango.freedesktop.org became inaccessible [1] a
> couple of days ago, probably due to some software upgrade on
> freedesktop.org.
> 
> I contacted upstream yesterday and was told that tango-icon-theme,
> tango-icon-theme-extras and icon-naming-utils are dead and that we
> shouldn't rely on upstream sources being available (they even mentioned
> they probably won't care about the 404). It has been suggested to use
> gnome-icon-theme and gnome-icon-theme-extras instead.
> 
> Given that xfce4-settings seems to be the only package depending on
> tango-icon-theme, I'd suggest to:
> 
> * Remove the "tango-icon-theme" dependency from xfce4-settings (this
>   shouldn't break anything, does it?)
> 

is broken from the time we remove the icon theme. Xfce is going to miss
all those icons until somebody installs a new icon theme. We have to
replace with something.

did somebody talked with xfce about this or at least with xfce maintainers?

> * Move both tango-icon-theme and tango-icon-theme-extras to
>   [unsupported].
> 
> * Think about what to do with icon-naming-utils. We seem to need those
>   for gnome-icon-theme and gnome-icon-theme-symbolic, so putting the
>   source tarball on our source mirror might be the best thing to do
>   (unless there's a proper alternative, of course).
> 


gentoo distfiles are useful for something. I'll take care of
icon-naming-utils.


> Objections and other suggestions welcome.
> 
> Cheers,
> Lukas
> 
> [1] http://tango.freedesktop.org/Tango_Icon_Library#Download
> 
> - End forwarded message -


-- 
Ionuț



signature.asc
Description: OpenPGP digital signature

[arch-general] Fwd: [aur-general] Dropping tango-icon-theme{, -extras}

[Lukas Fleischer]

Forwarding this to arch-general to get some developers' attention on
this (I failed at entering the mail address the first time).

- Forwarded message from Lukas Fleischer  -

Date: Tue, 22 Nov 2011 10:17:47 +0100
From: Lukas Fleischer 
To: arch-general@archlinux, aur-gene...@archlinux.org
Subject: [aur-general] Dropping tango-icon-theme{,-extras}
User-Agent: Mutt/1.5.21 (2010-09-15)

Hi!

All sources hosted at tango.freedesktop.org became inaccessible [1] a
couple of days ago, probably due to some software upgrade on
freedesktop.org.

I contacted upstream yesterday and was told that tango-icon-theme,
tango-icon-theme-extras and icon-naming-utils are dead and that we
shouldn't rely on upstream sources being available (they even mentioned
they probably won't care about the 404). It has been suggested to use
gnome-icon-theme and gnome-icon-theme-extras instead.

Given that xfce4-settings seems to be the only package depending on
tango-icon-theme, I'd suggest to:

* Remove the "tango-icon-theme" dependency from xfce4-settings (this
  shouldn't break anything, does it?)

* Move both tango-icon-theme and tango-icon-theme-extras to
  [unsupported].

* Think about what to do with icon-naming-utils. We seem to need those
  for gnome-icon-theme and gnome-icon-theme-symbolic, so putting the
  source tarball on our source mirror might be the best thing to do
  (unless there's a proper alternative, of course).

Objections and other suggestions welcome.

Cheers,
Lukas

[1] http://tango.freedesktop.org/Tango_Icon_Library#Download

- End forwarded message -

Re: [arch-general] Automatic File Associations Alloting

[Philipp Überbacher]

Excerpts from Mantas Mikulėnas's message of 2011-11-22 00:50:25 +0100:
> On 2011-11-21 23:36, Philipp Überbacher wrote:
> > So how is this stuff controlled these days? Those funky desktop files?
> > gconf? dconf? Something else entirely?
> 
> The default programs are kept in
> ~/.local/share/applications/mimeapps.list, according to fd.o "MIME
> Actions spec".
> 
> 
> 
> All popular DEs - GNOME, Xfce, KDE - use this, and should respect
> explicitly set defaults.

Thanks, this page is rather informative and links to the original
mailinglist discussion, hope I'll find time to read it and understand
the reasoning for some of the decisions. For example, I find it odd that
they wanted to have a way for an application to become the new default
after installation ("Application X wants to be the default application
for text/html after installation"). In my book there's no reason why
this decision should be up to the application instead of the user (or
possibly DE). Well, maybe I'll figure out their reasoning.

Thanks again for the link.

Regards,
Philipp