[arch-general] TexLive 2020 packages

[Rémy Oudompheng via arch-general]

Hello,

TexLive 2020 is frozen upstream and will be officially released in the
coming days.
Packages have been uploaded to [testing] and [community-testing] (for biber).

Please let me know if you encounter issues with these.

Regards,
Rémy.

[arch-general] TexLive 2018 move in [extra] today

[Rémy Oudompheng via arch-general]

Hello,

I will move Texlive 2018 packages to [extra] today, along with zathura
and qpdfview which were rebuilt for libsynctex.

Rémy.

[arch-general] TeXLive 2017 packages are now available in [testing]

[Rémy Oudompheng via arch-general]

Hello,

TexLive 2017 has been released at the beginning of the month and is
now packaged in [testing].
No particular issue is expected when upgrading to this release.

Note that a few packages disappear in this release, following upstream
changes in structure:
* texlive-genericextra (merged in texlive-core)
* texlive-htmlxml (merged in texlive-core and formatsextra)
* texlive-plainextra (merged in texlive-core)

Pacman hooks for TeXLive, which were in texlive-bin, are now in
texlive-core, which should fix bugs like FS50238, FS20423 and FS51918.

I expect to move them to [extra] early July.

Happy TeXing,

Regards,
Rémy.

Re: [arch-general] New TeXLive 2016 packages in [testing]

[Rémy Oudompheng via arch-general]

2016-06-20 0:45 GMT+02:00 Rémy Oudompheng <remyoudomph...@gmail.com>:
> Hello,
>
> I have published new TeXLive packages for the 2016 release in [testing].
> The structure of the packages has been left unchanged (e.g. no introduction
> of pacman hooks).
>
> Feel free to test them and notify me of any problem or weirdness.
>
> Cheers,
> Rémy.

I have updated the packages to remove the "biber" utility from
texlive-bin (which is now 16MB smaller), because it is now built in a
more appropriate ay as a separate package (now in
[community-testing]).

I plan to move the packages to [extra] before the end of the month.

Regards,
Rémy.

[arch-general] New TeXLive 2016 packages in [testing]

[Rémy Oudompheng via arch-general]

Hello,

I have published new TeXLive packages for the 2016 release in [testing].
The structure of the packages has been left unchanged (e.g. no introduction
of pacman hooks).

Feel free to test them and notify me of any problem or weirdness.

Cheers,
Rémy.

Re: [arch-general] Any ETA on the Tex Live 2015 update?

[Rémy Oudompheng]

2015-08-24 17:59 GMT+02:00 Sebastiaan Lokhorst :
> 2015-08-22 21:27 GMT+02:00 Mohammad_AlSaleh :
>>
>> I'm wondering if there is any reason for the hold-up. Other than
>> the maintainers(s) being busy of course.
>>
>
> I'm also curious about this. It seems like the maintainer hasn't been
> active for the past 5 months.[1]
> What is the normal course of action in such a case? For instance, how could
> I contact the maintainer?
>
> Thanks,
> Sebastiaan
>
> [1] https://www.archlinux.org/packages/?maintainer=remy

I am not very active because TeXLive is updated only once a year. I
usually do a couple of incremental updates because TeXLive packages
also receive continuous updates between 2 yearly releases, and to
catch up with bug fixes.

The packages are now available in [testing]. They were almost ready
for a while but remaining issues had to be fixed and I couldn't find
the time until today.

You can always contact me through e-mail at r...@archlinux.org.

Regards,
Rémy.

[arch-general] TeXLive 2014 packages

[Rémy Oudompheng]

Hello,

I have updated TeXLive packages for the 2014 release in the [testing] repo.

The main visible change is the split of the huge texlive-langcjk
package into 3 packages (langchinese, langjapanese, langkorean) to
follow upstream split of the corresponding TeXLive collection.

The upgrade should not cause any particular issue. Please report any
problem you are experiencing.

Regards,
Rémy.

[arch-general] Incremental update for TeXLive 2013

[Rémy Oudompheng]

Hello,

I am going to push updated TeXLive packages to [extra].

The following bugs are expected to be fixed:
https://bugs.archlinux.org/task/34932
https://bugs.archlinux.org/task/28560
https://bugs.archlinux.org/task/28514

Regards,
Rémy.

[arch-general] pyalpm 0.6.2

[Rémy Oudompheng]

Hello,

pyalpm 0.6.2 has been released to [extra].

The following fixes are included:
  * pycman: recognize RemoteFileSigLevel and UseDelta=x options (FS#34791)
  * init_with_config now handles IgnorePkg and similar options (FS#29688)

Regards,
Rémy.

[arch-general] Texlive 2013 packages released in [extra]

[Rémy Oudompheng]

On 2013/7/3 Rémy Oudompheng remyoudomph...@gmail.com wrote:
 Hello,

 I have pushed TeXLive 2013 packages to [testing].


The packages are now available in [extra].

Please read the news announcement for any issues after the upgrade:

https://www.archlinux.org/news/texlive-2013-update-may-require-user-intervention/

Rémy.

[arch-general] Texlive 2013 packages releases to [testing]

[Rémy Oudompheng]

Hello,

I have pushed TeXLive 2013 packages to [testing].

The main difference with the 2012 packages is that /etc/texmf files
are now in texlive-core rather than texlive-bin.

The texlive-bin package now contains almost only binaries, and
texlive-core contains all basic data files including the ones in
/etc/texmf.

Feel free to report any issues you encounter.

If you have an existing installation, the upgrade might install new
versions of /etc/texmf/ files as *.pacnew. It is unlikely that things
work properly if you don't handle the pacnew files unless you realy
know what you are doing.

If pacnew files appear (notably texmf.cnf and fmtutil.cnf), and the
installation reports a failure in regenerating formats (which you will
know by not being able to use an engine), you will need to handle the
pacnew files, and run fmtutil-sys --all by hand.

If this situation reaches a high level of absurdity, and if possible
considering pacman's behaviour, new packages not behaving like this
might be built later before going to [extra].

Regards,
Rémy.

[arch-general] Last TeXLive 2012 packages before TeXLive 2013

[Rémy Oudompheng]

Hello,

TeXLive 2012 continuous updates have been frozen for TeXLive 2013 preparation.

I have uploaded updated versions of the TeXLive 2012 packages to
[testing], feel free to report any problems.

Regards,
Rémy.

[arch-general] Namcap 3.2.5

[Rémy Oudompheng]

Hello,

Namcap 3.2.5 is available in [testing].

It features the following changes:
- support SKIP in checksums (FS#34647)
- export CARCH correctly to parsepkgbuild (FS#32568)
- recognize .MTREE as package metadata (FS#34591)

Rémy.

Re: [arch-general] SystemD poll

[Rémy Oudompheng]

The cumulated amount of time spent on these endless discussions has
now almost certainly get past the amount of time necessary to fix
initscripts.

Fix them instead of feeding trolls.

Rémy.

Re: [arch-general] simple trick to make dealing with python 2/3 scripts easier

[Rémy Oudompheng]

On 2012/8/17 Ben Booth benwbo...@gmail.com wrote:
 Lots of python scripts still use #!/usr/bin/python instead of explicitly
 stating which version of python to use. Here's quick trick to make running
 various python version 2 or 3 scripts easier:

 remove the /usr/bin/python symlink and replace with this shell script:

 #!/usr/bin/env bash
 exec /usr/bin/${PYTHON:-python3} $@

 Now you can set the PYTHON environment variable to be either python2 or
 python3, depending on which version of python the script expects. Just don't
 set PYTHON=python, or you'll get a recursive loop! The only problem with
 this approach is that /usr/bin/python is owned by the python package, so if
 you upgrade the python package it might create problems. Any one know of
 some way to work around this problem?

Run your scripts using python2 script.py or use setuptools that
rewrites shebang automatically.

Rémy.

Re: [arch-general] Arch Linux and systemd

[Rémy Oudompheng]

On 2012/8/17 Myra Nelson myra.nel...@hughes.net wrote:
 On Thu, Aug 16, 2012 at 4:34 PM, Nicholas MIller nick.k...@gmail.comwrote:
 That seems to be one of the more well thought out (not pro), responces to
 systemd,


 Thank you. My intent was to start an intelligent discussion. The rants and
 raves are going no where. I'm not necessarily against systemd, just the
 PTB's upstream dictating how Linux is and can be used. To me Linux is about
 choice, unlike the OS I used for so many years. My other goal is to get the
 devs involved to think about how to help the Arch community in general. If
 Arch is what you make of it, don't take that choice away.

The tools dictate how to use the system. Archlinux has never dictated
which tools to use, and the move to systemd is not more a dictation
about which tool to use than anything before. Arch is still what you
make of it, some tools just don't have alternatives and you are
welcome to develop one of them to help that choice.

Nobody is removing an alternative here, it's just cleaning up the
dead, the community is free to revive them.
I don't see how this discussion is different from the other ones. Most
of the discussions are based on the assumption that we currently have
working boot scripts in bash. This one is too.

Rémy.

Re: [arch-general] [arch-dev-public] Migration to systemd

[Rémy Oudompheng]

On 2012/8/16 Kevin Chadwick ma1l1i...@yahoo.co.uk wrote:
  Lennart said systemd will only ever run on Linux and is only designed
  for a full fledged Fedora but is useful on embedded too. However I
  don't think he realised what level the Linux embedded world could
  expand to.

As far as I know, Archlinux does not target non-x86 embedded devices.
Some derived projects like ArchlinuxARM may do so, but their decisions
are totally independent from the desktop Archlinux team.

Rémy.

Re: [arch-general] SystemD poll

[Rémy Oudompheng]

On 2012/8/18 John Briggs johne...@optusnet.com.au wrote:
 IMHO systemd is unnecessarily complex in trying to do too many separate
 tasks.

I don't understand why you are saying that. The systemd project may be
larger than a small utility, but it is composed of:
* multiple, small utilities that do well knwon and well defined tasks
(we package that in systemd-tools),
* a core daemon (systemd) which is hardly larger than bash wrt lines of code
* udev

These things are separate and each one of them does not look complex to me.
What complexity do you think it has ?

Rémy.

Re: [arch-general] [arch-dev-public] Migration to systemd

[Rémy Oudompheng]

On 2012/8/15 Felipe Contreras felipe.contre...@gmail.com wrote:
 On Wed, Aug 15, 2012 at 1:55 PM, Thomas Bächler tho...@archlinux.org wrote:
 Am 15.08.2012 13:34, schrieb Felipe Contreras:
 1./ Be a small simple binary

 The systemd main binary is not very large (larger than sysvinit's
 /sbin/init, but not by much).

 But that binary alone is useless, and certainly not *simple*.

 /sbin/init from sysvinit alone is useless. What is your point?

 The rest are rather simple scripts (in the case of Arch Linux).

 And you are still ignoring the fact that systemd is anything but
 *simple*. How convenient to ignore that argument.

Here are my two cents about that:
* I don't care about having a faster boot if the sequence is incorrect
or buggy (or, worse, leaves me with an unbootable system)
* I don't care about having a simpler boot if it doesn't work
* I don't care about systemd or bash scripts as long as it is
maintained and bug-fixed.

The situation is:
* I hate bash
* I don't think bash scripts are simple at all
* The current initscripts do not do what I expect them to do (being
able to start services, notably when a dependency is not up).
* I don't think we have enough manpower to maintain bash scripts like
Debian folks do
* I don't think we are looking for a replacement to /sbin/init, but we
are definitely looking for a boot sequence that works

I am personnally open to having something else than systemd but I do
not see anyone showing an alternative.

Rémy.

Re: [arch-general] [arch-dev-public] Migration to systemd

[Rémy Oudompheng]

On 2012/8/15 Kevin Chadwick ma1l1i...@yahoo.co.uk wrote:
 Am 15.08.2012 11:21, schrieb Kevin Chadwick:
  1./ Be a small simple binary

 The systemd main binary is not very large (larger than sysvinit's
 /sbin/init, but not by much).


 Just 26 times as large and who knows how many times more complicated.

systemd has not the same purpose that /sbin/init. You are comparing
completely different things.

  2./ Have no dependencies

 That is pure BS. If something has no dependencies, it has to do
 everything in the binary itself. You either end up with no features, or
 potential for tons of bugs.


 No it has the potential and freedom to do anything or nothing without
 the overhead of copying a much larger binary when forking processes or
 imposing any limitations.

Forking processes does not copy binaries.

 Twisting my words yet again like so many other posts which are pro
 systemd. Without a C library which was invented as the heart of UNIX you
 wouldn't have a UNIX-like OS or any general OS including Windows.


 Here's a list of dependencies for you. There are likely many kernel
 CONFIG options and modules required than the couple listed here and
 likely growing.

 cgroups, dbus, ipv6, udev, kmod, pam, libcap

These dependencies just enumerate basic system administration tools in
the form of libraries. A boot procedure relying on shell scripts would
have the same dependencies as commands, that doesn't make any
difference.

I am not pro-systemd at all, I'm even rather for alternatives. Please
don't make the pro-alternative arguments ridiculous.

Rémy.

Re: [arch-general] TeXlive 2012 packages

[Rémy Oudompheng]

On 2012/6/26 Rémy Oudompheng remyoudomph...@gmail.com wrote:
 Hello,

 I am going to put Texlive 2012 packages in [testing]. Texlive 2012 is
 not yet released, but it is frozen, so I do not expect changes to
 these packages except to fix packaging errors.
 Please try them and complain on mailing lists. Don't hesitate to
 compile your own theses, memoirs or books.

The packages will move today.

Rémy.

Re: [arch-general] TeXlive 2012 packages

[Rémy Oudompheng]

On 2012/7/3 Rémy Oudompheng remyoudomph...@gmail.com wrote:
 On 2012/6/26 Rémy Oudompheng remyoudomph...@gmail.com wrote:
 Hello,

 I am going to put Texlive 2012 packages in [testing]. Texlive 2012 is
 not yet released, but it is frozen, so I do not expect changes to
 these packages except to fix packaging errors.
 Please try them and complain on mailing lists. Don't hesitate to
 compile your own theses, memoirs or books.

 It seems the TexLive 2012 version of Luatex is affected by a bug that
 prevents it from compiling some fractions.

 http://tex.stackexchange.com/questions/61952/problem-compiling-some-math-using-lualatex

 I will repackage with the upstream patch.

The bug is actually with square roots and is quite serious. I have
packaged texlive-bin 2012.0-2 in [testing]. The texlive packages will
move to [extra] by the end of the week.

Rémy.

Re: [arch-general] TeXlive 2012 packages

[Rémy Oudompheng]

On 2012/6/26 Rémy Oudompheng remyoudomph...@gmail.com wrote:
 Hello,

 I am going to put Texlive 2012 packages in [testing]. Texlive 2012 is
 not yet released, but it is frozen, so I do not expect changes to
 these packages except to fix packaging errors.
 Please try them and complain on mailing lists. Don't hesitate to
 compile your own theses, memoirs or books.

It seems the TexLive 2012 version of Luatex is affected by a bug that
prevents it from compiling some fractions.

http://tex.stackexchange.com/questions/61952/problem-compiling-some-math-using-lualatex

I will repackage with the upstream patch.

Regards,
Rémy.

Re: [arch-general] TeXlive 2012 packages

[Rémy Oudompheng]

On 2012/6/27 Genes MailLists li...@sapience.com wrote:
 Update:

        After installing and getting errors - I re-installed all the texlive
 2012 packages again - this time there are no errors - and now I can use
 texlive (it was totally broken before the second install).

  gene

I would have needed the logs of failed format generation to debug.
Smooth upgrade paths have always been an issue with Texlive packages.
I'll try a bit more.

Rémy.

[arch-general] TeXlive 2012 packages

[Rémy Oudompheng]

Hello,

I am going to put Texlive 2012 packages in [testing]. Texlive 2012 is
not yet released, but it is frozen, so I do not expect changes to
these packages except to fix packaging errors.
Please try them and complain on mailing lists. Don't hesitate to
compile your own theses, memoirs or books.

Regards,
Rémy.

Re: [arch-general] Archlinux Package texlive-latexextra

[Rémy Oudompheng]

Le 25 mars 2012 21:33, Hans-J. Schmid hans-j.sch...@hans-jschmid.com a écrit :
 Dear Rémy,

 thanks a lot for supporting Archlinux and your brilliant work on maintaining
 all these packages.

 I am having a quick question. I am just writing a CV and use the moderncv
 package ( http://www.ctan.org/tex-archive/macros/latex/contrib/moderncv/)
 which has been updated a few weeks ago. I would like to use one of the new
 styles of moderncv. So are there any plans to update the texlive-latexextra
 package which moderncv is a part of in the near future?

 Very kind regards and keep up the good work,
 Hans-J.

Hello,

It can be done. You should mark the package out-of-date indicating if
psosible what are the modules you are interested in. The process takes
some time and I'm not sure if I can do it soon, but it's possible.

Rémy.

Re: [arch-general] [arch-dev-public] Cleaning up orphaned packages

[Rémy Oudompheng]

Le 5 mars 2012 16:40, Lukas Fleischer archli...@cryptocrack.de a écrit :
 On Mon, Mar 05, 2012 at 01:01:03AM +0100, Pierre Schmitz wrote:
 Am 24.02.2012 17:06, schrieb Lukas Fleischer:
  Apart from that, +1 to this idea. I already checked the list of unneeded
  orphans and there's 20 packages I'd like to maintain if they aren't
  picked up in [extra]...

 Send me a list of these packages. But ensure they are still orphan and
 are not a dep or makedep of any package in core/extra.

 Well, there's only a few packages left (others have already been moved
 or are required by another [core]/[extra] package):

 * bluez-firmware
 * cmus
 * evilwm
 * fortune-mod
 * id3v2
 * jhead
 * libofx
 * libofx-doc

libofx is an indirect dependency of gnucash, which is in extra. The
thing is, aqbanking needs to move. I can adopt it.

Rémy.

Re: [arch-general] [mkinitcpio] support for /usr on a separate partition

[Rémy Oudompheng]

On Fri 13 January 2012 at 21:48 -0500, Dave Reisner wrote:
 Hi all,
 
 With the release of mkinitcpio 0.8.2, we've added support for mounting
 /usr from early userspace when it exists as a separate partition. This
 has been something people have been asking about for a little while, so
 I figured I'd make a call out for the feature.
 

Thanks a lot! I added the two hooks and could upgrade without breakage
due to my separate /usr partition on LVM.

-- 
Rémy.

Re: [arch-general] TeXLive update

[Rémy Oudompheng]

On Sun 04 December 2011 at 20:47 +0100, Rémy Oudompheng wrote:
 Hello,
 
 I have done an update of TeXLive to catch up with the distribution
 updates. I think I had a free fix for FS#25250, the packages are in
 [testing] and will move to [extra] quite quickly unless new problmes
 are reported.
 
 Regards,
 Rémy.

It is now moved to [extra].

Rémy.


pgp2pY9s5A5RA.pgp
Description: PGP signature

[arch-general] TeXLive update

[Rémy Oudompheng]

Hello,

I have done an update of TeXLive to catch up with the distribution
updates. I think I had a free fix for FS#25250, the packages are in
[testing] and will move to [extra] quite quickly unless new problmes
are reported.

Regards,
Rémy.

Re: [arch-general] [signoff] texlive-bin 2011.1-1 and texlive-* 2011.*

[Rémy Oudompheng]

On 2011/7/24 Rémy Oudompheng remyoudomph...@gmail.com wrote:
 Hello,

 TeXLive 2011 has been officially released. Packages in [testing] have
 been updated to reflect this.


Packages have been moved to [extra].

Rémy.

[arch-general] [signoff] Netcfg 2.6.8-1

[Rémy Oudompheng]

Hello,

netcfg 2.6.8 is released. It is a bug fix release for bugs
FS#25514 [1], FS#25473 [2], FS#25530 [3].

Please sign it off and move it to [core] when possible.

[1] http://bugs.archlinux.org/task/25514
[2] http://bugs.archlinux.org/task/25473
[3] http://bugs.archlinux.org/task/25530

Regards,
-- 
Rémy.


pgpGGVZ4xzzhV.pgp
Description: PGP signature

Re: [arch-general] [signoff] linux-3.0-2

[Rémy Oudompheng]

On 2011/8/1 Tobias Powalowski tobias.powalow...@googlemail.com wrote:
 Hi guys,
 please signoff 3.0 series for both arches.

Using that for some days, signof i686.

-- 
Rémy.

[arch-general] [signoff] netcfg 2.6.6-1

[Rémy Oudompheng]

Hello,

I have prepared the netcfg 2.6.6 release. I have let go the previous
signoff thread because of several outstanding issues, which I think are
now resolved.

NEWS except
---
version 2.6.6
- fix wrong rc scripts names in suspend hook (FS#20330)
- fix wireless failure when using wpa-config and a custom
  ctrl_interface path (FS#24949)
- bash-completion: add -r to option list (FS#25188)

Regards,
Rémy.


pgpephjkVVinN.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] [signoff] texlive-bin 2011.1-1 and texlive-* 2011.*

[Rémy Oudompheng]

On 2011/7/25 Calvin Morrison mutanttur...@gmail.com wrote:
 On 24 July 2011 20:37, Rémy Oudompheng remyoudomph...@gmail.com wrote:
 Hello,

 TeXLive 2011 has been officially released. Packages in [testing] have
 been updated to reflect this.

 Hey,

 While updating I got some weird output from texlive updating. here is
 the terminal output:

 [...]

 Anyone have an idea about this? also, does it matter?

The only thing that matters in the output of the regeneration after
both texlive-bin and texlive-core are updated. Previously only the
texlive-core update would trigger the format regeneration, but this
would cause problems in case only texlive-bin would be updated.

I have changed texlive-bin so that any update triggers the format
regeneration: the drawback is that eptex fails to generate format
files due to German hyphenation patterns being interpreted with wrong
encoding. I don't know yet how to fix this and will have to
investigate. Any help is appreciated for that matter.

Rémy.

[arch-general] [signoff] texlive-bin 2011.1-1 and texlive-* 2011.*

[Rémy Oudompheng]

Hello,

TeXLive 2011 has been officially released. Packages in [testing] have
been updated to reflect this.

* biblatex-biber is not packaged and depends and a whole lot of Perl
packages. You can find it on AUR, or some for some developer to
package it and its dependencies
* eptex format generation fails, I don't understand how to fix it, so
if anyone has an idea...

Rémy.

[arch-general] [signoff] netcfg 2.6.4-1

[Rémy Oudompheng]

Hello,

I have just released netcfg 2.6.4. As I think the amount of outstanding
bugs inside is pretty negligible, I suggest starting a signoff thread
for inclusion into [core].

Then I will start working on including pending new features for 2.7
release.

Highlights of netcfg 2.6.4 are a shining new netcfg-profiles(5) man page,
that gathers the (previously non-existent ethernet(5) and wireless(5)
man pages).
- The netcfg(8) man pages has been translated back to markdown/pandoc syntx
for easier updates.
- The netcfg-profiles(5) man page documents many options of the various
available connection types, and should complement the provided examples.
It should plug the usual criticism about netcfg's documentation being
very hard to find.

It is expected that the 2.6.4 release is the final one in the 2.6.x
series.

This release works for me in standard ethernet and WPA modes, using DHCP,
so I sign it off.

-- 
Rémy.


pgp4lxvuYoiWH.pgp
Description: PGP signature

[arch-general] Introducing pacweb, another pyalpm demo

[Rémy Oudompheng]

Hello,

I am currently working on another toy example use of pyalpm: beside
pycman, the command line utility that comes with pyalpm, I have now
pacweb, a browsable Web interface to pacman.

  http://projects.archlinux.org/users/remy/pacweb.git/

It is not suitable for public consumption, but offers an alternative
display of the pacman database. Intrepid users might run it as root,
to allow performing some actions (changing package install reasons,
add/remove individual packages), as well as wide opening seurity breaches
on their systems.

It is currently based on jinja (recently added to repos for Python 3)
for templating, and steals Archweb style for the current appearance.
I have also made a PKGBUILD available on the AUR.

The amount of actual Python source code is very small and should be
easily readable.

-- 
Rémy.


pgprCDKoIcqNl.pgp
Description: PGP signature

[arch-general] [netcfg] Getting rid of wireless_tools

[Rémy Oudompheng]

Hello,

wpa_supplicant is supposed to provide most of the wireless_tools
functionality. I have set up a branch of netcfg that replaces all uses
of wireless_tools by wpa_supplicant.

http://projects.archlinux.org/users/remy/netcfg.git/log/?h=no-iwconfig

iwconfig is still used by the deprecated IWCONFIG option, but there is
still one thing I don't really understand.

In src/connections/wireless, there is block that calls iwconfig mode
Managed before starting wpa_supplicant. The log is not really
explicit about why this was added (it merely says it was necessary for
iwl3945), and wpa_supplicant man page only says it's necessary for the
hostap driver, which we do not use. Does anybody knows the reason why
it is needed?

Rémy.

[arch-general] netcfg 2.6 release

[Rémy Oudompheng]

Hello,

netcfg 2.6 has been released and pushed in [testing].

The following features has been added since the last release:
- add support for IPv6 configuration (FS#18699)
- add support for static routes configuration (FS#18700)
- add support for creating tun/tap interfaces (FS#15049)
- add configuration file /etc/conf.d/netcfg for net-auto-wireless
- add support for restricting automatic startup of profiles (FS#23169)
- bridge: add support for several brctl options (FS#16625)
- wireless: add support for explicit BSSID (FS#24582)
- wireless: add support for ad-hoc connections (FS#19683)
- wireless: no longer require wireless_tools to work
- use /run instead of /var/run
- drops hard dependency on net-tools package
- drops hard dependency on wireless_tools package

Most importantly:
- netcfg no longer puts no files in /run (dhcpcd still puts files there)
- netcfg only depends on iproute2 and dhcpcd : wpa_supplicant is
optional (required for wireless), wpa_actiond, ifplugd are required
for net-auto* scripts
- net-tools, wireless_tools are needed if you use legacy options
IFOPTS and IWCONFIG, but this is strongly discouraged
- /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)
- IPv6 is supported: no address configuration (even
auto-configuration) will be done unless you say IP6=something in your
profile. See the examples to see how it works
- dhclient is needed if you want to support DHCPv6: this is expected
to be an uncommon case, since auto-configuration exists.
- netcfg can create tun/tap interfaces: it currently does not do
anything with these (FS#15049)

Regards,
-- 
Rémy.

Re: [arch-general] netcfg 2.6 release

[Rémy Oudompheng]

On Sun 19 June 2011 at 23:23 +0200, Rémy Oudompheng wrote:
 Most importantly:
 - netcfg no longer puts no files in /run (dhcpcd still puts files there)
 - netcfg only depends on iproute2 and dhcpcd : wpa_supplicant is
 optional (required for wireless), wpa_actiond, ifplugd are required
 for net-auto* scripts
 - net-tools, wireless_tools are needed if you use legacy options
 IFOPTS and IWCONFIG, but this is strongly discouraged

Also, the none-old and wep-old SECURITY modes are no longer
supported. They are now aliases to the wpa_supplicant bases
none and wep.

-- 
Rémy.

Re: [arch-general] netcfg 2.6 release

[Rémy Oudompheng]

On 2011/6/19 Rémy Oudompheng remyoudomph...@gmail.com wrote:
 Hello,

 netcfg 2.6 has been released and pushed in [testing].

Due to a small bug in net-auto-wireless, the version is now 2.6.1.
Additionally some basic configuration of tun/tap interfaces is now
possible.

Rémy.

Re: [arch-general] netcfg 2.6 release

[Rémy Oudompheng]

On 2011/6/20 Loui Chang louipc@gmail.com 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?

Rémy.

[arch-general] [netcfg] Prerelease package before 2.6 release

[Rémy Oudompheng]

Hello,

I have uploaded a premilinary netcfg package including the latest
changes. It does not correspond to a particular tag in the Git
repository (it's commit 1f5183b8).

http://dev.archlinux.org/~remy/netcfg/netcfg-2.5.90-1-any.pkg.tar.xz

I plan to produce version 2.6 after some polishing has been made.

* I can test static configuration
* I can test IPv4 wireless
* I remember wireless IPv6 worked previously, maybe due to
  autoconfiguration. I don't know if there are real people out in the
  world using DHCP for IPv6.

net-tools is now an optional dependency. It's only necessary if you want
to use the IFCFG option.

Changes:

version 2.6
- add support for IPv6 configuration (FS#18699)
- add support for static routes configuration (FS#18700)
- add support for creating tun/tap interfaces (FS#15049)
- wireless: add support for explicit BSSID (FS#24582)
- wireless: add support for ad-hoc connections (FS#19683)
- use /run instead of /var/run
- drops dependency on net-tools package

Regards,
  Rémy.


pgpl4AviVmScy.pgp
Description: PGP signature

Re: [arch-general] Dejavu sans mono fonts rendering issue.

[Rémy Oudompheng]

On 2011/6/11 mwnn mwnn...@gmail.com wrote:
 Hi,

   I am unable to configure fonts on my new arch linux system. The
 fonts from the old slackware installation are similar to
 http://i.imgur.com/UcwHS.png. The new arch linux fonts look like
 http://imageshack.us/photo/my-images/695/newemacs.jpg/

Hello,

You do not seem to have a question or a problem that people might try
to solve. Do you have any?

Regards,
Rémy.

Re: [arch-general] [arch-announce] Deprecation of net-tools

[Rémy Oudompheng]

On 2011/6/10 James Rayner ja...@archlinux.org wrote:
 netcfg has an option that runs ip/iproute with any custom option
 (routes, IPs anything), the option is IPCFG. It may be seen in the
 example ethernet-iproute[1].

 IFCFG is the obscure command you mention, unfortunately it's not too
 obscure, as this was how static IPs were set before iproute
 configuration was added. It was retained for backwards compatibility.

 The only reason net-tools was still a requirement was setting hostname.
 A change similar to initscripts [2] at line 121 of
 src/connections/ethernet [3] would suffice.

 After that it ought to be safe to make net-tools an optional dependency.
 Systems already using net-tools will keep functioning, and a notice
 could be placed in code that handles IFCFG to advise those users to
 migrate to the iproute configuration.


I will add some warning about IFCFG. I made the needed change for
hostname and the next release will set net-tools to be optional.

I will need testers for the various patches I merged from the bug
tracker, notably IPv6. Any comments on the suggested implementation
are welcome.

-- 
Rémy.

Re: [arch-general] [arch-announce] Deprecation of net-tools

[Rémy Oudompheng]

On 2011/6/9 Thomas S Hatch thatc...@gmail.com wrote:
 Does netcfg still need net-tools? or can it be an opt depends? It was my
 understanding that it only used ip unless specified otherwise.

Actually, I think it only depends on net-tools because there is some
obscure option that allows users to make it run ifconfig with certain
options. Of course, it could be replaced by an option that runs ip
with custom options... All the remaining things are indeed done with
iproute2

Rémy.

Re: [arch-general] TeXLive 2011 pretest

[Rémy Oudompheng]

On 2011/6/1 Rémy Oudompheng r...@archlinux.org wrote:
 TeXLive 2011 is in pre-testing phase.

I have pushed packages to [testing]. Some notes:
* on installation, fmtutil-sys will spew a nerror saying that eptex
format was not generated. I guess it means eptex will not work unless
someone finds a fix.
* biblatex-biber is not packaged, you can use the package from AUR in
the meanwhile.
* other issues I mentioned are closed, except maybe ConTeXt.

Don't hesitate to report any problems.

Rémy.

[arch-general] TeXLive 2011 pretest

[Rémy Oudompheng]

TeXLive 2011 is in pre-testing phase. Experimental builds of texlive-bin
will be found in
  http://pkgbuild.com/~remy/texlive-experimental/

Current issues are:
- no install script for texlive-bin where it should run mktexlsr and
  fmtutil-sys --all
- dangling symlinks, due to new scripts appearing in texlive-*
- segfaulting luatex, so I guess I'll keep with compiling it separately
- no biblatex-biber. TeXLive only provide a binary that bundles Perl +
  all dependencies. I plan to adopt biblatex-biber from AUR for that and
  add it as an optional dependency of texlive-core. However, it comes
  with a very unusual set of dependencies. We can only blame François for
  being a great Perl enthusiast.

Once upstream seems stable (they say ConTeXt is currently broken),
and the PKGBUILDs reach a final form, packages will hit [testing].

Regards,
-- 
Rémy.


pgpbyhifcJEns.pgp
Description: PGP signature

Re: [arch-general] [signoff] netcfg 2.5.5-1

[Rémy Oudompheng]

On 2011/5/23 Rémy Oudompheng remyoudomph...@gmail.com wrote:
 version 2.5.5
 - new connection types: openvpn (FS#21490), vlan
 - new option HIDDEN (for hidden SSIDs)
 - new option SKIPNOCARRIER (FS#21755)
 - default WPA driver is now nl80211
 - minor fixes and improvements (FS#17190, FS#17546,
  FS#20150, FS#20569, FS#21377, FS#23293)
 - better zsh completion file (FS#19823)

 Please test on various network settings :)

It would be nice to have other signoffs and then that someone pushes
that into [core] for me.

Then I will start pushing the change to remove /var/run/* directories
from package and probably merge several patches from the bug tracker.

Rémy.

[arch-general] [signoff] netcfg 2.5.5-1

[Rémy Oudompheng]

version 2.5.5
- new connection types: openvpn (FS#21490), vlan
- new option HIDDEN (for hidden SSIDs)
- new option SKIPNOCARRIER (FS#21755)
- default WPA driver is now nl80211
- minor fixes and improvements (FS#17190, FS#17546,
 FS#20150, FS#20569, FS#21377, FS#23293)
- better zsh completion file (FS#19823)

Please test on various network settings :)

--
Rémy.

Re: [arch-general] Display Manager rc.d scripts

[Rémy Oudompheng]

On 2011/5/8 Grigorios Bouzakis grb...@xsmail.com wrote:
 Hello,
 can anyone think of a reason the rc.d scripts are added to kdm, gdm and
 slim? They are not recommended by anyone  they are to be blame for
 occasional weird problems. The standard and IMO only way is to start
 them from inittab.
 They dont come from upstream  i dont know when they were added, i
 remember them being there ever since i started using Arch, they may
 come from CRUX or something.
 I am considering requesting them removal from all display managers.
 In [0] Pierre said some people want to keep them for backwards
 compatibility. Backwards compatibility is desired only when something
 works correctly. Thoughts?

I never used inittab to launch a display manager and always used
rc-scripts, and I will never switch unless I go for systemd. I don't
understand the point of removing these scripts, unless you want users
to write them themselves. As far as I know, most major distributions
that don't use systemd ship rc-scripts for the display managers.

Moreover, rc-scripts are distribution specific and I don't see how
they can be provided by upstream.

-- 
Rémy.

Re: [arch-general] Need for debug - can do i do?

[Rémy Oudompheng]

On 2011/5/7 rafael ff1 rafael.f...@gmail.com wrote:
 HI there!

 I'm trying to update PCSX2 with some help of its dev team [1], but it
 is crashing all the time. According to 'gdb' output, it is somehow
 related to lib32-glibc, but it is omitting some information. I was
 hoping to be able to activate more verbosity, which AFAIK I can get by
 compiling it with some debug flags. [2]

 Is it correct or there is another better way to do it ?

I don't think recompiling glibc with debugging flags is going to help
you in any way. Are you sure that your pcsx executable is compiled
with debugging symbols? A debug version of glibc is usually of no use
except to debug glibc itself.

In the backtrace linked at  http://pastebin.com/eCWRNd2X, it is
*Thread1* that segfaulted.

Rémy.

[arch-general] Updated TeXLive packages

[Rémy Oudompheng]

Hello,

I have uploaded updated TeXLive packages in [testing]. Apart from regular
package updates from TeXLive, symlinks now belong to their respective
packages (FS #23174, FS#22736).

Since the currently shipped LuaTeX version (0.62) was unstable, as well
as 0.66, the luatex in texlive-bin is now a SVN snapshot.

TeXLive 2011 should be officially out this summer, so the next package
update will probably be numbered 2011.x

-- 
Rémy.


pgpnWKt2XvPoN.pgp
Description: PGP signature

[arch-general] GHC 7.0.2 and Haskell packages in [testing] and [community-testing]

[Rémy Oudompheng]

Hello,

GHC has been updated to 7.0.2 in the [testing] and [community-testing]
repositories. As with all GHC upgrades, you may have to cleanup globally
registered packages if they did not upgrade properly, as well as your
local Haskell packages.

The usual parts of Haskell Platform (everything except OpenGL) are also
in [testing]. Haskell Platform has been updated to version 2011.2.

Regards,
Rémy.


pgp2OtdvgX5qu.pgp
Description: PGP signature

Re: [arch-general] Ghost / Daniel Griffiths packages in [community]

[Rémy Oudompheng]

On 2011/2/15 Jelle van der Waa je...@vdwaa.nl wrote:
 Sadly Ghost resigned as TU, he has done a good job and I thank him again
 for all his hard work.

 But there are still much packages left in [community] which he owns,
 therefore I like to see these packages adopted or moved to
 [unsupported] .

 Here is a link with all his packages, i already adopted some but he is
 also still listed as maintainer there.
 http://www.archlinux.org/packages/?sort=arch=repo=q=maintainer=dgriffithslast_update=flagged=limit=all

I'd like to adopt scribus, but the Web interface seems to answer
randomly at my clicks.

-- 
Rémy.

[arch-general] Package update : hplip 3.11.1

[Rémy Oudompheng]

HPLIP 3.11.1 was released several days ago : it includes support for
new printers and scanning support for several printers (e.g. the one I
bought last week, HP Deskjet 2050). I thought the package was not very
critical so that I could update it directly in [extra]. I can at least
print and scan (hp-scan still doesn't work with my printer, but
scanimage does).

Now you know who you can blame if your printer suddenly stops working
at next update.

-- 
Rémy.

[arch-general] [signoff] TeXLive packages

[Rémy Oudompheng]

Hello,

I have updated the texlive non-binary packages to track the upstream
updates. You will find the detailed list of updated packages in the
attached file. The update should remain straightforward. I have
cleaned up the install scriptlet, hoping that it still works as
intended. Please notify me of any inconsistencies.

Rémy.
Upgrading package texlive-bibtexextra from 19862 to 20942
- upgrade package amsrefs 15878 - 20249
- upgrade package beebe 19862 - 20832
- upgrade package biblatex 19592 - 20519
- upgrade package biblatex-apa 19814 - 20565
- upgrade package biblatex-chem 18827 - 20829
- upgrade package biblatex-dw 19846 - 20521
- new package biblatex-mla
- upgrade package biblatex-nature 17634 - 20515
- upgrade package biblatex-philosophy 17824 - 20530
- upgrade package biblatex-science 17662 - 20516
- upgrade package cell 15878 - 20756
- upgrade package historische-zeitschrift 17430 - 20170
- upgrade package rsc 16127 - 20942
- new package showtags
- deleted package elsevier-bib

Upgrading package texlive-core from 20288 to 20954
- upgrade package bibtex 18835 - 20729
- upgrade package context 20272 - 20438
- upgrade package context-letter 20207 - 20359
- upgrade package courier 15878 - 20926
- upgrade package drv 16678 - 20511
- upgrade package dvips 20191 - 20950
- new package eqnarray
- upgrade package expl3 20100 - 20793
- upgrade package fontspec 19960 - 20472
- upgrade package genmisc 15878 - 20683
- upgrade package helvetic 16767 - 20926
- upgrade package hyperref 20278 - 20783
- upgrade package hyphenex 15878 - 20631
- upgrade package installfont 19837 - 20355
- upgrade package latex2man 18835 - 20844
- upgrade package latexconfig 20014 - 20663
- upgrade package latexmk 19650 - 20887
- upgrade package ltxmisc 20188 - 20350
- new package luacode
- upgrade package luainputenc 18253 - 20491
- upgrade package luamplib 19691 - 20881
- upgrade package luaotfload 20127 - 20475
- new package luasseq
- upgrade package luatexbase 18560 - 20476
- upgrade package luatextra 19860 - 20747
- upgrade package mkjobtexmf 18835 - 20859
- upgrade package natbib 16643 - 20668
- upgrade package pdfjam 18835 - 20459
- upgrade package pdfpages 19665 - 20796
- upgrade package pdftex-def 19749 - 20593
- upgrade package plain 20014 - 20544
- upgrade package powerdot 20178 - 20649
- upgrade package purifyeps 18835 - 20636
- upgrade package rec-thy 20114 - 20909
- new package statex
- upgrade package statex2 15878 - 20307
- upgrade package tablor 18250 - 20473
- upgrade package texinfo 19610 - 20918
- new package textcase
- new package threeddice
- upgrade package times 20188 - 20926
- upgrade package xepersian 19887 - 20681
- upgrade package xetex-itrans 20175 - 20757
- upgrade package xpackages 20099 - 20954
- upgrade package xunicode 19594 - 20553
- new package ytableau
- deleted package apalike
- deleted package uhrzeit

Upgrading package texlive-fontsextra from 19878 to 20923
- upgrade package Asana-Math 18651 - 20023
- upgrade package adforn 19877 - 20019
- new package adfsymbols
- new package bbold-type1
- upgrade package bera 15878 - 20031
- upgrade package berenisadf 19812 - 19952
- upgrade package braille 17130 - 20655
- upgrade package ccicons 16440 - 20563
- new package cmtiup
- new package comfortaa
- upgrade package dictsym 18947 - 20031
- upgrade package dingbat 19193 - 19910
- new package droid
- upgrade package duerer 15878 - 20741
- upgrade package ean 15878 - 20851
- upgrade package euxm 13293 - 20202
- upgrade package gentium 19390 - 20033
- upgrade package jamtimes 19762 - 20408
- new package lato
- upgrade package ly1 18995 - 20923
- upgrade package mdputu 19763 - 20298
- new package ocr-b
- upgrade package poltawski 19661 - 20075
- new package starfont
- upgrade package tapir 15878 - 20484
- upgrade package tfrupee 19687 - 20770
- upgrade package xits 19510 - 20217
- deleted package apl
- deleted package logic
- deleted package pclnfss
- deleted package simpsons
- deleted package zefonts

Upgrading package texlive-games from 18651 to 20619
- new package bartel-chess-fonts
- upgrade package chess 15878 - 20582
- upgrade package chessboard 15878 - 19440
- upgrade package chessfss 15878 - 19440
- upgrade package skaknew 18651 - 20031
- upgrade package xskak 15878 - 19440
- deleted package cchess

Upgrading package texlive-genericextra from 19909 to 20769
- new package epigram
- new package fntproof
- upgrade package lecturer 19909 - 20011
- upgrade package xlop 15878 - 20769
- deleted package vrb
- deleted package vtex

Upgrading package texlive-htmlxml from 19804 to 20271
- upgrade package tex4ht 19804 - 20271

Upgrading package texlive-humanities from 18675 to 19440
- upgrade package bibleref 18247 - 19317
- upgrade package ednotes 15878 - 19440
- upgrade package gb4e 16735 - 19216
- upgrade package linguex 18675 - 19440
- deleted package tree-dvips
- deleted package fc_arith

Upgrading package texlive-langcjk from 19645 to 20535
- upgrade package adobemapping 19169 - 20535

Upgrading package 

Re: [arch-general] Multi architecture binary pkgs

[Rémy Oudompheng]

On 2010/12/6 jesse jaara jesse.ja...@gmail.com wrote:
 Currently, if one wants to make a pkg, lets
 say, for an app that only has binaries available
 and only for 32bit archs, then one usually
 makes a bin32-appname pkg for it. I don't
 like this and would like to have the bin32
 and the non-bin32 pkgs to be just one
 pkg with the name of the app. But if one
 makes this kind of a pkg, one must use
 ugly if [[ $CARCH =  statements are in
 the PKGBUILD, so I was thinking that
 could it be possible to implement some
 new variables in PKGBUILDS
 like depends32 and optdepends32
 and then build32() {} and
 package32() {}? I dont know how makepkg
 is written, so I dont know how hard it is
 to implement these, but in the best case it shouldn't
 be more than just one or two if-statements
 in the code, so if arch is x86_64 use
 the 32 variables if they are present.

Hello,

This seems to assume that pacman and makepkg run on systems that are
either 32-bit or 64-bit. IMO, your proposal looks very ad hoc, and
would add unnecessary complications to makepkg, with no benefit when
dealing with PowerPC, ARM, and other architectures.

-- 
Rémy.

Re: [arch-general] Multi architecture binary pkgs

[Rémy Oudompheng]

On 2010/12/6 Rémy Oudompheng remyoudomph...@gmail.com wrote:
 This seems to assume that pacman and makepkg run on systems that are
 either 32-bit or 64-bit. IMO, your proposal looks very ad hoc, and
 would add unnecessary complications to makepkg, with no benefit when
 dealing with PowerPC, ARM, and other architectures.

However, maybe a sensible way to do that would be to allow build()
function to be replaced by build_$arch functions in the same fashion
as with split packages.

-- 
Rémy.

Re: [arch-general] [signoff] kernel26-lts 2.6.32.26-1

[Rémy Oudompheng]

2010/11/23 Tobias Powalowski t.p...@gmx.de:
 Latest LTS kernel is in testing,
 please signoff for both arches.

Everything working as expected here, signoff x86.

Rémy.

Re: [arch-general] [signoff] kernel26-lts 2.6.32.25-2

[Rémy Oudompheng]

Tobias Powalowski t.p...@gmx.de:
 Latest kernel is in testing,
 adopted changes from main kernel config:
 - added more cpus for x86_64
 - added tomoyo support
 - disabled rds modules
 - build in rtc into the kernel
 - added pcieaspm option

 please signoff for both arches.

signoff i686

-- 
Rémy.