Wondering whether I should make an outside facing view/cached table
containing values in a somewhat non changing way, even though they no longer
reflect our actual naming policies.
On Sat, Oct 30 2021, Marc Espie wrote:
> I think the most reasonable solution is this:
I have checked that this does the right thing on riscv64
with lang/compcert and lang/freebasic reverted to their previous
version. This looks like the most practical solution even though...
a bit hackish maybe
On 2021/10/30 18:10, Marc Espie wrote:
> I think the most reasonable solution is this:
Makes sense. We should probably rename it from MODGCC4/GCC49_ARCHS sometime!
> Index: gcc4.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/
I think the most reasonable solution is this:
Index: gcc4.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/gcc4.port.mk,v
retrieving revision 1.14
diff -u -p -r1.14 gcc4.port.mk
--- gcc4.port.mk27 Apr 2019 21:26:35 -
ts
> >> Changes by:j...@cvs.openbsd.org2021/10/29 15:37:58
> >>
> >> Modified files:
> >>lang/compcert : Makefile
> >>
> >> Log message:
> >> Unbreak sqlports on archs that don't have lang/gcc support (riscv64
re.
>
>> On Oct 29, 2021, at 5:38 PM, Jeremie Courreges-Anglas
>> wrote:
>>
>> CVSROOT:/cvs
>> Module name:ports
>> Changes by:j...@cvs.openbsd.org2021/10/29 15:37:58
>>
>> Modified files:
>> lang/compcert : Makefi
On Sat, Feb 01, 2020 at 10:53:41PM -0800, Andrew Hewus Fresh wrote:
> On Sat, Feb 01, 2020 at 07:10:40PM -0800, Andrew Hewus Fresh wrote:
> > After the most recent simplification of portgen's port finding code, I
> > think we can stop using sqlports and instead look to see
On Sat, Feb 01, 2020 at 07:10:40PM -0800, Andrew Hewus Fresh wrote:
> After the most recent simplification of portgen's port finding code, I
> think we can stop using sqlports and instead look to see if any
> $PORTSDIR/*/$PKGSTEM exist without a significant loss of functionality.
After the most recent simplification of portgen's port finding code, I
think we can stop using sqlports and instead look to see if any
$PORTSDIR/*/$PKGSTEM exist without a significant loss of functionality.
We currently look for any FullPkgPath that matches the PKGSTEM in
sqlports. I'm
On Sat, Nov 23, 2019 at 01:48:16PM -0800, Andrew Hewus Fresh wrote:
> On Sat, Nov 23, 2019 at 01:25:16PM +0100, Marc Espie wrote:
> > Woah. That code is horrible. It also spends a lot of time
> > connecting/disconnecting.
> >
> > - The database connection should be
ran out of time to actually look at the sqlports schema.
> > Index: Utils.pm
> > ===
> > RCS file: /cvs/ports/infrastructure/lib/OpenBSD/PortGen/Utils.pm,v
> > retrieving revision 1.4
> > diff -u -p -r
Before:
# spent 125s within DBI::st::execute which was called 33 times, avg 3.80s/call:
# 33 times (125s+0s) by DBD::_::db::selectcol_arrayref at line 1694 of DBI.pm,
avg 3.80s/call
sub DBI::st::execute; # xsub
After:
# spent 806ms within DBI::st::execute which was called 33 times, avg
24.4ms/
; + "SELECT FULLPKGPATH FROM PortsQ WHERE DISTNAME LIKE ?",
> {}, "$module%"
> ) };
Woah. That code is horrible. It also spends a lot of time
connecting/disconnecting.
- The database connection should be a singleton
- sqlports should always be opened ReadOnly
- The query should be prepared.
Apart from that, PortsQ will help, but the basic code should be taken out
and shot.
ene Wendling wrote:
> > > > Hi,
> > > >
> > > > As i'm working on portgen(1) and remembered Pamela's manpage
> > > > diff, i've found out that sqlports-compact is mentioned, and
> > > > its presence still checked. I'
portgen(1) and remembered Pamela's manpage diff,
> > > i've found out that sqlports-compact is mentioned, and its presence
> > > still checked. I'm proposing to remove those bits.
> > >
> > > It has been successfully tried in a chroot without sqlport
On Mon, 18 Nov 2019 19:31:02 -0800
Andrew Hewus Fresh wrote:
> On Mon, Nov 18, 2019 at 01:23:49PM +0100, Charlene Wendling wrote:
> > Hi,
> >
> > As i'm working on portgen(1) and remembered Pamela's manpage diff,
> > i've found out that sqlports-compac
On Mon, Nov 18, 2019 at 01:23:49PM +0100, Charlene Wendling wrote:
> Hi,
>
> As i'm working on portgen(1) and remembered Pamela's manpage diff, i've
> found out that sqlports-compact is mentioned, and its presence still
> checked. I'm proposing to remove those
Hi,
As i'm working on portgen(1) and remembered Pamela's manpage diff, i've
found out that sqlports-compact is mentioned, and its presence still
checked. I'm proposing to remove those bits.
It has been successfully tried in a chroot without sqlports installed,
and the runti
etrieving revision 1.2
> diff -u -p -r1.2 portgen.1
> --- portgen.1 24 Jun 2019 18:56:42 - 1.2
> +++ portgen.1 16 Nov 2019 23:33:56 -
> @@ -61,8 +61,6 @@ The following packages must be installed
> .Pp
> .Bl -item -offset indent -compact
> .It
> -.Cm sqlports-c
On Sat, Nov 16, 2019 at 06:50:44PM -0500, Pamela Mosiejczuk wrote:
> Oops, just tripped over this. OK to update?
sure
.1 16 Nov 2019 23:33:56 -
@@ -61,8 +61,6 @@ The following packages must be installed
.Pp
.Bl -item -offset indent -compact
.It
-.Cm sqlports-compact
-or
.Cm sqlports
.It
.Cm p5-DBI
ile: /cvs/ports/databases/sqlports/Makefile,v
retrieving revision 1.119
diff -u -p -r1.119 Makefile
--- Makefile20 Jul 2019 23:12:47 - 1.119
+++ Makefile3 Oct 2019 11:36:33 -
@@ -1,7 +1,7 @@
# $OpenBSD: Makefile,v 1.119 2019/07/20 23:12:47 espie Exp $
CATEGORIES =
On Mon, Jul 15, 2019 at 09:00:46PM -0400, Daniel Jakots wrote:
> On Tue, 2 Jul 2019 17:42:07 +0200, Juan Francisco Cantero Hurtado
> wrote:
>
> > I've the python script but I've not started yet with the port. The
> > question for the porters (and in special people running the bulks,
> > signing/u
On Tue, 2 Jul 2019 17:42:07 +0200, Juan Francisco Cantero Hurtado
wrote:
> I've the python script but I've not started yet with the port. The
> question for the porters (and in special people running the bulks,
> signing/uploading packages) is, are you against this idea?
It looks like to me no o
On Tue, Jul 02, 2019 at 09:44:51PM +0100, Stuart Henderson wrote:
> On 2019/07/02 21:48, Hiltjo Posthuma wrote:
> > On Tue, Jul 02, 2019 at 07:02:04PM +0200, Landry Breuil wrote:
> > > On Tue, Jul 02, 2019 at 12:21:50PM -0400, Daniel Jakots wrote:
> > > > I think it would be indeed nice to provide
ntries etc anyway?
> I also use a similar method at the moment and wrote the shellscript below for
> my own use:
>
>
> #!/bin/sh
> # fetch generated ports INDEX from databases/sqlports (portslist) from
> # packages snapshots.
>
> mkdir -p dl
> cd dl || exit 1
>
&
e shellscript below for
my own use:
#!/bin/sh
# fetch generated ports INDEX from databases/sqlports (portslist) from
# packages snapshots.
mkdir -p dl
cd dl || exit 1
pubkey="/etc/signify/openbsd-65-pkg.pub"
url="$(cat /etc/installurl)/snapshots/packages/$(uname -m)/"
e.pub/tmp-ports/take2/packages-versions.json
> On Tue, 2 Jul 2019 17:42:07 +0200, Juan Francisco Cantero Hurtado
> wrote:
>
> > More than a year ago I talked with espie@ about making the sqlports
> > info available as a json file in the CDNs/mirrors. My idea was to
> >
On Tue, Jul 02, 2019 at 12:21:50PM -0400, Daniel Jakots wrote:
> I think it would be indeed nice to provide a way for people to easily
> see the content of the ports tree without having to take the sqlite3 db
> out from sqlports.tgz.
>
> Regarding the JSON, I think only one, with as much info as
>
the field names ;)
Cheers,
Daniel
On Tue, 2 Jul 2019 17:42:07 +0200, Juan Francisco Cantero Hurtado
wrote:
> More than a year ago I talked with espie@ about making the sqlports
> info available as a json file in the CDNs/mirrors. My idea was to
> provide that info for people who want
More than a year ago I talked with espie@ about making the sqlports info
available as a json file in the CDNs/mirrors. My idea was to provide
that info for people who want to create simple/static javascript web
pages, external tools for monitoring the ports tree or some type of
automation system
DBI::_firesafe; Â Â Â Â # just in case
> > >Â Â Â Â Â Â require DBD::SQLite; Â Â Â Â # load the driver
> > >Â Â ' called at
> > >/usr/local/libdata/perl5/site_perl/amd64-openbsd/DBI.pm line 793
> > >And well the package does not
gt; >Â Â ' called at
> >/usr/local/libdata/perl5/site_perl/amd64-openbsd/DBI.pm line 793
> >And well the package does not generate anything , only the port does
> >I dont faq5.html anywhere and it is late
> >I think the line
> >The sqlpo
;And well the package does not generate anything , only the port does
>I dont faq5.html anywhere and it is late
>I think the line
>The sqlports port includes the script used to generate the database,
><>
>Would not hurt.
>Unless there is a bette
# load the driver
' called at /usr/local/libdata/perl5/site_perl/amd64-openbsd/DBI.pm
line 793
And well the package does not generate anything , only the port does
I dont faq5.html anywhere and it is late
I think the line
The sqlports port includes the script used to generate the database
ivers/arc
sqlite3 /usr/obj/pobj/sqlports-5.0/sqlports-5.0/sqlports-compact 'select [cut]'
ritchie /usr/ports/databases/sqlports$
This is is expected given that SHARED_ONLY is still defined for all
ports. (Details in mksqlitedb:140 / Info.pm:127)
ok jca@
--
jca | PGP : 0x1524E7EE / 5135
SHARED_ONLY is going away, drop it from the variables available in
the database. Did I miss anything? OK?
Index: Makefile
===
RCS file: /cvs/ports/databases/sqlports/Makefile,v
retrieving revision 1.60
diff -u -p -r1.60 Makefile
On Mon, Mar 23, 2015 at 07:42:02PM -0700, Constantine A. Murenin wrote:
> On 23 March 2015 at 15:59, Stuart Henderson wrote:
> > On 2015/03/23 10:14, Constantine A. Murenin wrote:
> >> May I also ask why is it necessary to remove the timestamp information
> >> from the tar archives themselves?
> >
On 2015-03-24, Constantine A. Murenin wrote:
> On 23 March 2015 at 15:59, Stuart Henderson wrote:
>> On 2015/03/23 10:14, Constantine A. Murenin wrote:
>>> May I also ask why is it necessary to remove the timestamp information
>>> from the tar archives themselves?
>>
>> To improve rsyncability.
>
On 23 March 2015 at 15:59, Stuart Henderson wrote:
> On 2015/03/23 10:14, Constantine A. Murenin wrote:
>> May I also ask why is it necessary to remove the timestamp information
>> from the tar archives themselves?
>
> To improve rsyncability.
Could you elaborate?
0. Doesn't rsync ignore timesta
On 2015/03/23 10:14, Constantine A. Murenin wrote:
> May I also ask why is it necessary to remove the timestamp information
> from the tar archives themselves?
To improve rsyncability.
nce
>> 2014-09-21.
>>
>> Is there a cross-platform way to best get it back from the package file?
> Yes, parse the +CONTENTS file and restore the associated @ts.
>
> Any tool that reads files can do so easily. In perl,
> perl -ne '$seen = 1 if m/sqlports-compa
best get it back from the package file?
Yes, parse the +CONTENTS file and restore the associated @ts.
Any tool that reads files can do so easily. In perl,
perl -ne '$seen = 1 if m/sqlports-compact/; if ($seen == 1 && m/\@ts\s+(.*)/) {
system("date -r $1"); exit 0; }' /var/
quot;, and
both "+CONTENTS" and "+DESC" themselves have the correct timestamps,
too, just not "share/sqlports-compact".
>From the reversing as per below, it seems like there are 4 sources for
two timestamps:
2014-09-18T08:47Z
+DESC
+CONTENTS /@ts
2014-09-18T12:17Z
2014-09-18 22:14 GMT+04:00 Marc Espie :
> On Thu, Sep 18, 2014 at 09:30:42PM +0400, Vadim Zhukov wrote:
>> The bsd.port.mk's dump-vars always prints
>> SUBPACKAGE=whatever-is-default-for-the-current-port value. Which is,
>> actually, useless. Then this value gets into
On Thu, Sep 18, 2014 at 09:30:42PM +0400, Vadim Zhukov wrote:
> The bsd.port.mk's dump-vars always prints
> SUBPACKAGE=whatever-is-default-for-the-current-port value. Which is,
> actually, useless. Then this value gets into sqlports directly. Making
> SUBPACKAGE field totall
The bsd.port.mk's dump-vars always prints
SUBPACKAGE=whatever-is-default-for-the-current-port value. Which is,
actually, useless. Then this value gets into sqlports directly. Making
SUBPACKAGE field totally useless as well.
Options I see:
a) Get rid of SUBPACKAGE in dump-vars output and sql
ories, makes sense. ;)
> On Thu, Oct 31, 2013 at 03:38:20PM +0400, Vadim Zhukov wrote:
> > 31.10.2013 13:32 "Brett Mahar" <
brett.ma...@gmx.com> ??:
> > >
> > > Hi espie@ and ports@,
> > >
> > > When
> > Hi espie@ and ports@,
> >
> > When I type "env SUBPACKAGE="-main" make install" sqlports errors out as
> below.
> >
> > Since the error says "Stop in /usr/ports/mystuff/mail", I rm -rf
> /usr/ports/mystuff/ and then sqlports bui
31.10.2013 13:32 пользователь "Brett Mahar" написал:
>
> Hi espie@ and ports@,
>
> When I type "env SUBPACKAGE="-main" make install" sqlports errors out as
below.
>
> Since the error says "Stop in /usr/ports/mystuff/mail", I rm -rf
/usr
Hi espie@ and ports@,
When I type "env SUBPACKAGE="-main" make install" sqlports errors out as below.
Since the error says "Stop in /usr/ports/mystuff/mail", I rm -rf
/usr/ports/mystuff/ and then sqlports built fine.
Is there some way I can make it ignore my PO
This unbreaks fetching SHARED_LIBS and TARGETS in sqlports.
okay?
--
WBR,
Vadim Zhukov
Index: Makefile
===
RCS file: /cvs/ports/databases/sqlports/Makefile,v
retrieving revision 1.51
diff -u -p -r1.51 Makefile
--- Makefile
On Mon, May 06, 2013 at 05:26:47PM +0200, Marc Espie wrote:
> No, it makes ways more sense to fix things in the associated Makefiles
Not sure what you mean.
--
best regards
q#
On Mon, May 06, 2013 at 03:54:56PM +0100, Mikolaj Kucharski wrote:
> Hi,
>
> I have custom PORTSDIR_PATH in /etc/mk.conf and that makes sqlports fail
> doring build when it tries to visit non existing directories under
> mystuff, which do exist under $PORTSDIR.
>
> # grep -
Hi,
I have custom PORTSDIR_PATH in /etc/mk.conf and that makes sqlports fail
doring build when it tries to visit non existing directories under
mystuff, which do exist under $PORTSDIR.
# grep -e ^PORTSDIR_PATH /etc/mk.conf
PORTSDIR_PATH = ${PORTSDIR}/mystuff:/home/users/build/mystuff:${PORTSDIR
BTW, databases/ports-readmes is static.
It's probably not difficult for someone who wants to learn Catalyst
to write mostly the same thing as a dynamic application.
I chose catalyst because it includes a self-contained small web server,
so it can be installed without needing any configuration.
O
Okay ?
Index: Makefile
===
RCS file: /cvs/ports/Makefile,v
retrieving revision 1.68
diff -u -p -r1.68 Makefile
--- Makefile9 Mar 2012 10:57:54 - 1.68
+++ Makefile26 May 2012 12:28:49 -
@@ -4,7 +4,6 @@
PKGPATH
Now that things are consistent, it's much simpler to generate ports readmes
from sqlports (and faster).
Please comment.
I intend for this to improve and get committed, then scrape the old
readme.html framework from infrastructure/mk/
ports-readmes.tgz
Description: ports-readmes.tgz
Warnings seen during sqlports build:
NO_BUILD has unknown value binary port in games/adom
NO_REGRESS has unknown value Tes in games/wmminichess
NO_REGRESS has unknown value testsuite available at
http://www.gnashdev.org/testcases/ in www/gnash
Index: games/adom/Makefile
I just committed a small bit of introspection: TARGETS is now defined
to be the list of targets overrides for a given port (e.g., stuff
like do-install and the likes).
sqlports-1.12 collects the info, for whoever might want to use it.
I can make
views in the sqlports-compact representation for user-friendlyness.
Specifically, it's getting to the point where all the "user" information in
sqlports-main is now accessible in sqlports-compact as views (I have the
main ports table to finish and that's about it).
Th
Closer to what will be the final version
Index: Makefile
===
RCS file: /cvs/ports/databases/sqlports/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile15 Sep 2007 22:27:39 - 1.10
+++ Makefile
Well, I've refactored quite a bit of code to allow for more compact
databases...
I'm keeping the old one for now, and creating a new sqlports-compact
version, that's more suitable for automated handling, as the sql queries
are ways more fun than before..
The refactoring means tha
Hi all,
For your enjoyment the attached port installs a tool I wrote for
browsing the sqlports database.
This is a ruby cgi script. It requires mod_ruby and ruby-sqlite3. This
cgi script runs under an unchrooted httpd.
After install, you can use it by browsing to
http://localhost/cgi
rm -f distinfo
--
best regards
q#
Index: Makefile
===
RCS file: /cvs/ports/databases/sqlports/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- Makefile2006/12/27 11:16:10 1.8
+++ Makefile2007/02/14 00:26:33
> * bump pkgname
Okay, that was a bit incorrect.
Bumped DISTNAME, not PKGNAME, because table structure changed a bit and
using ``IF EXISTS'' when updating would cause lots of errors and Paths not
updated.
I've reuploaded the patch just after sending the mail.
--
Martynas Venckus
* make FULLPKGPATH NOT NULL on Paths
* make ``DROP IF EXISTS'', so that errors disappear
* change the Descr structure. Generating index for VALUE costs pretty
much, and only FULLPKGPATH must be unique (i saved 20% of space, try
comparing yourself)
* Descr and Paths are the same structure, s
I for one would enjoy writting code for this project if RoR is chosen.
The down side is I never worked with SQLite (but I'm a fast learner)
and my spare time is very little, but I guess that's everyone's
problem.
So who's in?
don't want to restrict your efforts. I have no idea if my
idea of a ports page would be the most useful.
What I can tell is that, with sqlports, you can make a killer search
engine, that would allow you to search for basically anything.
I can also tell you that sqlports, as opposed to earli
69 matches
Mail list logo
