Hi all;
this issue is solved and tested in 6.0.4-rc1.
The proposed patch has also been accepted for uClibc-ng 1.0.25.
kp
Am Sonntag, 7. Mai 2017, 17:23:19 schrieb kp kirchdoerfer:
> Hi Bob, Hi Erich;
>
> thanks for the profound work on this bug.
>
> I've contacted the maintainer of uClibc-ng
Hi Bob, Hi Erich;
thanks for the profound work on this bug.
I've contacted the maintainer of uClibc-ng and received some homework to track
this issue. The proposed patch by by ddrown needs testing and if successful,
might be accepted.
kp
Am Mittwoch, 3. Mai 2017, 22:04:53 schrieb Erich Titl:
Hi Bob
(copying this to leaf-devel)
Sorry, I was too fast, I did not look into the i386 code but the one in
x86_64
Am 03.05.2017 um 20:03 schrieb Robert K Coffman Jr. -Info From Data Corp.:
Eric,
IRC user ddrown confirmed the x64 patch I mentioned earlier seems to fix
the issue on i386 as w
Hi Bob
(copying this to leaf-devel)
Am 03.05.2017 um 20:03 schrieb Robert K Coffman Jr. -Info From Data Corp.:
Eric,
IRC user ddrown confirmed the x64 patch I mentioned earlier seems to fix
the issue on i386 as well. I'm not really sure what to do with that
information. Is it possible to pat
Hi Andrew;
Am Samstag, 29. Oktober 2016, 20:12:11 schrieb Andrew:
> hi.
>
> about versioning:
>
> The current proposed translation is:
>
> 5.2.8 -> 52800
> 6.0.0 -> 6
> 6.0.0-minorfix -> 60001
> 6.0.1-beta1 -> 60010
> 6.0.1-rc-1 -> 60020
> 6.0.1 -> 60100
>
hi.
about versioning:
The current proposed translation is:
5.2.8 -> 52800
6.0.0 -> 6
6.0.0-minorfix -> 60001
6.0.1-beta1 -> 60010
6.0.1-rc-1 -> 60020
6.0.1 -> 60100
6.0.1-minorfix -> 60101
6.0.2-beta1 -> 60110
this limits versioning to max 1
Am Donnerstag, 14. Januar 2016, 09:49:05 schrieb Erich Titl:
> Hi Folks
>
> In my effort to port new-initrd to master I looked at the linux directory
>
> Why do we have config files for 4.1 and 4.4 plus the corresponding tarballs?
> Shouldn't we make the config files release agnostic?
It is use
Hi KP
Am 14.01.2016 um 15:45 schrieb kp kirchdoerfer:
> Am Donnerstag, 14. Januar 2016, 09:49:05 schrieb Erich Titl:
>> Hi Folks
>>
>> In my effort to port new-initrd to master I looked at the linux directory
>>
>> Why do we have config files for 4.1 and 4.4 plus the corresponding tarballs?
>> Sho
Hi Andrew
Am 14.01.2016 um 11:04 schrieb Andrew:
> Hi.
>
> Git conflict appears when there's two modifications of same code in
> merged branches.
>
> So only case of avoiding it - don't touch code which is modified in
> other branch, that is impossible in real world :)
So I thought, anyway I
Hi.
Git conflict appears when there's two modifications of same code in
merged branches.
So only case of avoiding it - don't touch code which is modified in
other branch, that is impossible in real world :)
14.01.2016 10:20, Erich Titl пишет:
> Hi Yves
>
> Am 14.01.2016 um 09:10 schrieb Yves B
Hi Folks
In my effort to port new-initrd to master I looked at the linux directory
Why do we have config files for 4.1 and 4.4 plus the corresponding tarballs?
Shouldn't we make the config files release agnostic?
cheers
ET
---
Hi Folks
I just looked at leaf.sourceforge.net and was wondering
Created on 2003-02-04 10:24:27 by install
Updated on 2005-08-24 11:48:30 by mhnoyes
Latest news:
LEAF Bering-uClibc maintenance update 4.3.3 released
Wouldn't we think that the release of 5.2.3 it worth a note?
Should we
Hi Yves
Am 14.01.2016 um 09:10 schrieb Yves Blusseau:
> Hi Erich,
>
> the best is to merge the new-initrd branch into the maint or master.
> In either case (merge or rebase) you need to resolve the conflicts.
> There are no other alternative.
Pretty disappointing :-(
Is there a best practise st
Hi Erich,
the best is to merge the new-initrd branch into the maint or master.
In either case (merge or rebase) you need to resolve the conflicts.
There are no other alternative.
Yves
> Le 14 janv. 2016 à 08:10, Erich Titl a écrit :
>
> Hi Yves
>
> KP has asked me to port my stuff from new-in
Hi Yves
KP has asked me to port my stuff from new-initrd to master. I would like
to do that with a minimum of manual intervention, but I am a bit stuck
with the way the LEAF project is built within the git repository.
The branch new-initrd is branched off tag 5.2.2. In the meantime maint
and mast
ee
> a reason to do this.
>
> Thanks
>
> ET
>
> --
>
> ___
> leaf-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/leaf-devel
----
Hi Andrew
I am digging in the linux source directory and I am wondering why this
is/was necessary
# workaround -- patch 2.7.1 needs --follow-symlinks, patch 2.61 will not
work
cp -L $(LINUX_CONFIG) $(LINUX_CONFIG).n; rm $(LINUX_CONFIG); mv
$(LINUX_CONFIG).n $(LINUX_CONFIG)
This makes a l
Hi Andrew
Am 08.12.2015 um 13:54 schrieb Andrew:
> 08.12.2015 13:03, Erich Titl пишет:
>> Hi Andrew
>>
>> Am 08.12.2015 um 11:28 schrieb Andrew:
>>> Hi.
>>>
>>> You're right, only .cdiff files (+ generic config) are needed.
>>>
>>> Other per-target .config files are present just for easier update
08.12.2015 13:03, Erich Titl пишет:
> Hi Andrew
>
> Am 08.12.2015 um 11:28 schrieb Andrew:
>> Hi.
>>
>> You're right, only .cdiff files (+ generic config) are needed.
>>
>> Other per-target .config files are present just for easier update (this
>> was actual when usual .diff were used - after confi
Hi Andrew
Am 08.12.2015 um 11:28 schrieb Andrew:
> Hi.
>
> You're right, only .cdiff files (+ generic config) are needed.
>
> Other per-target .config files are present just for easier update (this
> was actual when usual .diff were used - after config change new config
> not always lays smoot
Hi.
You're right, only .cdiff files (+ generic config) are needed.
Other per-target .config files are present just for easier update (this
was actual when usual .diff were used - after config change new config
not always lays smooth, usually there were patching errors due to
changed context)
Hi Folks
What is the canonical way to modify kernel config files? I see there is
a number of cdiff files in the repo, also the same number of
architecture related config files. Now I am wondering where exactly the
modifications should go and why we are keeping all this redundant
information. I bel
Hi Folks
I cannot reach the LEAF page anymore, am I the only one?
Thanks
Erich
--
___
leaf-devel mailing list
[email protected]
https://lists.sourceforge.net/l
moved to leaf-devel from leaf-user
Hi again
Am 29.09.2015 um 14:39 schrieb Erich Titl:
> Hi Folks
>
> I just upgraded my ALIX router to 5.2 just to see that dhcpcd apparently
> did not request an IPv4 address.
>
> Configuring network interfaces: eth0: adding address
> fe80::20d:b9ff:fe33:ecc0
>
Am 09.04.2015 um 17:03 schrieb Andrew:
> 09.04.2015 17:47, Erich Titl пишет:
...
They are, but of course they cannot be replaced automatically if they
are not in either the tarball, the squashfs or in the modules directory.
>>> They'll be in modules directory because they'll be in moddb.
09.04.2015 17:47, Erich Titl пишет:
> Am 09.04.2015 um 16:36 schrieb Andrew:
> ...
>> So let's store both packed modules + unpacked on server side, as we
>> decided earlier.
>> Packed modules will be suitable for routers with enough storage space;
>> unpacked - for tiny systems.
>> I just voting ag
Am 09.04.2015 um 16:36 schrieb Andrew:
...
>
> So let's store both packed modules + unpacked on server side, as we
> decided earlier.
> Packed modules will be suitable for routers with enough storage space;
> unpacked - for tiny systems.
> I just voting against excluding packed modules in prefer
09.04.2015 16:32, Erich Titl пишет:
> Am 09.04.2015 um 14:25 schrieb Andrew:
>> 09.04.2015 14:35, Erich Titl пишет:
>>> Am 09.04.2015 um 11:12 schrieb Andrew:
Hi.
>>> ...
>>>
For me, it's much easier to update just one file instead of hundreds of
modules on persist storage. Esp.
Am 09.04.2015 um 14:25 schrieb Andrew:
> 09.04.2015 14:35, Erich Titl пишет:
>> Am 09.04.2015 um 11:12 schrieb Andrew:
>>> Hi.
>>>
>> ...
>>
>>> For me, it's much easier to update just one file instead of hundreds of
>>> modules on persist storage. Esp. when one broken (non-updated) module
>>> can
09.04.2015 14:35, Erich Titl пишет:
> Am 09.04.2015 um 11:12 schrieb Andrew:
>> Hi.
>>
> ...
>
>> For me, it's much easier to update just one file instead of hundreds of
>> modules on persist storage. Esp. when one broken (non-updated) module
>> can break system.
> You can't be serious. If we upgra
Am 09.04.2015 um 11:12 schrieb Andrew:
> Hi.
>
...
> For me, it's much easier to update just one file instead of hundreds of
> modules on persist storage. Esp. when one broken (non-updated) module
> can break system.
You can't be serious. If we upgrade, we upgrade the kernel, initrd,
initmod a
Hi.
09.04.2015 10:42, Erich Titl пишет:
> Hi Folks
>
> I have been able to test the upgrade script successfully using a
> squashfs file as the source for the modules. This leads us to the
> question if we should use this method as a means to distribute the modules.
>
> The use of a squashfs file i
Hi Folks
I have been able to test the upgrade script successfully using a
squashfs file as the source for the modules. This leads us to the
question if we should use this method as a means to distribute the modules.
The use of a squashfs file instead of a compressed tarball for the
distribution o
Hi KP
Am 05.04.2015 um 11:51 schrieb kp kirchdoerfer:
Hi Erich;
sounds interesting.
For building images see:
http://bering-uclibc.zetam.org/wiki/Bering-uClibc_5.x_-_Developer_Guide_-_Building_an_Image
and buildimage.pl in the root of the buildenv.
Can you explain which repository/branch hold
Hi Erich;
sounds interesting.
For building images see:
http://bering-uclibc.zetam.org/wiki/Bering-uClibc_5.x_-_Developer_Guide_-_Building_an_Image
and buildimage.pl in the root of the buildenv.
Can you explain which repository/branch holds your testbed?
The packages repo can be become a mess r
Hi Folks
following Andrew's suggestions I made a few tests with squashfs to see
how an agreement on the presentation of data could be reached. I have
not tested with the existing upgrade script, I just wanted to see what
implications a squashfs based distribution of the modules tarball would
have.
Am 03.04.2015 um 13:26 schrieb Andrew:
> 03.04.2015 14:02, Erich Titl пишет:
...
>> The numbers imply that there is nothing to be gained in size over the
>> tarball using squashfs. The advantage of using a squashfs is that we do
>> not need to unpack the tarball for each file involved. This method
03.04.2015 14:02, Erich Titl пишет:
> Hi Andrew
>
> Am 02.04.2015 um 22:35 schrieb Andrew:
>> 02.04.2015 22:09, Mega пишет:
> ...
>
>>From other side, we may do other trick: we may store modules in
>> squashfs instead of tgz, and mount it instead of unpacking. And
>> even we
>>
Hi Andrew
Am 02.04.2015 um 22:35 schrieb Andrew:
> 02.04.2015 22:09, Mega пишет:
...
>>
> From other side, we may do other trick: we may store modules in
> squashfs instead of tgz, and mount it instead of unpacking. And
> even we
> may remove moddb.lrp - just mount this sq
02.04.2015 22:09, Mega пишет:
> Am 02.04.2015 um 16:27 schrieb Andrew:
>> 02.04.2015 16:34, Erich Titl пишет:
>>> Hi Andrew
>>>
>>> Am 02.04.2015 um 12:35 schrieb Andrew:
02.04.2015 13:16, Erich Titl пишет:
> Hi Andrew
>>> ...
>>>
>> Single tarball is easier for update than hundreds of
Am 02.04.2015 um 16:27 schrieb Andrew:
02.04.2015 16:34, Erich Titl пишет:
Hi Andrew
Am 02.04.2015 um 12:35 schrieb Andrew:
02.04.2015 13:16, Erich Titl пишет:
Hi Andrew
...
Single tarball is easier for update than hundreds of small files.
No it is not, if you have insufficient space. It
02.04.2015 16:34, Erich Titl пишет:
> Hi Andrew
>
> Am 02.04.2015 um 12:35 schrieb Andrew:
>> 02.04.2015 13:16, Erich Titl пишет:
>>> Hi Andrew
> ...
>
Single tarball is easier for update than hundreds of small files.
>>> No it is not, if you have insufficient space. It is just a bloody pain
>
Hi Andrew
Am 02.04.2015 um 12:35 schrieb Andrew:
> 02.04.2015 13:16, Erich Titl пишет:
>> Hi Andrew
...
>>> Single tarball is easier for update than hundreds of small files.
>> No it is not, if you have insufficient space. It is just a bloody pain
>> in the butt. And then what is IT for if we can
02.04.2015 13:16, Erich Titl пишет:
> Hi Andrew
>
> Am 02.04.2015 um 11:32 schrieb Andrew:
>> Hi.
>>
>> 02.04.2015 11:22, Erich Titl пишет:
>>> Hi Folks
>>>
>>> Upgrade has proven to be functional on the i386 platform. I cannot judge
>>> other platforms, as I don't have any hardware to test with.
>
Hi Andrew
Am 02.04.2015 um 11:32 schrieb Andrew:
> Hi.
>
> 02.04.2015 11:22, Erich Titl пишет:
>> Hi Folks
>>
>> Upgrade has proven to be functional on the i386 platform. I cannot judge
>> other platforms, as I don't have any hardware to test with.
>>
>> I would like to know what you judge necess
Hi.
02.04.2015 11:22, Erich Titl пишет:
> Hi Folks
>
> Upgrade has proven to be functional on the i386 platform. I cannot judge
> other platforms, as I don't have any hardware to test with.
>
> I would like to know what you judge necessary to enable the packages
> repository to serve the necessary
Hi Folks
Upgrade has proven to be functional on the i386 platform. I cannot judge
other platforms, as I don't have any hardware to test with.
I would like to know what you judge necessary to enable the packages
repository to serve the necessary files. As KP pointed out, existing
procedures build
31.03.2015 01:08, Erich Titl пишет:
> Am 30.03.2015 um 23:24 schrieb Andrew:
>> 30.03.2015 23:40, Erich Titl пишет:
>>> Am 30.03.2015 um 18:39 schrieb Andrew:
30.03.2015 18:23, Erich Titl пишет:
> Am 30.03.2015 um 17:03 schrieb Andrew:
>>> ...
> ...
modules.tgz updating possibility?
>
Am 30.03.2015 um 23:24 schrieb Andrew:
> 30.03.2015 23:40, Erich Titl пишет:
>> Am 30.03.2015 um 18:39 schrieb Andrew:
>>> 30.03.2015 18:23, Erich Titl пишет:
Am 30.03.2015 um 17:03 schrieb Andrew:
>> ...
...
>>> modules.tgz updating possibility?
>> No problem on my side, recreating the tarbal
30.03.2015 23:40, Erich Titl пишет:
> Am 30.03.2015 um 18:39 schrieb Andrew:
>> 30.03.2015 18:23, Erich Titl пишет:
>>> Am 30.03.2015 um 17:03 schrieb Andrew:
> ...
>>> Correct, you cannot just add hardware without adding modules. As there
>>> is no space on the target machine to hold modules.tgz t
Am 30.03.2015 um 18:39 schrieb Andrew:
> 30.03.2015 18:23, Erich Titl пишет:
>> Am 30.03.2015 um 17:03 schrieb Andrew:
...
>>
>> Correct, you cannot just add hardware without adding modules. As there
>> is no space on the target machine to hold modules.tgz this is not
>> relevant. Lots of our syste
30.03.2015 18:23, Erich Titl пишет:
> Am 30.03.2015 um 17:03 schrieb Andrew:
>> 30.03.2015 17:21, Erich Titl пишет:
> ...
>
>>> Impossible, it is too big. Upgrade is not thought as an initial setup tool.
>> But this will cause a mismatched modules.tgz version. And will cause a
>> headache for addin
Am 30.03.2015 um 17:09 schrieb kp kirchdoerfer:
> Am Montag, 30. März 2015, 16:40:01 schrieb Erich Titl:
>> Am 30.03.2015 um 16:10 schrieb kp kirchdoerfer:
>>> Hi Erich;
>>>
...
>> :
>
> are in a ?
Fingers slower than brain :-(
The modules are in a directory tree.
>
>
>>> I prefer you load t
Am 30.03.2015 um 17:03 schrieb Andrew:
> 30.03.2015 17:21, Erich Titl пишет:
...
>> Impossible, it is too big. Upgrade is not thought as an initial setup tool.
> But this will cause a mismatched modules.tgz version. And will cause a
> headache for adding new hardware that isn't supported by curre
Am Montag, 30. März 2015, 16:40:01 schrieb Erich Titl:
> Am 30.03.2015 um 16:10 schrieb kp kirchdoerfer:
> > Hi Erich;
> >
> > I disagree with a few of your decisions, mainly because they put a lot of
> > extra work upon the dude instead get it once forever right in the upgrade
> > script. I'll ex
30.03.2015 17:21, Erich Titl пишет:
> Am 30.03.2015 um 15:48 schrieb Andrew:
>> 30.03.2015 16:33, Erich Titl пишет:
>>> Hi Folks
>>>
> ...
>>> - modules-$ARCH.tgz tarballs are unpacked into module-$ARCH directories,
>>> this makes no big difference in size, as the modules are compressed
>>> anyway.
Am 30.03.2015 um 16:10 schrieb kp kirchdoerfer:
> Hi Erich;
>
> I disagree with a few of your decisions, mainly because they put a lot of
> extra work upon the dude instead get it once forever right in the upgrade
> script. I'll explain in the text...
>
>
> Am Montag, 30. März 2015, 15:33:48 s
Am 30.03.2015 um 15:48 schrieb Andrew:
> 30.03.2015 16:33, Erich Titl пишет:
>> Hi Folks
>>
...
>> - modules-$ARCH.tgz tarballs are unpacked into module-$ARCH directories,
>> this makes no big difference in size, as the modules are compressed
>> anyway. The tarballs can be deleted.
> How it'll work
Hi Erich;
I disagree with a few of your decisions, mainly because they put a lot of
extra work upon the dude instead get it once forever right in the upgrade
script. I'll explain in the text...
Am Montag, 30. März 2015, 15:33:48 schrieb Erich Titl:
> Hi Folks
>
> I adapted the 5.1.4-rc1 branc
30.03.2015 16:33, Erich Titl пишет:
> Hi Folks
>
> I adapted the 5.1.4-rc1 branch in the package repository to provide all
> necessary data to upgrade.
>
> the main differences to the existing packages are
>
> - modules-$ARCH.tgz tarballs are unpacked into module-$ARCH directories,
> this makes no
Hi Folks
I adapted the 5.1.4-rc1 branch in the package repository to provide all
necessary data to upgrade.
the main differences to the existing packages are
- modules-$ARCH.tgz tarballs are unpacked into module-$ARCH directories,
this makes no big difference in size, as the modules are compress
Hi Yves
Am 28.03.2015 um 18:27 schrieb Yves Blusseau:
> Sorry for my intrusion but why don't you use a git clone working dir for the
> document root of the http server.
What would that achieve? Isn't is just another repository and thus a
copy of the data?
> With that we can change the tree easi
Sorry for my intrusion but why don't you use a git clone working dir for the
document root of the http server.
With that we can change the tree easily, we need only one branch that represent
all the versions of the packages that can be download.
Also with this the same file in different paths are
Am 27.03.2015 um 19:34 schrieb kp kirchdoerfer:
Am Freitag, 27. März 2015, 17:54:43 schrieb Erich Titl:
Am 27.03.2015 um 16:43 schrieb kp kirchdoerfer:
Am Freitag, 27. März 2015, 16:22:40 schrieb Erich Titl:
Am 27.03.2015 um 15:53 schrieb kp kirchdoerfer:
Am Freitag, 27. März 2015, 09:12:04
Am Freitag, 27. März 2015, 17:54:43 schrieb Erich Titl:
> Am 27.03.2015 um 16:43 schrieb kp kirchdoerfer:
> > Am Freitag, 27. März 2015, 16:22:40 schrieb Erich Titl:
> >> Am 27.03.2015 um 15:53 schrieb kp kirchdoerfer:
> >>> Am Freitag, 27. März 2015, 09:12:04 schrieb Erich Titl:
> >> ...
> >>
> >
Am 27.03.2015 um 16:43 schrieb kp kirchdoerfer:
> Am Freitag, 27. März 2015, 16:22:40 schrieb Erich Titl:
>> Am 27.03.2015 um 15:53 schrieb kp kirchdoerfer:
>>> Am Freitag, 27. März 2015, 09:12:04 schrieb Erich Titl:
>> ...
>>
>>> Yes it's effcient with branches.But it's not really efficient with
>
Am Freitag, 27. März 2015, 16:39:54 schrieb Erich Titl:
> Hi
>
> Am 27.03.2015 um 15:53 schrieb kp kirchdoerfer:
> ...>
>
> > Just play with it and let's know about your findings.
> > Esp stable is a playground, but I hope we can shrink the other repos as
> > well later.
>
> I can now access the
Am Freitag, 27. März 2015, 16:22:40 schrieb Erich Titl:
> Am 27.03.2015 um 15:53 schrieb kp kirchdoerfer:
> > Am Freitag, 27. März 2015, 09:12:04 schrieb Erich Titl:
> ...
>
> > Yes it's effcient with branches.But it's not really efficient with
> > binaries, though as discussed that's a workaround
Hi
Am 27.03.2015 um 15:53 schrieb kp kirchdoerfer:
...>
> Just play with it and let's know about your findings.
> Esp stable is a playground, but I hope we can shrink the other repos as well
> later.
I can now access the packages as
http://sourceforge.net/p/leaf/packages/ci/5.1.3/tree/
and
ht
Am 27.03.2015 um 15:53 schrieb kp kirchdoerfer:
> Am Freitag, 27. März 2015, 09:12:04 schrieb Erich Titl:
...
>
> Yes it's effcient with branches.But it's not really efficient with binaries,
> though as discussed that's a workaround for the missing ftp/whatever-space.
To git a file is a file is
Am Freitag, 27. März 2015, 09:12:04 schrieb Erich Titl:
> Hi Folks
>
> Am 24.03.2015 um 12:38 schrieb Erich Titl:
> ..
>
> > I don't know, if we can use this to just give access to the current or
> > stable files. I did some local experiments
> >
> > mega@leafbuilder:~/leaf/devel/packages$ du -s
Hi Folks
Am 24.03.2015 um 12:38 schrieb Erich Titl:
..
>
> I don't know, if we can use this to just give access to the current or
> stable files. I did some local experiments
>
> mega@leafbuilder:~/leaf/devel/packages$ du -s .
> 5961104 .
>
> mega@leafbuilder:~/leaf/devel/packages$ git branch
Hi Folks
I am playing a little with the package repository, trying to make it
appear to a browser in a reasonable tree form.
I _believe_ by using the git features branches and tags we could provide
a reasonable tree for our packages.
Just looking at the current settings for the packages
https:/
Am 21.03.2015 um 08:18 schrieb Per Sjoholm:
> On 03/20/2015 10:38 PM, Mega wrote:
>>> What does it take to have git on the client?
>>
>> The client is the LEAF route.
>
> What does git require of LEAF in terms of resources ?
It would need git on the router, no way.
cheers
Erich
smime.p7s
D
On 03/20/2015 10:38 PM, Mega wrote:
>> What does it take to have git on the client?
>
> The client is the LEAF route.
What does git require of LEAF in terms of resources ?
/Per
--
Dive into the World of Parallel Program
Am 20.03.2015 um 07:44 schrieb Per Sjoholm:
On 03/19/2015 04:59 PM, Mega wrote:
...
Mayby even intergrate some contentious delivery tool and have virtbox, qemu,
qemu/gns3 as targets
What does it take to have git on the client?
The client is the LEAF route.
cheers
Erich
smime.p7s
De
On 03/19/2015 04:59 PM, Mega wrote:
> Hi Yves
>
> Am 18.03.2015 um 12:45 schrieb Yves Blusseau:
>> Using git to store the packages and using branch to group the packages by
>> version/architecture is really a good thing
>> and it's not dependent to how and where the files are host.
>> But using ht
Hi Yves
Am 18.03.2015 um 12:45 schrieb Yves Blusseau:
Using git to store the packages and using branch to group the packages by
version/architecture is really a good thing and it's not dependent to how and
where the files are host.
But using http to get the packages is a bad thing for me becau
Using git to store the packages and using branch to group the packages by
version/architecture is really a good thing and it's not dependent to how and
where the files are host.
But using http to get the packages is a bad thing for me because is dependent
of how the http server expose the files/
Hi Erich;
Am Freitag, 13. März 2015, 22:48:54 schrieb Erich Titl:
> Hi KP
>
> Am 13.03.2015 um 14:57 schrieb kp kirchdoerfer:
> > Am Donnerstag, 12. März 2015, 19:15:02 schrieb Erich Titl:
> ...
>
> > I've added one.
> >
> > That's all in the git repo packages, uploading is via git (add, commit
Hi KP
Am 13.03.2015 um 14:57 schrieb kp kirchdoerfer:
> Am Donnerstag, 12. März 2015, 19:15:02 schrieb Erich Titl:
...
>
> I've added one.
>
> That's all in the git repo packages, uploading is via git (add, commit,
> push...)
I believe I understand now, weird but if it works.
I would l like
Hi KP
Am 13.03.2015 um 14:57 schrieb kp kirchdoerfer:
> Am Donnerstag, 12. März 2015, 19:15:02 schrieb Erich Titl:
..
>
> I've added one.
>
> That's all in the git repo packages, uploading is via git (add, commit,
> push...)
A, that is where it's at, OK clone the packages repo :-(
ET
Am 13.03.2015 um 14:57 schrieb kp kirchdoerfer:
>>
>> So it looks like https access works, but the version file used to check
>> access to the net fails. We need something to check for, version is a
>> good surrogate.
>>
>
> I've added one.
>
> That's all in the git repo packages, uploading is v
Am Donnerstag, 12. März 2015, 19:15:02 schrieb Erich Titl:
> Hi KP
>
> Am 12.03.2015 um 17:59 schrieb kp kirchdoerfer:
> ...
>
> > Look for
> >
> > https://sourceforge.net/p/leaf/packages/ci/master/tree/stable/
> >
> > does that help you?
>
> AP# sh upgrade -v
> upgrade: checking web access by
Am 12.03.2015 um 19:10 schrieb kp kirchdoerfer:
> Hi Erich;
>
> Am Donnerstag, 12. März 2015, 18:55:37 schrieb Erich Titl:
...
>>
>> OK, be it that way, but if you upload files, do you have any control on
>> the location, e.g. the URL they can be accessed with?
>
> For the major part no, AFAIK i
Hi KP
Am 12.03.2015 um 17:59 schrieb kp kirchdoerfer:
...
>
> Look for
>
> https://sourceforge.net/p/leaf/packages/ci/master/tree/stable/
>
> does that help you?
>
AP# sh upgrade -v
upgrade: checking web access by retrieving the version file
aborting: wget error code 0
upgrade: abort wget e
Hi Erich;
Am Donnerstag, 12. März 2015, 18:55:37 schrieb Erich Titl:
> Hi KP
>
> Am 12.03.2015 um 17:59 schrieb kp kirchdoerfer:
> ...
>
> > It seems one of us has a misconception of the SF features we can use.
> >
> > It is my understanding that we only have limited access/space to/on the SF
>
Hi KP
Am 12.03.2015 um 17:59 schrieb kp kirchdoerfer:
...
>
> It seems one of us has a misconception of the SF features we can use.
>
> It is my understanding that we only have limited access/space to/on the SF
> shell, and it's mainly used to install a CMS, but not to use it as space to
> ma
Hi Erich;
Am Donnerstag, 12. März 2015, 17:02:29 schrieb Erich Titl:
> Hi KP
>
> Am 12.03.2015 um 16:17 schrieb kp kirchdoerfer:
> > HI Erich;
> >
> > Am Mittwoch, 11. März 2015, 19:27:00 schrieb Erich Titl:
> >> Am 11.03.2015 um 15:54 schrieb kp kirchdoerfer:
> >>> Hi Erich;
> >>
> >> ..
> >>
Hi KP
Am 12.03.2015 um 16:17 schrieb kp kirchdoerfer:
> HI Erich;
>
> Am Mittwoch, 11. März 2015, 19:27:00 schrieb Erich Titl:
>> Am 11.03.2015 um 15:54 schrieb kp kirchdoerfer:
>>> Hi Erich;
>>
>> ..
>>
>>> It is part of the release work to put the files into the git repositories
>>> (package/5_
HI Erich;
Am Mittwoch, 11. März 2015, 19:27:00 schrieb Erich Titl:
> Am 11.03.2015 um 15:54 schrieb kp kirchdoerfer:
> > Hi Erich;
>
> ..
>
> > It is part of the release work to put the files into the git repositories
> > (package/5_1 etc), and it's me who does the work currently.
> >
> > All a
Yves
Am 11.03.2015 um 12:22 schrieb Yves Blusseau:
>
>> Le 11 mars 2015 à 09:39, Erich Titl a écrit :
>>
>> Hi Yves
>>
>> Am 11.03.2015 um 08:56 schrieb Yves Blusseau:
>>>
>> ...
>>
I guess with your tool we somehow duplicate a git repository to another
filepath without actually d
Am 10.03.2015 um 16:32 schrieb kp kirchdoerfer:
> Hi Erich;
>
> Am Dienstag, 10. März 2015, 11:39:21 schrieb Erich Titl:
>> Hi Folks
>>
>> I upgraded my WLAN repeater LEAF box today and found a little problem I
>> would like to discuss.
>>
>> The previous release was ~5.1.1 and pata-acpi was loade
Am 11.03.2015 um 16:04 schrieb kp kirchdoerfer:
> Am Dienstag, 10. März 2015, 21:28:25 schrieb Erich Titl:
>> Hi KP
>>
...
>>
>> I don't know about others, but this is on mine anyway. Rather loose some
>> weight on the module side.
>
> AFAIK it's not that easy to save space/memory with modules, no
Am 11.03.2015 um 15:54 schrieb kp kirchdoerfer:
> Hi Erich;
>
..
>
> It is part of the release work to put the files into the git repositories
> (package/5_1 etc), and it's me who does the work currently.
>
> All archs and packages are rebuild from scratch for a new release, then the
> tarball
Am Dienstag, 10. März 2015, 21:28:25 schrieb Erich Titl:
> Hi KP
>
> Am 10.03.2015 um 19:48 schrieb kp kirchdoerfer:
> ...
>
> > Don't think so, they generate the same links as proposed.
>
> Yes, they _generate_ it. That must be the CMS underneath.
I guess they use
http://git-scm.com/docs/git-
Hi Erich;
Am Mittwoch, 11. März 2015, 14:50:52 schrieb Erich Titl:
> Yves
>
> Am 11.03.2015 um 12:22 schrieb Yves Blusseau:
> >> Le 11 mars 2015 à 09:39, Erich Titl a écrit :
> >>
> >> Hi Yves
> >>
> >> Am 11.03.2015 um 08:56 schrieb Yves Blusseau:
> >>
> >> ...
> >>
> I guess with your
> Le 11 mars 2015 à 09:39, Erich Titl a écrit :
>
> Hi Yves
>
> Am 11.03.2015 um 08:56 schrieb Yves Blusseau:
>>
> ...
>
>>>
>>> I guess with your tool we somehow duplicate a git repository to another
>>> filepath without actually duplicating the data and we should be able to
>>> point to th
Hi Yves
Am 11.03.2015 um 08:56 schrieb Yves Blusseau:
>
...
>>
>> I guess with your tool we somehow duplicate a git repository to another
>> filepath without actually duplicating the data and we should be able to
>> point to this partial tree. Is that it?
>
> With this we can manage all the pac
> Le 9 mars 2015 à 23:00, Erich Titl a écrit :
>
> Hi Yves
>
> please bear with me, I don't get it
>
> Am 09.03.2015 um 13:03 schrieb Yves Blusseau:
>>
> ..>
>> An example using a local repository (it’s the same for a remote repository)
>>
>> # Create the repository
>> cd /tmp
>> git init --
1 - 100 of 735 matches
Mail list logo
