ively unannounced change, pkgin on a -9 system without either
> > security/mozilla-rootcerts-openssl installed or /etc/openssl will now
> > just fail, including any attempt to install mozilla-rootcerts-openssl
> > to resolve.
>
> Only if the binary pkgs repository URL was us
On Tue, Apr 23, 2024 at 03:17:14PM +0100, David Brownlee wrote:
> However, while better checking of trust anchors is a better end state
> - assuming I am understanding the situation correctly: in an
> effectively unannounced change, pkgin on a -9 system without either
> security/mozil
t;
> > For netbsd-10 /etc/openssl is populated by the OS, but doing that
> > would be a breaking change on netbsd-9, however it may be that the
> > latest pkgin is enforcing SSL certificates by default on netbsd-9
> > which would be... unhelpful in this case
>
> I don't s
David Brownlee wrote:
> On Tue, 23 Apr 2024 at 02:27, beaker wrote:
> > I have a 9.3/i386 VM on which I recently ran
> > $ sudo pkgin update ; sudo pkgin upgrade ;sudo pkgin autoremove
> >
> > which worked but subsequent attempts to use pkgin repo
a breaking change on netbsd-9, however it may be that the
> latest pkgin is enforcing SSL certificates by default on netbsd-9
> which would be... unhelpful in this case
I don't see it as uhelpful -- doctrine has always been that the sysadmin
should choose which CAs to configure as trust ancho
On Tue, 23 Apr 2024 at 02:27, beaker wrote:
>
> Hello,
>
> I have a 9.3/i386 VM on which I recently ran
> $ sudo pkgin update ; sudo pkgin upgrade ;sudo pkgin autoremove
>
> which worked but subsequent attempts to use pkgin report the following error:
>
> --
>
Hello,
I have a 9.3/i386 VM on which I recently ran
$ sudo pkgin update ; sudo pkgin upgrade ;sudo pkgin autoremove
which worked but subsequent attempts to use pkgin report the following error:
--
$ sudo pkgin update
cleaning database from
http://cdn.netbsd.org
On Mon, Mar 25, 2024 at 05:40:44PM +0100, Enrico Weigelt, metux IT consult
wrote:
> A simple `pkg_add pkgin` runs for over a quarter hour, and pkgin install
> call took another half an hour, until it recognized a wrong parameter:
echo 'ip6addrctl=YES' >> /etc/rc.conf
echo 'ip6ad
On 25.03.24 20:40, Justin Parrott wrote:
This is not an issue with the local system.
maybe a combination of both the guest and the host (maybe host offering
IPv6 address but no actual routing).
But fortunately fixed it with some tweaks now :)
--mtx
--
---
Hinweis: unverschlüsselte E-Mails
? I bet it's the network, not
> > specifically pkgin.
>
> meanwhile turned out it seems to be ipv6 related (somebody in irc gave
> me a hint on that). calling pkgin with -4 makes it *a lot* faster
> (pkg_add doesnt seem to have that switch).
>
> Also explicitly dropping ipv6 defau
Hi @all,
Your timing is similar to what I had in some early tests. That said,
have you measured what is the slow part? I bet it's the network, not
specifically pkgin.
meanwhile turned out it seems to be ipv6 related (somebody in irc gave
me a hint on that). calling pkgin with -4 makes
lays in package
> > installations.
> >
> > A simple `pkg_add pkgin` runs for over a quarter hour, and pkgin install
> > call took another half an hour, until it recognized a wrong parameter:
>
> I have experience with a similar setup, from setting up the NetBSD CI
> image
Am 25.03.24 um 17:40 schrieb Enrico Weigelt, metux IT consult:
I'm currently in process of setting up an CI build process for Xorg
on NetBSD (inside Qemu), but encountering really long delays in package
installations.
A simple `pkg_add pkgin` runs for over a quarter hour, and pkgin install
call
delays in package
> installations.
>
> A simple `pkg_add pkgin` runs for over a quarter hour, and pkgin install
> call took another half an hour, until it recognized a wrong parameter:
>
> https://gitlab.freedesktop.org/metux/ci-templates/-/jobs/56754224
>
> Am
Hello folks,
I'm currently in process of setting up an CI build process for Xorg
on NetBSD (inside Qemu), but encountering really long delays in package
installations.
A simple `pkg_add pkgin` runs for over a quarter hour, and pkgin install
call took another half an hour, until it recognized
pin wrote:
> Apparently nobody has answered your question in the mailing-list.
>
> > Is there a way to hold back packages from pkgin similar to 'apt-mark '
> > ?
>
> The short answer is no, there isn't.
>
> > The pkg in question is ../wm/dwm which I customize
Is there a way to hold back packages from pkgin similar to 'apt-mark ' ?
Didn't see anything in the manpage and when I try to use 'pkgin import
pkg_list.txt'
where the not-to-be-updated pkg has been removed pkgin STILL tries to update the
pkg. The pkg in question is ../wm/dwm which I customize
some time back I sent an email to the
author about such docs to check if I was able to upgrade it but never got an
answer.Best regards,r0ller Eredeti levél Feladó: nia
Dátum: 2022 november 15 08:23:58Tárgy: Re: the vine package in
pkgin is wine64?Címzett: r0ller On Fri, Nov 11
On Fri, Nov 11, 2022 at 10:41:15PM +, r0ller wrote:
> Running 32 bit win stuff does not work with that.
I'm running 32-bit only WINE programs in a 32-bit NetBSD chroot
(using sandboxctl). It works okay:
https://washbear.neocities.org/wine-sandbox.html
Got the answer: that package in pkgin is just the wine64 package and not the
WoW64. So running 32 bit win stuff does not work with that. That's a pity as
the WoW64 (called wine64 in pkgsrc/wip) is only the 4.4 version.
Eredeti levél Feladó: r0ller Dátum: 2022 november
11 11:14
Hi All,I've just discovered that now there's a wine package in pkgin :) As I'm
on amd64 it must be the wine64 which previously resided in pkgsrc/wip only,
right?Therefore, I tried to enable the USER_LDT option and disable SVS in a
custom kernel config but I couldn't build it (see my previous
pkgsrc.org/pkgdb-change/
>
> oh, I fear I have split. But, permit me, this is bad: I have a
> super-fresh install; I used pkg_add to instappl pkgin and nothing more!
> So what went wrong?
>
> localhost$ /usr/sbin/pkg_add -V
> 20201218
> localhost$ /usr/pkg/sbin/pkg_add -V
Hi.
replying to myself
Riccardo Mottola wrote:
> I fear this "dirs" come from this step:
>
> In /var/db/pkg.refcount
> tar cf - . | (cd /usr/pkg/pkgdb && tar xfv -)
>
> since pkg.refcount contained "dirs"
>
> ls /usr/pkg/pkgdb/dirs/
> etc usr var
>
> is it out of place?
the proper command
me, this is bad: I have a
super-fresh install; I used pkg_add to instappl pkgin and nothing more!
So what went wrong?
localhost$ /usr/sbin/pkg_add -V
20201218
localhost$ /usr/pkg/sbin/pkg_add -V
20210410
The versions are exactly the two which are cited as "good"!
I will follow th
Hi Greg
Greg Troxel wrote:
> I don't either, but my advice is to *always* set PKG_DBDIR explicitly in
> btoh mk.conf and pkg_install.conf. Check if you have the split brain
> situation, or something else:
>
> https://pkgsrc.org/pkgdb-change/
I tried to perform the split migration according to
Riccardo Mottola writes:
> I installed using pkg_add pkgin. Then I installed a myriad of packages
> using "pkgin install", so to be quick and not compile stuff myself.
>
> I wonder however that "pkg_info" then does not list these packages, why?
I don't either,
Hello,
I just installed a fresh 9.2 on an HP ProBook amd64. It went quite
smooth! (FreeBSD didn't even boot with SATA in AHCI mode...) Yay.
Wireless worked out of the box, X11 too (well Intel graphics is a good
bet there.)
I installed using pkg_add pkgin. Then I installed a myriad
On 12 Jul 2021, Greg Troxel wrote:
> Benny Siegert writes:
(snip)
>> It sounds like pkgin and your pkg_* tools disagree on what the correct
>> PKG_DBDIR is. Probably one of them is using /var/db/pkg and the other
>> /usr/pkg/pkgdb. Check if you have both, set the location
Hi Greg,
Thanks for the suggestion. I'm still doing the backup but will come back with
the outcome.
Best regards,
r0ller
Eredeti levél
Feladó: Greg Troxel < g...@lexort.com (Link -> mailto:g...@lexort.com) >
Dátum: 2021 július 9 13:06:24
Tárgy: Re: pkgin does no
Benny Siegert writes:
> On Mon, Jul 12, 2021 at 2:46 AM Mark Carroll wrote:
>> Does anybody have an idea what I messed up on the
>> latter? I first noticed when "pkg_admin audit" was telling me less than
>> I expected on that system.
>
> It sounds lik
On Mon, Jul 12, 2021 at 2:46 AM Mark Carroll wrote:
> Does anybody have an idea what I messed up on the
> latter? I first noticed when "pkg_admin audit" was telling me less than
> I expected on that system.
It sounds like pkgin and your pkg_* tools disagree on what th
I've somehow misconfigured something and can't work out what. On one
NetBSD 9.2 system, if I pkgin install something, then "pkg_info -u"
reports it as installed. On the other, pkg_info doesn't seem to know
anything about what I installed with pkgin, though "pkgin show-keep"
Boot to single user and full fsck. Also make the backups you have been meaning
to get around to right away
Hi Greg,
Thanks for your suggestions! It indeed seems to be corrupted :( I tried
to nuke (rm -rf) the directory
/usr/pkg/pkgdb/p5-Net-SSLeay-1.88nb1 but I got back that the directory
is not empty which is pretty unusual for rm -rf. Now, when I try to list
its contents, three files are
r0ller writes:
> The only error I see in pkg_install-err.log (which is not shown as
> error) which seems to block each pkg install is:
>
> pkg_admin: Cannot read +CONTENTS of package p5-Net-SSLeay-1.88nb1
>
> Does anyone have any hint?
pkg_admin rebuild-tree
pkg_admin check
make sure your
nothing seems to have been upgraded and pkgin does not seem to install
> > anything.
>
> The repositories are identical (9.2 is actually a symlink on the server
> pointing at the 9.0 repo).
>
> Martin
to expand: pkgsrc is developed separately and has a separate release
schedul
On Thu, Jul 08, 2021 at 02:36:17PM +0200, r0ller wrote:
> is quite noticeable when starting firefox. However, after changing
> repositories.conf to point to amd64/9.2/All and upgrading all packages,
> nothing seems to have been upgraded and pkgin does not seem to install
&
,
nothing seems to have been upgraded and pkgin does not seem to install
anything. There are many warnings about the platform difference (built
for 9.0 vs 9.2) but no errors (except one maybe, see later). However,
when e.g. installing firefox-86.0.1 pkgin acts as if it was doing its
job
On Wed, 7 Apr 2021, Dan Cîrnaț wrote:
Telling pkgin: 'pkgin install gdm' led to 59 packages being
"refreshed", and 4 more installed.
Please be aware that those pkgin repos only have packages for
the main pkgsrc tree, excluding pkgsrc-wip. The gdm version
there is 2.x., an old on
On 06/04/2021 22:54, Bob Bernstein wrote:
I am taking a first run at pkgin. It fails trying to get a file from:
https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/9.99.81/All
...which can be found in my /usr/pkg/etc/pkgin/repositories.conf.
I have here:
$ uname -a
NetBSD nebbytwo
On 07.04.21 03:44, Bob Bernstein wrote:
Telling pkgin: 'pkgin install gdm' led to 59 packages being "refreshed",
and 4 more installed.
Please be aware that those pkgin repos only have packages for the main
pkgsrc tree, excluding pkgsrc-wip. The gdm version there is 2.x., an
old one.
Dan
On Wed, 7 Apr 2021, Chavdar Ivanov wrote:
I don't think there are "official" pkgin repos for -current.
However, check https://pkgsrc.joyent.com/install-on-netbsd/ .
What I put in my /usr/pkg/etc/pkgin/reposiories.conf was:
https://pkgsrc.joyent.com/packages/NetBSD/trunk/x86_64/All
On Tue, 6 Apr 2021 at 22:54, Bob Bernstein wrote:
>
> I am taking a first run at pkgin. It fails trying to get a file
> from:
>
> https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/9.99.81/All
>
> ...which can be found in my
> /usr/pkg/etc/pkgin/repositori
I am taking a first run at pkgin. It fails trying to get a file
from:
https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/9.99.81/All
...which can be found in my
/usr/pkg/etc/pkgin/repositories.conf.
I have here:
$ uname -a
NetBSD nebbytwo 9.99.81 NetBSD 9.99.81 (GENERIC) #0: Sat Mar
all based on observation rather than documentation.
>> When running pkgin to upgrade one or more packages, it often says "X
>> packages to refresh, Y packages to upgrade".
> Refresh means the version hasn't changed but the package has been
> rebuilt since you last install
On 17/06/2020 07:39, Lars-Johan Liman wrote:
Hi!
This is all based on observation rather than documentation.
When running pkgin to upgrade one or more packages, it often says "X
packages to refresh, Y packages to upgrade".
Refresh means the version hasn't changed but the packag
Hi!
When running pkgin to upgrade one or more packages, it often says "X
packages to refresh, Y packages to upgrade".
What's the difference between a refresh and an upgrade of a package?
And where is it documented? ;-)
Thanks!
t; but not in amd64. For me the following simple workaround worked:
>
> Thanks for the specific report.
>
> > I modified the repository pointer in
> >
> > /usr/pkg/etc/pkgin/repositories.conf
> >
> > from:
> >
> > http://cdn.netbsd.org/pub/pkgsrc/pack
; I modified the repository pointer in
>
> /usr/pkg/etc/pkgin/repositories.conf
>
> from:
>
> http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/9.0/All
>
> to:
>
> http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/9.0/All
amd64 is the name of the port,
Hi Dima (all)!
I've found that the x86_64 and amd64 directories seem to be out of sync
on cdn.netbsd.org. In short, pkg_summary seems to be updated in x86_64
but not in amd64. For me the following simple workaround worked:
I modified the repository pointer in
/usr/pkg/etc/pkgin
Hi Matthew,
MN> http://cdn.Netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/...
MN> http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/...
MN> yielded different data. Both hostnames resolved to the same IP addresses
MS> I fixed the host header thing when that was pointed out.
NetBSD
> REPOSITORY =
> http://cdn.Netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.2/All
>
>
> Looks like Roland is rather using the 8.0 repo?
>
> I essentially noticed the same problem here, too, after...
>
> - an update on the netbsd-8 branch on May 2nd and
>
FILE_SIZE = 25004
OPSYS = NetBSD
REPOSITORY =
http://cdn.Netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.2/All
Looks like Roland is rather using the 8.0 repo?
I essentially noticed the same problem here, too, after...
- an update on the netbsd-8 branch on
On 15.05.2020 17:22, nottobay wrote:
I keep getting a bunch of errors saying "download error
size does not match pkg_summary" I try just telling it to proceed but
the package still doesn't install. I have already tried forcing a pgkin
update and it didn't fix it, and I'm using the default repo
I had same problems and I've found that CDN directory contents may be
not in sync with pkg_summary. I tried to work it out (thinking
there might be one server not in sync) but had short time and no
success so that time I just switched to legacy source.
How cdn is organized in short? It would be
It is saying no such file or directory for /var/db/cache but /var/db/ at
454982 out of 38176044 so space isn't the problem,
On Fri, May 15, 2020, 11:38 wrote:
> Hello,
>
> On Fri, May 15, 2020 at 11:22:59AM -0400, nottobay wrote:
> >I keep getting a bunch of errors saying "download error
>
Hello,
On Fri, May 15, 2020 at 11:22:59AM -0400, nottobay wrote:
>I keep getting a bunch of errors saying "download error
>size does not match pkg_summary" I try just telling it to proceed but the
>package still doesn't install. I have already tried forcing a pgkin update
>and it
On 2020-02-01 01:38, Greg Troxel wrote:
[---]
> If you can't trust your local storage, you have no basis for getting
> anything at all right. Your local storage is where the public keys are
> stored that you use to validate, where you store files in installed
> packages, and where you store
For a quick summary from all your answers since martin's, if I may.
His answer is still perfectly valid to me.
Assuming you trust everything before, because not assuming that is confusing
and counterproductive in this particular discussion,
I wanted to focus, while there is probably work there
Jan Danielsson writes:
>- If you don't know if:
> o the server storage can be trusted
> o you can fully trust the link
> o you can trust your local storage up until the point at which you
> install the package
> .. then you need the binary package to be signed.
If you
Johnny Billquist writes:
> On 2020-01-31 15:02, Greg Troxel wrote:
>> The other thing https gives you is hiding the names of the packages you
>> download from passive eavesdroppers on the network bewteen your computer
>> and the TNF server. One such possible eavesdropper is your ISP. This
>>
On 2020-01-31 20:36, Manuel Bouyer wrote:
[---]
>>*Assuming you can trust the build environment (which includes the
>> signing process)*, and assuming that you can trust the underlying crypto:
>>
>>- HTTPS protects the connection between you and the server (assuming
>> server
On 2020-01-31 15:02, Greg Troxel wrote:
The other thing https gives you is hiding the names of the packages you
download from passive eavesdroppers on the network bewteen your computer
and the TNF server. One such possible eavesdropper is your ISP. This
is part of the "https everyhwere" push;
On Fri, Jan 31, 2020 at 07:21:40PM +0100, Jan Danielsson wrote:
> On 2020-01-31 08:49, yarl-bau...@mailoo.org wrote:
> > Please Maya and Mr Billquist, can you be more specific about how it is
> > insecure?
>
>There are different domains to consider.
>
>*Assuming you can trust the build
On 2020-01-31 08:49, yarl-bau...@mailoo.org wrote:
> Please Maya and Mr Billquist, can you be more specific about how it is
> insecure?
There are different domains to consider.
*Assuming you can trust the build environment (which includes the
signing process)*, and assuming that you can
Ottavio Caruso writes:
> I have interpreted "binary packages safety" as something intrinsic to
> potential vulnerability of the 3rd party software itself, as opposed
> to package integrity checking with digital signatures, checksums, etc,
> at least related to questions 1 and 3.
In my view, the
Johnny Billquist writes:
> (Which is why I objected to the implication that https is important,
> and somehow adds some security here in the first place.)
I think you are incorrect to dismiss https. In a world without signed
packages, the flow of built binary packages from an official build
to signing binary packages (we manually
sign the pkg-vulnerabilities file but that's unrelated).
Leo & al.,
The original questions were [sic]:
1) "is safe the use pkgsrc binary packages. For example using pkgin?"
2) "Is the authenticity and integrity of packages installed thi
Ottavio Caruso writes:
> [...]
> I believe there's an internal pkgsrc security mailing list to which
> users have no access (I could be wrong), so I don't really know how this
> auditing really works.
>
> One can always "pkg_admin fetch-pkg-vulnerabilities && pkg_admin audit".
> [...]
give you. And which still means you have no idea if the software
is sane, proper, does what you think, or hasn't been tampered with.
Johnny
De : Martin Husemann
À : Ottavio Caruso
Sujet : Re: pkgsrc binary packages security with pkgin
Date : 31/01/2020 09:51:53 Europe/Paris
Copie à
On 2020-01-31 12:39, Johnny Billquist wrote:
On 2020-01-31 12:37, Manuel Bouyer wrote:
On Fri, Jan 31, 2020 at 12:32:06PM +0100, Johnny Billquist wrote:
Of course you can. But then you need to have a whole list of trusted
public
keys that needs to be managed, which again leads to the question
On 2020-01-31 12:37, Manuel Bouyer wrote:
On Fri, Jan 31, 2020 at 12:32:06PM +0100, Johnny Billquist wrote:
Of course you can. But then you need to have a whole list of trusted public
keys that needs to be managed, which again leads to the question of which
keys are now the acceptable ones. And
On Fri, Jan 31, 2020 at 12:32:06PM +0100, Johnny Billquist wrote:
> Of course you can. But then you need to have a whole list of trusted public
> keys that needs to be managed, which again leads to the question of which
> keys are now the acceptable ones. And how to you trust new builders? Can
>
On 2020-01-31 12:32, Johnny Billquist wrote:
On 2020-01-31 12:07, Manuel Bouyer wrote:
On Fri, Jan 31, 2020 at 11:39:32AM +0100, Johnny Billquist wrote:
On 2020-01-31 11:34, Manuel Bouyer wrote:
On Fri, Jan 31, 2020 at 11:08:05AM +0100, Johnny Billquist wrote:
On 2020-01-31 10:25,
On 2020-01-31 12:07, Manuel Bouyer wrote:
On Fri, Jan 31, 2020 at 11:39:32AM +0100, Johnny Billquist wrote:
On 2020-01-31 11:34, Manuel Bouyer wrote:
On Fri, Jan 31, 2020 at 11:08:05AM +0100, Johnny Billquist wrote:
On 2020-01-31 10:25, yarl-bau...@mailoo.org wrote:
That's exactly the answer
On 2020-01-31 11:34, Manuel Bouyer wrote:
On Fri, Jan 31, 2020 at 11:08:05AM +0100, Johnny Billquist wrote:
On 2020-01-31 10:25, yarl-bau...@mailoo.org wrote:
That's exactly the answer I was waiting and hoping for. Thank you.
I'll follow tech-pkg from now on. Packages must be signed.
And
On Fri, Jan 31, 2020 at 11:39:32AM +0100, Johnny Billquist wrote:
> On 2020-01-31 11:34, Manuel Bouyer wrote:
> > On Fri, Jan 31, 2020 at 11:08:05AM +0100, Johnny Billquist wrote:
> > > On 2020-01-31 10:25, yarl-bau...@mailoo.org wrote:
> > > > That's exactly the answer I was waiting and hoping
On Fri, Jan 31, 2020 at 11:08:05AM +0100, Johnny Billquist wrote:
> On 2020-01-31 10:25, yarl-bau...@mailoo.org wrote:
> > That's exactly the answer I was waiting and hoping for. Thank you.
> >
> > I'll follow tech-pkg from now on. Packages must be signed.
>
> And with that signature, you know
, which is the same thing https
would give you. And which still means you have no idea if the software
is sane, proper, does what you think, or hasn't been tampered with.
Johnny
De : Martin Husemann
À : Ottavio Caruso
Sujet : Re: pkgsrc binary packages security with pkgin
Date : 31/01
That's exactly the answer I was waiting and hoping for. Thank you.
I'll follow tech-pkg from now on. Packages must be signed.
De : Martin Husemann
À : Ottavio Caruso
Sujet : Re: pkgsrc binary packages security with pkgin
Date : 31/01/2020 09:51:53 Europe/Paris
Copie à : netbsd-users
De : yarl-bau...@mailoo.org
À : Ottavio Caruso
Sujet : Re: pkgsrc binary packages security with pkgin
Date : 31/01/2020 10:15:00 Europe/Paris
De : Ottavio Caruso
À : netbsd-users@netbsd.org
Sujet : Re: pkgsrc binary packages security with pkgin
Date : 31/01/2020 09:26:06 Europe/Paris
One
Let me (as someone not heavily involved into pkgsrc and binary pkg building)
try to unriddle a few bits that I think get easily confused in this context.
When it comes to 3rd party packages, you have to trust:
(1) the original source of the package ("upstream") and its release policies.
On 31/01/2020 07:49, yarl-bau...@mailoo.org wrote:
Please Maya and Mr Billquist, can you be more specific about how it is insecure?
To all: Is someone working on it and what is ongoing to improve this?
I feel this thread belongs to pkgsrc-users@ or even better tech-pkg@ and
I'm not the OP,
Please Maya and Mr Billquist, can you be more specific about how it is insecure?
To all: Is someone working on it and what is ongoing to improve this?
Thank you very much.
De : J. Lewis Muir
À : Johnny Billquist
Sujet : Re: pkgsrc binary packages security with pkgin
Date : 27/01/2020 12:08
On 01/26, Johnny Billquist wrote:
> The code is not audited anyway, but just downloaded from various places, and
> then built.
I don't follow. What code are you saying is not audited? The source
code of each package? If so, I think that's mostly true (of course
there are exceptions where the
Op 26/01/2020 om 02:55 schreef Johnny Billquist:
On 2020-01-26 03:43, J. Lewis Muir wrote:
On 01/25, m...@netbsd.org wrote:
On Sat, Jan 25, 2020 at 01:34:34AM +0100, yarl-bau...@mailoo.org wrote:
May I ask how is safe the use pkgsrc binary packages. For example
using pkgin. Does libfetch
Is there projects to improve this?
De : m...@netbsd.org
À : yarl-bau...@mailoo.org
Sujet : Re: pkgsrc binary packages security with pkgin
Date : 25/01/2020 23:11:25 Europe/Paris
Copie à : netbsd-users@netbsd.org
On Sat, Jan 25, 2020 at 01:34:34AM +0100, yarl-bau...@mailoo.org wrote:
> He
On 2020-01-26 03:43, J. Lewis Muir wrote:
On 01/25, m...@netbsd.org wrote:
On Sat, Jan 25, 2020 at 01:34:34AM +0100, yarl-bau...@mailoo.org wrote:
May I ask how is safe the use pkgsrc binary packages. For example using pkgin.
Does libfetch is doing fine with https? Any thoughts
On 01/25, m...@netbsd.org wrote:
> On Sat, Jan 25, 2020 at 01:34:34AM +0100, yarl-bau...@mailoo.org wrote:
> > May I ask how is safe the use pkgsrc binary packages. For example using
> > pkgin. Does libfetch is doing fine with https? Any thoughts?
> >
> > Is the
On Sat, Jan 25, 2020 at 01:34:34AM +0100, yarl-bau...@mailoo.org wrote:
> Hello,
>
> May I ask how is safe the use pkgsrc binary packages. For example using
> pkgin. Does libfetch is doing fine with https? Any thoughts?
>
> Is the authenticity and integrity of packages
Hello,
May I ask how is safe the use pkgsrc binary packages. For example using pkgin.
Does libfetch is doing fine with https? Any thoughts?
Is the authenticity and integrity of packages installed this way is guaranteed
assuming no bugs in software involved?
Is it safer to compile by yourself
request to
install/upgrade a package that
depends on another package older version of which is already installed on your
system
you will get an error as pkg_add will blindly try to install the newer version
on top of the old
(and get a conflict).
Pkgin is more advanced: it builds a whole
On Tue, May 14, 2019 at 07:39:54PM +0530, Mayuresh wrote:
> I often try to switch to binary mode. Then one odd time you'll come across
> something that's not present in the binary repository and then you'd want
> to turn to pkgsrc. Often by that time some things would have evolved and
> pkgsrc
o (other than you
mentioned) well, as well.
> Pkgin is more advanced: it builds a whole dependency tree and upgrade all
> dependencies.
I do not know what others' experience with binary installation in general
is. And I am not even talking about build options mismatch here.
I often try to swit
http://pkgin.net/ says:
NetBSD, and more widely, all operating systems relying on pkgsrc have
tools like pkg_add and pkg_delete, but those are unable to correctly
handle binary upgrades, and sometimes even installation itself.
Could someone please clarify what it means? Are pkg_add
At Sat, 20 Apr 2019 13:20:03 +0100, Chavdar Ivanov wrote:
Subject: Re: pkg/54123 (crash trying 'pkgin upgrade' with locally built
pkg_summary)
>
> I have always used
>
> cd /usr/pkgsrc/packages/All ; ( for i in *.tgz; pkg_info -X $i ) |
> bzip2 > pkg_summary.bz2
Ah, that
Re: pkg/54123 (crash trying 'pkgin upgrade' with locally built
> pkg_summary)
> >
> > While pkgin shouldn't crash and should be able to handle bad input, it
> > should be pointed out that this use-case is not expected to work at all,
> > and any fix will simply enforce that.
[[ I tried sending this to gnats-admin, but it hasn't appeared yet, and
in any case folks here might have answers or suggestions too. ]]
At Wed, 17 Apr 2019 23:32:40 +0100, Jonathan Perkin wrote:
Subject: Re: pkg/54123 (crash trying 'pkgin upgrade' with locally built
pkg_summary)
>
>
Thx!
Yes, that's understandable. Still, https://gitlab.com/iMil/pkgin
looks to be outdated as well :(
The best would be if http://pkgin.net/ pointed to
https://github.com/joyent/pkgin which seems to be the master branch.
Den fre 19 okt. 2018 15:45matthew sporleder skrev:
> On Thu, Oct 18, 2
does http://pkgin.net/ points to https://github.com/NetBSDfr/pkgin ?
> This github repo has not seen any commit for the last two years.
> Wouldn't be better if it would point to https://github.com/joyent/pkgin ,
> just like pkgsrc.se does?
> Is there a reason for it?
>
> Thank
1 - 100 of 156 matches
Mail list logo
