Closed #472.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/472#event-1744561408___
Rpm-maint mailing list
rpm --eval does macro expansion, and %if is not a macro.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The beecrypt glue code in rpm doesn't even support MD2 as digest, so yes, just
remove it in digest_openssl.c...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Aside from using wildcards and queries, the original request is something that
IMHO belongs to the application using rpm, like with depsolving. I.e. dnf for
Fedora.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #450.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/450#event-1691225816___
Rpm-maint mailing list
That's not a bug, no epoch means epoch zero and 2 > 0. So it does work as
expected.
Can't you use `Requires: tar >= 2:1.28`?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Ohhh, we're going full circle here. In the beginning numberless Source/Patch
was the same as number zero.
In 2008 came commit 724b07bba5e802998b1b79b408c2401d2a238a3b that used INT_MAX
for Source and Patch. Shortly after that was commit
1a173c486dd1d83f22f8123317303fc1fb880f54 that made Source
The beauty of the current way deltarpms are handled is that it's just some
funky transport mechanism to get the full rpm. (Though I agree that the payload
re-compression is the weak spot.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
Pardon the dumb question, but if armv8 is just the 32bit mode of aarch64 why
doesn't aarch64 also need those float/neon/crypto modifiers?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
g them as it should.
Hmm, I wonder why that is so. It shouldn't be able to parse the new
rich dependencies and thus fail in the dependency check.
I don't mind them being backported, though. ;)
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX GmbH
(I.e. the build should work if you comment out the __prelink_undo_cmd
definition in /usr/lib/rpm/macros. Can you confirm this?)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
My guess is the `int maxndx = data->d_size / shdr.sh_entsize` line in
is_prelinked(). There should be a test if `shdr.sh_entsize` is zero.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
No, that's fine. We can also remove the code that is not needed in rpm (i.e.
the non-rpmxdb code in rpmidx).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This issue once was https://github.com/rpm-software-management/rpm/pull/253
When you have foo-1-1.i586 installed and you do 'rpm -U foo-1-1.i686', rpm will
not add an erase element for the i586 package.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
(Huh, SUSE carries has a patch like that? Weird. We don't use it for sure.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
True, that's something we might want to investigate. It depends a bit on where
rpm's bottleneck is. If it's IO bound, adding parallelism won't help much.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
sign_hash is in the external libimaevm. But it shouldn't be needed if you don't
try to build with imaevm support.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #403.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/403#event-1500834651___
Rpm-maint mailing list
Closed #404.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/404#event-1500826006___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
I think the question is not if two versions of a package may be installed, but
if the install itself can be done in parallel. I.e. if two 'rpm -U' calls can
be done in parallel. That won't work because of the global transaction lock.
And I don't think we should change this. ;)
--
You are
Closed #402.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/402#event-1499170179___
Rpm-maint mailing list
That's caused by a SUSE patch.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/402#issuecomment-369615998___
Rpm-maint mailing
That's because the needed information simply isn't available in the repository
metadata...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
See https://github.com/openSUSE/libsolv/pull/255 for the background.
I think rpm should not overwrite the count with the entry length (line 1107 in
header.c). I don't know if everything still works if the line is removed.
Please investigate ;)
--
You are receiving this because you are
Before this commit, rpm simply did not take hardlinks into account when
calculating disk space requirements. This made it fail spectaculary for
packages that contain a high number of hardlinks, like glibc-locale.
We now "bind" the file size to the last hardlink member. This is still not
Ok, updated.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/379#issuecomment-356616236___
Rpm-maint mailing list
I don't see any signature tag number after RPMSIGTAG_RESERVEDSPACE.
Thinking a bit more about the comment, it's a bit wrong. It should be "all tag
numbers lower than RPMSIGTAG_RESERVEDSPACE" must be already added. We can add
higher tags afterwards with no problems.
--
You are receiving this
It just feels odd to me that the behavior of a file with just one macro is
different than a file with two macros. But don't mind me ;)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
That "return an error if all definitions fail" is pretty weird. What's the
rationale for that?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
(The 'alien' tool could simply turn off that check by setting
%_wrong_version_format_terminate_build to zero in the generated spec file.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
;$CC" CFLAGS="$CFLAGS" $db_dist/configure $ARGS \
--enable-shared --enable-static \
- --with-uniquename=_rpmdb --srcdir=$db_dist
+ --with-uniquename=_rpmdb --srcdir=$db_dist --with-pic
mv Makefile Makefile.orig
cat Makefile.orig | sed -e '/^install[:-]/c\
Cheers,
Mich
sion just does not for some
> reason.
As Panu said: you need to run the configure script with the
--without-external-db option, otherwise it will not build berkeley
db (and yes, that's a bug in the configure script).
Cheers,
Michael,
--
Michael Schroeder m...@
No, the point of set-versions is that you only have one provides/requires for
all of the symbols. This means that it's a somewhat probabilistic method,
there's some small chance it will not detect a missing symbol.
--
You are receiving this because you are subscribed to this thread.
Reply to
First, I don't see why you need the rich deps here. Wouldn't a
`libfoo.so.1(do_foo@FOO_1.0)(64bit))` requires be enough?
Then, wouldn't your proposal mean that over time you'll have a provide for
every symbol? That'll be quite some burden on the metadata size and dependency
solver setup. If
Why isn't this "can be enabled with --multiarch" and no-multiarch is the
default?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
addArchedDep seems to be identical to addDep, so I don't see why you don't just
use ei->marker but generate it differently.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
…text
Guide users to the correct operator instead.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/317
-- Commit Summary --
* Forbid 'if' richops in 'or' context and 'unless' richops in 'and' context
-- File Changes --
Eek, that's horrible. Please add a way (macro) to disable this.
Calling sync() hurts very much for big servers with huge disks and a big buffer
cache. I get that's it's somewhat acceptable for software installation on the
server (syncfs would still be much nicer so that data partitions don't
Please do not test `(X or (Y if Z))`, it may well be that we make this illegal
in the future. `(X or (Y if Z))` is the same as `(X or Y or not(Z))`, the `or
not(Z)` does not make much sense.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
Actually my plan was to add some next the the existing rich-op tests, but I
just found the with/without tests. Where is the rest of them?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I'd expect `rpm --define '%xxx /hello//world' --eval '%{dirname:%xxx}'` to
return `/hello/%%` instead of `/hello/%`. Sorry for being not clear enough.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
An (A unless B) dependency implements (A and not(B)). This kind is useful
for "or" type dependencies, e.g. "Conflicts" or "Supplements".
As "Conflicts: (A unless B)" is equivalent to "Requires: (B if A)", I
thought this type is not needed. But there is no such equivalence
for Supplements, thus
I didn't say they all should not re-expand. Things like "%{expand:}" obviously
have to do it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
(duplicating first comment to generate mail to rpm-maint)
Watch this:
```
$ rpm --define '%xxx /hello//world' --eval '%xxx'
/hello/%%/world
$ rpm --define '%xxx /hello//world' --eval '%{shrink:%xxx}'
/hello/%/world
$ rpm --define '%xxx /hello//world' --eval '%{dirname:%xxx}'
/hello/%
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/313___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
But isn't that going to break lots of existing scripts? I don't see the harm of
allowing non-array tags like %{NAME} in array queries. (I.e. automatically add
a '=' for non-array tags.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
It works like expected. You can't use and/or/if with with/without, because
with/without work on package sets. You may only use or/with/without in sets.
Just re-arrange your expressions.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
Here's my attempt to implement with/without deps. I (mis)used the dbiIndexSet
functions for set management, using tag==0 for rpmdb packages and tag==1 for
rpmal packages. I guess some test coverage would also be nice, but I'll be on
vacation the next three weeks. Please step in to add tests. ;)
Wouldn't it be better if rpmdb gets dump/load/stat options?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Please remove the part that patches ndb/glue.c from this commit.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Well, "most similar to Berkeley DB" is maybe not the perfect way to choose a
database ;)
Anyway, another database backend to test is good to have. Thanks for spending
your time on this!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view
he glue code update the
chroot if it was changed. Much code for little gain, IMHO.
I suggest to go with 1), code removal is always good ;) Plus, Berkeley db
also doesn't check for database switches, so it is no regression.
Cheers,
Michael.
--
Michael Schroeder
Trust me, the patch works fine for the setup used at SUSE. But I agree that it
makes no sense to merge it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
(It works for SUSE because we always open with DB_PRIVATE and thus don't use
the dbenv at all. So there's no ignorant denial involved ;-) )
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
mlschroe commented on this pull request.
> @@ -511,13 +511,14 @@ void rpmpsmNotify(rpmpsm psm, int what, rpm_loff_t
> amount)
*/
static void markReplacedInstance(rpmts ts, rpmte te)
{
+/* this must match rpmNameVersionCompare in depends.c */
No, rpm currently does not use the sha sig
mlschroe commented on this pull request.
> @@ -511,13 +511,14 @@ void rpmpsmNotify(rpmpsm psm, int what, rpm_loff_t
> amount)
*/
static void markReplacedInstance(rpmts ts, rpmte te)
{
+/* this must match rpmNameVersionCompare in depends.c */
No, please don't, the comment is correct.
It's done so that ^C exists rpm if in read-only mode. I don't know how it
interacts with the db-env, SUSE only uses DB_PRIVATE.
Panu also changed the signal handling quite a bit recently, so it may well be
that the patch is no longer needed.
--
You are receiving this because you are
(but you also have the problem that there will be an empty argument if
with_int_bdb is not defined. Hmm. So revert that "expand after split" commit?
Too bad rpm does not have some quoting mechanism.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email
Yes, I also ran into that problem. But it's compatible to before ;)
Anyway, making the split macro aware would IMHO be a good thing. It would also
make it more consistent in regard to what expandMacro itself does, i.e. call
matchchar to find the end of a %{ or %( macro.
--
You are receiving
I actually started with modifying headerIsSource, but then decided to do it in
applyRetrofit because that's where the old code does the real detection and I
wanted to make sure not to break things for people relying on the current code
of headerIsSource.
Note that you still need the
Use a simple heuristic instead of looking at the lead type when we can't
decided if a header is from a source package or not.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/218
-- Commit Summary --
* Add
I also think you should expand the macros after splitting the arguments, so
that the behavior is more useful and compatible. Example:
```
%foo() 1:%1 2:%2
```
And `rpm --eval "%foo %nil bar` should return `1: 2:bar` like before.
--
You are receiving this because you are subscribed to this
If you have a
```
%foo() %1
```
macro, `rpm --eval "%{foo xx}"` used to print `xx%%`, but now just prints
`xx%`. This is because commit 5adc56897b9da5dac49701f704ef54390db57c59 added an
extra expansion call.
I think that all % characters need to be replaced by %% after the expansion or
Done. This still needs a ACK from Mark, though.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/180#issuecomment-297672144___
This is by design. The sources go into the main debuginfo package, all other
debuginfo packages get an require to the main one.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hey, I asked for the same think 6 years ago. Sadly Panu didn't like it:
```
...but this doesn't sound like something I'd want to encourage. Specs are
messy enough as is without having them become self-aware ;) Surely there must
be better ways to communicate things to scripts than having them
Hmm. Seems like rpm doesn't use the --root argument when it searches for the
platform file. I wonder if this is a bug or not.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
But if you can't mix them then they should not be marked as "compat". Wouldn't
it be better to declare the system as "armv7l" via /etc/rpm/platform or
something like that? Dunno if 'mock' supports that, though.
--
You are receiving this because you are subscribed to this thread.
Reply to this
@mlschroe pushed 1 commit.
d7bfb25 Also add directories to split debuginfo packages
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
The attached patch makes rpm create debuginfo subpackage for each
subpackage that contains files with debug data.
This is pretty much a complete rewrite of the old SUSE patch,
so this needs a review. As this is off by default it can't break
anything.
Cheers,
Michael.
--
Michael Schroeder
The attached patch makes rpm create -debugsource subpackages containing
the debug sources.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13
This adds support for SUSE style debuginfo packages. Due to the changes in rpm
upstream the patch had to be pretty much rewritten from scratch.
As the new functionality is off per default the patch cannot break anything.
You can view, comment on, or merge this pull request online at:
mlschroe commented on this pull request.
> +switch (num) {
+case 0:
+if (!bn) {
+bn = sig->bn = BN_new();
+}
+if (!bn) return 1;
+
+/* Create a BIGNUM from the signature pointer.
+ Note: this assumes big-endian data as required
+
mlschroe commented on this pull request.
> +switch (num) {
+case 0:
+if (!bn) {
+bn = sig->bn = BN_new();
+}
+if (!bn) return 1;
+
+/* Create a BIGNUM from the signature pointer.
+ Note: this assumes big-endian data as required
+
About suse patterns: in the old days(tm), they were pretty similar to comps.
Nowadays they are just rpm packages with standard dependencies. You shouldn't
try to judge them by looking at that messy spec file.
--
You are receiving this because you are subscribed to this thread.
Reply to this
Wait a sec, those files are appdata, not appstream. Appstream is the data
included in repositories. Appdata is the data installed in /usr/share/appdata
and /usr/share/metainfo.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Oh my. No discussion on the mailing list?
And the commit doesn't even do anything, because '^' is skipped at the start of
the while loop in rpmvercmp. So is this really needed at all?
(And the comment is also wrong, it's the same as with ~ ;) )
(And you also need support for this in libsolv...)
he anti-cheating configurable with a rpm macro...
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
__
added for a reason...
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
Rpm-maint mai
I guess it's needed, as I'm not sure that lzma_easy_encoder creates the bitwise
identical output as lzma_stream_encoder_mt with threads set to 1.
---
Reply to this email directly or view it on GitHub:
?
In that case the script needs to annotate the output in some way.
It has to transport the information, which files generated the dependency.
Otherwise things like 'rpm -q --filerequire' would no longer work.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE
and push this pretty much as-is [**], unless others have objections.
Florian?
Ok, pushed.
Happy hacking,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32
,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
On Thu, Sep 11, 2014 at 03:02:15PM +0200, Florian Festi wrote:
On 09/11/2014 02:51 PM, Michael Schroeder wrote:
Ah, but I was hoping for a discussion of the syntax. Are you ok with
the enclosing the rich deps with ()? What about the op names, I'd
love to use as 'and' and | as 'or' (which
On Mon, Sep 08, 2014 at 04:51:12PM +0200, Michael Schroeder wrote:
Hi Panu et al,
attached is an updated version of my rich dependencies patch.
I cleanup up the code a bit, now we have only one generic parser
instead of three specialized ones, and we use a callback function
to do the needed
,
and it also must not be chained or stacked.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
diff --git a/build/pack.c b/build
the code simpler and a tiny bit faster.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
From 5b29f64744d01952a77ff6899ba295ff7608093b
check: 8ms
So it's a very little bit slower for small packages, but helps a
lot for big packages or big transactions.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar
three different parsers for complex
deps (in rpmds.c, parseReqs.c, and rpmdb.c), this is something
that really should be unified.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while
.
As said, SUSE uses suggests/recommends since 2006 in a Debian
compatible way, it makes no sense to use to swap them.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar
Hi,
the attached patch adds a %_rundir macro to the platform files.
The default value is /run, it can be changed with the --with-rundir
configure option.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746
On Tue, Mar 11, 2014 at 04:07:41PM +0100, Michael Schroeder wrote:
On Tue, Feb 25, 2014 at 03:25:21PM +0100, Michael Schroeder wrote:
Hi rpm-maint,
attached is a little patch that I have in my rpm to make --recommends
et al work with old SUSE rpms.
I also need the following patch
On Tue, Feb 25, 2014 at 03:25:21PM +0100, Michael Schroeder wrote:
Hi rpm-maint,
attached is a little patch that I have in my rpm to make --recommends
et al work with old SUSE rpms.
I also need the following patch to make rpm export the old tags.
There seems to be no way to access array type
Hi rpm-maint,
attached is a little patch that I have in my rpm to make --recommends
et al work with old SUSE rpms.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar
On Wed, Oct 09, 2013 at 02:25:43PM +0300, Panu Matilainen wrote:
I've no clue about the AppData part (what it contains or how it would be
used)...
It can be used to link appdata.xml contents to packages withour needing
to retrieve the complete filelist.
Cheers,
Michael.
--
Michael
files in the /usr/share/applications directory, independent
of the type. (I must admit that I have no clue about what other types
are allowed in those desktop files.)
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB
.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
From 56699101dec027590cca137a5d268fbc88799121 Mon Sep 17 00:00:00 2001
From: Michael Schroeder m
.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
From fae0eef24582dd9e071be8e884ff0851d4b57437 Mon Sep 17 00:00:00 2001
From: Michael Schroeder m
On Wed, Sep 11, 2013 at 07:09:29PM +0200, Michael Schroeder wrote:
There are different (and easier) ways to fix this:
- you can always put an empty string into the pool, it would always
have id 1. This simplifies the dummy entry check to:
if (i != 1 str[0] == 0)
- you could get
() to convert
a const char * to a char * is clever.)
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--- rpmio/rpmstrpool.c.orig 2013-09
601 - 700 of 791 matches
Mail list logo
