Re: [arch-general] Why is /lib/libncurses.so a linker script?

[Allan McRae]

On 12/04/17 20:09, Magnus Therning wrote:
> 
> Allan McRae  writes:
> 
>> On 12/04/17 19:33, Magnus Therning wrote:
>>> I'm just curious what the reason is.
>>
>> Because absolutely everything should link to the wide character version.
> 
> Wouldn't a symbolic link have the same result?
> 

Then you get some software thinking its linked to libncurses.so and some
thinking its linked to libncursesw.so.  Because they are the same thing,
conflict occur and shit hits the fan.

A

Re: [arch-general] Why is /lib/libncurses.so a linker script?

[Allan McRae]

On 12/04/17 19:33, Magnus Therning wrote:
> I'm just curious what the reason is.
> 

Because absolutely everything should link to the wide character version.

> Oh, and yes, it does cause some problems: 
> https://bugs.archlinux.org/task/53598

Stupid software is stupid.

A

Re: [arch-general] Suppressing specific pacman warnings

[Allan McRae]

On 03/04/17 08:17, João Miguel via arch-general wrote:
>>> I found this old bug report (https://bugs.archlinux.org/task/31594)
>>> regarding this, but there's no decision about it.
> Note: if this is really not worth anyone's time, this should be closed
> as WONTFIX.

That bug is about a completely different issue...

Your issue is a WONTFIX.

A

Re: [arch-general] Firefox 52 Audio broken

[Allan McRae]

On 08/03/17 08:14, Eli Schwartz via arch-general wrote:
> On 03/07/2017 05:04 PM, Ralf Mardorf wrote:
>> On Tue, 7 Mar 2017 22:18:19 +0100, LoneVVolf wrote:
>>> On 07-03-17 21:14, Ralf Mardorf wrote:
 On Tue, 7 Mar 2017 16:00:18 +0100, Carlchristian Eckert wrote:  
> As a workaround, have you tried using apulse? It is a pulseaudio
> emulation for ALSA. Some time ago, I used it successfully to run
> Skype (which also depends on pulseaudio) without having pulseaudio
> installed.  

 I don't know, if the required asoundrc could have impact on real-time
 pro-audio usage. I won't test it.  
>>>
>>> I just tested apulse-git successfully, no changes to my alsa setup
>>> were needed.
>>
>> Thank you,
>>
>> I confirm that apulse-git works with Firefox 52.0-1 and an asoundrc
>> isn't required :).
> 
> Keep in mind that firefox 52.0-2 uses "ac_add_options --enable-alsa"
> 
> Carry on...
> 

Until firefox-54, which will return to pulse because it breaks alsa...

A

Re: [arch-general] Firefox 52 Audio broken

[Allan McRae]

On 07/03/17 23:09, jjgaris via arch-general wrote:
> One solution I could think of is an alternative firefox package (not in AUR) 
> that still allows users to make their own 
> choice. Would that be a possibility?

No.

Re: [arch-general] Firefox 52 Audio broken

[Allan McRae]

On 07/03/17 18:29, jjgaris via arch-general wrote:
> Since the update to firefox 52 the audio support has been broken.
> This seems to be because pulse audio is now a dependency by default in 
> firefox.
> However firefox can still be build with ALSA support.
> 
> Without getting into any dicussion about issues about pulseaudio itself, I 
> believe it should be possible to use firefox on arch without being forces to 
> use pulse 
> audio. I am certainly not the only one to have banned this package from my 
> boxes. And having more choices is certainly a good thing.
> 
> Not sure this is the right place but I would like to ask to change back to 
> the old defaults (ALSA). 
> With the old defaults, the user can choose to use pulse audio (or JACK) or 
> stay with plain ALSA support.
>

Upstream changed to pulseaudio by default. Arch follows upstream

You can compile firefox yourself to set it being alsa only.

A

Re: [arch-general] Arch install broken by invalid signatures (anthraxx) using 201610 iso

[Allan McRae]

On 08/01/17 17:11, David C. Rankin wrote:
> All,
> 
>   Attempting an arch install tonight, and I get the following at pacstrap /mnt



>   What was this caused by? I had to boot from the 10/2016 iso. Is it a change
> in signatures since then? I'll download a new iso and try, but I'd be
> surprised if an iso less than 5 months old no longer works?
> 

The key probably expired...   Just do "pacman-key --refresh-keys" on the
install media.

A

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Allan McRae]

On 26/12/16 22:12, NicoHood wrote:
> 
> 
> On 12/16/2016 05:46 PM, Diego Viola via arch-general wrote:
>> On Sat, Dec 3, 2016 at 3:27 AM, fnodeuser  wrote:
>>> https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html
>>>
>>> i have a few things to add to this.
>>>
>>> the message digests at the download page for the .iso file, must change to 
>>> sha256 and sha512 ones, or to a sha512 one.
>>>
>>> if an upstream does not sign the files, does not have https enabled, and/or 
>>> refuses to take security and privacy seriously, sha512 must be used in the 
>>> PKGBUILD files.
>>>
>>> in the cases of upstreams that use md5 and/or sha1 message digests, those 
>>> will be added in a second ALGOsums= line under the sha512sums= line.  if 
>>> they use md5 and sha1, then sha1sums must be used for the second ALGOsums= 
>>> line.
>>
>> Once again I must say thanks, fnodeuser.
>>
> 
> Yesterday I wanted to install ArchLinux on someone else computer. He
> used Windows until now and had no gpg handy yet (it is really annoying
> to install on windows).
> 
> So we needed to verify the source otherwise. But there was no real
> option as md5/sha1 is broken and his internet is too slow to download it
> again via torrent. We did not install Arch then and I will send him my
> sha512sum from my computer the next days where I did a torrent download.
> 
> The ArchLinux website connects via https. His mirror that he used did
> not (http or ftp). So we had a real problem and there was no way to
> verify the source properly. Adding sha256 and sha512 would not cause
> more trouble but would be extremely helpful here.
> 
> @Allan I think you are responsible for this if I am correct. Would you
> please be so kind and add sha256 sums to the download page?

I have nothing to do with this.

Also, is there even a theoretical case where a joint md5 and sha1
collision has occured?

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Allan McRae]

On 16/12/16 21:28, NicoHood wrote:
> make sha512 the default

Hey...  guess what is still not happening?

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Allan McRae]

On 16/12/16 11:35, fnodeuser wrote:
> "With great power comes great responsibility."
>   -Uncle Ben

I will not have misquotes on this mailing list!

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Allan McRae]

On 10/12/16 02:05, NicoHood wrote:
> An official rule would be still better. So let us know what you (devs)
> think about this finally.

Been there, done that...

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Allan McRae]

On 08/12/16 08:51, sivmu wrote:
> Am 07.12.2016 um 10:49 schrieb Allan McRae:
>> > ...
>> > I advocate keeping md5sum as the default because it is broken.  If I see
>> > someone purely verifying their sources using md5sum in a PKGBUILD (and
>> > not pgp signature), I know that they have done nothing to actually
>> > verify the source themselves.
>> > ...
> That is a very dangerous assumtion. I know for a fact that many
> maintainers used md5 for verification because it is the default.
> There are/were maintainers that downloaded the source, verified the pgp
> signature and generated the md5 checksum to include it in the PKGBUILD
> (without the pgp signature)

Idiots...  so again using md5sums as the default saves me from people
who don't know how to package.

A

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Allan McRae]

On 07/12/16 19:58, Gregory Mullen wrote:
>> But we don't care about that...  we just want to feel warm and fuzzy with
> a false sense of security.
> 
> No one is suggesting sha*sum replace, and actual security/authentication
> check. Only that maybe it's not a good idea to use a system we all know is
> broken.
> 

If everyone knows it is broken, upstream will not be providing md5sums
to compare against and then and PKGBUILD maintainer that has verified
the source files using upstream provided hashes will not use md5sum.

All we do by changing away from md5sum as the default is hiding the
large number of packages that do nothing to verify upstream source
integrity.

In fact, I am making CRC the default.

A

Re: [arch-general] Stronger Hashes for PKGBUILDs

[Allan McRae]

On 07/12/16 19:35, Gregory Mullen wrote:
> Grayhatter here, developer of Tox -- The security centered TAV client. No
> matter what the reason is, NO ONE should be using MD5. We can argue about
> what hash we want to use, but literally nothing, is better than using MD5.
> I don't mean MD5 is better than everything else, I mean NOT using a hash,
> is better than using MD5.

Ignoring "slight" exaggerations...

> The argument that an insecure hash is fine because it doesn't need to be
> secure, and that PGP is a better replacement; Is a plainly BAD argument.
> The issue at hand is not, what should we use to verify the authenticity of
> the packages. The question is, is MD5 an acceptable hashing algorithm? We
> all know it's not. If given the choice, NO ONE who knows about the SERIOUS
> issues with MD5 would think it's a reasonable suggestion.
> 
> Switching to sha256/512 isn't a hard switch `sha{256,512}sum` is in
> coreutils (a member of base no less).
> 
> To recap... we have a lot of good reasons to drop MD5 like the broken algo
> it is. No applicable reasons why need to keep it. So... why haven't we
> replaced it yet?

I advocate keeping md5sum as the default because it is broken.  If I see
someone purely verifying their sources using md5sum in a PKGBUILD (and
not pgp signature), I know that they have done nothing to actually
verify the source themselves.

If sha2sums become default, I now know nothing.  Did the maintainer of
the PKGBUILD get that checksum from a securely distributed source from
upstream?  Had the source already been compromised upstream before the
PKGBUILD was made?  Now I am securely verifying the unknown.

But we don't care about that...  we just want to feel warm and fuzzy
with a false sense of security.

A

Re: [arch-general] ensuring integrity of sources (was: [arch-dev-public] todo list for moving http -> https sources)

[Allan McRae]

On 01/11/16 03:14, Bennett Piater wrote:
> On 10/31/2016 06:04 PM, Levente Polyak wrote:
>> On the other side we have a dev/TU authenticating the buildscript.
>> Both cover certain areas but are still independent and one does not make
>> the other futile.
> 
> Since this thread is helpfully on arch-general now, I want to quickly
> chime in and say that I would really like authenticated buildscripts at
> some point :)
> 

I would like some bourbon.

Allan




* It might appear unrelated, but I can spend time on pacman/makepkg if I
don't have to work for bourbon.  Then again, bourbon reduces the quality
of my coding after a point...

** makepkg --source --sign

Re: [arch-general] Implement sql/sqlite database for pacman local database

[Allan McRae]

On 22/10/16 14:06, Alive 4ever wrote:
> On Sat, Oct 22, 2016 at 02:15:01AM +0800, Chi-Hsuan Yen via arch-general 
> wrote:
>> On Sat, Oct 22, 2016 at 1:54 AM, Robin via arch-general <
>> arch-general@archlinux.org> wrote:
>>
>>> Hi,
>>>
 I was curious why does 'pacman -Q' operations took longer than 'apt'
 counterparts.
>>> Sounds interesting but I have a few question about how did you measure
>>> this and how big the difference is. (Shouldn't be that big). Would be great
>>> if you provide more information on the comparability of you systems and the
>>> tools you used for tracing.
>>> Maybe there are other reasons why it is slow on your installation ?
>>>
 For long term pacman development road map, it would be better to use
 single sql based database for tracking locally installed packages
 instead of keeping directories of every installed packages.
>>> I am not sure if a sql based database would be a good solution if you
>>> where right. It adds much more complexity and also a dependencies on $SQL
>>> backend. For me as a semi-professional arch user this would be worse than a
>>> maybe "not that fast" package dB querying.
>>>
>>> Regards,
>>>  Robin
>>
>>
>> Sometimes I have a similar problem, too. When the system just boots up, or
>> I just exploits my disk (for example building Firefox), pacman-related
>> files are moved out of the disk cache, so it needs some time to read them
>> all from the disk. Here's a simple performance test:
>>
>> $ sudo -v && time pacman -Q linux && sudo sync && sudo sync && echo 3 |
>> sudo tee /proc/sys/vm/drop_caches && time pacman -Q linux
>> [sudo] password for yen:
>> linux 4.8.3-1
>> pacman --color=auto -Q linux  0.00s user 0.00s system 2% cpu 0.121 total
>> 3
>> linux 4.8.3-1
>> pacman --color=auto -Q linux  0.00s user 0.01s system 0% cpu 1.229 total
>>
>> The difference is more than 10 times. I use a 5-year-old HDD. I guess on
>> even older machines things are worse.
>>
>> Regards,
>>
>> Yen Chi Hsuan
> 
> My own test - before optimization, ``pacman -Qs linux`` took almost half
> a minute.
> $ time pacman -Qs linux
> real0m26.716s
> user0m0.063s
> sys 0m0.230s
> 
> After running ``pacman-optimize``, it runs instantly.
> $ time pacman -Qs linux
> real0m0.048s
> user0m0.030s
> sys 0m0.017s
> 
> The filesystem fragmentation can be felt more deeply on slower and older
> HDD.
> .

Isn't caching brilliant...

Re: [arch-general] Implement sql/sqlite database for pacman local database

[Allan McRae]

As the currently lead pacman developer...   We will never have a sql (or
other) database backend.

When we did tests for the sync backends, using a single tar file gave
the same speed-up as using some sql variant (and we still have not
optimised any reading from that - for the sync "dbs", we always load all
information regardless of what proportion is needed)  I intend to move
the local db to a single tar file too at some stage.

Allan

Re: [arch-general] What happened to the Beginner's Guide?

[Allan McRae]

On 03/10/16 00:51, David C. Rankin wrote:
> I wonder how Allan would view the matter.

The Beginner's Guide should never have existed.

A

Re: [arch-general] Arch GNU/Linux install for beginners and new users

[Allan McRae]

On 23/09/16 14:23, Eli Schwartz via arch-general wrote:
> On 09/22/2016 08:19 PM, Allan McRae wrote:
>> Anyone else who replies to this thread will be stuck in the moderation
>> queue (which no-one checks).
> 
> I took this to mean that this thread got "locked" so to speak, and any
> replies to this thread would require manual approval (which isn't going
> to happen) by a list moderator in order to get through.
> 
> So, why are people still successfully posting new emails to this email
> thread? :(
> Because I was enjoying the thought that we wouldn't have to listen to
> any further stupidity, and I feel kind of let down that it isn't so...

Everyone who replies to the list (you included) are banned from posting
until I feel like reinstating permissions.

Allan

Re: [arch-general] Arch GNU/Linux install for beginners and new users

[Allan McRae]

Anyone else who replies to this thread will be stuck in the moderation
queue (which no-one checks).

Allan

Re: [arch-general] libgcrypt.so.20 missing

[Allan McRae]

On 14/01/14 22:13, Damjan wrote:
> On 13.01.2014 22:52, Thomas Bächler wrote:
>> Am 13.01.2014 22:48, schrieb Mark Lee:
>>> Salutations,
>>>
>>> All right then; if it works for you guys. Will an announcement be made
>>> on the arch website to ensure the upgrade doesn't break more systems or
>>> will we continue the wait game and hope that all the mirrors sync and
>>> the issue just goes away?
>>
>> As Lukas pointed out by now, a mistake was made when moving the
>> packages, and libgcrypt was moved 20 minutes after the rest of the
>> packages. Any mirror that synced in that timeframe will have an
>> inconsistent state.
>>
>> There is no point in announcing anything, since all mirrors should have
>> the corrected files already, and whoever didn't break their systems by
>> now won't break them.
> 
> I've had the problem on both my Arch computers.
> 
> I'll have to manually install libgcrypt-1.6.0-1 now without checking its
> signature. Which is a bit scary :)
> 
> Can anyone confirm the checksum of the 32bit package file? I used
> sha512sum /var/cache/pacman/pkg/libgcrypt-1.6.0-1-i686.pkg.tar.xz
> 
> eb4344f7a5602aa061575b2014abea21eb20c395f063d24904c914ea49ffaaa3cb31023b17ed2221bdd483676bd15194a0df748a6914d74cfaec8d76274d1036
> 

"pacman -S libgcrypt" will verify the package in your cache before
reinstalling.

Re: [arch-general] LUKS emergency self-destruct

[Allan McRae]

On 13/01/14 20:57, Paladin wrote:
> Hi,
> does anyone know if there is plan to implement this:
> http://www.kali.org/how-to/emergency-self-destruction-luks-kali/
> in Arch?
> 
> Patch https://github.com/offensive-security/cryptsetup-nuke-keys
> is not too big and IMHO it would be great to have this option..
> 
> Patch is for 1.6.1 but it cannot be that difficult to port it to
> 1.6.3 which we have.
> 

Arch provides vanilla packages.  So no.

Re: [arch-general] Default value of "j" in makeflags of makepkg.conf

[Allan McRae]

On 04/01/14 01:03, Martin S. Weber wrote:
> On Fri, Jan 03, 2014 at 03:23:24PM +0100, Thomas B?chler wrote:
>> Am 03.01.2014 15:21, schrieb Martti K?hne:
>>> You can't expect every upstream to fix their autohell to conform to
>>> our expectations here.
>>
>> So, we keep repeating ourselves.
>>
>> There is the !makeflags option for PKGBUILDs to work around this problem
>> (which you would know if you read the thread). If a package is broken
>> with -j, this option helps.
>>
> 
> netbsd / pkgsrc did switch to a more concurrent default for $MAKE_JOBS.
> 
> MAKE_JOBS_SAFE=no is a way to turn it off.
> 
> In current 'stable' pkgsrc, 590 / 11862 packages have it set (to no,
> i.e., not parallel build safe).
> 
> Each predates someone running into the pkg not building for them while
> it built for others.
> 
> You wanna find those inexplicably not building on some machines manually,
> again?
> 
> Have fun.
> 

Why would it need done manually?   You have already found us a list!

Allan

Re: [arch-general] PCRE 8.34-1 Upgrade breaks expected regex behavior for MediaWiki

[Allan McRae]

On 30/12/13 14:45, Peter Baldridge wrote:
> Hello All,
> 
> The most recent upgrade to pcre 8.34-1 seems to disallow group names
> starting with a digit.  A quote from the PCRE news.txt [1]:
> 
>> "Perl no longer allows group names to start with digits, so I have made this
> change also in PCRE."
> 
> I found this bug report[2] on the mediawiki site that apparently has a
> working patch though I'll probably just downgrade until the patch is
> in the official package.
> 
> This breaks my MediaWiki install with the following error in the
> httpd/error.log:
> 
>> PHP Warning:  preg_match(): Compilation failed: group name must start with a 
>> non-digit at offset 8 in /usr/share/webapps/mediawiki/includes/MagicWord.php 
>> on line 907
> 
> I'm not sure how Arch would handle this since it is an upstream bug.
> If someone needs any other info let me know.
> 
> [1] http://pcre.org/news.txt
> [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=58640
> 


Bugs should be reported to the bug tracker where the maintainer of the
mediawiki package will see it (and may backport any patch applied upstream).

Allan

Re: [arch-general] Patch for update-mime-info slowness

[Allan McRae]

On 06/12/13 05:39, Timothée Ravier wrote:
> On 05/12/2013 20:10, Lukas Jirkovsky wrote:
>> On Thu, Dec 5, 2013 at 7:37 PM, Gaetan Bisson  wrote:
>>> [2013-12-04 15:00:31 -0500] Sébastien Leblanc:
 I am kind of annoyed by the time it takes to update the MIME database
>>>
>>> Please, please, please. Bug reports and feature requests go to:
>>
>> I'm not sure whether this should classify as a bug report.
> 
> How could this not qualify for a bug report?
> 
> Maybe this should also be discussed upstream as this is not a Arch
> specific issue as far as I understand. Maybe they do have reasons for
> calling fsync so heavily.
> 
>> Back to the topic. Lately, I have been annoyed by that, too. Maybe
>> it's some recent change (or I just didn't notice it before). I concur,
>> syncing something like MIME database that can be easily rebuild in
>> case an unlikely filesystem corruption occurs seems kinda stupid.
> 
> Again, file a bug upstream.
> 

I have seen this bug filed upstream and rejected.  It is a "feature"...

For the same reason, I would frown on Arch patching it out.  It is how
upstream decided they want their software.

Allan

Re: [arch-general] apache 2.4

[Allan McRae]

On 04/12/13 14:49, Anatol Pomozov wrote:
> Hi
> 
>> Exactly.  AFAIK, we have no-one interested in maintaining apache-2.4.
>> I'm sure we could have apache22 and apache (2.4) otherwise.
> 
> If no-one from core developers wants to maintain this package could
> you please move apache and modules to community repo? There are TU who
> will help to maintain this. We already have another popular http
> server (nginx) that is successfully maintained by community and Apache
> should be fine there as well.
> 

TUs know how to request this  (hint: arch-dev-public...)

Re: [arch-general] apache 2.4

[Allan McRae]

On 04/12/13 07:59, Karol Babioch wrote:
> Hi,
> 
> Am 03.12.2013 16:37, schrieb David C. Rankin:
>> The 2.2->2.4 update represents a "major" update to crucial parts of apache
>> including:
> 
> This is exactly the reason why the new version should be provided by
> Arch itself and not some "third-party" AUR packages.
> 
>> For something as fundamental to server operations as apache, Arch should
>> continue to provide 2.2 as the core package while providing 2.4 in testing 
>> for
>> an extended period. A clear timeline for the move of 2.4 from testing to core
>> should be developed by reasoned discussion with input from the user base. 
>> Once
>> 2.4 moves to core, 2.2 should be maintained in core as (eg. apache22) for so
>> long as support is provided by apache.org.
> 
> Having used Arch for a couple of years now, this usually is something
> that gets resolved by an appropriate RFC over on the arch-dev mailing
> list. I have no problem with there actually being two version of Apache
> in the repositories for a while, so people get some time to get their
> installations migrated. Looking at this from the "outside" there seems
> to be no effort to get this thing started at all. I don't see any
> technical reasons for this, but at least to me it seems that basically
> nobody cares ...
> 

Exactly.  AFAIK, we have no-one interested in maintaining apache-2.4.
I'm sure we could have apache22 and apache (2.4) otherwise.

A

Re: [arch-general] Sourcing /etc/rc.conf in configs and .install scripts

[Allan McRae]

On 13/11/13 07:41, Karol Blazewicz wrote:
> * core/nfs-utils/nfs-utils.install:
> 
> post_upgrade() {
>   if [ "$(vercmp $2 1.2.0-2)" -lt 0 ]; then
> cat << 'EOM'
>   ==> IMPORTANT NFS UTILS CHANGES:
>   ==> This is a rather important upgrade, you are going to have to
> change config files.
>   ==> /etc/rc.conf daemons changes:
>   ==> Change portmap to rpcbind
>   ==> Change nfslock to nfs-common
>   ==> Change nfsd to nfs-server
>   ==>
>   ==> Extended configuration options for NFS (clients & server) are
> available in:
>   ==> /etc/conf.d/nfs-common
>   ==> /etc/conf.d/nfs-server
>   ==> Please change them to your needs.
> EOM
>   fi
> }

I'd say any package with a multiline output should have a bug filed to
remove it.

A

Re: [arch-general] Revisit official SELinux support

[Allan McRae]

On 01/11/13 08:56, Timothée Ravier wrote:
> On 31/10/2013 00:36, Allan McRae wrote:
>> On 31/10/13 09:36, Timothée Ravier wrote:
>>> Only packagers will be impacted as there are still some patches needed
>>> and this could slow down 'core packages' updates when issues arise. But
>>> fixes usually comes quite quickly as both Fedora and Gentoo maintain
>>> packages with SELinux support.
>>
>> Requiring patches not accepted upstream is an immediate blocker.
> 
> Sorry, I chose my words poorly. I meant two things:
>   * First, patches required for SELinux should be pushed and accepted
> upstream. I don't know the current state about those. I'll post an
> update later.
>   * Future core packages releases may require patches to make SELinux
> work or even make the packages build with SELinux activated. On this
> front there isn't too much to be concerned of as both Gentoo and Fedora
> SELinux folks are affected by those issues too and will surely provide
> patches which we could push upstream if necessary.

It is completely necessary that all these patches are pushed upstream
due to the Arch patching policy.

>>> I see a couple of issues that will also have to be resolved for SELinux
>>> on Arch to be usable:
>>>  * It needs some support in pacman, otherwise package updates will be
>>> painful;
>>
>> I'm interested as a pacman developer what support would be needed, but
>> that too is a likely blocker.
> 
> First, as I don't know pacman internals very well, I may say/assume
> stupid things. Please correct me if that happens.
> 
> Among other things, SELinux use labels stored in files extended
> attributes to do access control. You can reset those attributes to the
> default values from the policy using the restorecon command tool or
> using a function in the libselinux library.
> 
> However, I suspect that updating packages using pacman will overwrite
> those attributes, requiring relabeling at each update as we don't know
> which files had their attributes changed.
> 
> What's needed is a switch/option in pacman to restore SELinux labels on
> both new files and files that have been overwritten during update.
> 
> I'll work on a patch once I got a test system running again.
> 
> Is this something unacceptable to put in pacman?

Sounds like this should be a post update hook.   But we don't have hooks
yet...

A

Re: [arch-general] Revisit official SELinux support

[Allan McRae]

On 31/10/13 09:36, Timothée Ravier wrote:
> On 29/10/2013 01:21, Allan McRae wrote:
>> I'd suggest that someone maintains an unofficial repo with all the
>> packages required to set this up to prove the work required for
>> continual maintenance of this has been done.  Then requests could be
>> made to (e.g.) add support to the kernel, providing full details of what
>> is required and if it has any effect on those not using SELinux.
> 
> Hi,
> 
> I've had this on my TODO list for a while but never got to finish it up
> to the point of having a really functional system as it is quite time
> consuming (especially the SELinux policy fixing part).
> 
> But I should have some time for it now so I'll try to make those packages.
> 
> Impact for non-SELinux users should be rather minimal:
>  * kernel: TOMOYO is already enabled and need explicit boot parameter to
> operate and so will SELinux once enabled. No major changes here except
> for a slightly bigger kernel.
>  * userspace: only a very restricted set of packages needs tweaks, but
> it won't impact performance for non-SELinux users. No major changes here
> except for slightly bigger packages.
> 
> Only packagers will be impacted as there are still some patches needed
> and this could slow down 'core packages' updates when issues arise. But
> fixes usually comes quite quickly as both Fedora and Gentoo maintain
> packages with SELinux support.

Requiring patches not accepted upstream is an immediate blocker.

> I see a couple of issues that will also have to be resolved for SELinux
> on Arch to be usable:
>  * It needs some support in pacman, otherwise package updates will be
> painful;

I'm interested as a pacman developer what support would be needed, but
that too is a likely blocker.

>  * It needs a proper policy tuned for Arch Linux packages. Filesystem
> hierarchy differences between Fedora and Arch will prevent us from just
> applying the Fedora policy to Arch;
>  * Performance comparisons between no-SELinux and disabled-SELinux
> installations to make sure the impact is minimal.
> 
> Cheers,
> 
> Tim
> 
> 

Re: [arch-general] Revisit official SELinux support

[Allan McRae]

On 29/10/13 09:39, Karol Babioch wrote:
> Hi,
> 
> I'm wondering whether there was ever an actual discussion regarding the
> SELinux support within Arch. I could only find a bug report from
> September 2012 (see [1]), which was closed by Dave Reisner with kind of
> a lame comment: "A million times no.".
> 
> After having dealt with SELinux on a couple of occasions I think that it
> is real security enhancement worth the initial hassle of setting it up
> properly (at least in a server environment).
> 
> Looking into the support for SELinux in Arch I think it is way too messy
> to be actually used in practice (see [2]).
> 
> I wouldn't go so far to suggest to enable SELinux by default as proposed
> in the bug report mentioned above, but I think it would actually make
> sense to support it - more or less - officially. I'm thinking about a
> model similar to the one implemented by Debian (see [3]). It basically
> comes down to installing some default policies and enabling SELinux by
> running a script.
> 
> This would, however, require at least the stock kernel to have support
> for SELinux built-in by default. Are there any technical reasons for
> this not being the case already?
> 
> I don't want this to become a discussion about the pros and cons of
> SELinux (on a desktop system) in general. I'm just wondering whether it
> would be feasible to implement "official" support for SELinux within
> Arch. So, if possible, please keep it technical.
> 
> Best regards,
> Karol Babioch
> 
> [1]: https://bugs.archlinux.org/task/31448
> [2]: https://wiki.archlinux.org/index.php/SELinux
> [3]: https://wiki.debian.org/SELinux/Setup


Looking at [2], it appears the SELinux work for Arch is much further
along than it once was.

I'd suggest that someone maintains an unofficial repo with all the
packages required to set this up to prove the work required for
continual maintenance of this has been done.  Then requests could be
made to (e.g.) add support to the kernel, providing full details of what
is required and if it has any effect on those not using SELinux.

Allan

Re: [arch-general] Static libs

[Allan McRae]

On 29/10/13 08:43, Carsten Mattner wrote:
> On Sun, Oct 27, 2013 at 2:17 AM, Timothée Ravier  wrote:
>> On 26/10/2013 22:22, Carsten Mattner wrote:
>>> Yes but this was news to me and is unusual. So this should be stated
>>> clearly on archlinux.org or at least the wikipedia article.
>>
>> Please edit/update the pages you deem fit for this information in the
>> Arch Wiki and/or Wikipedia.
> 
> Checked Debian and Fedora and was surprised that both don't bundle
> .a files. Must be not that unusual and I was wrong.
> 

Not quite correct.   Fedora and Debian do provide static libs in their
-devel packages along with headers.

Allan

Re: [arch-general] glibc 2.18-5 question

[Allan McRae]

On 27/09/13 01:15, LANGLOIS Olivier PIS -EXT wrote:
> Hi,
> 
> I just checked what was the motivation for this 5th release and I have found:
> 
> http://hmarco.org/bugs/CVE-2013-4788.html
> 
> where it says:
> 
> The vulnerability is caused due to the non initialization to a random value 
> (it is always zero) of the "pointer guard" by the glibc only when generating 
> static compiled executables. Dynamic executables are not affected. Pointer 
> guard is used to mangle the content of sensible pointers (longjmp, signal 
> handlers, etc.), if the pointer guard value is zero (non-initialized) then it 
> is not effective.
> 
> So, out of curiosity, how big is the threat since I am under the impression 
> that almost 100% if not 100% of Arch binaries uses libc.so
>

In short, I am not overly concerned about this.  But fixing the issue
was the right thing to do, so it will not spread any further.

Allan

Re: [arch-general] glibc 2.18-5 question

[Allan McRae]

On 27/09/13 22:56, Chris Down wrote:
> On 2013-09-26 08:53, Gaetan Bisson wrote:
>> Some Arch packages even provide static libraries for convenience, such
>> as gcc and glibc. And unfortunately a few higher-level packages also
>> provide static libraries because their maintainers did not notice the
>> waste of space...
> 
> Well, static libraries are not a waste of space if it was intentional.
> Static linking should be preferred for a number of reasons[0], they
> should be preferred in any sane Linux distribution (of which,
> unfortunately I can't name any at the moment until stali comes out).
> 
> 0: http://sta.li/faq
> 

My favourite counter link calling that opinion full of shit:

http://www.akkadia.org/drepper/no_static_linking.html

Re: [arch-general] Arch Linux Community on Gittip

[Allan McRae]

On 06/09/13 05:14, Karol Blazewicz wrote:
> I asked about this before:
> https://mailman.archlinux.org/pipermail/arch-general/2013-May/033590.html
> but now Dusty wants to make it official (or "official")
> https://bbs.archlinux.org/viewtopic.php?id=169356
> 
> Some people didn't like the Official Arch Linux Google+ page, so I
> want to make sure if the kind of official Arch Linux community Dusty
> wants is OK with the Arch Overlords. It seems OK to me.
> 

I'll give it the OK.  I don't think people will confuse donating
directly to anyone on that with donating to the distribution.

Also, "official" here, means a full fledged community of Gittip, which
requires 150 members in the group.

(And the $1 a week I receive there lately is not influencing my decision
in any way!)

Allan

Re: [arch-general] arch rollback machine

[Allan McRae]

On 23/08/13 19:36, Lieven Moors wrote:
> Hi,
> 
> Does anyone know what is happening with Arch Rollback Machine?
> The server (arm.konnichi.com) has been unavailable for more than a week now, 
> and I'm depending on it to keep an offline machine up to date...
> 
> Greetings,
> 
> lieven
> 

It has been shut down.

Allan

Re: [arch-general] 64 bit kernel with 32 bit userspace

[Allan McRae]

On 21/08/13 00:56, Laszlo Papp wrote:
> Hi,
> 
> based on the following forum entry, I would like to open this topic up for
> a wide discussion.
> 
> https://bbs.archlinux.org/viewtopic.php?pid=1314594
> 

Based on my comment:
https://bbs.archlinux.org/viewtopic.php?pid=1314755#p1314755

Do it yourself.

Re: [arch-general] Question about repository updates and atomicity

[Allan McRae]

On 15/08/13 17:08, Johannes Ernst wrote:
> I'm trying to understand what may and may not go wrong between package
> uploads to a repository, repository synchronization via rsync (which seems
> to be the preferred method for mirrors to get their stuff) and downloads
> via pacman.
> 
> Assume a developer uploads a new version of two packages to a repository.
> My understanding is that uploads delete the older version of the uploaded
> package currently in the repository. (unlike other package management
> systems e.g. debian's where multiple versions of the same package can
> reside in the same repository).
> 
> An hour later, a mirror repository starts rsycing. While the rsync is
> ongoing, a user uses pacman to download both packages from the mirror.
> 
> Question: what mechanisms exists, if any, to avoid that the user gets the
> old version of package A and the new version of package B? (assume the
> rsync is still ongoing while the download occurs)

The database file will either have both new packages or no new packages.


> It seems the "safe" way of doing the rsync would be to take down the mirror
> during the critical section (when all old versions are removed and the new
> ones put there instead), and restart it afterwards? Or is there something
> somewhere that I'm not seeing? The debian guys probably keep the old
> version(s) around for exactly that reason...
> 
> Any insight very much appreciated ...

Re: [arch-general] testing/glibc 2.18-1 breaks vte

[Allan McRae]

On 14/08/13 19:21, Chris “Kwpolska” Warrick wrote:
> I am running [testing] on Arch Linux x86_64.  With the recent update
> of glibc to 2.18-1, all vte-based terminals fail to start under a
> non-root user.  They claim that "grantpt failed: Operation not
> permitted".  Downgrading to core’s 2.17-6 restores regular
> functionality.  Non-vte terminals (xterm, urxvt) are not affected by
> this.
> 
> What is going on?
> 

Remove the /dev/pts line from your fstab.

Re: [arch-general] Does leading slash matter in install scriptlets?

[Allan McRae]

On 07/08/13 20:46, lolilolicon wrote:
> On Wed, Aug 7, 2013 at 6:19 PM, Allan McRae  wrote:
>>
>> I believe it possibly did in the past, but pacman chroots into the
>> --root directory before running any scripts so it makes no difference.
> 
> That's great, seeing that there're so many packages on both sides.
> Is a leading slash preferred, then?
> 

Given it does not matter, there is no preference (at least from me).

Re: [arch-general] Does leading slash matter in install scriptlets?

[Allan McRae]

On 07/08/13 18:35, lolilolicon wrote:
> Many install scriptlets include the leading slash in file paths, e.g.
> 
> post_install() {
> update-desktop-database -q
> gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor
> }
> 
> while some strip the leading slash,
> 
> post_install() {
> update-desktop-database -q
> gtk-update-icon-cache -q -t -f usr/share/icons/hicolor
> }
> 
> Would this make a difference with `pacman -S --root  `?
> If not, is there any case in which it would make a difference?
> 

I believe it possibly did in the past, but pacman chroots into the
--root directory before running any scripts so it makes no difference.

Allan

Re: [arch-general] Upstream urls and package descriptions

[Allan McRae]

On 02/08/13 02:02, Karol Blazewicz wrote:
> Intro:
> Below are some questions / ideas I came up with. I simply don't know
> if anyone cares about these issues, whether there are rules or at
> least suggestions how to best deal with them or is it up to the
> maintainer.
> 
> I've heard there were some plans wrt a build server that would
> periodically check if packages still build. Any news?

I see I have just received word that a proof-of-concept for the idea is
available.  So there is some progress.

> If there indeed are issues that need fixing, should I file the
> low-priority bugs now? Summer vacation may not be the best time for
> Arch-related work so maybe I should wait until September so that
> people are back from holidays?

I'm fairly sure summer holidays are in the end of December/start of
January, so that should not be an issue! :D


> Upstream urls:
> I found that dozens of packages in the repos have an upstream url that
> prints 'Page Not Found' in one way or another. Should I open bug
> reports for these packages or does nobody care about it? I could also
> check if the source is still available. If opening bug reports is OK,
> should I limit creating the reports to e.g. 10 a day?
> If I find a url that works, I will include it as a suggestion for the
> maintainer.

If there are bugs, open bugs.  The bug tracker is for tracking bugs...
It does not matter how many are opened. Even better if you provide a
solution in the bug.

We can close bugs far quicker than you can create them, so that will
never be a real issue.

> For example for
> https://www.archlinux.org/packages/community/i686/autocutsel/ neither
> the url nor the source is available, but I found what seems like a
> perfectly good autocutsel website: http://www.nongnu.org/autocutsel/
> with a link to the source.

File a bug.

> Some projects seem to be gone for good e.g.
> https://www.archlinux.org/packages/extra/i686/apricots/ even grabs the
> sources from ftp.archlinux.org
> https://projects.archlinux.org/svntogit/packages.git/plain/trunk/PKGBUILD?h=packages/apricots
> Would http://freecode.com/projects/apricots be a better website? It
> has some info e.g. that last development is from a decade ago, a
> screenshot, a longer description ...

I'd say such packages should just be dropped altogether.

> What about urls that point to a redirect? Is it OK only if the
> redirect is automatic and otherwise upstream urls should be updated if
> they moved e.g. from SourceForge to GoogleCode?
> An example: https://www.archlinux.org/packages/extra/any/junit/ has
> http://junit.sourceforge.net/ as the upstream url, but when you go
> there, it says 'Please see our main site at junit.org'.

Even an automatic redirect might not be permanent, so I think these
should be changed.

> Is there a rule that 'www' should be omitted or that it should be included?
> https://www.archlinux.org/packages/extra/i686/alsa-lib/ :
> http://www.alsa-project.org
> https://www.archlinux.org/packages/extra/any/alsa-firmware/ :
> http://alsa-project.org/

If both are correct, it does not matter.

About here I got bored...

Re: [arch-general] Why is netcfg again in [base]?

[Allan McRae]

On 16/07/13 21:59, Karol Blazewicz wrote:
> On Tue, Jul 16, 2013 at 12:12 PM, A Rojas  wrote:
>> I thought it was deprecated in favour of netctl. Now it's impossible to
>> install the base group, since netctl and netcfg are in conflict.
>>
> 
> https://mailman.archlinux.org/pipermail/arch-projects/2013-July/003809.html
> 

Which does not go anywhere near answering the question...

Anyway, this was fixed in -5 (and it appears that netcfg is removed again).

Re: [arch-general] /etc/shells should keep /bin/zsh

[Allan McRae]

On 01/07/13 20:11, Karol Blazewicz wrote:
> I know arch-general si not for reporting bugs and I'm not trying to
> rush anyone, but it's been already a month of confusion wrt
> https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/zsh&id=c84d9770988fdc0f2e6c7bd5fa748d5a18580fb4
> 
> https://bugs.archlinux.org/task/35724
> 

If a bug is open that long, it is likely to be closed as "Won't Fix".

Re: [arch-general] Grub 2.00.5043-1 locales missing

[Allan McRae]

On 27/06/13 15:54, Star Brilliant wrote:
> After I upgraded to grub 2.00.5043-1, I found that grub switched back to
> English interface because the locale files are missing.
> 
> Those locale files used to be in /usr/share/locale but it is not there
> in the new version.
> 
> Is it a mistake, or the upstream just removed those locale files?
> 

There is a fixed version in [testing]

Re: [arch-general] makepkg --noprepare option

[Allan McRae]

On 24/06/13 01:39, kachelaqa wrote:
> For version 4.1.1 of pacman, a --noprepare option was added to makepkg
> [1]. But, for version 4.1.2, the option is no longer available.

Are you sure?

Re: [arch-general] [arch-dev-public] /usr move - update instructions

[Allan McRae]

On 02/06/13 18:21, David Benfell wrote:
> I'm assuming I can't post to arch-dev-public since I'm not a developer:
> 
> On 06/01/2013 05:34 PM, Allan McRae wrote:
> 
>> 5) Update your system. # pacman -Syu --ignore filesystem,bash #
>> pacman -S bash # pacman -Su
> 
> I'm wondering if this bit assumes that bash is the shell in use (I
> happen to prefer zsh).
> 

No.  It is for install scripts that call things with /bin/sh shebangs.

Re: [arch-general] Finishing the /usr move

[Allan McRae]

On 01/06/13 23:36, Genes Lists wrote:
> On 05/31/2013 12:26 PM, Karol Blazewicz wrote:
>> https://mailman.archlinux.org/pipermail/arch-dev-public/2013-May/025026.html
>>
>> 3) Update your system:
>> $ pacman -Syu --ignore filesystem
>> $ pacman -Su
>>
>> It should say '#', not '$'.
>>
> 
>  I had a problem with this
> 
> # pacman -Syu --ignore filesystem
> ...
> (77/91) upgrading postfix
>  [] 100%
> warning: /etc/postfix/main.cf installed as /etc/postfix/main.cf.pacnew
> /tmp/alpm_Pd1z7b/.INSTALL: /usr/lib/postfix/post-install: /bin/sh: bad
> interpreter: No such file or directory
> 
> ...
> 
> # pacman -Su
> 
> (1/1) checking for file conflicts
>  [] 100%
> error: failed to commit transaction (conflicting files)
> filesystem: /bin exists in filesystem
> filesystem: /sbin exists in filesystem
> filesystem: /usr/sbin exists in filesystem
> Errors occurred, no packages were upgraded.
> 
> 
> # ls -l /bin
> -rwxr-xr-x 1 root root 593296 Nov  3  2011 mbchk
> 
> 
> Suggestions for best way to recover from this?
> 

Lstest instructions would have kept you from the
/tmp/alpm_Pd1z7b/.INSTALL error:
https://mailman.archlinux.org/pipermail/arch-dev-public/2013-June/025043.html

Fix your grub package.

Re: [arch-general] Finishing the /usr move

[Allan McRae]

On 01/06/13 23:40, Genes Lists wrote:
> On 06/01/2013 09:36 AM, Genes Lists wrote:
> 
>>
>>
>> # ls -l /bin
>> -rwxr-xr-x 1 root root 593296 Nov  3  2011 mbchk
>>
>>
>> Suggestions for best way to recover from this?
>>
>> Thanks
>>
>> gene
>>
> 
>  Also grub is in /sbin
> 
> # ls -l /sbin
> total 936
> -rwxr-xr-x 1 root root 918148 Nov  3  2011 grub
> -rwxr-xr-x 1 root root  12920 Nov  3  2011 grub-install
> -rwxr-xr-x 1 root root   2298 Nov  3  2011 grub-md5-crypt
> -rwxr-xr-x 1 root root   2533 Nov  3  2011 grub-set-default
> -rwxr-xr-x 1 root root   2473 Nov  3  2011 grub-terminfo
> -rwxr-xr-x 1 root root   6179 Nov  3  2011 install-grub
> 

I guess this is grub-0.97, which has not been in the Arch repos for a
long, long time   So, up to you to fix it.

Re: [arch-general] Arch Linux Community on Gittip

[Allan McRae]

On 22/05/13 06:45, Karol Blazewicz wrote:
> http://archlinux.me/dusty/2013/05/21/arch-linux-community-on-gittip/
> 
> Does this initiative have the Uber Archers blessing? Does it need one?
> 
> I recall that there were issues regarding the official Google+ page
> even though it was started by an Arch dev, the info was posted on the
> forums https://bbs.archlinux.org/viewtopic.php?id=129923 and things
> seemed OK.
> 

I don't think it needs our blessing.  I think people will understand the
difference between donating to an individual and the distribution.

Allan

Re: [arch-general] Current "CPPFLAGS=-D_FORTIFY_SOURCE=2" break some builds

[Allan McRae]

On 08/05/13 08:10, Anatol Pomozov wrote:
> Hi, Allan
> 
> 
> On Mon, May 6, 2013 at 3:34 PM, Allan McRae  wrote:
> 
>> On 07/05/13 06:20, Leonid Isaev wrote:
>>> On Mon, 6 May 2013 16:01:30 -0400
>>> Eric Bélanger  wrote:
>>>
>>>> On Mon, May 6, 2013 at 3:45 PM, Leonid Isaev 
>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> With gcc 4.8.0-4 I can no longer build core/links package from
>> ABS,
>>>>> with SSL support. The issue is _not_related to makepkg (as I originally
>>>>> thought), even plain ./configure fails if I export
>>>>> CPPFLAGS=-D_FORTIFY_SOURCE=2, regardless of the content of
>> {C,CXX,LD}FLAGS.
>>>>> Here is the error:
>>>>> 
>>>>> $ ./configure --with-ssl
>>>>> [ ... ]
>>>>> checking for openssl... yes
>>>>> checking OPENSSL_CFLAGS...
>>>>> checking OPENSSL_LIBS... -lssl -lcrypto
>>>>> checking for OpenSSL... no
>>>>> checking for OpenSSL... no
>>>>> configure: error: OpenSSL not found
>>>>> $ cat config.log
>>>>> [ ... ]
>>>>> configure:8095: checking for openssl
>>>>> configure:8102: checking OPENSSL_CFLAGS
>>>>> configure:8107: checking OPENSSL_LIBS
>>>>> configure:8139: checking for OpenSSL
>>>>> configure:8150: gcc -o conftest -g -O2 -D_FORTIFY_SOURCE=2   conftest.c
>>>>> -lssl
>>>>> -lcrypto  -lm  1>&5
>>>>> In file included from configure:8143:0:
>>>>> confdefs.h:8:16: error: duplicate 'unsigned'
>>>>>  #define size_t unsigned
>>>>> ^
>>>>> configure: failed program was:
>>>>> #line 8143 "configure"
>>>>> #include "confdefs.h"
>>>>> #include 
>>>>> int main() {
>>>>> SSLeay_add_ssl_algorithms()
>>>>> ; return 0; }
>>>>> 
>>>>>
>>>>> With gcc 4.7.2 all builds fine with Arch's default makepkg.conf, i.e.
>> no
>>>>> "duplicate unsigned error". Also, unsetting CPPFLAGS allows a
>> successfull
>>>>> build.
>>>>>
>>>>> Since core/links has been successfully rebuilt, what was the gcc
>> version?
>>>>> ANd
>>>>> can anyone else confirm the above issue?
>>>>>
>>>>> TIA,
>>>>> L.
>>>>>
>>>>>
>>>> Aready fixed in links in testing. Just add a prepare function with:
>>>>   sed -i "/ac_cpp=/s/\$CPPFLAGS/\$CPPFLAGS -O2/" configure
>>>>
>>>
>>> I see, thank you. Alternatively one could simply do CPPFLAGS+=" -O2" in
>>> PKGBUILD...
>>>
>>> I'm still confused though: are we supposed to pass -On flags to cpp now
>> (this
>>> is even mentioned against in the configure script)? Or is it still a
>>> gcc/glibc problem?
>>>
>>
>> The reason we do the sed is so -O2 is not passed with CPPFLAGS during
>> the actual built.  This is just working around an autoconf limitation.
>>
> 
> Could you please share more info about autoconf limitation? It is not clear
> for me why autoconf does not pass -O2. And why it is needed when
> -D_FORTIFY_SOURCE=2 is enabled. Is it a bug that reported to autoconf
> project? Or maybe it is some fundamental issue that Arch packages will live
> forever?
> 

In short, autoconf is making broken assumptions about warnings given of
by gcc.  Autoconf checks for headers by looking for a warning from gcc
when it is missing - but not a specific warning, any warning...
-D_FORTIFY_SOURCE=2 gives a warning when is it not used with
optimization so the header check fails incorrectly.   Autoconf should
not pass -O2 with CPPFLAGS because it is not a preprocessor flag.

Note that not all software that uses autoconf is affected.  Some do not
pass CPPFLAGS when testing for headers.

Allan

Re: [arch-general] Current "CPPFLAGS=-D_FORTIFY_SOURCE=2" break some builds

[Allan McRae]

On 07/05/13 06:20, Leonid Isaev wrote:
> On Mon, 6 May 2013 16:01:30 -0400
> Eric Bélanger  wrote:
> 
>> On Mon, May 6, 2013 at 3:45 PM, Leonid Isaev  wrote:
>>
>>> Hi,
>>>
>>> With gcc 4.8.0-4 I can no longer build core/links package from ABS,
>>> with SSL support. The issue is _not_related to makepkg (as I originally
>>> thought), even plain ./configure fails if I export
>>> CPPFLAGS=-D_FORTIFY_SOURCE=2, regardless of the content of {C,CXX,LD}FLAGS.
>>> Here is the error:
>>> 
>>> $ ./configure --with-ssl
>>> [ ... ]
>>> checking for openssl... yes
>>> checking OPENSSL_CFLAGS...
>>> checking OPENSSL_LIBS... -lssl -lcrypto
>>> checking for OpenSSL... no
>>> checking for OpenSSL... no
>>> configure: error: OpenSSL not found
>>> $ cat config.log
>>> [ ... ]
>>> configure:8095: checking for openssl
>>> configure:8102: checking OPENSSL_CFLAGS
>>> configure:8107: checking OPENSSL_LIBS
>>> configure:8139: checking for OpenSSL
>>> configure:8150: gcc -o conftest -g -O2 -D_FORTIFY_SOURCE=2   conftest.c
>>> -lssl
>>> -lcrypto  -lm  1>&5
>>> In file included from configure:8143:0:
>>> confdefs.h:8:16: error: duplicate 'unsigned'
>>>  #define size_t unsigned
>>> ^
>>> configure: failed program was:
>>> #line 8143 "configure"
>>> #include "confdefs.h"
>>> #include 
>>> int main() {
>>> SSLeay_add_ssl_algorithms()
>>> ; return 0; }
>>> 
>>>
>>> With gcc 4.7.2 all builds fine with Arch's default makepkg.conf, i.e. no
>>> "duplicate unsigned error". Also, unsetting CPPFLAGS allows a successfull
>>> build.
>>>
>>> Since core/links has been successfully rebuilt, what was the gcc version?
>>> ANd
>>> can anyone else confirm the above issue?
>>>
>>> TIA,
>>> L.
>>>
>>>
>> Aready fixed in links in testing. Just add a prepare function with:
>>   sed -i "/ac_cpp=/s/\$CPPFLAGS/\$CPPFLAGS -O2/" configure
>>
> 
> I see, thank you. Alternatively one could simply do CPPFLAGS+=" -O2" in
> PKGBUILD...
> 
> I'm still confused though: are we supposed to pass -On flags to cpp now (this
> is even mentioned against in the configure script)? Or is it still a
> gcc/glibc problem?
> 

The reason we do the sed is so -O2 is not passed with CPPFLAGS during
the actual built.  This is just working around an autoconf limitation.

Allan

Re: [arch-general] [arch-dev-public] [pacman-dev] debug package repositories

[Allan McRae]

On 15/04/13 19:46, Lukas Jirkovsky wrote:
> On 15 April 2013 09:59, Thomas Bächler  wrote:
>> Separate debug repositories won't happen - we can't even put
>> split packages into different repositories
> 
> Fair enough.
> 
>> Even if
>> the db sizes double, we are still way under 5MB per db, which is a
>> reasonable size considering our users' bandwidth nowadays.
> 
> It's not only the size of the database. I can see the problem with the
> size of repositories if someone keeps a mirror to save bandwidth if
> they have lots of computers, but they don't need debug packages.
> 
> 
> On 15 April 2013 10:11, Allan McRae  wrote:
>>
>> DB size is not the only consideration.  For example -Ss output will be
>> "polluted".
> 
> Maybe it could be filtered on the pacman side, ie. add some switch
> that would enable/disable showing of -debug packages.
> 

Not keen on that...

The issues that prevent split packages going across repos are entirely
different to what is required to keep a separate debug package repo.

In fact, I will provide the needed patches for a separate [debug] and
[community-debug] repo if that is what is decided to happen.

Allan

Re: [arch-general] [arch-dev-public] [pacman-dev] debug package repositories

[Allan McRae]

On 15/04/13 18:59, Thomas Bächler wrote:
> Am 13.04.2013 17:55, schrieb William Giokas:
>> All,
>>
>> With the inclusion of the debug option in pacman 4.1.0, I think it makes
>> sense to do something with this in the official repositories. I've
>> sifted through some bug reports asking for inclusion of the debug
>> symbols in a separate package or repository officially for testing
>> purposes. With [extra] and [community] approaching 1.5 and 2 megabytes
>> respectively, I think that adding debug symbols directly into these
>> repositories would be a bad idea as it would probably add ~50% to those
>> databases, and I've already seen some people complain about the sizes. 
> 
> This doesn't belong to the pacman mailing list (I'm forwarding to
> arch-dev-public and arch-general), but I'll summarize what will probably
> happen: Separate debug repositories won't happen - we can't even put
> split packages into different repositories, so it is unlikely that we'll
> support separate debug repositories - and I don't see the need. Even if
> the db sizes double, we are still way under 5MB per db, which is a
> reasonable size considering our users' bandwidth nowadays.
> 
> Allan stated that he'll add a glibc-debug package to core, and it is
> also likely that KDE will get debug packages in extra (they have been
> requested a few times).
> 
> Some links:
> 
> https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024736.html
> https://mailman.archlinux.org/pipermail/arch-dev-public/2013-March/024740.html
> 

DB size is not the only consideration.  For example -Ss output will be
"polluted".

Allan

Re: [arch-general] debug package repositories

[Allan McRae]

On 15/04/13 05:24, Sébastien Luttringer wrote:
> On Sat, Apr 13, 2013 at 7:14 PM, William Giokas <1007...@gmail.com> wrote:
> 
>> What I would propose (and I've implemented this locally fine) is to have
>> a separate series of repositories named [$repo-debug] that only contain
>> the -debug packages, allowing those that don't bother with testing or
>> debugging to simply not include them in their pacman.conf, but if there
>> is something that they want to run valgrind or whatever on, they can
>> simply enable the right [*-debug] repo for that package, and once they
>> are done debugging simply remove that repo from their list along with
>> the package. For really large packages, this will save people a while
>> lot of time recompiling dependencies for these symbols.
> 
> Why do you suggest to use a different repository to debug packages
> instead of pushing them directly to existing repositories.
> Users will not suffers of having debug packages into main repositories.
> I see difficulties in bandwidth needed to push package (for dev/tu)
> and in storage space in all our mirror around the world.
> Having a separate debug repository doesnt' address this.
> 

It would make the repo dbs ~twice as large and pollute -Ss output for
people who do not want to enable debug packages.

Allan

Re: [arch-general] 3.8.6 kernel compile fails with gcc 4.8

[Allan McRae]

On 09/04/13 00:25, Damjan wrote:
> For various reasons I'm compiling my own kernels, but just now I have
> got this error while trying to update and compile 3.8.6.
> 
> gcc is 4.8.0-1
> arch is i686
> 
> How do I get "preprocessed source"?
> 
> 
>   CC [M]  drivers/net/ethernet/intel/e1000e/netdev.o
> drivers/net/ethernet/intel/e1000e/netdev.c: In function ‘e1000_xmit_frame’:
> drivers/net/ethernet/intel/e1000e/netdev.c:5159:1: internal compiler
> error: Maximum number of LRA constraint passes is achieved (30)
> 
>  }
>  ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make[5]: *** [drivers/net/ethernet/intel/e1000e/netdev.o] Error 1
> make[4]: *** [drivers/net/ethernet/intel/e1000e] Error 2
> 
> 

Can you repeat it?

Re: [arch-general] netctl development

[Allan McRae]

On 28/03/13 21:04, Robbie Smith wrote:
> Is there a publicly-accessible list to follow the development of
> netcfg’s successor-to-be, netctl?
> 
> From my experiments with systemd and netcfg, there’s a few features that
> could definitely come in useful, and I’m certainly willing to help
> contribute where I can, be it testing, coding, or writing documentation.
> 

The "arch-projects" mailing list.

Re: [arch-general] RFC: Mesa and shared LLVM libraries

[Allan McRae]

On 04/03/13 06:11, Armin K. wrote:
> On 03/03/2013 09:04 PM, Armin K. wrote:
>> Hello everyone,
>>
>> First, I am aware that ArchLinux is against patching packages to
>> implement some features, but this might be worth the effort.
>>
>> Tom Stellard of AMD has announced a R600 backend patch against LLVM 3.2
>> few days ago [1]. It's basically his repository (llvm-amdgpu-snapshot)
>> diffed against upstream LLVM (llvm).
>>
>> By applying the patch to ArchLinux LLVM package, one could benefit from
>> enabling Mesa to link against LLVM shared library. Doing so, space would
>> be saved and so the memory at runtime, too (I guess since it will use
>> shared mappings).
>>
>> I've done some work regarding that. I've managed to split libLLVM-3.2.so
>> from llvm package and put it into libllvm package.
>>
>> The package is a bit big though - the shared library contains all (~100)
>> static libraries linked into one single library.
>>
>> The result is like this:
>>
>> Targets (1): libllvm-3.2-5
>>
>> Total Installed Size:   21.77 MiB
>>
>> Building MesaLib against shared libLLVM-3.2.so saves space drastically.
>> For all MesaLib produced packages, the output is like this one:
>>
>> Targets (6): ati-dri-9.1-2  intel-dri-9.1-2  mesa-9.1-2
>> mesa-libgl-9.1-2  nouveau-dri-9.1-2  svga-dri-9.1-2
>>
>> Total Installed Size:   82.13 MiB
>> Net Upgrade Size:   -282.07 MiB
>>
>> 260 MB saved ... Looks nice to me.
>>
>> R600 backend will be part of LLVM 3.3 anyways, and this can be used in
>> the future without patching anything.
>>
>> I am attaching patches for llvm and mesa PKGBUILDs to incorporate these
>> changes. Do as you may please.
>>
>> If someone is interested in forwarding this to -dev-public list it would
>> be nice.
>>
>> Have a nice evening.
>>
>> (As a side note, somehow llvm tarball sha256sum was wrong when I
>> downloaded it).
>>
>> [1] http://lists.freedesktop.org/archives/mesa-dev/2013-March/035561.html
> 
> Hm, it seems that attachments are blocked
> 
> mesa.patch http://paste.debian.net/plainh/638c2e73
> llvm.patch http://paste.debian.net/plainh/bd11c4da
> 
> As another side note, the 0003 patch available on Tom Stellard's web
> site fails to apply with "patch already applied".
> 

This is known.  I understand we are waiting for LLVM-3.3.

Re: [arch-general] How to wait efficiently for a package to update?

[Allan McRae]

On 08/02/13 14:14, Oon-Ee Ng wrote:
> So I'm checking out python-sympy for some calculations in the Robotics
> subject I teach and realized that a bug was recently fixed in git
> which is crucial to what I hope to use it for. python-sympy-git in the
> AUR and that's settled.
> 
> Then I got to wondering, I only really want to use the -git version
> till the next release, but since python-sympy is no longer installed
> (conflicts) I wouldn't automatically get it unless I check every once
> in a while if version is > 0.7.2.
> 
> I figured installing a blank package with nothing in package() named
> python-sympy and with version 0.7.2 would allow me to get notified
> when python-sympy-0.7.3 or later gets in the repos. Is this a good way
> of doing it, or are there better ways?
> 
> 


The other option is to use ABS to build the current python-sympy with
the patch you need.  Or you could even file a bug report to get that
done officially (if the bug is bad enough).

Allan

Re: [arch-general] broken system after today upgrade

[Allan McRae]

On 24/01/13 00:29, arnaud gaboury wrote:
> On Wed, Jan 23, 2013 at 2:12 PM, Allan McRae  wrote:
> 
>> On 24/01/13 00:08, arnaud gaboury wrote:
>>>
>>> My issue maybe comes from the upgrade of glibc 2.17-2 from testing.
>>> I have now /lib --> usr/lib and lib64/ > usr/lib.
>>>  /usr/lib64 > lib
>>>
>>> Is this the expected structure after the upgrade ?
>>>
>>
>> Yes
>>
>> Give the complete package list of what was upgraded.
>>
>> Allan
>>
> 
> Allan,
> 
> thank your help. Please find all the pacman logs in chronoligal order with
> some explainations.
> Sorry for the long logs
> To summarize, I first upgraded on m system.
> 
> [2013-01-22 19:38] kalu: synchronized database testing
> [2013-01-22 19:38] kalu: synchronized database core
> [2013-01-22 19:38] kalu: synchronized database extra
> [2013-01-22 19:38] kalu: synchronized database community-testing
> [2013-01-22 19:38] kalu: synchronized database community
> [2013-01-22 19:38] kalu: synchronized database multilib-testing
> [2013-01-22 19:38] kalu: synchronized database multilib
> [2013-01-22 19:38] kalu: starting sysupgrade...
> [2013-01-22 19:40] kalu: Failed to commit sysupgrade transaction:
> conflicting files
> [2013-01-22 19:43] Running 'pacman -Syu'
> [2013-01-22 19:43] synchronizing package lists
> [2013-01-22 19:43] starting full system upgrade
> [2013-01-22 20:04] Running 'pacman -S bash'
> [2013-01-22 20:05] Running 'pacman -S filesystem'
> [2013-01-22 20:05] Running 'pacman -S glibc'
> [2013-01-22 20:05] call to execv failed (No such file or directory)
> [2013-01-22 20:05] upgraded glibc (2.17-1 -> 2.17-2)
> 

So there was a file conflict - not sure what, but for next time, just
deal with that...

> 
> The upgrade went bad, and I made the mistake to #pacman -S glibc. It broke
> immediatly my filesystem.
> Then I log out and boot with Ubuntu Live CD. I chroot and tried many things
> with no sucess. My bad, as I realized this morning I mounted the wrong
> /dev/sdb partition as /usr .
> I then  boot my system on fallback. Here again, I tried to finish the
> upgrade with no sucess.
> I then boot with Archiso, and couldn-t finish as execv was not found.
> I then downgraded glibc and filesystem, and tried again to upgrade
> correctly, with no sucess.
> 




That is a lot of going around in circles...

Make sure everything is updated, then run "pacman -Qk -r /mnt" to check
all the files are ready.

It seems you are using the Arch install CD, so run "arch-chroot /mnt"
then "mkinitcpio -p linux".

Then try booting.   We need some details of what is happening when it
fails to give any more help.

Allan

Re: [arch-general] broken system after today upgrade

[Allan McRae]

On 24/01/13 00:08, arnaud gaboury wrote:
> 
> My issue maybe comes from the upgrade of glibc 2.17-2 from testing.
> I have now /lib --> usr/lib and lib64/ > usr/lib.
>  /usr/lib64 > lib
> 
> Is this the expected structure after the upgrade ?
> 

Yes

Give the complete package list of what was upgraded.

Allan

Re: [arch-general] SeaMonkey outdated. Critical security holes in the current version!

[Allan McRae]

Hrm...  this got dropped to [community] so that there would be a better
response time to updates.  Obviously it has not happened, so it should
be dropped.

I'll wait 24 hours...

Allan

Re: [arch-general] Combining package deltas and signing?

[Allan McRae]

On 31/12/12 05:26, Magnus Therning wrote:
> On Fri, Dec 28, 2012 at 10:54:14PM -0500, Sébastien Leblanc wrote:
>> I believe signatures are checked after packages are rebuilt from
>> deltas. Therefore, if your delta is compromised, the resulting
>> package won't validate with the signature.
> 
> Excellent.  I also notice you use the word "deltas", plural, which
> leads me to the next question :)
> 
> Will deltas be combined by pacman, or will only ever a single delta be
> used?
> 

They can be combined.  pacman does a calculation to see whether the
delta chain is worth it.

Re: [arch-general] Combining package deltas and signing?

[Allan McRae]

On 28/12/12 05:27, Magnus Therning wrote:
> Do these two features play nice together?
> 

Why wouldn't they?

Re: [arch-general] List of mirrors with signed databases?

[Allan McRae]

On 27/12/12 05:08, Magnus Therning wrote:
> Hi all,
> 
> I'm late to the party of signing packages and databases, but was a
> little surprised to find this statement on the pacman-key wikipage[1]:
> 
> Although all official packages are now signed, as of June 2012
> signing of the databases is a work in progress.
> 
> Is there a list of mirrors where the databases *are* signed already?
> (The ones I'm using are not.)
> 
> /M
> 
> [1]: https://wiki.archlinux.org/index.php/Pacman-key
> 

If any are signed, it is not by an official Arch signature.

Re: [arch-general] [util-linux 2.22.1-2] "uuidd" typo error

[Allan McRae]

On 18/11/12 09:59, Martín Cigorraga wrote:
> Hi folks,
> 
> the core/util-linux 2.22.1-2 has the following typo error:
> 
> ( 26/130) installing util-linux
>  [###] 100%
> install: invalid user 'uuidd'
> error: command failed to execute correctly
> 
> so i have two question:
> 1. which severity should i report in the bugtracker

None.   2.22.1-3 is in [core]

> 2. how this affects a fresh install and how should i proceed

Nothing worth worrying about.

Allan

Re: [arch-general] Forum and wiki registration bug

[Allan McRae]

On 14/11/12 23:28, Karol Blazewicz wrote:
> The current registration question for the forums is
> What is the output of "date -u +%W$(uname)|sha256sum|sed 's/\W//g'"?
> and for the wiki
> What is the output of "date -u +%W`uname`|sha256sum|sed 's/\W//g'"?
> so I guess the wiki is csh-friendly.
> 
> The code breaks in the first week of the year.
> Old forum thread: https://bbs.archlinux.org/viewtopic.php?id=132824
> New forum thread: https://bbs.archlinux.org/viewtopic.php?id=152460
> 
> Allan suggested a fix, but it hasn't been implemented:
> https://mailman.archlinux.org/pipermail/arch-dev-public/2011-December/022296.html
> 
> I can open a bug report for this, but there are also ideas how to make
> it easier for people using other shells or non-Linux systems, e.g.,:
> https://bbs.archlinux.org/viewtopic.php?pid=1151464#p1151464
> There already is https://bugs.archlinux.org/task/32066 open.
> 

I am 99% sure that it was decided that we do not care about people
trying to register from non-Linux systems.  But there is a bug report,
so we will see...

Filing a bug for the first week of the year issue would be useful.

Allan

Re: [arch-general] [arch-dev-public] Bug Squashing Day: Saturday 17th November

[Allan McRae]

On 12/11/12 16:41, Karol Blazewicz wrote:
> Why are some bug descriptions truncated?
> 
> Is:
> FS#26200 - [gnome-control-center] 3.2.0-1 does not show any items when used
> 
> Should be:
> FS#26200 - [gnome-control-center] 3.2.0-1 does not show any items when
> used with LXDE
> 
> https://bugs.archlinux.org/task/26200
> 
> 
> Why not use the wiki template for bug reports
> https://wiki.archlinux.org/index.php/Template:Bug ?
> 

It is a wiki...  fix it.

Re: [arch-general] devtools?

[Allan McRae]

On 01/11/12 10:57, Joakim Hernberg wrote:
> On Thu, 01 Nov 2012 10:47:56 +1000
> Allan McRae  wrote:
> 
>> On 01/11/12 10:41, Joakim Hernberg wrote:
>>> On Thu, 01 Nov 2012 07:27:28 +1000
>>> Allan McRae  wrote:
>>>
>>>> On 01/11/12 07:01, Joakim Hernberg wrote:
>>>>> On Wed, 31 Oct 2012 16:27:59 +0100
>>>>> Alexander Rødseth  wrote:
>>>>>
>>>>>> Do you only get this error with this particular package, or with
>>>>>> extra-x86_64-build in general?
>>>>>> Submitting this as a "support request" for the devtools package
>>>>>> may work out.
>>>>>
>>>>> AFAIK, it happens with every package, and it also happens with the
>>>>> sister scripts like extra-i686-build.
>>>>>
>>>>
>>>> What is the mirror at the top of your /etc/pacman.d/mirrorlist?
>>>
>>> Server = http://ftp5.gwdg.de/pub/linux/archlinux/$repo/os/$arch
>>>
>>
>> And that correctly ends up in the mirrorlist file in the created
>> chroot?
>>
> 
> No :(
> 
> jack@tor /home/jack $
> cat /var/lib/archbuild/extra-x86_64/root/etc/pacman.d/mirrorlist
> Server = 
> 

Well...  we have located the bug then.   Can you post your mirrorlist
file so we can see where it is failing at extracting this.

Allan

Re: [arch-general] devtools?

[Allan McRae]

On 01/11/12 10:41, Joakim Hernberg wrote:
> On Thu, 01 Nov 2012 07:27:28 +1000
> Allan McRae  wrote:
> 
>> On 01/11/12 07:01, Joakim Hernberg wrote:
>>> On Wed, 31 Oct 2012 16:27:59 +0100
>>> Alexander Rødseth  wrote:
>>>
>>>> Do you only get this error with this particular package, or with
>>>> extra-x86_64-build in general?
>>>> Submitting this as a "support request" for the devtools package may
>>>> work out.
>>>
>>> AFAIK, it happens with every package, and it also happens with the
>>> sister scripts like extra-i686-build.
>>>
>>
>> What is the mirror at the top of your /etc/pacman.d/mirrorlist?
> 
> Server = http://ftp5.gwdg.de/pub/linux/archlinux/$repo/os/$arch
> 

And that correctly ends up in the mirrorlist file in the created chroot?

Re: [arch-general] devtools?

[Allan McRae]

On 01/11/12 07:01, Joakim Hernberg wrote:
> On Wed, 31 Oct 2012 16:27:59 +0100
> Alexander Rødseth  wrote:
> 
>> Do you only get this error with this particular package, or with
>> extra-x86_64-build in general?
>> Submitting this as a "support request" for the devtools package may
>> work out.
> 
> AFAIK, it happens with every package, and it also happens with the
> sister scripts like extra-i686-build.
> 

What is the mirror at the top of your /etc/pacman.d/mirrorlist?

Re: [arch-general] Local packages newer than ones from core?

[Allan McRae]

On 28/10/12 15:41, kendell clark wrote:
> 
> Hi all
> I just tried to update my internal system with #pacman -Syyu tonight and
> recieved the following warnings from pacman.
>  warning: binutils: local (2.23-1) is newer than core (2.22-10)
> warning: e2fsprogs: local (1.42.6-1) is newer than core (1.42.5-1)
> warning: gcc: local (4.7.2-2) is newer than core (4.7.2-1)
> warning: gcc-libs: local (4.7.2-2) is newer than core (4.7.2-1)
> warning: glib2: local (2.34.1-1) is newer than core (2.32.4-1)
> warning: glibc: local (2.16.0-5) is newer than core (2.16.0-4)
> warning: hwids: local (20121022-1) is newer than core (20121012-1)
> warning: iproute2: local (3.6.0-2) is newer than core (3.5.1-1)
> warning: iptables: local (1.4.16.2-1) is newer than core (1.4.15-1)
> warning: linux-api-headers: local (3.6.3-1) is newer than core (3.5.5-1)
> warning: perl: local (5.16.1-2) is newer than core (5.16.1-1)


All those packages are in the [testing] repo.   Looks like you have that
enabled and then disabled it.


> I don't mean to sound like a noob but I still am, smiles. I've never
> seen this warning message before and as far as I know this isn't
> possible, as I only pull packages from core, community, and multilib. I
> have built some local aur packages, espeak development version, dropbox,
> dropbox daemon, and mangler. THis could be the cause, although I'm not
> sure how to find out. Any help would be greatly appreciated. i'm
> beginning to really love arch, especially without pulseaudio.
> One final note: I have the linux-lts package installed as opposed to the
> latest 3.6.x kernel, as speakup is broken in  kernels later tahn 3.4.
> Thanks
> Kendell clark
> 
> 
> 

Re: [arch-general] syslog-ng depends on systemd?

[Allan McRae]

On 21/10/12 17:28, gt wrote:
> Hi,
> 
> with the recent update of syslog-ng (3.3.6-2), systemd has been added as
> a dependency. 
> 
> I though systemd providing its own logging and syslog-ng wasn't needed.
> Then why is systemd needed for syslog-ng to run? As far i can see from
> the diffs, nothing has changed apart from adding systemd as a
> dependency.
> 


Look in syslog-ng.conf:

unix-dgram("/run/systemd/journal/syslog");


That means, in its default configuration it requires systemd.

[arch-general] Full mailing-list moderation

[Allan McRae]

People just do not learn...

All post to the mailing list are now moderated.  As this takes time away
from us actually maintaining the distribution, this will only occur
intermittently.

Allan

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

[Allan McRae]

On 01/10/12 20:23, Jorge Almeida wrote:
> On Mon, Oct 1, 2012 at 6:49 AM, gt  wrote:
>> On Mon, Oct 01, 2012 at 11:49:05AM +1000, Allan McRae wrote:
>>> On 01/10/12 11:21, Armando M. Baratti wrote:
>>>> Authoritarian and despotic.
>>>>
>>>> My ban, please.
>>>>
>>>
>>> Done...  and for two weeks because I had to look up what despotic meant.
>>
>> lol, always keep a dictionary handy. May I suggest sdcv.
> 
> This poster should also be banned, since this post doesn't call for help
> nor offers it.
> 
> Oops... Mine too... Now I've done it!
> 
> ("The life of Brian", anyone? The lapidation sketch? Oops again: I hope
> Allan McRae is familiar with the word "lapidation", or it's two weeks
> for me too.)
> 

Lapidation fails when I can just punish everyone...   I am more than
happy to just close the list again.

I have not because I am not "prone to panic attacks".  (Hi Pete! - here
is your answer who those emails go to)

Allan

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

[Allan McRae]

On 01/10/12 11:21, Armando M. Baratti wrote:
> On 29-09-2012 20:41, Allan McRae wrote:
>> On 30/09/12 09:32, Heiko Baums wrote:
>>> schrieb Martín Cigorraga :
>> 
>>
>> The replies by Martin and Heiko had not technical aspect and were not
>> asking for help.   Both accounts are banned for one week.
>>
>> Allan
>>
>>
>>
> Authoritarian and despotic.
> 
> My ban, please.
> 

Done...  and for two weeks because I had to look up what despotic meant.

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

[Allan McRae]

On 30/09/12 09:32, Heiko Baums wrote:
> schrieb Martín Cigorraga :



The replies by Martin and Heiko had not technical aspect and were not
asking for help.   Both accounts are banned for one week.

Allan

Re: [arch-general] Mailing list closed for 24 hours

[Allan McRae]

On 28/09/12 19:38, Nicolas Sebrecht wrote:
> BTW, what a wonderfull attitude from you to non official people. Highly
> contructive and motivating. Thanks.

Thanks.

Re: [arch-general] Mailing list closed for 24 hours

[Allan McRae]

On 28/09/12 19:01, Nicolas Sebrecht wrote:
> The 27/09/12, Karol Blazewicz wrote:
> 
>> Can you give some examples of discussions you would see moving to 
>> archlinux-dev?
> 
> Sure.
> 
>   Subject: [arch-general] Modifying archiso
>   From: Robbie Smith 
>   Date: Tue, 18 Sep 2012 19:47:11 +1000
>   To: arch-general@archlinux.org
>   Message-ID: <5058431f.5090...@gmail.com>
>   
>   Subject: [arch-general] Open Build Service adds support for Arch Linux
>   From: André Prata 
>   Date: Tue, 11 Sep 2012 11:48:36 +0100
>   To: arch-general@archlinux.org
>   
>   Subject: [arch-general] swt - why depends bump to java-runtime>=7?
>   From: "David C. Rankin" 
>   Date: Mon, 10 Sep 2012 16:06:46 -0500
>   To: Archlinux 
>   Message-ID: <504e5666.3000...@suddenlinkmail.com>
>   
>   Subject: [arch-general] archiso - more install guides
>   From: vadim kochan 
>   Date: Sat, 8 Sep 2012 22:33:39 +0300
>   To: arch-general@archlinux.org
>   
>   Subject: [arch-general] Requesting ownership of the bugs for AIF in the 
> bugtracker
>   From: Jeremiah Dodds 
>   Date: Mon, 03 Sep 2012 05:21:24 -0400
>   To: Arch General List 
>   Message-ID: 
> <87ehmjxy0b.fsf@friendface.i-did-not-set--mail-host-address--so-tickle-me>
>   
>   Subject: [arch-dev-public] Re: [RFC] another base cleanup
>   From: Nicolas Sebrecht 
>   Date: Thu, 7 Jun 2012 09:27:58 +0200
>   To: Public mailing list for Arch Linux development 
> 
>   Message-ID: <20120607072758.GB2427@nicolas-desktop>
> 
> These are only samples. I can't take the samples of topic not even
> written

If all that crap went to arch-dev-public, I would have to unsubscribe
there too.

Allan

Re: [arch-general] Mailing list closed for 24 hours

[Allan McRae]

On 26/09/12 21:35, Allan McRae wrote:
> I am invoking the easy way to end flamewars...
> 
> This mailing list will be shut down for the next 24 hours.  Any messages
> sent to the list will go to /dev/null.
> 
> Once the list is reinstated, I will automatically ban any person who
> sends an email that is not asking for help or providing help.
> 

And we are back...

Remember sticking to help requests and answering these will ensure this
list remains open for everyone.

Allan

[arch-general] Mailing list closed for 24 hours

[Allan McRae]

I am invoking the easy way to end flamewars...

This mailing list will be shut down for the next 24 hours.  Any messages
sent to the list will go to /dev/null.

Once the list is reinstated, I will automatically ban any person who
sends an email that is not asking for help or providing help.

Allan

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

[Allan McRae]

On 26/09/12 20:39, Heiko Baums wrote:
 > See also Denis' blog to which he sent a link in his last e-mail.

Fact checking needed   especially since it was the developer you
were replying to whose blog post that actually was.

Allan

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

[Allan McRae]

On 22/09/12 21:39, Øyvind Heggstad wrote:
> On Sat, 22 Sep 2012 15:37:26 +0900
> Zhengyu Xu  wrote:
> 
>> On Sat, 2012-09-22 at 12:00 +0530, Aurko Roy wrote:
>>> On Sat, Sep 22, 2012 at 11:39 AM, Zhengyu Xu 
>>> wrote:
>>>
 Dear all,

 After updating systemd to 191-1 in testing repo, I had following
 messages during booting and the process was stuck (crashed).

 [   10.539416] systemd[1]: segfault at 7d ip b75a97b7 sp bfb0ece8
 error 4 in libc-2.16.so[b752a000+1a4000]
 [   10.539700] systemd[1]: Caught , core dump failed.

 Downgrade to 189-4 can solve this problem. I want to know if this
 is a personal problem or a general bug affecting others as well.

 Best regards,
 Z.


>>> Boots fine on my x86_64 desktop.
>>>
>>
>> Thank you, I forgot to say that mine is i686.
>>
> 
> 
> For those interested in the actual problem at hand and not the trolling
> loser (unsubscribing == letting the troll win btw, so imo don't do it)
> 
> https://bugs.archlinux.org/task/31645
> 

This is more informative...
https://bugs.freedesktop.org/show_bug.cgi?id=55213

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

[Allan McRae]

On 22/09/12 18:42, Heiko Baums wrote:
> Am Sat, 22 Sep 2012 18:18:49 +1000
> schrieb Allan McRae :
> 
>> Medical condition?
> 
> I'm very fine. Thanks.
> 
> Do I really need to say PulseAudio and Lennart Poettering? And do I
> really need to say "made my own experiences" (with PA and systemd,
> btw.).
> 
>> Because we have never had unbootable systems due to upgrades in
>> [testing] before...
> 
> And now you have them. Did you have even one totally unbootable system
> with sysvinit and initscripts? I doubt that.

Yes. A bash update in [testing] resulted in unbootable systems.   I
thought you were around then...  maybe it just feels that long.

Allan

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

[Allan McRae]

On 22/09/12 18:07, Heiko Baums wrote:
> Am Sat, 22 Sep 2012 15:09:02 +0900
> schrieb Zhengyu Xu :
> 
>> After updating systemd to 191-1 in testing repo, I had following
>> messages during booting and the process was stuck (crashed).
>>
>> [   10.539416] systemd[1]: segfault at 7d ip b75a97b7 sp bfb0ece8
>> error 4 in libc-2.16.so[b752a000+1a4000]
>> [   10.539700] systemd[1]: Caught , core dump failed.
>>
>> Downgrade to 189-4 can solve this problem. I want to know if this
>> is a personal problem or a general bug affecting others as well.
> 
> Why am I not surprised?

Medical condition?

> Yes, binary init system is so much better than a script based init
> system. And Poetterix is so damn good, so advanced, such an evolution
> and so much better than the common and over 40 years well tested
> sysvinit.
> 
> Come on systemd fanboys, here you have the first example. There's more
> to come. I'll get my popcorn.
> 

Because we have never had unbootable systems due to upgrades in
[testing] before...  You say "sysvinit" but that relied on many compiled
binaries (e.g. bash)

Allan

Re: [arch-general] libffado update

[Allan McRae]

On 21/09/12 23:36, Aapo Vienamo wrote:
> Hello. I noticed that libffado was updated recently. It looks like that the 
> new
> version of libffado is incompatible with the version of jack in the arch 
> repos.
> 
> To demonstrate the problem:
> 
> aapo ~ $ jackd -dfirewire -r192000
> jackd 0.121.3
> Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and 
> others.
> jackd comes with ABSOLUTELY NO WARRANTY
> This is free software, and you are welcome to redistribute it
> under certain conditions; see the file COPYING for details
> 
> JACK compiled with System V SHM support.
> loading driver ..
> firewire ERR: Incompatible libffado version! (libffado 2.1.0-Unversioned 
> directory)
> cannot load driver module firewire
> no message buffer overruns
> 
> What should be done about this? I have tried jack2 but I found it too 
> unstable 
> to be actually useful.
> 

bugs.archlinux.org

Re: [arch-general] Iinstallation program

[Allan McRae]

On 21/09/12 18:03, Jan Litwiński wrote:
> When will Arch have more friendly installation program like Ubuntu, 
> Fedora, or opwnSUSE. I installed Arch some years ago and it was very 
> difficult for me.
> 

Ha ha ha...   best troll ever!

Re: [arch-general] After update package fontconfig causes ldconfig issue

[Allan McRae]

On 08/09/12 17:43, Ralf Mardorf wrote:
> On Sat, 2012-09-08 at 09:38 +0200, Ralf Mardorf wrote:
>> On Sat, 2012-09-08 at 09:17 +0200, Laurent Carlier wrote:
>>> Le samedi 8 septembre 2012 07:23:18 Ralf Mardorf a écrit :
 When an update today run ldconfig, I noticed that there's something
 wrong, caused by an update from yesterday.

 [root@archlinux spinymouse]# ldconfig
 ldconfig: /usr/lib32/libfontconfig.so.1 is not an ELF file - it has the
 wrong magic bytes at the start.

 ldconfig: /usr/lib32/libfontconfig.so.1.6.2 is not an ELF file - it has
 the wrong magic bytes at the start.

 ldconfig: /usr/lib32/libfontconfig.so is not an ELF file - it has the
 wrong magic bytes at the start.

 [root@archlinux spinymouse]# pacman -Qi fontconfig | grep Install\ Date
 Install Date   : Fri Sep  7 07:18:11 2012
 [root@archlinux spinymouse]# pacman -Ql fontconfig | grep libfontconfig
 fontconfig /usr/lib/libfontconfig.so
 fontconfig /usr/lib/libfontconfig.so.1
 fontconfig /usr/lib/libfontconfig.so.1.6.2

 Regards,
 Ralf
>>>
>>> All these files are from lib32-fontconfig package. And they are all correct:
>>> $ readelf -h  /usr/lib32/libfontconfig.so.1
>>> ELF Header:
>>>   Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
>>>   Class: ELF32
>>>   Data:  2's complement, little endian
>>>   Version:   1 (current)
>>>   OS/ABI:UNIX - System V
>>>   ABI Version:   0
>>>   Type:  DYN (Shared object file)
>>>   Machine:   Intel 80386
>>>   Version:   0x1
>>>   Entry point address:   0x45f0
>>>   Start of program headers:  52 (bytes into file)
>>>   Start of section headers:  227008 (bytes into file)
>>>   Flags: 0x0
>>>   Size of this header:   52 (bytes)
>>>   Size of program headers:   32 (bytes)
>>>   Number of program headers: 7
>>>   Size of section headers:   40 (bytes)
>>>   Number of section headers: 27
>>>   Section header string table index: 26
>>>
>>>
>>> Something must be rotten on your system.
>>
>> The only cause for this could be updates.
> 
> Or a power blackout I had yesterday. But how should a power blackout
> cause a broken header for a lib?
>

Right after you updated? The file might not have been written to disk yet...

Re: [arch-general] how to handle dependency cycle?

[Allan McRae]

On 07/09/12 03:02, Krzysztof Warzecha wrote:
> Hello,
> 
> I found dependency cycle in extra:
> 
> libjpeg -> nasm (makedepends)
> nasm -> ghostscript (makedepends)
> ghostscript -> libjpg (depends)
> 
> check_package.py script (one that sends Integrity Check to
> arch-dev-public) does not treat this as dependency cycle, but clearly
> I can't build one package without at least one another.
> 
> Assuming I have no packages from extra, how do I handle this? In this
> case I could just drop ghostscript from nasm and everything will work
> (well, I hope so). This is just bug?

It is probably not a bug.   You can drop ghostscript from nasm
makedepends, build the rest then rebuild nasm.

Allan

Re: [arch-general] [arch-dev-public] fontconfig 2.10.1 will require user interaction

[Allan McRae]

On 06/09/12 18:20, Heiko Baums wrote:
> Am Thu, 6 Sep 2012 10:06:57 +0200
> schrieb Andreas Radke :
> 
>> Pacman will detect the symlinks and break before the install scriptlet
>> will be run. So this is not an option.
> 
> Did you test it?
> 
> I'm pretty sure it won't, since I tested this before in one of my AUR
> packages. Well, it was the removal of files in /lib due to the change
> from /lib to /usr/lib, but at least this has worked.
> 

Conflict checking is done before pre_install scripts are run.  Those
files are not owned by any package so will produce a conflict.

Allan

Re: [arch-general] git update groupadd failure: Invalid configuration: SYS_GID_MIN (101), GID_MIN (100), SYS_GID_MAX (99)

[Allan McRae]

On 05/09/12 00:03, David C. Rankin wrote:
> All,
> 
>   pacman -Syu this morning and groupadd failed while installing git with the
> following message:
> 
> ( 28/115) upgrading git
> [###] 100%
> groupadd: Invalid configuration: SYS_GID_MIN (101), GID_MIN (100), 
> SYS_GID_MAX (99)
> useradd: group 'git' does not exist
> error: command failed to execute correctly
> 
>   It appears to see a min of 100 and a max of 99. That doesn't appear to ever 
> work.
> 
> [confused construction worker] "I've cut it twice and it's still too short?"
> 

This is the default in /etc/login.defs :

#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN  1000
GID_MAX 6
# System accounts
SYS_GID_MIN   500
SYS_GID_MAX   999



Is yours changed?

Re: [arch-general] libsystemd to systemd

[Allan McRae]

On 31/08/12 20:44, Kevin Chadwick wrote:
>>> IIUC the OP got issues regarding to networkmanager, while not switching
>>> to systemd.  
>>
>> For the people not reading the forums: it seems the problem was with
>> the order of daemons in rc.conf, and should be unrelated to systemd.
>> For people not using systemd, this change should really not have any
>> effect at all (you'll just have some extra unused files around).
> 
> While the cause has been explained I think we are missing the Why or is
> it How.
> 
> If dbus was out of order how come it worked under initscripts? Is
> it because initscripts checks the list and starts dbus early in any case
> and the init script compatibility over-rid systemds similar behaviour?
> 

He is not using systemd at all...   So the upgrade of systemd is a
red-herring here.

Allan

Re: [arch-general] Sudo arch wiki

[Allan McRae]

On 31/08/12 09:48, Kevin Chadwick wrote:
> Cmnd_Alias EDITS
> = /usr/bin/vim, /usr/bin/nano, /usr/bin/cat, /usr/bin/vi Cmnd_Alias
> ARCHLINUX = /usr/sbin/gparted, /usr/bin/pacman, /usr/bin/pacman-color
> 
> root ALL = (ALL) ALL
> USER_NAME ALL = (ALL) ALL, NOPASSWD: WHEELER, NOPASSWD: PROCESSES,
> NOPASSWD: ARCHLINUX, NOPASSWD: EDITS
> 
> 
> 
> 
> The arch wiki docs are usually very good but the sudo page is
> dangerous.
> 
> The offered configs suggest adding editors to sudo when sudoedit should
> only be added and only to a set file otherwise sudo is basically just
> su and without a password in the example so suid all due to the user
> being able to edit sudoers or escape the editor.
> 

It is a wiki.  Edit it...

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

[Allan McRae]

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

Arch does not patch the software it uses when we do not agree with
upstream decisions.  So we would require breaking one of the core Arch
principles to implement any suggestions so far.

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

Are you looking at the _original_ bug report.  It has an actual comment
explaining why it was closed.

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

As is a standard and well documented practice for all political
discussion on the forums...

Allan

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

[Allan McRae]

On 02/07/12 10:51, Andrew Hills wrote:
> On Sun, Jul 1, 2012 at 8:47 PM, Allan McRae  wrote:
>> I have found a solution.   All mirrors in countries with disputed names
>> are just removed from the official mirrorlist.
> 
> I believe servers south of the Mason-Dixon line should be listed under
> the country name "Confederate States of America". Under this new
> solution, I propose removing USA servers south of the Mason-Dixon line
> from the mirrorlist.
> 

Done.

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

[Allan McRae]

On 02/07/12 09:47, Tom Gundersen wrote:
> On Sun, Jul 1, 2012 at 9:49 PM, Loui Chang  wrote:
>> Gimme a break. These kind of political issues aren't solved by "taking
>> it upstream". Since when are politicians or people under the influence
>> of politics known for their outstanding adherence to logic and reason?
>> It's not such a simple technical thing that you can "take it upstream."
>> If you have any idea how the ISO works you will wake up to the fact of
>> how ridiculous that suggestion is. If Taiwan (ROC) can't get it to
>> happen, what do you expect of us?
> 
> I didn't mean to imply that this was a simple problem to solve (and I agree 
> with
> your aim for what that's worth). Simply that we do not want to make political
> decisions at all. This might be a straightforward one, but it sets a
> precedent and
> next time around we might be asked to decide on something less clear-cut.
> 
>> But as has been suggested maybe Arch should choose a different upstream
>> for this kind of information. Please open your mind a little, a false
>> standard is no standard at all.
> 
> I had a look at ICU, but could not find any satisfactory
> documentation. They claim
> to take their data from the same ISO standard that we already use, but I could
> find no explanation for the discrepancy.
> 
> To be a bit constructive: IMHO any proposal for a change must be made in 
> general
> terms, and not by special-casing based on this issue. So, if we can
> find a new upstream
> that is comparable to ISO3166, but at the same time is somehow more
> "neutral", that
> would be something to consider I guess.
> 
> I have to agree with Allan though, this issue is likely going nowhere.
>

I have found a solution.   All mirrors in countries with disputed names
are just removed from the official mirrorlist.

Allan

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

[Allan McRae]

On 02/07/12 05:49, Loui Chang wrote:
> On Sun 01 Jul 2012 21:23 +0200, Tom Gundersen wrote:
>> On Sun, Jul 1, 2012 at 7:28 PM, Loui Chang  wrote:
>>> On Sun 01 Jul 2012 23:08 +0800, Zero, Chien-An Cho wrote:
 Hello,

 First of all, I am sorry to bring political issues to here. I have
 been using ArchLinux for years, deployed on many servers, though I'm
 not joining the community until now. The recent changes to the
 ArchLinux webpages (ex. Downloads, Mirror Status) is really offending
 Taiwanese people. I would like to bring up this issue, and preferably
 to resolve this issue.

 I have posted this message on the forum:
 https://bbs.archlinux.org/viewtopic.php?id=144315 . The moderator
 suggested me to post on arch-general, so here it is. :)
 There is also a bug tracking issue submitted by other Taiwanese user
 that I'm requesting for reopen here:
 https://bugs.archlinux.org/task/30444

 The following text is the same as the post on forum, except a few
 modification to make text smoother.

 The recent changes on the download page named Taiwan as Taiwan,
 Province of China, which is not reflecting the truth that Taiwan is a
 independent country which having its own government. I think this
 might be caused by following the ISO-3166 country name list standard.
 However, I don't think ISO-3166 is a good list when it comes to the
 country name.

 Many open source communities have encountered this problem before.
 Most of them understand that ISO-3166 is not really a neutral list
 that we all hope for, and thus made switch to a separate maintained
 country list. For example, FreeBSD[1], Rails[2], Debian[3]. Many big
 commercial entities also opt not to use "Taiwan, PRC" in their country
 list, like: Apple[4], IBM[5], also try Google, Facebook, Twitter, et
 cetra. A possible solution might be using the country name list from
 ICU[6].

 I believed the ArchLinux is trying to expand its user-base around the
 world, so a neutral country name list would be the best for the
 benefit of all of us, ArchLinux developers and users. As a Taiwanese
 ArchLinux user, I'm really happy to see that user base of ArchLinux is
 growing in Taiwan. Some educational institutions provide mirrors site
 in Taiwan, Wiki localized in Traditional Chinese in the recent years.
 I sincerely hope this issue can be resolved as soon as possible. Let's
 keep the issue simple and not flaming it, thanks.

 References:

 [1] FreeBSD: http://www.freebsd.org/cgi/query-pr.cgi?pr=138672
 [2] Rails: 
 http://www.koziarski.net/archives/2008/9/24/countries-and-controversies/
 [3] Debian: http://lists.debian.org/debian-devel/2004/04/msg00798.html
 [4] Apple: http://www.apple.com/choose-your-country/
 [5] IBM: http://www.ibm.com/planetwide/select/selector.html
 [6] ICU: 
 http://source.icu-project.org/repos/icu/icu/trunk/source/data/region/en.txt
>>>
>>> I agree. I'm very disappointed by the response of Dave Reisner on that
>>> bug report. The reality is that the PRC does not have jurisdiction or
>>> claim over Taiwan. When standards are false they should not be followed.
>>>
>>> Dave: Can you educate yourself a little about the Republic of China and
>>> Taiwan vs the People's Republic of China, before making a final
>>> decision? Thank you.
>>
>> This has been discussed a number of times. While no one has so far
>> questioned the validity of the bug, the consensus seems to be that
>> this should be taken upstream [0].
>>
>> I hope it is clear that no offense is intended, and that we do not
>> want to make any political judgments (and hence defer to the UN).
>>
>> [0]: .
> 
> Gimme a break. These kind of political issues aren't solved by "taking
> it upstream". Since when are politicians or people under the influence
> of politics known for their outstanding adherence to logic and reason?
> It's not such a simple technical thing that you can "take it upstream."
> If you have any idea how the ISO works you will wake up to the fact of
> how ridiculous that suggestion is. If Taiwan (ROC) can't get it to
> happen, what do you expect of us?
> 
> But as has been suggested maybe Arch should choose a different upstream
> for this kind of information. Please open your mind a little, a false
> standard is no standard at all.
> 


Well...  this discussion will go nowhere...  And I should point out that
most developers are now not subscribed from this list because of its low
signal-to-noise ratio so this thread will likely not get to the right
people.

The solution is to find us a different upstream that has any sort of
standards backing. This is just like Arch's policy with software.  We do
not patch because a feature is not the way we like it.

Allan

Re: [arch-general] update of chroot fails - error: cannot remove file '/sys/': Read-only file system

[Allan McRae]

On 30/06/12 13:37, David C. Rankin wrote:
> On 06/29/2012 08:07 PM, Allan McRae wrote:
>> Just because the answers are getting more ridiculous
>>
>>
>> Open /usr/sbin/mkarchroot and change:
>>
>>  mount -o remount,ro,bind "${working_dir}/sys"
>> to
>>  mount -o remount,bind "${working_dir}/sys"
>>
>>
>> Allan
> 
> Ooh, you're good :)
> 
>   That was it -- works like a charm now.
> 
> ... just how did the little ',ro' come to cause such a problem?
> 

/sys is in the filesystem package.   When pacman upgrades filesystem it
tries to remove /sys then reinstall it (not really, simplified...).  It
sees /sys is read only and so it can not deal with that so bails.  It is
a bug in pacman.

Allan

Re: [arch-general] update of chroot fails - error: cannot remove file '/sys/': Read-only file system

[Allan McRae]

On 30/06/12 10:58, Genes MailLists wrote:
> On 06/29/2012 06:25 PM, David C. Rankin wrote:
> ...
> 
>> error: cannot remove file '/sys/': Read-only file system
>> error: could not commit transaction
>> error: failed to commit transaction (transaction aborted)
>> Errors occurred, no packages were upgraded.
>>
>>
> 
>   I may be off base but can you check if your / filesystem is full?
> 
>  gene/
> 
> 


Just because the answers are getting more ridiculous


Open /usr/sbin/mkarchroot and change:

mount -o remount,ro,bind "${working_dir}/sys"
to
mount -o remount,bind "${working_dir}/sys"


Allan

Re: [arch-general] Pacman behaviour comparing numerical versions for package upgrades

[Allan McRae]

On 29/06/12 16:01, martin kalcher wrote:
> Am 29.06.2012 07:58, schrieb Allan McRae:
>> On 29/06/12 15:50, Myra Nelson wrote:

>>>  "Ignoring upgrade from perl-datetime-format-strptime from 1.51-1
>>> to 1.5000-1"
>>>
>>> No complaints as it's easy to fix, I was just wondering about the
>>> reasoning. I'll jump out on a limb here and assume it's because the
>>> repo package has 4 digits then the package version after the decimal
>>> point and my package has two digits then the package version after the
>>> decimal point. The developer changed his numbering scheme after 1.5000
>>> to 1.51.
>>>
>>> Is this the correct behaviour for pacman?
>>>
>>
>>
>> 5000 > 51
> 
> So we dont need this:
> 
>>> I'm used to the warning package ??? local is newer than extra ???.
> 

Just to be clear:

pacman sees 1.5000 as being newer than 1.51 as 5000 > 51.  So that
warning is correct, because only perl package versioning thinks that
5000 < 51 ...

Allan