After manually removing and manually installing the previously stated package
name using fdnpkg tool, still was getting the error.
However, upon rebooting and then running fdnpkg checkupdates, now seeing zero
packages needing updating.
So somehow it magically fixed itself.
Looks like I'm good to
I do recall there was at least one package that was on the 1.3 install media
that contained some erroneous files. This was not a problem during
installation. But, it could cause a file collision with other packages. I
forget which package that was.
Also, I have seen that sometimes FDNPKG would
Although I've just successfully updated a clean install FD13 LiveCD
image (with all packages, no sources) using fdnpkg, only one of the many
packages failed. Oddly with the same error first mentioned on this
thread!
nethack, local version 3.4.3a updating to 3.6.7
again, only stdout or a prompt st
Just installed freedos using the typical recommended FD13-livecd media
image within qemu, and no problems with fdnpkg echoing "removing..." and
then "installing ..." updates.
Since I had no prior knowledge of fdnpkg stdout, I did not even notice
the missing "removing ..." stdout.
I do not think I
> On Aug 31, 2024, at 11:54 PM, Roger via Freedos-user
> wrote:
> [..]
> Yikies that was a long typed-up explanation post!
Yup, LOL.
Long posts are a great way to avoid playing “20 questions”. :-)
>
> However, read threw it and as soon as I realized fdnpkg should have been
> removing packag
> On Sat, Aug 31, 2024 at 11:23:28PM -0400, Jerome Shidel via Freedos-user
> wrote:
>
>
>> On Aug 31, 2024, at 9:11 PM, Roger via Freedos-user
>> wrote:
>>
>> Using FreeDOS 13, first installed within Qemu (host Linux) using FreeDOS
>> Full USB image, and getting the following error with fdnpkg:
> On Aug 31, 2024, at 9:11 PM, Roger via Freedos-user
> wrote:
>
> Using FreeDOS 13, first installed within Qemu (host Linux) using FreeDOS
> Full USB image, and getting the following error with fdnpkg:
>
> c:\ fdnpkg update
>
> "Error: Package contains a file that already exists locally:"
Using FreeDOS 13, first installed within Qemu (host Linux) using FreeDOS
Full USB image, and getting the following error with fdnpkg:
c:\ fdnpkg update
"Error: Package contains a file that already exists locally:"
If I'm not mistaken, fdnpkg will not automatically upgrade already
installed pac
On Tue, Jun 4, 2024 at 9:53 PM Brandon Taylor via Freedos-user
wrote:
>
> Well, a pox on me for thinking I could fix something when I clearly
> have no idea what I'm doing. I guess there was a reason why the FreeDOS
> developers disabled "physical hardware networking" even though I was
> trying to
uesday, June 4, 2024 7:57 PM
To: Discussion and general questions about FreeDOS.
Cc: Jerome Shidel
Subject: Re: [Freedos-user] "fdnpkg update" not working
On Jun 4, 2024, at 7:33 PM, Brandon Taylor via Freedos-user
wrote:
I've tried several times lately to run fd
> On Jun 4, 2024, at 7:33 PM, Brandon Taylor via Freedos-user
> wrote:
>
> I've tried several times lately to run fdnpkg update, but the command hangs
> repeatedly at Loading
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/base...
> ` and no progress is ever
I've tried several times lately to run fdnpkg update, but the command hangs
repeatedly at Loading
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/base...
` and no progress is ever made. I've tried pinging www.ibiblio.org and
discovered that it's up and running. Th
On 9/9/22 19:55, Paul Dufresne wrote:
I am not sure... but I would guess fdimples... use the command line
fdnpkg:
http://fdnpkg.sourceforge.net/
I think when launched without parameters, it give help... or then with
/? ... I don't clearly remember.The file format used by packages is
described
I have a Linux based gateway, Debian Buster based. It occurs to me that I could
run an ftp or http server to serve out freedos locally.
How would I point fdnpkg to the local repository? How would I mirror ibiblio
without putting too much load on it?
__
OK, Mateusz, thanks for clarifying.
On 2/26/2016 11:49 AM, Mateusz Viste wrote:
> Hi,
>
> IIRC, FreeDOS 1.1 is broken by default when it comes to package
> management. Hopefully v1.2 will work better.
>
> As for now, you'd have to install packages via FDNPKG first, and only
> then these packages w
Hi,
IIRC, FreeDOS 1.1 is broken by default when it comes to package
management. Hopefully v1.2 will work better.
As for now, you'd have to install packages via FDNPKG first, and only
then these packages will be detected and handled properly.
Example: FDNPKG INSTALL MEM
To answer your second qu
Perhaps FDNPKG is more of a future-proofing tool, but after installing
it on default FD 1.1 (with a few other programs installed outside C:\DOS
e.g. C:\ARACHNE, C:\DILLODOS, C:\LINKS and 1-2 more), I ran FDNPKG
CHECKUPDATES and it found 0 updates to install.
Is this expected -- no updates for t
Hi Don,
> 1) BIOS Set in IDE emulation - NO issues with FDNPKG.
> 2) BIOS Set in Native SATA mode with AHCI.SYS, FDNPKG is prevented from
> extracting the executable files. Perhaps a security feature of this PC
No. AHCI / SATA is just the newer way of talking to various drives
compared to IDE.
Hi Mateusz,
Just wanted to give and update - Your FDNPKG is not the issue. After
checking every aspect of the installation process, changing my CDROM drive
and changing BIOS settings, I discovered the following about my HP Elite
8000 Desktop PC.
1) BIOS Set in IDE emulation - NO issues with FDNP
Okay, I'm not sure I understand the wholeness of your situation, but is
it right to sum it up like this? "you had troubles because of using a
severly outdated FDNPKG v0.96 that was embedded inside the boot.img
portion of all_cd.iso" ?
If that's correct, then the problem should be gone by now, s
I just boot the latest all_cd.iso and the fdnpkg version on it is 0.96
On Wed, Nov 25, 2015 at 3:48 PM, Don Flowers wrote:
> Hey Mateusz,
> I usually start my clean install from the all_cd.iso with FDNPKG install
> kernel, but since you announced the update to FDNPKG, I tried to install
> FDNPKG
Hey Mateusz,
I usually start my clean install from the all_cd.iso with FDNPKG install
kernel, but since you announced the update to FDNPKG, I tried to install
FDNPKG first. After loading the db to temp it begins the install but then
produces several (-15) errors in the DOC, NLS and BIN directory en
Thanks for the more detailed report. Can you confirm please that you get
all the "-15" errors using FNDPKG v0.99.3, and not any earlier version?
To know the exact version you are using, simply run FDNPKG without any
arguments. It will print its version somewhere at the top of the screen.
-15 is
I am getting a (-15) error on almost every package in the NLS
extraction and the actual binaries. I eventually extracted the
"boot.img" and copied the new fdnpkg files to it and the extracted
the "all_cd" files to a directory on my hard drive and adjusted the
FDNPKG.CFG file. It works fine this wa
On 25/11/2015 02:05, Don Flowers wrote:
> Been having trouble - did you update the boot.img my fdnpkg is all out
> of whack.
That's unlikely. I included more than enough of whack inside FDNPKG so
it never runs out of it. Surely the problem must be different.
Mateusz
> On Tue, Nov 24, 2015 at
Been having trouble - did you update the boot.img my fdnpkg is all out of
whack.
On Tue, Nov 24, 2015 at 11:44 AM, Mateusz Viste wrote:
> On 24/11/2015 16:32, Dale E Sterner wrote:
> > Is there an Ibiblio link?
>
> As usual, yes :)
>
>
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/di
On 24/11/2015 16:32, Dale E Sterner wrote:
> Is there an Ibiblio link?
As usual, yes :)
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/util/fdnpkg.zip
Also updatable from itself, ie: FDNPKG UPDATE FDNPKG
Mateusz
> On Mon, 23 Nov 2015 18:40:41 +0100 Mateusz Vi
Is there an Ibiblio link?
DS
On Mon, 23 Nov 2015 18:40:41 +0100 Mateusz Viste
writes:
> Hi all,
>
> I released FDNPKG v0.99.3 today. This is a purely bugfix release,
> I'd
> highly recommend upgrading any older version.
>
> FDNPKG v0.99.3 [23 Nov 2015]
> - [fix] files zipped uncompressed a
Hi all,
I released FDNPKG v0.99.3 today. This is a purely bugfix release, I'd
highly recommend upgrading any older version.
FDNPKG v0.99.3 [23 Nov 2015]
- [fix] files zipped uncompressed are extracted correctly (v0.99.2 regress),
- [fix] closing file descriptors on install failure (no risk of fs
I am back in Windows for the moment. I was trying to install assign ( I
overlooked it in my list) the syntax I used is FDNPKG INSTALL ASSIGN, then
it goes to the ibiblio BASE repo and stops, it previously gave the failed
to download repo error but then gave notice of an update (curious?) but
will n
On 15/11/2015 14:30, Don Flowers wrote:
> I have been reinstalling FreeDOS and have my NIC card setup,
> I have a working connection (am writing this from my DILLODOS browser)
> but cannot get a download from FDNPKG. I can download to my HD and then
> install
> but FDNPKG is stalling.
Are you us
I have been reinstalling FreeDOS and have my NIC card setup,
I have a working connection (am writing this from my DILLODOS browser)
but cannot get a download from FDNPKG. I can download to my HD and then install
but FDNPKG is stalling.
And by the way, if anyone doesn't know yet, Matesuz changed th
Hi all,
I worked on this a few hours last weekend and I released FDNPKG v0.99.2
right now.
http://fdnpkg.sourceforge.net/
Changelog:
- [new] added the FDINST tool: a very light package installer for 8086+,
- [mnt] adapted parts of the FDNPKG code for compatibility with FDINST,
- [mnt] FDN
oh shizam!! i will start when i can~
--
View this message in context:
http://freedos.10956.n7.nabble.com/FDNPKG-v0-99-tp23151p23186.html
Sent from the FreeDOS - User mailing list archive at Nabble.com.
--
_
On 04/09/2015 12:32, sparky4 wrote:
> my XT is overkill and it has EMS so yeah i when you stabilize it i will
> defiantly port it to 16 bit
>
>
> is it a good time to port it? i been working on memory management software
Sure it is. It won't get any updates in nearest months, so, by all
>> I want to make a 16 bit version of this program...
>You are most certainly welcome to do so - that's what open-source is all
>about.
>I can't help but wonder though - is there any practical need behind such
>work?
IBM XT
I don't really see what this would improve. Sure, it would make
>FD
On 9/2/2015 9:12 AM, dmccunney wrote:
> On Wed, Sep 2, 2015 at 1:37 AM, Mateusz Viste wrote:
>> On 02/09/2015 04:43, Ralf Quint wrote:
>>> You are making a totally wrong assumptionn that 16bit software means you
>>> are limited to 640KB of memory.
>> Absolutely not - my assumption is that running
Hi Bob, Dennis,
Good point on these hardware EMS cards, it is indeed a way of providing
additional memory irrespectively of the CPU model. I never had one of
these, but I did hear about them. I stand corrected on that one! :)
cheers,
Mateusz
On 02/09/2015 18:12, dmccunney wrote:
> On Wed, Se
On Wed, Sep 2, 2015 at 1:37 AM, Mateusz Viste wrote:
> On 02/09/2015 04:43, Ralf Quint wrote:
>> You are making a totally wrong assumptionn that 16bit software means you
>> are limited to 640KB of memory.
>
> Absolutely not - my assumption is that running on 8086/80186 means I am
> limited to 640K
On Wed, 9/2/15, Mateusz Viste wrote:
Subject: Re: [Freedos-user] FDNPKG v0.99
To: freedos-user@lists.sourceforge.net
Date: Wednesday, September 2, 2015, 1:37 AM
On 02/09/2015 04:43, Ralf
Quint wrote:
> You are making a totally
wr
On 02/09/2015 04:43, Ralf Quint wrote:
> You are making a totally wrong assumptionn that 16bit software means you
> are limited to 640KB of memory.
Absolutely not - my assumption is that running on 8086/80186 means I am
limited to 640KB (or let's say < 1M). Hence for software with higher
memory
On 01/09/2015 19:47, Rugxulo wrote:
> And I also announced it for News (but it hasn't shown up on front page yet).
That's cool, thanks!
> P.S. I knew that LZMA was slower for older-class machines, but I
> traditionally just unpacked/repacked
But keep in mind that you are a "special case" ;)
What
On 9/1/2015 10:02 AM, Mateusz Viste wrote:
> Now, of course I could implement some indexing mechanisms on top of
> that, and end up designing a specialized 16 bit database engine that
> would fit in the 640K limit of memory...
You are making a totally wrong assumptionn that 16bit software means you
Hello Mateusz!
Em Mon, 31 Aug 2015 19:29:00 +0200
Mateusz Viste escreveu:
> Today I released a new version of FDNPKG.
Congratulations on this new release!
--
,= ,-_-. =. Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) http://oitofelix.freeshell.org/
`-'(. .)`-' irc://c
A 16 bit database engine is a little bit of a stretch, is it not? I don't
think that keeping some data in memory and indexing to records on disk
qualifies as a database engine. I agree that it is more work, or in this
case rework. And I agree that when time is limited, projects like this
become
Hi,
On Tue, Sep 1, 2015 at 4:26 AM, Mateusz Viste wrote:
> On 31/08/2015 22:46, Dale E Sterner wrote:
>> Is there an Ibiblio link for this?
>
> Sure, here it is:
>
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/util/fdnpkg.zip
It may be redundant, but I also mi
Hi Michael, nice to hear from you!
Of course disk-based structures are easy to implement - FDNPKG already
uses them extensively for storage. The key word here is speed - keeping
packages metadata in RAM is fast. Parsing and searching through on-disk
data structures is at least a magnitude slowe
The current memory requirement is a function of your design, which I think
could be improved. Disk based data structures are not that difficult to
implement.
I have a PCjr with a 20GB Maxtor drive on it, of which 600MB is in use.
There are lots of 8086 and 80286 class machines with larger than or
On 31/08/2015 22:46, Dale E Sterner wrote:
> Is there an Ibiblio link for this?
>
> DS
Sure, here it is:
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.1/repos/util/fdnpkg.zip
Mateusz
--
__
Hi Sparky,
On 31/08/2015 19:38, sparky4 wrote:
> I want to make a 16 bit version of this program...
You are most certainly welcome to do so - that's what open-source is all
about.
I can't help but wonder though - is there any practical need behind such
work? I don't really see what this w
Is there an Ibiblio link for this?
DS
On Mon, 31 Aug 2015 19:29:00 +0200 Mateusz Viste
writes:
> Hello all,
>
> Today I released a new version of FDNPKG. Nothing major here, just a
> few
> details that were a little annoying on the long run. See the
> changelog
> below.
>
> FDNPKG v0.99
I want to make a 16 bit version of this program...
--
View this message in context:
http://freedos.10956.n7.nabble.com/FDNPKG-v0-99-tp23151p23152.html
Sent from the FreeDOS - User mailing list archive at Nabble.com.
-
Hello all,
Today I released a new version of FDNPKG. Nothing major here, just a few
details that were a little annoying on the long run. See the changelog
below.
FDNPKG v0.99 [31 Aug 2015]
- [new] support for "link" files to include third-party apps into %PATH%,
- [fix] compiled FDNPKG with
On 12/06/2015 16:56, John Hupp wrote:
> I agree that there is no perfect solution. But the same is true on
> other platforms. Look at common Linux distributions: repositories of
> vetted apps, hosted on servers that get special attention, with a single
> update channel that keeps everything up to
On 6/12/2015 9:07 AM, Rugxulo wrote:
> It's just that there is no perfect solution, sadly.
I agree that there is no perfect solution. But the same is true on
other platforms. Look at common Linux distributions: repositories of
vetted apps, hosted on servers that get special attention, with a s
Hi,
BTW, thanks for responding to this.
On Fri, Jun 12, 2015 at 12:59 AM, Mateusz Viste wrote:
>
> Hi, I'm temporarily hijacking this thread for FDNPKG's agenda :)
You're of course welcome to do so.
> On 11/06/2015 22:55, Rugxulo wrote:
>> FDNPKG is a great idea, but we need more package(r)s.
Hi, I'm temporarily hijacking this thread for FDNPKG's agenda :)
On 11/06/2015 22:55, Rugxulo wrote:
> FDNPKG is a great idea, but we need more package(r)s. Well, I did try
> to install something from there yesterday (under QEMU to RAM disk),
> but it seemed to expect "c:\games" hardcoded. (Maybe
On 8/14/2014 3:52 AM, Mateusz Viste wrote:
> Hi Ulrich,
>
> Thanks for your feedback!
>
> On 08/14/2014 12:05 AM, Ulrich wrote:
>> FDNPKG installs the MTCP programs into C:\FDOS\MTCP instead of C:\FDOS\BIN.
> This is not really about FDNPKG, but more about "how packages are
> structured". Indeed, I
On 08/15/2014 03:01 PM, Tom Ehlert wrote:
> it should have been
>c:\USR\BIN\ZIP %0 %1 %2 %3 %4 %5 %6 %7 %8 %9
Okay, I understand now, you were simply trying to be able to use 10
parameters instead of 9. I didn't ever think about this limitation,
since 9 parameters were always enough for
Hi Mateusz,
> On 08/15/2014 12:29 PM, Tom Ehlert wrote:
>> a better way to achieve the same effect would be a directory on the
>> PATH with batches that redirect to the proper location.
>>
>> ZIP.BAT
>> shift
>> c:\USR\BIN\ZIP %1 %2 %3 %4 %5 %6 %7 %8 %9
> Exactly what I was saying, yes.
Hi Tom,
On 08/15/2014 12:29 PM, Tom Ehlert wrote:
> a better way to achieve the same effect would be a directory on the
> PATH with batches that redirect to the proper location.
>
> ZIP.BAT
> shift
> c:\USR\BIN\ZIP %1 %2 %3 %4 %5 %6 %7 %8 %9
Exactly what I was saying, yes. For now, that's
>> 'Which means "Accept what the package manager does by default." I
>> mostly concur, but an advanced user might have reasons for wanting
>> things elsewhere. It's nice it the package manager gives them an
>> option to do so and specify where, but if it needs AUTOEXEC.BAT
>> modified for things
>> This is not really about FDNPKG, but more about "how packages are
>> structured". Indeed, I tend to avoid putting to much stuff into
>> %FREEDOS%\BIN, and only put there stuff that is supposed to be part of
>> the FreeDOS "core" (ie BASE, that is similar functionality than what
>> MSDOS was p
On 08/15/2014 01:24 AM, Ulrich wrote:
> Yes I think this a good idea. About the PATH: What about creating an external
> batchfile like C:\PKGS.BAT, that is automatically called by AUTOEXEC.BAT?
> FDNPKG could update the PATH statement according to each package. The
> content, for example:
>
> PA
On Thu, Aug 14, 2014 at 5:30 PM, dmccunney wrote:
[SNIP]
>
> 'Which means "Accept what the package manager does by default." I
> mostly concur, but an advanced user might have reasons for wanting
> things elsewhere. It's nice it the package manager gives them an
> option to do so and specify whe
On Thu, Aug 14, 2014 at 7:24 PM, Ulrich wrote:
> Am 14.08.2014 um 12:52 schrieb Mateusz Viste :
>
>> Now the question is where to put any 3rd party apps that are still
>> supposed to be callable from anywhere in the directories tree? One
>> option could be to create another "BIN-like" directory fo
On Thu, Aug 14, 2014 at 5:33 PM, Ulrich wrote:
> Am 14.08.2014 um 17:51 schrieb dmccunney :
>> On Thu, Aug 14, 2014 at 10:54 AM, Mateusz Viste wrote:
>>
>>> But the question now is different (I took the liberty to change the
>>> subject of this message accordingly): where would you put applicatio
Am 14.08.2014 um 12:52 schrieb Mateusz Viste :
> Thanks for your feedback!
Thanks for yours :-)
>
> On 08/14/2014 12:05 AM, Ulrich wrote:
>> FDNPKG installs the MTCP programs into C:\FDOS\MTCP instead of C:\FDOS\BIN.
>
> This is not really about FDNPKG, but more about "how packages are
> str
That's good information. I don't think I had seen that before.
On Thu, Aug 14, 2014 at 8:52 AM, Mateusz Viste wrote:
> oops, forgot to paste the link.. The "packaging" documentation link was
> meant to be this:
>
>http://www.freedos.org/wiki/index.php/Package
>
> Mateusz
>
>
>
> On 08/14/201
Am 14.08.2014 um 17:51 schrieb dmccunney :
> On Thu, Aug 14, 2014 at 10:54 AM, Mateusz Viste wrote:
>
>> But the question now is different (I took the liberty to change the
>> subject of this message accordingly): where would you put applications
>> that need to be reachable from %PATH% ?
>
>
oops, forgot to paste the link.. The "packaging" documentation link was
meant to be this:
http://www.freedos.org/wiki/index.php/Package
Mateusz
On 08/14/2014 05:44 PM, Mateusz Viste wrote:
> Hi,
>
> I am unsure whether you are thinking about documentation for packaging
> (ie. creating pack
On Thu, Aug 14, 2014 at 10:54 AM, Mateusz Viste wrote:
> But the question now is different (I took the liberty to change the
> subject of this message accordingly): where would you put applications
> that need to be reachable from %PATH% ?
>From a system viewpoint, it doesn't matter, as long as
Hi,
I am unsure whether you are thinking about documentation for packaging
(ie. creating packages) or documentation for FDNPKG... These are two
different things.
If you are looking for pointers about how to create package, you might
find some good information to start here:
If, on the other h
On 08/14/2014 04:36 PM, Louis Santillan wrote:
> One school of thought is the NextSTEP style folders [0]. So you would
> have functionally named folders /System, /User, /Programs, /Games,
> etc.
This is actually how it already works. FDNPKG uses 'categories' of
software, and puts software there
On Thu, Aug 14, 2014 at 3:52 AM, Mateusz Viste wrote:
[SNIP]
> This is not really about FDNPKG, but more about "how packages are
> structured". Indeed, I tend to avoid putting to much stuff into
> %FREEDOS%\BIN, and only put there stuff that is supposed to be part of
> the FreeDOS "core" (ie BASE,
I know Masteusz has put in a lot of work into FDNPKG. One thing I
really appreciated when I transitioned to Linux almost 20 years ago
was how good the documentation was. Especially when I used Crux Linux
and their ports package system [0]. How to make a package, how to use
the various commands,
Hi Ulrich,
Thanks for your feedback!
On 08/14/2014 12:05 AM, Ulrich wrote:
> FDNPKG installs the MTCP programs into C:\FDOS\MTCP instead of C:\FDOS\BIN.
This is not really about FDNPKG, but more about "how packages are
structured". Indeed, I tend to avoid putting to much stuff into
%FREEDOS%\B
> Yes, this would be cool indeed. Any volunteers? :)
> In fact, we almost have such 1.11 distro: all_cd is pretty much working,
> only requires a 'smart' installer (like the one we had in 1.0 or 1.1),
> and maybe a downgrade of FDISK (if confirmed that the version is causing
> the vbox incompati
Hi Mateusz,
obviously FDNPKG installs a few things differently than the FreeDOS 1.1 CD. So
it's hard to say what is a bug, what is a feature.
FDNPKG installs the MTCP programs into C:\FDOS\MTCP instead of C:\FDOS\BIN. So
mTCP will not work with an AUTOEXEC.BAT from 1.1, the user needs to add
C
On 08/13/2014 12:07 AM, Rugxulo wrote:
> Are you saying this is a bug in FD FDISK or VBox? Because as long as
> it's not FD FDISK getting inherently confused, you could maybe do a
> simple workaround: copy it to and run from RAM disk. Would that avoid
> the issue? Just curious.
I have no idea, tru
On 08/13/2014 01:46 AM, Ulrich wrote:
> Unfortunately it isn't so easy. I just tried to remove/reinstall UIDE in
> FreeDOS 1.1. The C:\FDOS\PACKAGES\UIDEX.LST file in FD1.1 doesn't include
> xmgr.sys and rdisk.com. So when uninstalling UIDEX these are not removed. And
> when reinstalling UIDE, F
Am 12.08.2014 um 20:23 schrieb Mateusz Viste :
> On 08/11/2014 09:07 PM, Ulrich wrote:
>> So doing a FDNPKG update from time to time could make FreeDOS a kind of a
>> rolling release (or at least create a "testing" branch).
>
> I'm glad you think so, since that's exactly the motivation that led
Hi again,
On Aug 11, 2014 4:49 AM, "Mateusz Viste" wrote:
>
> About FDISK incompatibility: I am getting an error message "Error
> Reading Hard Disk: Function number of drive not permitted". Is it what
> you end up with, too? If so, then it appears to be a problem only if you
> run FDISK from the
On 08/11/2014 09:07 PM, Ulrich wrote:
> So doing a FDNPKG update from time to time could make FreeDOS a kind of a
> rolling release (or at least create a "testing" branch).
I'm glad you think so, since that's exactly the motivation that led me
to creating FDNPKG in the first place :)
> - Users
Mateusz, thanks a lot for looking into the problem!
I think FDNPKG could be really useful. FreeDOS 1.1 is two and a half years old
and at least some programs are under active development. So doing a FDNPKG
update from time to time could make FreeDOS a kind of a rolling release (or at
least cre
Hi,
On Aug 11, 2014 9:44 AM, "Mateusz Viste" wrote:
>
> But have you booted from a "floppy" (1.4M image), or from an "emulated
> floppy" (as a CD) ?
Just floppy, no CD anything.
> The problem seems to appear when one boots from a CD with floppy
> emulation, and fdisk being ran from the said "em
But have you booted from a "floppy" (1.4M image), or from an "emulated
floppy" (as a CD) ?
The problem seems to appear when one boots from a CD with floppy
emulation, and fdisk being ran from the said "emulated" floppy...
cheers,
Mateusz
On 08/11/2014 04:34 PM, Rugxulo wrote:
> Hi,
>
> On Mo
Hi,
On Mon, Aug 11, 2014 at 4:49 AM, Mateusz Viste wrote:
>
> About FDISK incompatibility: I am getting an error message "Error
> Reading Hard Disk: Function number of drive not permitted". Is it what
> you end up with, too? If so, then it appears to be a problem only if you
> run FDISK from the
Hi Rugxulo,
Thanks for your offer, but I managed to reproduce the various problems
easily on a small vbox FreeDOS install, so I should have enough to
investigate :)
And yes, the vbox guest environment is quite confusing indeed... hard to
sort out "real" bugs out of buggy vbox behavior (but at
Hi again,
I looked into the issue, by installing a fresh FreeDOS 1.1 inside a
vbox, and booting all_cd on top of it. Now:
FDNPKG freezing: debugging this really scares me. I wanted to check if
there's some memory leak maybe, and typed "MEM" in the vbox shell where
I launched FreeDOS... The ans
Hi,
On Sun, Aug 10, 2014 at 8:57 PM, Mateusz Viste wrote:
>
> About fdnpkg freezing: how could I reproduce this problem exactly? Should it
> be enough to just install
> freedos 1.1 on virtualbox, without any special configuration, and boot the
> latest version of all_cd.iso
> on top of it? What
Hi Ulrich,
Thank you for your report.
This sounds unfortunate :)
It seems you have three different problems.
About fdisk: could you tell more about the problem? What version of fdisk works
correctly for you?
About missing versions: could you please locate the *.lsm file of one of the
"unknow
I am a bit stuck with FDNPKG.
If I use:
fdnpkg listlocal
on a fresh install of FreeDOS 1.1, I get a list of all installed packages with
"(unknown version)"
behind their names.
If I do:
fdnpkg update
I get the message: "79 package(s) checked, 0 package(s) updated, 0 package(s)
failed".
D
Mateusz Viste schreef op 13-10-2013 23:56:
> Of course, if you have plenty of disk space, you might want to copy
> these repositories to your hard disk, and make the repositories pointing
> there.
I think Mark ment pointing to the ISO file, but I guess no native ISO
support is implemented, so a
Hi,
You only have to comment out the default (online) repositories from the
FDNPKG.CFG file, and declare the offline repos instead. For example, if
your CDROM drive is "E:", then you'd have to add such directives:
REPO E:\ARCHIVER
REPO E:\BASE
REPO E:\DEVEL
REPO E:\EMULATOR
REPO E:\GA
how do you make fdnpkg use all_cd.iso (the offline repository)?
eufdp...@yahoo.com
eufdp...@yahoo.com
eufdp...@yahoo.com
eufdp...@yahoo.com
eufdp...@yahoo.com
---
Mateusz Viste schreef op 12-10-2013 21:52:
> argument). So for such need, a full-blown script (like the one you did)
> will probably be inevitable anyway...
I'm lazy, so prefer INSTALL KERNEL instead of remembering to type FDNPKG
INSTALL KERNEL. Even for a single package thus :)
Something like
That's true - IIRC, there are a few packages in BASE that lack sources
(these are the few packages that I dumped long ago from the FreeDOS 1.0 CD).
I will look into this matter when I will have a moment. Unfortunately it
won't be soon, but I'll try to straighten this issue by the end of the year.
Mateusz Viste schreef op 12-10-2013 21:28:
> This could be an interesting feature. It doesn't make as much sense as
> in a linux distro, because there is no dependencies between FreeDOS
> packages, but it could be nice anyway to be able to install a few
> packages in one command (especially when t
Hello Bernd,
On 10/12/2013 05:01 PM, Bernd Blaauw wrote:
> Does the program have to write all the "mkdir" lines all the time when
> installing a package? I'd expect only the non-existing ones to be listed.
Indeed, this is useless. It never bothered me, but you are right - it's
useless, and it ta
1 - 100 of 140 matches
Mail list logo
