no time to
waste on stuff like that.
mega@leafbuilder:~/leaf/devel/packages$ git pull --rebase
ssh: connect to host git.code.sf.net port 22: Connection refused
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
mega@l
06.06.2015 10:39, Erich Titl пишет:
> Hi KP
>
> Am 06.06.2015 um 01:34 schrieb kp kirchdoerfer:
>> Hi Erich;
>>
>> ...sorry for being late.
>>
>> Am Dienstag, 2. Juni 2015, 10:44:39 schrieb Erich Titl:
>>> Hi KP
>>>
>>> I am somewhat online again and I would like to get the upgrade thing
>>> runnin
06.06.2015 02:34, kp kirchdoerfer пишет:
> Hi Erich;
>
> ...sorry for being late.
>
> Am Dienstag, 2. Juni 2015, 10:44:39 schrieb Erich Titl:
>> Hi KP
>>
>> I am somewhat online again and I would like to get the upgrade thing
>> running (again). Looking at the packages repo I only see 5_0 and 5_1.
Hi KP
Am 06.06.2015 um 01:34 schrieb kp kirchdoerfer:
> Hi Erich;
>
> ...sorry for being late.
>
> Am Dienstag, 2. Juni 2015, 10:44:39 schrieb Erich Titl:
>> Hi KP
>>
>> I am somewhat online again and I would like to get the upgrade thing
>> running (again). Looking at the packages repo I only s
Hi Erich;
...sorry for being late.
Am Dienstag, 2. Juni 2015, 10:44:39 schrieb Erich Titl:
> Hi KP
>
> I am somewhat online again and I would like to get the upgrade thing
> running (again). Looking at the packages repo I only see 5_0 and 5_1.
I haven't changed anything since your tests. Lookin
Hi KP
I am somewhat online again and I would like to get the upgrade thing
running (again). Looking at the packages repo I only see 5_0 and 5_1.
What is the actual content (5.1.x) of 5_1?
Will there be a 5_2 (5.2.x) sometime soon?
Thanks
ET
smime.p7s
Description: S/MIME Cryptographic Sign
Hi all;
I've once again did a full rebuild for kernel 3.14 (arch=386) and the "usual
suspects" fail to build (see attachements). Any help to fix is welcome.
thx kp
(just in case attaching fails, the packages affected are: iscsi, perf, accel-
ppp and accel-pptp)
buildtool::Config::adjustFileCon
On 01/19/2012 03:16 PM, Erich Titl wrote:
-snip-
> There are package managers that address the dependency issue, maybe we
> should just look at them (and take the least complicated one)
-snip-
Erich,
Many of the other embedded distributions use opkg.
https://secure.wikimedia.org/wikipedia/en
Hi Per
on 19.01.2012 22:49, Per Sjoholm wrote:
> Hi Erich
>
> On 01/18/2012 10:56 AM, Erich Titl wrote:
...
>>> When the parts are working together,
>>> then we can consolidate and also chose a different implementation if needed.
>>> Maybe use python as a base for system mgmt tasks, it has most
Hi Erich
On 01/18/2012 10:56 AM, Erich Titl wrote:
> Hi Per
>
> at 18.01.2012 08:32, Per Sjoholm wrote:
>> On 01/17/2012 05:18 PM, KP Kirchdoerfer wrote:
>>> Am 17.01.2012 08:40, schrieb Per Sjoholm:
Thanks I tried libpt never occurred in my mind to check for lpt...
Coming from leaf
Hi Per
at 18.01.2012 08:32, Per Sjoholm wrote:
> On 01/17/2012 05:18 PM, KP Kirchdoerfer wrote:
>> Am 17.01.2012 08:40, schrieb Per Sjoholm:
>>> Thanks I tried libpt never occurred in my mind to check for lpt...
>>> Coming from leaf 2.0 I really like 4.2.
>>>
>>> Usually I load the package wi
On 01/17/2012 05:18 PM, KP Kirchdoerfer wrote:
> Am 17.01.2012 08:40, schrieb Per Sjoholm:
>> Thanks I tried libpt never occurred in my mind to check for lpt...
>> Coming from leaf 2.0 I really like 4.2.
>>
>> Usually I load the package with apkg and use the text via mhttpds as a
>> guide.
Am 17.01.2012 08:40, schrieb Per Sjoholm:
> Thanks I tried libpt never occurred in my mind to check for lpt...
> Coming from leaf 2.0 I really like 4.2.
>
> Usually I load the package with apkg and use the text via mhttpds as a
> guide.
>
> Suggestion
> It seems that it should be possible
Thanks I tried libpt never occurred in my mind to check for lpt...
Coming from leaf 2.0 I really like 4.2.
Usually I load the package with apkg and use the text via mhttpds as a guide.
Suggestion
It seems that it should be possible to to have some Packages Requires
statements in a file.
t
Everyone,
I've committed through "r" in our packages tree. 600+ files processed
and ~200 to go.
Anyone that wants to update a glibc-2.0 package with a name that begins
with "a-r" may do so.
--
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/
__
On Fri, 2002-05-17 at 10:50, Greg Morgan wrote:
> Mike Noyes <[EMAIL PROTECTED]> wrote:
>
> > Everyone,
> > I committed through "o" to our new packages repository. 500+ files
> > processed and ~300 to go.
>
> Ummm...I noticed a problem but I am not sure how to help. An example
> case is this do
Mike Noyes <[EMAIL PROTECTED]> wrote:
> Everyone,
> I committed through "o" to our new packages repository. 500+ files
> processed and ~300 to go.
Ummm...I noticed a problem but I am not sure how to help. An example
case is this document.
http://leaf.sourceforge.net/pub/doc/guide/install-eigers
Everyone,
I committed through "o" to our new packages repository. 500+ files
processed and ~300 to go.
Anyone that wants to update a glibc-2.0 package with a name that begins
with "a-o" may do so.
--
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/
> Can anyone recommend the best way to get libcrypto and libssl onto my
> slink UML machine? I am trying to build a mini_httpd package. I don't
> think the packages were available for slink. I am thinking "apt-get source
> openssl-dev" or something like that, but wanted to get your feedback
> b
Can anyone recommend the best way to get libcrypto and libssl onto my
slink UML machine? I am trying to build a mini_httpd package. I don't
think the packages were available for slink. I am thinking "apt-get source
openssl-dev" or something like that, but wanted to get your feedback
before beati
On Tue, 4 Dec 2001, Jack Coates wrote:
> On Tue, 4 Dec 2001, Charles Steinkuehler wrote:
>
>
> > Yeah, I think it's pretty big, plus I believe most of these packages require
> > openssl and other huge add-ons to run. The basics of public-key
> > cryptography, however, are pretty simple, so I t
On Tue, 4 Dec 2001, Charles Steinkuehler wrote:
> Yeah, I think it's pretty big, plus I believe most of these packages require
> openssl and other huge add-ons to run. The basics of public-key
> cryptography, however, are pretty simple, so I think it'd be possible to
> make a small (a few K, pe
> >Yeah, I think it's pretty big, plus I believe most of these packages
> require
> >openssl and other huge add-ons to run. The basics of public-key
> >cryptography, however, are pretty simple, so I think it'd be possible to
> >make a small (a few K, perhaps) binary that would simply calculate an
Charles Steinkuehler wrote:
> OK, I think we're closer than I previously thought on the issue of format.
> I have always felt the bulk of the package should be in a 'classic' gzipped
> tar file (this probably wasn't clear), but that some sort of extension is
> required to tack on additional meta-
Charles Steinkuehler wrote:
>Yeah, I think it's pretty big, plus I believe most of these packages
require
>openssl and other huge add-ons to run. The basics of public-key
>cryptography, however, are pretty simple, so I think it'd be possible to
>make a small (a few K, perhaps) binary that would
> On 12/3/01 at 4:54 PM, Charles Steinkuehler <[EMAIL PROTECTED]>
> wrote:
>
> > Hmm...looks like a new file format, smells like a new file format...
>
> Bah. Not really. The file "format" is all in the *.lrp package, and
> the package contents remain the same. Just give it a new wrapper,
> cal
On 12/3/01 at 4:54 PM, Charles Steinkuehler <[EMAIL PROTECTED]>
wrote:
> Hmm...looks like a new file format, smells like a new file format...
Bah. Not really. The file "format" is all in the *.lrp package, and
the package contents remain the same. Just give it a new wrapper,
call it *.srp, an
> You could use the two-file format already used for things like the Linux
> kernel, or if you really wanted, just wrap both files up like this -
> create a standard *.lrp file, then you could wrap it up into a *.srp
> file ("Secure LRP") with a digital signature.
>
> Then the unpackers would have
Charles Steinkuehler wrote:
> Most of the feature issues can be cobbled around by adding more
> .whatever files to the package format, but I'd REALLY like to have
> a way of cryptographically signing packages, in preperation for making
> trusted downloading of packages an available feature at run
David Douthitt wrote:
>About all that can be asked for is a "comment-like" tag that package
>creators use to detail dependencies.
Agreed. That's what I was thinking of - comments for things the
maintainer knows of, with no guarantee that its accurate or comprehensive.
And I see what you mean
> > Should we maybe start a sub-project to work on a new packaging format?
I've
> > got a lot of various ideas on possible formats and features, but no time
to
> > play with them :<
>
> I have a strong faith in the current format - even if we package up
> "newfangledsoftware 2.2.2" as a *.lrp with
"Angelacos, Nathan" wrote:
> One question, though - What about adding a "Requires" tag?
> snort.lrp and tcpdump.lrp may both require libpcap.lrp
> newfangledsoftware 2.2.2 with glibc 2.1 requires glibc 2.1,
> and might segfault under 2.0.7.
>
> Maybe there's no way to automate the requires bi
David Douthitt wrote:
> I have a strong faith in the current format - even if we package up
> "newfangledsoftware 2.2.2" as a *.lrp with glibc 2.0, it'll still work
> in that LRP 2.9.4 somebody's running.
>
> If we add a new file (*.desc) to the /var/lib/lrpkg directory, the
> package STILL works
Charles Steinkuehler wrote:
>
> > Here's the keywords my script understands:
> >
> > keywords["Name"]=1
> > keywords["Version"]=1
> > keywords["Release"]=1
> > keywords["Packager"]=1
> > keywords["Packaged"]=1
> > keywords["Keywords"]=1
> > keywords["Description"]=1
> > keywords["URL"]=1
> > keyw
Charles Steinkuehler wrote:
>How do your fields compare against those stored by rpm & deb?
>
A quick cruise over to debian and rpm.org produced this for me
(Sorry, Dave, if I'm speaking out of turn)
rpm debianDave
NamesourceName
Version Version
> Here's the keywords my script understands:
>
> keywords["Name"]=1
> keywords["Version"]=1
> keywords["Release"]=1
> keywords["Packager"]=1
> keywords["Packaged"]=1
> keywords["Keywords"]=1
> keywords["Description"]=1
> keywords["URL"]=1
> keywords["License"]=1
> keywords["Group"]=1
>
> and p
"Angelacos, Nathan" wrote:
>
> Jack Coates <[EMAIL PROTECTED]> wrote:
>
> >And for this reason I'm thinking that versioning in the filename is a
> >convenient nice-to-have.
It would. But with an 8 character limit, what about programs like nmap,
which is has version numbers like 2.3BETA10 - whi
Jack Coates <[EMAIL PROTECTED]> wrote:
>And for this reason I'm thinking that versioning in the filename is a
>convenient nice-to-have. If the version and author attributes are kept
>on the web server that should be enough to enable accurate downloads,
>though there are still troubleshooting issu
On Mon, 3 Dec 2001, David Douthitt wrote:
> On 12/2/01 at 9:59 PM, Jack Coates <[EMAIL PROTECTED]> wrote:
>
> > there are two problems with this scenario:
> > 1) It's a PITA to look all over the place for packages.
> > The leaf.sf.net site is not exactly good guidance since
> > the packages page
On 12/2/01 at 9:59 PM, Jack Coates <[EMAIL PROTECTED]> wrote:
> there are two problems with this scenario:
> 1) It's a PITA to look all over the place for packages.
> The leaf.sf.net site is not exactly good guidance since
> the packages page is empty and they're all under pub/
> which isn't link
so, when I was looking for PPP packages I found that there are tons of
locations for package downloads, and many packages have two or three
versions.
there are two problems with this scenario:
1) It's a PITA to look all over the place for packages. The leaf.sf.net
site is not exactly good guidanc
Food for thought for the underconvinced. I took my current router disk
image, copied all the .lrp files to a temp directory and renamed them to
.tgz, then gunzip'd them and recompressed them with bzip2.
bootbeep.tgz etc.tgzlog.tgz oidentd.tgz root.tgz weblet.tgz
dnscache.tgz local.tg
David Douthitt, 2001-03-30 11:11 -0600
>Mike Noyes wrote:
> >
> > David Douthitt, 2001-03-30 09:50 -0600
> > >...what you have after this is done is a source code directory that
> > >could, in theory, be compiled straight away to create a usable LRP
> > >binary.
>
> > That sounds great!
>
> > Ok,
Mike Noyes wrote:
>
> David Douthitt, 2001-03-30 09:50 -0600
> >...what you have after this is done is a source code directory that
> >could, in theory, be compiled straight away to create a usable LRP
> >binary.
> That sounds great!
> Ok, I just added wrappers for .o and .tar.gz. I can remove
David Douthitt, 2001-03-30 09:50 -0600
>...what you have after this is done is a source code directory that
>could, in theory, be compiled straight away to create a usable LRP
>binary.
David,
That sounds great!
> > >* I never created *.diff files for makefile only changes - such as
> > >static l
Mike Noyes wrote:
>
> David Douthitt, 2001-03-30 09:23 -0600
> >Let me see if I understand this right:
> >
> >* What I have now is "working directories" which include multiple
> >versions as well as compiled binaries.
> >* CVS would be source files only (with diffs and docs included)
> >
> >Is t
David Douthitt, 2001-03-30 09:23 -0600
>Mike Noyes wrote:
> > David,
> > I'm talking about an import of the src tree from the CD into CVS. Are
> > you talking about importing the compiled output, or am I confused
> > again?
>
>Let me see if I understand this right:
>
>* What I have now is "working
Mike Noyes wrote:
>
> David Douthitt, 2001-03-30 09:09 -0600
> >Mike Noyes wrote:
> >
> > > David,
> > > It looks like you have an oxygen tree that's almost ready for import
> > > into CVS. I can add binary wrappers for .o and tar.gz. This should
> > > allow you to import your src tree as oxygen.
David Douthitt, 2001-03-30 09:09 -0600
>If you like. I'm not sure what you mean by "binary wrappers for .o
>and tar.gz" ...?
Everyone,
This should explain how CVS handles binary files. It'll also explain why I
need to add binary file wrappers.
9. Handling binary files
http://www.cvshome.org/do
David Douthitt, 2001-03-30 09:09 -0600
>Mike Noyes wrote:
>
> > David,
> > It looks like you have an oxygen tree that's almost ready for import
> > into CVS. I can add binary wrappers for .o and tar.gz. This should
> > allow you to import your src tree as oxygen. Did I miss anything? Is
> > this s
Mike Noyes wrote:
> David,
> It looks like you have an oxygen tree that's almost ready for import into
> CVS. I can add binary wrappers for .o and tar.gz. This should allow you to
> import your src tree as oxygen. Did I miss anything? Is this something
> you'd like to do?
If you like. I'm not s
David Douthitt, 2001-03-30 08:32 -0600
>Mike Noyes wrote:
> > David,
> > Are all the files in this src directory text, or are there binary
> > files too?
>
>The src directory is basically a snapshot of my build directories; so
>all have *.o files, as well as *diff files and so on. In some cases
>
Mike Noyes wrote:
>
> David Douthitt, 2001-03-30 07:26 -0600
> >The CDROM I have has (in part) the following breakdown:
> >
> >src --+-- base ...like busybox, ctar, tftp, ...
> > |
> > +-- pkgs --+-- net
> > |
> > +-- sys
> > |
> >
David Douthitt, 2001-03-30 07:26 -0600
>The CDROM I have has (in part) the following breakdown:
>
>src --+-- base ...like busybox, ctar, tftp, ...
> |
> +-- pkgs --+-- net
> |
> +-- sys
> |
> +-- ...et al...
David,
Ar
Mike Noyes wrote:
> CVS: I would like us to use CVS for packages (.lrp). I added a binary
> wrapper this morning for .lrp. I'd like some feedback on possible directory
> structures. I think it should look something like this:
>
> packages -+
>+ /boot -+
>|+ /eige
Mike Noyes, 2001-03-28 10:20 -0800
>Everyone,
>I'd like us to start using the SF Tracker to handle package submissions.
>Comments?
>
>Note: I don't know if it's necessary to tarball/zip them before uploading.
Everyone,
PatchManager: I checked last night, and the Patch Manager handles binary
f
56 matches
Mail list logo
