Re: Cooperation with Listaller in dependency-management

On Sun, 31 Oct 2010 18:00:01 +0100, Anders F Björklund
<afb <at> users.sourceforge.net> wrote:
> Matthias Klumpp wrote:
> 
>>> That is why I started on recreating some of them from scratch.
>>> Parts at http://afb.users.sourceforge.net/zero-install/index/
>> This looks nice, I think it's exactly what I need!
> 
> As you might have noticed, there are two types of feeds.
> 
> One is just repackaged from the vendor, and those are
> currently lacking most if not all of the dependencies:
> http://afb.users.sourceforge.net/zero-install/interfaces/firefox.xml
> http://afb.users.sourceforge.net/zero-install/interfaces/thunderbird.xml
...this can be changed! If the new dependency-scanner is ready, these
feeds can be autocompleted using LiDepScan and Debian's DDE.

> Others are created from scratch, but do require some
> build system for the "base" dependencies (gcc, make):
> http://afb.users.sourceforge.net/zero-install/interfaces/python.xml
> http://afb.users.sourceforge.net/zero-install/interfaces/gnupg.xml
> 
> There needs to be more created-from-source type feeds...
I'm going to push binreloc (to create relocatable binaries) a little more,
so creating relocatable apps will become easier.

> But some packages require extensive patching to work with
> Zero Install. For instance the GNU Build System (Autotools)
> have some paths hardcoded, so those don't work as feeds (yet).
> It should be possible to patch them, to use variables instead ?

Localized summaries and descriptions

I would like to propose the following changes to the behavior of the
_best_language_match method in model.py:

Split languages codes by a hyphen (-) instead of an underscore (_) since
this fits W3C's definition of the "xml:lang" attribute:
http://www.w3.org/TR/REC-xml/#sec-lang-tag

Extend the current language fallback algorithm (exact match, same country
and neutral culture, neutral language) to the following algorithm:
1. exact match
2. same language with neutral culture
3. neutral language (no language specified)
4. en-US
5. en
6. first language specified in feed
This would solve the problems like a feed containing a German and an English
summary and then failing to run on Italian systems.

I have attached a patch making the suggested modifications.

------------------------------------------------------------------------------
Achieve Improved Network Security with IP and DNS Reputation.
Defend against bad network traffic, including botnets, malware, 
phishing sites, and compromised hosts - saving your company time, 
money, and embarrassment.   Learn More! 
http://p.sf.net/sfu/hpdev2dev-nov

_______________________________________________

Re: Localized summaries and descriptions

+1

-- 
Antonio

On Wed, 03 Nov 2010 00:45:27 +0100, Bastian Eicher <bastian <at> eicher.net>  
wrote:

> I would like to propose the following changes to the behavior of the
> _best_language_match method in model.py:
>
> Split languages codes by a hyphen (-) instead of an underscore (_) since
> this fits W3C's definition of the "xml:lang" attribute:
> http://www.w3.org/TR/REC-xml/#sec-lang-tag
>
> Extend the current language fallback algorithm (exact match, same country
> and neutral culture, neutral language) to the following algorithm:
> 1. exact match
> 2. same language with neutral culture
> 3. neutral language (no language specified)
> 4. en-US
> 5. en
> 6. first language specified in feed
> This would solve the problems like a feed containing a German and an  
> English
> summary and then failing to run on Italian systems.
>
> I have attached a patch making the suggested modifications.

------------------------------------------------------------------------------

0compile's os.uname, on Mac OS X

So uname and config.guess returns some, err, surprising,
values on Mac OS X 10.6 Snow Leopard (which is multilib):

$ uname -sm
Darwin i386
$ echo "int main() {}" > test.c
$ gcc test.c 
$ file a.out 
a.out: Mach-O 64-bit executable x86_64

This is confusing 0compile a bit, since it thinks that
it is building things for "Darwin-i386" (which it isn't)

def get_arch_name():
	uname = os.uname()
	target_os = canonicalize_os(uname[0])
	target_machine = canonicalize_machine(uname[4])

The patch suggested for config.guess is to make it look
at the default compiler output rather than the machine:

http://git.savannah.gnu.org/gitweb/?p=config.git;a=commitdiff;h=ccf975556a0f6797fe80395cd6f314682a770f15

Even if it runs the 32-bit kernel by default, uname will
still report "i386" even when running the 64-bit kernel.

So I ported the same thing to Python, for use in 0compile.

--anders

Re: 0compile's os.uname, on Mac OS X

On 4 November 2010 19:24, Anders F Björklund <afb <at> users.sourceforge.net> wrote:
>
> So uname and config.guess returns some, err, surprising,
> values on Mac OS X 10.6 Snow Leopard (which is multilib):
>
> $ uname -sm
> Darwin i386
> $ echo "int main() {}" > test.c
> $ gcc test.c
> $ file a.out
> a.out: Mach-O 64-bit executable x86_64
>
> This is confusing 0compile a bit, since it thinks that
> it is building things for "Darwin-i386" (which it isn't)
>
> def get_arch_name():
>        uname = os.uname()
>        target_os = canonicalize_os(uname[0])
>        target_machine = canonicalize_machine(uname[4])
>
>
> The patch suggested for config.guess is to make it look
> at the default compiler output rather than the machine:
>
> http://git.savannah.gnu.org/gitweb/?p=config.git;a=commitdiff;h=ccf975556a0f6797fe80395cd6f314682a770f15
>
> Even if it runs the 32-bit kernel by default, uname will
> still report "i386" even when running the 64-bit kernel.
>
> So I ported the same thing to Python, for use in 0compile.

Re: 0compile's os.uname, on Mac OS X

 Thomas Leonard wrote:

>> So I ported the same thing to Python, for use in 0compile.
> 
> Applied - thanks!

Here's another patch while at it, to fix the library mappings.

i.e. Linux "libfoo.so.1.2.3" is Darwin "libfoo.1.2.3.dylib"

--anders

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev

_______________________________________________
Zero-install-devel mailing list
Zero-install-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

Re: 0compile's os.uname, on Mac OS X

On 4 November 2010 20:36, Anders F Björklund <afb <at> users.sourceforge.net> wrote:
>  Thomas Leonard wrote:
>
>>> So I ported the same thing to Python, for use in 0compile.
>>
>> Applied - thanks!
>
> Here's another patch while at it, to fix the library mappings.
>
> i.e. Linux "libfoo.so.1.2.3" is Darwin "libfoo.1.2.3.dylib"

Applied too!

--

-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
Zero-install-devel mailing list
Zero-install-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

Re: Zero Install distro

On Sun, Sep 12, 2010 at 05:02:46PM -0500, Yfrwlf wrote:
> Not to rile the list up or get super off-topic or anything, but...
> 
> What about making an entire distro based on Zero Install packages?
> 
> Zero Install allows an easy solution for dependency issues by allowing 
> for dependencies to always be available (sort of) somewhere on the net, 
> and to be installed automatically, unlike distros which are not as 
> modular and don't have all the dependencies available for all versions 
> of all programs, nor even an easy web link to where they can be found to 
> be installed.  As I see it, Zero Install gives Linux longevity.  It's 
> not hard to install a program which is much newer or older than the rest 
> of your OS.  This isn't normally a feature that many (older) Linux users 
> have cared about due to them using compilation and source code as the 
> fix, but for users who don't want to bother with dependencies and 
> compilation (though you could still use ZI for a source-based system 
> similar to the ebuild system) it is a great solution, since ZI's #2 goal 
> and solution is that developers can't package for every distro, but they 
> can package for ZI instead to reach every distro.
> 
> So coming back to my original statement, trying to create a distro on ZI 
> would have a lot of interesting challenges as far as I can tell, but 
> (with some work) it would allow the *entire* distro to be as modular as 
> ZI is.  No longer would you have to wait on major versions of Xorg, for 
> instance, to be packaged in a newer distro, so that you have to 
> completely upgrade to get it.  It'd allow you to upgrade right away 
> instead as long as ZI was the new package manager and thus could 
> regulate those things dependent on said version of Xorg.
> 
> I realize that doing so would cause all kinds of dependency issues that 

Re: 0compile's os.uname, on Mac OS X

Thomas Leonard wrote:

>> Here's another patch while at it, to fix the library mappings.
>> 
>> i.e. Linux "libfoo.so.1.2.3" is Darwin "libfoo.1.2.3.dylib"
> 
> Applied too!

Guess I could have tested that better:

Detected library major versions: {'z.dy': 'libz', 'z.1.dy': 'libz'}

Seemed to have hardcoded len('lib') and len('.so'):

					mappings[x[3:-3]] = target

Used some temp variables instead... Maybe constants are in order ?
(otherwise need to go through it all again for '.dll' on Windows)

Anyway, here's the fix for 0compile and similar for make-headers.

--anders

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 

Draft plan for <command> support

Here's a first draft of the design for the new <command> stuff. A
small amount of this has been implemented on the 'command' Git branch,
but mainly this is just some thoughts about how it *might* work, even
though it's written as if I already implemented it  Things I'm
really not sure about are in [...].

Here's how it works:

- Each Implementation has a set of zero or more named Commands.
- A Command is a way to run an Implementation.
- Three pre-defined command names are "run" (to run the program),
"test" (run the self tests) and "compile". These replace the "main",
"self-test" and "compile:command" attributes.

So:

  <implementation main='bin/prog' self-test='tests/alltests.py' ...>
    ...
  </implementation>

Can now also be written as:

  <implementation ...>
    <command name='run' path='bin/prog'/>
    <command name='test' path='tests/alltests.py'/>
    ...
  </implementation>

[ should we rename 'path' to 'exec'? we also need to support arbitrary
shell commands if we want to replace compile:command ]