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

[Loui Chang]

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

Get a better mail client.

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

[Kaiting Chen]

On Mon, Dec 6, 2010 at 9:12 PM, Allan McRae  wrote:

> Top posting vs. going off topic without changing subject lines. I'm not
> sure which is worse...
>

Bottom posting in Gmail is a pain in the ass. --Kaiting.

-- 
Kiwis and Limes: http://kaitocracy.blogspot.com/

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

[Allan McRae]

On 07/12/10 11:52, Loui Chang wrote:

On Mon 06 Dec 2010 10:27 -0700, Steve Holmes wrote:

Scroll CLEAR down to the bottom for my response.

On Wed, Oct 20, 2010 at 12:02:27PM -0400, Matthew Gyurgyik wrote:

Really please, please don't top post.
http://www.river.com/users/share/etiquette/


Who cares! it takes too long to scroll down through the past fifteen
generations to get to the relevant part of the message.


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



Top posting vs. going off topic without changing subject lines. I'm not 
sure which is worse...

Re: [arch-general] Python 3 Rationale?

[Loui Chang]

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

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

Re: [arch-general] [RFC] patches to initscripts

[Tom Gundersen]

On Tue, Dec 7, 2010 at 1:10 AM, Thomas Bächler  wrote:
> I pushed everything to the official git tree.

Great!

> There's one more thing about the check in the SWAP area of the crypttab
> code: Instead of using isLuks to check for a LUKS device, check with
> blkid whether there is any valid file system signature on it.
>
> The problem is: If blkid finds more than one valid signature, it will
> not return anything, and we will mistakenly believe that there is no
> file system (and happily overwrite the drive). This part of initscripts
> is giving me a headache everytime I touch it.

Hmmm... Interesting... I'll put this on my mental TODO list and have a
look next time I have time.

Cheers,

Tom

Re: [arch-general] [RFC] patches to initscripts

[Thomas Bächler]

Am 06.12.2010 16:48, schrieb Tom Gundersen:
> On Mon, Dec 6, 2010 at 1:52 PM, Thomas Bächler  wrote:
>> Thanks. The initscripts patch won't work though:
>>
>> [[ $USELVM =~ yes|YES && -x /sbin/lvm && -d /sys/block ]] || return
>> "return" is a statement that will only work inside a function. I don't
>> know what it will do on the top level, but certainly not what you'd expect.
> 
> D'oh! Copy-paste error, sorry about that.
> 
> Updated commit:
> .
> 
> Thanks for testing,
> 
> Tom
> 

I pushed everything to the official git tree.

There's one more thing about the check in the SWAP area of the crypttab
code: Instead of using isLuks to check for a LUKS device, check with
blkid whether there is any valid file system signature on it.

The problem is: If blkid finds more than one valid signature, it will
not return anything, and we will mistakenly believe that there is no
file system (and happily overwrite the drive). This part of initscripts
is giving me a headache everytime I touch it.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Python 3 Rationale?

[Ng Oon-Ee]

On Mon, 2010-12-06 at 10:27 -0700, Steve Holmes wrote:
> > Really please, please don't top post.
> > http://www.river.com/users/share/etiquette/
> 
> Who cares! it takes too long to scroll down through the past fifteen
> generations to get to the relevant part of the message.

If you're posting on an ML with hundreds of other users, you follow the
established styles. On most MLs, that's bottom-posting. "Who cares?" is
just a childish response.

Re: [arch-general] Python 3 Rationale?

[C Anthony Risinger]

On Mon, Dec 6, 2010 at 11:48 AM, Christoffer Hirth  wrote:
> Den 06. des. 2010 18:27, skrev Steve Holmes:
>>>
>>> Really please, please don't top post.
>>> >  http://www.river.com/users/share/etiquette/
>>
>> Who cares! it takes too long to scroll down through the past fifteen
>> generations to get to the relevant part of the message.
>>
> That no problem as you only keep the relevant parts...

indeed; not about retaining everything, but rather enough to keep
context.  if you haven't cleaned up your response you probably haven't
read enough to have one.

Steve, you posted to a 45+ day thread for this?

C Anthony

Re: [arch-general] Python 3 Rationale?

[Christoffer Hirth]

Den 06. des. 2010 18:27, skrev Steve Holmes:

Really please, please don't top post.
>  http://www.river.com/users/share/etiquette/

Who cares! it takes too long to scroll down through the past fifteen
generations to get to the relevant part of the message.


That no problem as you only keep the relevant parts...

--- Christoffer

[arch-general] dropping go-openoffice/icu-4.6 rebuilds

[Andreas Radke]

The former ooo-build project "go-openoffice" is deprecated by
upstream developers in favor of the upcoming LibreOffice (LibO).

It's time to drop it from our repos while we are rebuilding all
OpenOffice branches for the icu-4.6 .so-bump.

Please use the vanilla Oracle openoffice-base packages or try out the
new and already very stable libreoffice packages.

The Oracle office beta and devel packages will get rebuilt when new
upstream releases will happen. Don't expect them to work when we move
icu-4.6. They are of low interest.

-Andy

Re: [arch-general] Python 3 Rationale?

[Steve Holmes]

Scroll CLEAR down to the bottom for my response.

On Wed, Oct 20, 2010 at 12:02:27PM -0400, Matthew Gyurgyik wrote:
>  On 10/20/2010 11:45 AM, maxc wrote:
> >There is an excellent post by Guido here, Hilton: 
> >http://mail.python.org/pipermail/python-3000/2008-February/011910.html
> >
> >Guido seems to favor using /usr/bin/python3.0 or /usr/bin/python3
> >and /usr/bin/python as symlinks to the respective versions of
> >Python.
> >
> >'Perhaps we should only install "python3.0" and not "python".'
> >
> >We're not here to discussion semantics ofc. :) There is a much
> >broader concern which I hope we can address through friendly
> >discourse.
> >
> >On Oct 20, 2010, at 11:26 AM, Hilton Medeiros
> > wrote:
> >
> >>On Wed, 20 Oct 2010 10:58:42 -0400
> >>Max Countryman  wrote:
> >>
> >>> That is fine unless the Python development team has decide that
> >>> python3 will not become python.
> >>>
> >>> Python 2.7.x will be maintained for quite some time. (In excess of
> >>> four more years.) Even after it is dropped in the future there's no
> >>> indication that the python3 binary is intended to become the python
> >>> binary.
> >>>
> >>> The link I posted earlier to the thread on the Python mailing list
> >>> seems to indicate the opposite.
> >>
> >>A 'python' binary doesn't and won't ever exist, it is only a
> >>symlink, Max.
> Since you have seemed to miss my previous post. I'll post again!
> 
> Really please, please don't top post.
> http://www.river.com/users/share/etiquette/

Who cares! it takes too long to scroll down through the past fifteen
generations to get to the relevant part of the message.

Re: [arch-general] [RFC] patches to initscripts

[Tom Gundersen]

On Mon, Dec 6, 2010 at 1:52 PM, Thomas Bächler  wrote:
> Thanks. The initscripts patch won't work though:
>
> [[ $USELVM =~ yes|YES && -x /sbin/lvm && -d /sys/block ]] || return
> "return" is a statement that will only work inside a function. I don't
> know what it will do on the top level, but certainly not what you'd expect.

D'oh! Copy-paste error, sorry about that.

Updated commit:
.

Thanks for testing,

Tom

Re: [arch-general] Multi architecture binary pkgs

[C Anthony Risinger]

On Mon, Dec 6, 2010 at 8:48 AM, Rémy Oudompheng
 wrote:
> On 2010/12/6 Rémy Oudompheng  wrote:
>> This seems to assume that pacman and makepkg run on systems that are
>> either 32-bit or 64-bit. IMO, your proposal looks very "ad hoc", and
>> would add unnecessary complications to makepkg, with no benefit when
>> dealing with PowerPC, ARM, and other architectures.
>
> However, maybe a sensible way to do that would be to allow build()
> function to be replaced by "build_$arch" functions in the same fashion
> as with split packages.

i like that idea, though i wonder if that would also entail allowing
for all split functions (possibly) needing an $arch.

perhaps `_$arch` could be appended to ANY function in PKGBUILD, and
makepkg would use where appropriate; perhaps even build them all using
chroots/etc.

C Anthony

Re: [arch-general] Multi architecture binary pkgs

[Rémy Oudompheng]

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

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

-- 
Rémy.

Re: [arch-general] Multi architecture binary pkgs

[Rémy Oudompheng]

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

Hello,

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

-- 
Rémy.

Re: [arch-general] [RFC] patches to initscripts

[Thomas Bächler]

Am 06.12.2010 13:43, schrieb Tom Gundersen:
> On Mon, Dec 6, 2010 at 12:04 PM, Thomas Bächler  wrote:
>> https://github.com/teg/initscripts-arch/commit/b4c804d60d6e8361db3f19bf3a2fa6fb58ee8458
>>
>> Two short comments about this commit:
>>
>> 1) We need to run vgchange again after rw-mounting everything (without
>> --sysinit), so monitoring can be set up.
>> 2) mkinitcpio's LVM hook also needs --sysinit.
>>
>> The rest of the patches are fine.
> 
> Thanks to Thomas and Dave for fast feedback. I pushed a few more
> commits to my trees to address their comments:
> 
> 
> 

Thanks. The initscripts patch won't work though:

[[ $USELVM =~ yes|YES && -x /sbin/lvm && -d /sys/block ]] || return
"return" is a statement that will only work inside a function. I don't
know what it will do on the top level, but certainly not what you'd expect.

> Finally, here is a patch for mkinitcpio's LVM hook (don't know if this
> is the best way to contribute to svn repo's...):
> 
> 
> --- lvm2_hook   2010-12-06 13:20:10.588544437 +0100
> +++ lvm2_hook   2010-12-06 13:25:22.838755236 +0100
> @@ -20,6 +20,6 @@
>  msg "Scanning logical volumes..."
>  eval /sbin/lvm vgscan --ignorelockingfailure $LVMQUIET
>  msg "Activating logical volumes..."
> -eval /sbin/lvm vgchange --ignorelockingfailure
> --ignoremonitoring -ay $LVMQUIET
> +eval /sbin/vgchange --sysinit -a y $LVMQUIET
>  fi
>  }
> 

Heh, there is no good way, sadly.



signature.asc
Description: OpenPGP digital signature

[arch-general] Multi architecture binary pkgs

[jesse jaara]

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

-- 
(\_ /) copy the bunny to your profile
(0.o ) to help him achieve world domination.
(> <) come join the dark side.
/_|_\ (we have cookies.)

Re: [arch-general] [RFC] patches to initscripts

[Tom Gundersen]

On Mon, Dec 6, 2010 at 12:04 PM, Thomas Bächler  wrote:
> https://github.com/teg/initscripts-arch/commit/b4c804d60d6e8361db3f19bf3a2fa6fb58ee8458
>
> Two short comments about this commit:
>
> 1) We need to run vgchange again after rw-mounting everything (without
> --sysinit), so monitoring can be set up.
> 2) mkinitcpio's LVM hook also needs --sysinit.
>
> The rest of the patches are fine.

Thanks to Thomas and Dave for fast feedback. I pushed a few more
commits to my trees to address their comments:




Finally, here is a patch for mkinitcpio's LVM hook (don't know if this
is the best way to contribute to svn repo's...):


--- lvm2_hook   2010-12-06 13:20:10.588544437 +0100
+++ lvm2_hook   2010-12-06 13:25:22.838755236 +0100
@@ -20,6 +20,6 @@
 msg "Scanning logical volumes..."
 eval /sbin/lvm vgscan --ignorelockingfailure $LVMQUIET
 msg "Activating logical volumes..."
-eval /sbin/lvm vgchange --ignorelockingfailure
--ignoremonitoring -ay $LVMQUIET
+eval /sbin/vgchange --sysinit -a y $LVMQUIET
 fi
 }

Re: [arch-general] [RFC] patches to initscripts

[Thomas Bächler]

Am 06.12.2010 11:39, schrieb Tom Gundersen:
> On Fri, Nov 19, 2010 at 7:58 AM, Allan McRae  wrote:
>> While looking through bugs for [core] packages, I notice that there are a
>> large number of bug report for these three packages.  In total they account
>> for ~13% of the bugs in the tracker!
> 
> [...]
> 
>> But given these are some of the uniqueness of Arch, I wonder what we _as a
>> group_ could to do to improve this situation?  Perhaps organize a
>> hack-a-thon on IRC one day?  Or we could advertise for help, with the
>> selection criterion being a git repo provided by the applicant showing they
>> can do stuff?
> 
> As discussed with Allan, here are some patches to initscripts:
> .
> 
> Comments very much welcome.
> 
> I started off with what appeared to me as the low-hanging fruit. Once
> I have had feedback on this I'll have a look at more difficult (or
> invasive) problems.
> 
> My long-term goal is to ease the maintenance burden of initscripts by
> simplifying them and harmonizing them with other distros/projects
> (without, of course, loosing any of their features).

https://github.com/teg/initscripts-arch/commit/b4c804d60d6e8361db3f19bf3a2fa6fb58ee8458

Two short comments about this commit:

1) We need to run vgchange again after rw-mounting everything (without
--sysinit), so monitoring can be set up.
2) mkinitcpio's LVM hook also needs --sysinit.

The rest of the patches are fine.



signature.asc
Description: OpenPGP digital signature

[arch-general] [RFC] patches to initscripts

[Tom Gundersen]

On Fri, Nov 19, 2010 at 7:58 AM, Allan McRae  wrote:
> While looking through bugs for [core] packages, I notice that there are a
> large number of bug report for these three packages.  In total they account
> for ~13% of the bugs in the tracker!

[...]

> But given these are some of the uniqueness of Arch, I wonder what we _as a
> group_ could to do to improve this situation?  Perhaps organize a
> hack-a-thon on IRC one day?  Or we could advertise for help, with the
> selection criterion being a git repo provided by the applicant showing they
> can do stuff?

As discussed with Allan, here are some patches to initscripts:
.

Comments very much welcome.

I started off with what appeared to me as the low-hanging fruit. Once
I have had feedback on this I'll have a look at more difficult (or
invasive) problems.

My long-term goal is to ease the maintenance burden of initscripts by
simplifying them and harmonizing them with other distros/projects
(without, of course, loosing any of their features).

Cheers,

Tom