Re: [gentoo-dev] [PATCH 0/4] Eclass for single-impl Lua ebuilds

2020-10-01 Thread Daniel Pielmeier
Marek Szuba schrieb am 01.10.20 um 22:24:
> On 2020-10-01 20:31, Daniel Pielmeier wrote:
> 
>> I already had slotted lua 5.1 and 5.3 installed and the modified ebuild
>> built fine with lua-5.3 as before. However when I tried setting
>> LUA_SINGLE_TARGET="lua5-2", lua-5.2 was pulled in as a dependency but
>> conky still built against lua-5.3. The temporary pkg-config environment
>> was set correct but somehow it seems not used. Conky uses cmake and
>> pkg_search_module [1] to detect lua preferring 5.3 over 5.2.
>>
>> Am I doing something wrong using the eclass or is there an issue with
>> the lua detection in conky or maybe the the eclass?
> 
> I noticed the same thing while adapting x11-wm/awesome, it's caused by
> how the CMake module FindLua works. You will have to make sure that
> cmake looks for a specific version.
> 

Thanks Marek!

Probably the easiest solution is to pin it to 5.3 then.

-- 
Best Regards
Daniel



Re: [gentoo-dev] [PATCH 0/4] Eclass for single-impl Lua ebuilds

2020-10-01 Thread Daniel Pielmeier
Marek Szuba schrieb am 30.09.20 um 18:23:
> Same as lua.eclass and python-r1, this is a Lua version of
> python-single-r1. Setting LUA_SINGLE_TARGETS allows one to choose the
> (slotted) Lua implementation to build your ebuild against, optionally
> including both single- and multi-implementation Lua packages as
> dependencies.
> 

Hello Marek!

First of all thank you very much for your work on the eclasses
supporting slotted lua. It is very much appreciated.

As I am not really capable of doing a review I took your eclasses and
tried to use it for app-admin/conky (using lua-single) where new
versions already need at least lua-5.2. See the changes below.

I already had slotted lua 5.1 and 5.3 installed and the modified ebuild
built fine with lua-5.3 as before. However when I tried setting
LUA_SINGLE_TARGET="lua5-2", lua-5.2 was pulled in as a dependency but
conky still built against lua-5.3. The temporary pkg-config environment
was set correct but somehow it seems not used. Conky uses cmake and
pkg_search_module [1] to detect lua preferring 5.3 over 5.2.

Am I doing something wrong using the eclass or is there an issue with
the lua detection in conky or maybe the the eclass?

[1]
https://github.com/brndnmtthws/conky/blob/master/cmake/ConkyPlatformChecks.cmake

--- conky-1.11.6.ebuild 2020-09-21 12:32:10.180949870 +0200
+++ conky-1.11.6-r1.ebuild  2020-10-01 00:04:13.099147223 +0200
@@ -3,7 +3,9 @@

 EAPI=7

-inherit cmake linux-info readme.gentoo-r1 xdg
+LUA_COMPAT=( lua5-{2..3} )
+
+inherit cmake linux-info lua-single readme.gentoo-r1 xdg

 DESCRIPTION="An advanced, highly configurable system monitor for X"
 HOMEPAGE="https://github.com/brndnmtthws/conky;
@@ -45,7 +47,7 @@
weather-metar? ( net-misc/curl )
webserver? ( net-libs/libmicrohttpd )
xmms2? ( media-sound/xmms2 )
-   || ( dev-lang/lua:5.3 dev-lang/lua:5.2 )
+   ${LUA_DEPS}
 "
 RDEPEND="
${COMMON_DEPEND}
@@ -85,6 +87,8 @@

 pkg_setup() {
use ipv6 && linux-info_pkg_setup
+
+       lua-single_pkg_setup
 }

 src_prepare() {

-- 
-- 
Daniel Pielmeier



Re: [gentoo-dev] RFC: packages.g.o: new features available

2020-07-07 Thread Daniel Pielmeier
Am July 8, 2020 2:57:57 AM UTC schrieb Max Magorsch :
>Hi all,
>
>I am glad to announce further progress at packages.gentoo.org (pgo in
>the following). Compared to previous work during the last months,
>which mostly addressed the back end, the new changes are rather
>comprehensive. That's why I am looking forward to feedback here.
>
>So the tl;dr is that the new pgo version now displays:
>  - dependencies
>  - reverse dependencies
>  - pkgcheck results
>  - repology.org data
>  - github pull requests
>  - stabilization bugs
>  - keywording bugs
>  - security bugs
>  - general bugs
>for each package.
>
>Additionally, there are new sites for all package maintainers, that is:
>  - Gentoo Projects (e.g. pyt...@gentoo.org)
>  - Gentoo Developers  (e.g. la...@gentoo.org
>  - Proxied Maintainers (e.g. la...@the-cow.de)
>
>The maintainer's sites contain:
>  - all packages of the maintainer
>  - all outdated packages (according to repology)
>  - all related pull requests
>  - all related bugs (general, keywording and stabilization)
>  - all security bugs
>  - the changelog of all maintained packages
>You will find the new sites under the 'Maintainers' tab.
>
>The overall appearance of the site has also slightly changed to
>display all of the new information.
>
>Currently, the new version is deployed to:
>
>  https://packagestest.gentoo.org/
>
>Everyone is welcome to take a look around and tell me whether you
>consider the new information as useful for your workflow and/or what
>you would still change.
>
>I'm looking forward to your feedback.
>
>-M

Hey Max!

Thank you very much for your work on p.g.o. I really like it, especially all 
this nice information for package maintainers.

One thing I noticed when searching for the packages of a certain maintainer. It 
always lists some packages first which are not related to that maintainer. I 
tried a few different searches and this seems to happen all the time. Probably 
it is due @gentoo.org as all the unrelated packages contain gentoo in their 
names. However this differs from search to search. Ignoring this false 
positives the actual matching results seem complete. Omitting the domain also 
does not work and only lists unrelated packages in my case.

When navigating to the maintained packages using the maintainer tab the list is 
correct.

Just want to let you know and thanks again!

-- 
Best regards
Daniel

Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list

2020-05-24 Thread Daniel Pielmeier
Sending from the proper address so this mail also reaches the list!

Daniel Buschke schrieb am 24.05.20 um 18:40:
> Oh dear! I readded the database index for file names. Now the data query
> takes ~0.3 seconds *insert self slapping image here*

Good to hear! Now it's way quicker!

> Anyway, for some strange reason I cannot reproduce the slothy behaviour
> of portage, too. I'm 100% sure the bash version took 1 second while the
> python version took 3 seconds. Strange.

Me too. The bash version queries another URL than the python version.
Could this make a difference? However as of today it does not seem so!

> @Zac: Did you add some performance optimizations in the last 30 days?
> Maybe Caching? No? Then you fixed this by pure imagination :)

Don't think so, as it was the bash version that became slower :-)

-- 
Best Regards
Daniel



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list

2020-05-24 Thread Daniel Pielmeier
Daniel Buschke schrieb am 24.05.20 um 00:05:
> Am 23.05.2020 um 23:46 schrieb Daniel Pielmeier:
>> Hm correct me if I am wrong, but from looking at the patch Zac
>> provided I think he meant that the time portage consumes is only one
>> second while the "rest" is 3.2 seconds. So there is probably a
>> potential in improving the "rest" somehow.
> 
> Yes and no. The difference between the python and bash version is
> roughly 2 seconds. One second for importing portage (which Zac patched
> away) and another second for the rest of the portage stuff. So using the
> portage API adds two additional seconds.
> 
> The python version needs 3.2 seconds on my system. As said the portage
> API (or better calling the portage API) consumes ~2 seconds. As this is
> the most time intense part the question is if there is a way to optimize
> this.
> 

I did run some tests comparing the run time of the bash version, the
python version, the python version excluding the portage API and the
python version excluding the portage API AND the data query. I run all
the commands multiple times for multiple search strings (dropping caches
in between) and compared the average times excluding min/max values to
account for network hiccups.

Here the bash version takes around 2.9 seconds while the python version
takes 3.2 seconds. Excluding the portage API it takes 2.8 seconds and
also excluding the data query it takes 0.3 seconds. So in the python
version the data query takes 2.5 seconds (probably this is similar for
the bash version) while all the rest takes 0.7 seconds

My initial tests showed that the bash version is a lot quicker than the
python version. Somehow I can not reproduce this any more. As mentioned
previously the data query is the most time consuming part in both the
bash and the python version.

So I think the python version can compete with the bash version and it
should be okay to switch to it in upcoming pfl releases.

-- 
Best Regards
Daniel P :-)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list

2020-05-23 Thread Daniel Pielmeier
Am May 23, 2020 9:17:46 PM UTC schrieb Daniel Buschke 
:
>Am 23.05.2020 um 22:55 schrieb Zac Medico:
>> Since the portage API only added about 1 second to the python script
>> time, I guess it's on par with your bash implementation. ;-P
>
>Yeah, if you substract the second for loading and the second for doing 
>queries, then yes, it's pretty par with the bash implementation :D
Hm correct me if I am wrong, but from looking at the patch Zac provided I think 
he meant that the time portage consumes is only one second while the "rest" is 
3.2 seconds. So there is probably a potential in improving the "rest" somehow.

You see he exits after line 35 and until that not a lot happens besides all 
other imports, the argument parsing and the querying of the data.

-- 
Best regards
Daniel

Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation

2020-05-05 Thread Daniel Pielmeier
Am May 5, 2020 7:31:34 PM UTC schrieb "Toralf Förster" :
>On 4/26/20 10:08 AM, Michał Górny wrote:
>> I don't think we really want to try to investigate
>> which files are actually used but focus on what's installed.
>Hi,
>
>I do wonder if the http://www.portagefilelist.de/site/start (package
>app-portage/pfl) would be part of that or not?
>The maintainer of the pfl stopped the import of new data last year due
>to lack fo time to maintain that project and is looking for a
>usccessor.

Actually the maintainer decided to continue the project.
The code is now hosted at Github [1].
The site moved to a new server and the upload is working again.

[1] https://github.com/portagefilelist

-- 
Best regards
Daniel

[gentoo-dev] Last rites: media-sound/puddletag

2018-06-08 Thread Daniel Pielmeier
# Daniel Pielmeier  (8 June 2018)
# Does not support PyQt5 as well as python 3. Upstream unresponsive.
# Masked for removal in 30 days. Bug #649112.
media-sound/puddletag

-- 
Daniel Pielmeier







[gentoo-dev] Last rites: app-cdr/backlite

2017-05-07 Thread Daniel Pielmeier
# Daniel Pielmeier <bil...@gentoo.org> (7 May 2017)
# Fails to build with ffmpeg-3. Dead upstream.
# Masked for removal in 30 days. Bug #575824.
app-cdr/backlite


0xC5E80123.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Proposal: removing server profile variants from profiles.desc

2012-10-12 Thread Daniel Pielmeier
Markos Chandras schrieb am 12.10.2012 10:08:
 
 +1. I want these profiles to *staty*. I am using this profile on my
 home boxes. It is the most minimal profile as the rest of the
 profiles pull in too much useless stuff. What is wrong with these
 profiles anyway?
 

If you want a minimal profile you don't need the server profile.

ln -s ${PORTDIR}/profiles/default/linux/${ARCH}/10.0 make.profile
gives you a minimal profile.

-- 
Regards
Daniel



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)

2011-04-18 Thread Daniel Pielmeier
Corentin Chary schrieb am 18.04.2011 11:05:

 Fyi: I ran a new scan this morning. It only took 3 hours !
 
 GNU's Parallel is really a great tool:
 `python manage.py list-packages | gparallel --eta --progress --jobs
 400% euscan | python manage.py scan-upstream --feed  /dev/null`
 
 I'll try to implement charts as soon as I've got enought data.

I really like it. Keep up the good work. It gives a warm and fuzzy
feeling if there are no unpackaged releases for the own packages :)

There is one issue I recognized. How do you get the links for the
unpackaged upstream versions and do you verify if the listed tarballs
exist? I am asking because for app-editors/bluefish [1] there are eleven
unpackaged versions listed but only sources for the three 2.0.3 releases
exist and there are no releases for 2.1.x and 2.2.x.

http://euscan.iksaif.net/package/app-editors/bluefish/

-- 
Daniel Pielmeier



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Rewrite java-config in C++ or python

2011-02-26 Thread Daniel Pielmeier
2011/2/21 Uditha Galgamuwa nandun8...@gmail.com:
 Hi dev,
I am Uditha Galgamuwa from university of moratuwa,Sri Lanka.I am
 interested in the project idea Rewrite java-config in C++ or python which
 was in last year Gsoc.As I saw this project has not been implemented in Gsoc
 2010.Will this be available for this year's idea list from Gentoo
 foundation? I have good knowledge on programming with java and some
 knowledge on C++  and a basic understanding about XSLT as well.

It is on the list for 2011 (1), so I guess you can apply for it.

(1) http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2011_ideas

-- 
Daniel Pielmeier



Re: [gentoo-dev] Please move your packages to virtual/jpeg

2010-11-08 Thread Daniel Pielmeier
2010/11/8 Dirkjan Ochtman d...@gentoo.org:

 Here's a list of packages that depend on media-libs/jpeg, to make it
 easier to scan for your packages and see if there's anything you
 should do.

Easy would be if you had added the maintainers to that list :)

-- 
Daniel Pielmeier



Re: [gentoo-dev] Please move your packages to virtual/jpeg

2010-11-08 Thread Daniel Pielmeier
Kacper Kowalik schrieb am 08.11.2010 19:30:

 net-print/hplip

Done.

Thank you very much for the list.

-- 
Daniel Pielmeier



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/quassel: metadata.xml ChangeLog quassel-9999.ebuild quassel-0.7.1.ebuild

2010-11-04 Thread Daniel Pielmeier
Tomas Chvatal (scarabeus) scarab...@gentoo.org:
 scarabeus    10/11/04 14:33:59

  Modified:             metadata.xml ChangeLog quassel-.ebuild
                        quassel-0.7.1.ebuild
  Log:
  Introduce logrotate useflag.


Please don't! See http://bugs.gentoo.org/198901

-- 
Daniel Pielmeier



Re: [gentoo-dev] New eshowkw

2010-10-26 Thread Daniel Pielmeier
Krzysztof Pawlik schrieb am 26.10.2010 18:34:
 On 10/26/10 17:39, Tomáš Chvátal wrote:
 Hello guys,
 I took last few days to rewrite our eshowkw script from bash to python
 and enhance its functionality.
 
 I did the same some time ago, check it:
 http://git.overlays.gentoo.org/gitweb/?p=dev/nelchael.git;a=blob;f=scripts/eshowkw.py.
 

Why didn't you you introduce this to the community like Tomáš did? That
would have saved some time and both of you and everyone interested could
have worked on it. It is a perfect addition to gentoolkit-dev.

I wonder how many cool tools float around in the dev-spaces none is
aware of. I remember a thread here which tried to collect those and
place them somewhere public. Instead doing so why not adding them to
gentoolkit[-dev]. I guess most of them try to make Gentoo [development]
work easier.

-- 
Daniel Pielmeier



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] bash-4.1 for stable

2010-09-05 Thread Daniel Pielmeier
2010/9/5 Mike Frysinger vap...@gentoo.org:
 if people have packages that dont work with bash-4.1, nows the time to file
 blockers of Bug 3360373
 -mike

Should be Bug #336037,  I guess.

-- 
Daniel Pielmeier



Re: [gentoo-dev] [RFC][NEW] Utility to find orphaned files

2010-04-25 Thread Daniel Pielmeier
Angelo Arrifano schrieb am 25.04.2010 13:18:
 Hello developers developers and developers,
 
 Ever wondered how much crap is left in your X-years old Gentoo box?
 
 I just developed a python utility to efficiently find orphaned files in
 the system. By orphaned files I mean the files that are present on
 system directories and don't belong to any installed package.
 
 The package builds a virtual filesystem (cache) on the RAM using python
 hash tables. Then it uses the cache to find the ownership of files
 inside user-specified dirs.
 
 Building the cache takes less than 10 seconds here in a system with 1366
 installed packages.
 
 This is not intended to be a finished program yet, I'm looking forward
 for your constructive commentaries.

What about searching the complete file system but using an exclude file where
you can put directories and files which should not be searched. It is tedious to
tell every path on the command-line. Also for instance if you specify /lib it
will also search under /lib/modules and I am sure you do not consider all
contents there as unneeded.

You also need to consider that your tool will return other false positives like
byte compiled python modules and perl header files. In general everything an
ebuild does in phases where it adds files to file-system but files are not
stored to CONTENTS (pkg_{pre,post}inst). At this point the files are needed but
not recognized by the package manager. If the ebuild does not take care of this
files when removing (pkg_{pre,post}rm) the package they will remain on the
file-system and are now unneeded.

I have written something in perl which I recently tried to implement in python
(not the same functionality like the perl version yet). I am not a good perl or
python programmer but it fits my needs especially the perl version as I know a
bit more perl than python.

I attach both versions and a sample exclude file. Maybe it will be of help.

-- 
Daniel Pielmeier


cruft.tar.bz2
Description: BZip2 compressed data


signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: media-tv/linuxtv-dvb-firmware

2010-02-08 Thread Daniel Pielmeier
# Daniel Pielmeier bil...@gentoo.org (08 Feb 2010)
# Masked for removal on 10 Mar 2010.
# Manifest failures due to upstream source changes without version bump.
# SRC_URI changes all the time. Firmware extraction fails. Overly complex
# ebuild for just installing one or two files.
# Will be replaced by updating the vdr-guide with information on how to obtain
# and install the firmware.
media-tv/linuxtv-dvb-firmware

-- 
Daniel Pielmeier




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] LibGL.la removal news item for =eselect-opengl-1.1.1-r2 going stable

2010-01-25 Thread Daniel Pielmeier
2010/1/17 Krzysiek Pawlik nelch...@gentoo.org:
 On 01/17/10 18:20, Paweł Hajdan, Jr. wrote:
 Please: When you run tools which break checksums/dates of the database,
 give the user the possibility to decide whether he really wants this.

 Good point, I didn't realize that. However, I'd rather fix the tool (for
 example to update the portage database).

 Nope, that's a bad idea unless you plan to implement such feature for portage,
 paludis and pkgcore (and possibly other package managers).

 So use revdep-rebuild (longer but correct solution) or lafilefixer (quicker 
 but
 introduces other problems).

For those who actually worry about the md5sum breakage lafilefixer
causes, they can run lafilefixer in post_src_install using
/etc/portage/bashrc. This way the correct md5sums of the la-files are
recorded into the database.

Or even better write a python implementation of lafilefixer so bug
#271129 [1] could be fixed and portage takes care of it internally.

[1] http://bugs.gentoo.org/271129

-- 
Daniel Pielmeier



Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

2009-05-15 Thread Daniel Pielmeier
2009/5/15 Marijn Schouten (hkBst) hk...@gentoo.org:

 Thilo Bangert wrote:

 Fedora is a much more current distribution than Gentoo - and has been for
 a couple of years...

 Please elaborate what exactly you think Fedora does better than we do. I have 
 no
 first-hand experience with Fedora, but from what I read I had the impression
 that sometimes they go with new stuff before it is ready, like KDE4 and 
 pulseaudio.
 I like about the current situation that we also have all those things 
 available
 AFAICS, but have very broad choices in how much we want to bleed.
 IMO this is a different issue than having supposedly popular ebuilds not in 
 main
 tree.


AFAIK Fedora (formerly Red Hat Linux) is the playground for Red Hat
Enterprise Linux like Opensuse is for Suse Linux Enterprise. So it
makes more sense to compare it with the Gentoo unstable tree instead
of the stable one. Assuming this there is probably not a big
difference in the up-to-dateness.

-- 
Daniel Pielmeier



Re: [gentoo-dev] Passing arguments to eqmake3

2009-05-13 Thread Daniel Pielmeier
Nikos Chantziaras schrieb am 13.05.2009 23:31:
 I have a package that uses qmake (from Qt 3) as its build system and
 that installs into /usr/local by default (as any well packaged software
 should do).  This of course can be overridden at build time.  In this
 case, with:
 
   qmake PREFIX=/usr projectfile.pro
 
 In order to install into /usr (as any well written ebuild should do.) In
 the ebuild however, eqmake3 doesn't seem to accept any arguments.  This:
 
   eqmake3 PREFIX=/usr projectfile.pro | die qmake failed
 
 results in:
 
  * Project .pro file PREFIX=/usr does not exists
  * qmake cannot handle non-existing .pro files
 
 when trying to emerge.  What can I do?
 

Does it work if you switch PREFIX=/usr and projectfile.pro? According to
the qt3.eclass (at which you really should take a look if you use
functions from it) qmake3 expects the pro file as first parameter and
the additional options afterwards.

Also this question is not appropriate for this list. The gentoo-devhelp
mailing-list or #gentoo-dev-help on IRC are better places for this kind
of questions.

Btw: Is there a typo in the eclass? Shouldn't it be Project .pro file
PREFIX=/usr does not exist instead of Project .pro file
PREFIX=/usr does not exists

-- 
Daniel Pielmeier



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Project summaries

2009-05-10 Thread Daniel Pielmeier
Ulrich Mueller schrieb am 10.05.2009 23:08:
 
 
 Eselect project:
 
 I've joined the project one month ago. Looks like it's my duty to
 write a status report. ;-)
 

Thank you for bringing the eselect project back to life.

-- 
Daniel Pielmeier



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding

2009-03-31 Thread Daniel Pielmeier
2009/3/30 Mounir Lamouri mounir.lamo...@gmail.com:

 portage don't install empty files (they are ignored) so it would be
 painless.


Yeah I forgot about this, I thought it just does not install empty
directories. So there will be no difference in using -e or -s if the
other package managers have the same behaviour in that regard.

-- 
Regards,
Daniel



Re: [gentoo-dev] EAPI 3's default src_install needs bikeshedding

2009-03-30 Thread Daniel Pielmeier
Ciaran McCreesh schrieb am 30.03.2009 18:43:
 On Mon, 30 Mar 2009 18:33:48 +0200
 Thomas Sachau to...@gentoo.org wrote:
  else
  for x in AUTHORS ChangeLog NEWS README; do
  if [ -e ${x} ]; then
 
 Is -e really better than -s?
 

I think -s should be used here. I have seen projects out there which
don't use the mandatory autotools files (INSTALL, NEWS, README, AUTHORS,
ChangeLog, COPYING) at all or use other files than these. So they just
place an empty file there to make automake happy instead of using the
--foreign option. Besides that it makes no sense to install empty
documentation files at all.

-- 
Daniel Pielmeier




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: Deprecating EAPI0

2009-03-21 Thread Daniel Pielmeier

Alec Warner schrieb am 21.03.2009 20:45:


Be more specific, what actual problems have you encountered?
What are some other ways we could mitigate these issues (it seems like
tool improvements could be a big one here)?



Regarding the depreciation of EAPI's I think eclasses will probably 
benefit from a low number of possible EAPI's. I am thinking about the 
introduction of more and more EAPI's which all need to be considered in 
the eclasses which will get tedious.


Regards,

Daniel



Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

2009-03-09 Thread Daniel Pielmeier
2009/3/9 Christian Faulhammer fa...@gentoo.org:

  I don't know if there is a bug somewhere (I did not find one), but
 what about having the possibility to ask for one out many USE flags of
 a dependency.  For example app-misc/gramps needs dev-lang/python with
 USE=berkdb or USE=sqlite, but Portage won't tell the user that he can
 enable one but always asks for the first in the || () string.


|| ( dev-lang/python[berkdb] dev-lang/python[sqlite] )

I had a similar case recently and detected another problem if you try
to switch from one possibility to the other.

Say you have python with berkdb compiled to satisfy the dependency and
then set dev-lang/python -berkdb sqlite in package.use. After this
world dependency calculation will fail.

The only way I found to get around this is to recompile python with
the new use flags first. Afterwards dependency calculation succeeds.

-- 
Regards,
Daniel



Re: [gentoo-dev] Re: Ideas for a (fast) EAPI=3

2009-03-09 Thread Daniel Pielmeier
2009/3/9 Christian Faulhammer fa...@gentoo.org:
 Hi,

 Daniel Pielmeier daniel.pielme...@googlemail.com:

 || ( dev-lang/python[berkdb] dev-lang/python[sqlite] )

  That's the solution currently and not the optimum.


I have discussed this yesterday with loki_val, and workaround would be
using a useflag for one database backend and if it is deactivated use
the other.

!berkdb? dev-lang/python[sqlite]
berkdb? dev-lang/python[berkdb]

-- 
Regards,
Daniel



Re: [gentoo-dev] Repository stacking and complementary overlays

2009-03-05 Thread Daniel Pielmeier
2009/3/5 Marijn Schouten (hkBst) hk...@gentoo.org:

 The problem of ebuilds in one overlay not seeing ebuilds in another overlay,
 would also be solved by the package manager NOT failing to 
 see/notice/use/allow
 ebuilds from all installed overlays. Then there would be no need for a 
 hierarchy
 among overlays.

Not sure if this has been mentioned already, but why not making the
profile only affect the corresponding repository and allow repository
aware configuration (make.conf and /etc/portage/* in case of portage
being the package manager)? That way repository based masking and
unmasking would be possible.

-- 
Regards,
Daniel



Re: [gentoo-dev] Re: what happened to /etc/init.d/hal{d,daemon,whatever} script ?

2008-12-24 Thread Daniel Pielmeier
2008/12/23 Doug Goldstein car...@gentoo.org:

 Looks like people have been truly over-zealous when removing die
 statements from ebuilds lately. I've added back to HAL an assortment of
 die statements.

 I hope this hasn't happened in too many other ebuilds.


Maybe then someone should take a look at bug #233184 and close it.

-- 
Regards,
Daniel



Re: [gentoo-dev] Re: Last Rites: app-portage/udept

2008-12-16 Thread Daniel Pielmeier
2008/12/16 Robert R. Russell nahoy_kb...@hushmail.com:

 Does anyone have a substitute for udept's clean word file and
 clean /etc/portage options?


With clean world file you mean dep -w or dep --pruneworld and this
is what we are already discussing here.

eix-test-obsolete is quite usable as replacement for finding out
uneeded entries in /etc/portage

-- 
Regards,
Daniel



Re: [gentoo-dev] Re: Last Rites: app-portage/udept

2008-12-16 Thread Daniel Pielmeier
2008/12/16 Duncan 1i5t5.dun...@cox.net:

 FWIW, that's why I originally merged udept.  However, by that time I had
 gotten used to using a set of (local) stub scripts that added in all the
 appropriate switches, including --oneshot, so once I used udept to clean
 up the mess I had created before that, as a Gentoo noob, I was fine.  I
 didn't have to worry about using udept for that any more.

 I'd suggest a similar solution for you, either stub scripts as I use, or
 make use of EMERGE_DEFAULT_OPTS to put --oneshot in there.  If you use
 the latter, you can then create a stub using --ignore-default-opts
 --noreplace to add the (presumably already merged) entries to your world
 file.

 I actually use --oneshot when merging new stuff now, thus effectively
 giving me a temporary/testing merge option.  Then if I decide to keep
 it, I run my stub-script to add it to world, and until I either do that
 or delete it, it stays listed in the --pretend --depclean run I do
 routinely after my weekly update. =:^)

 (If you're interested in my stub scripts, mail me offlist and ask.  I can
 tarball them up and send them to you, along with a description of the
 method to my madness.  I've considered creating a proper package for
 them as I imagine quite a few people would find it useful, but I haven't,
 yet, and in some ways, they're almost too trivial to package.  Maybe if I
 had someone else test them and tell me whether they found them useful
 enough to be worth packaging...  You may also find Steve Long's emerge
 helper script useful.  It's a bit more featureful than my stub scripts,
 which are pretty much just bare emerge wrappers.  I believe it can be
 found in the forums.)

You are right avoiding this unneeded entries in the world file in the
first place is the way to go but somehow these things slip in and then
it would be good to have something to find out about it.

Also I don't like this kind of wrapper scripts but maybe I should get
used to it. Another thing is that I have other stuff set as
EMERGE_DEFAULT_OPTS that I probably don't want to miss when using
--ignore-default-opts in combination with --noreplace.

-- 
Regards,
Daniel



Re: [gentoo-dev] Re: Last Rites: app-portage/udept

2008-12-15 Thread Daniel Pielmeier
Duncan schrieb am 16.12.2008 00:47:
 Paul Varner fuzzy...@gentoo.org posted
 1229371818.21630.7.ca...@txslpc1d36.wkst.vzwnet.com, excerpted below, on 
 Mon, 15 Dec 2008 14:10:17 -0600:
 
 # Paul Varner fuzzy...@gentoo.org (14 Dec 2008) # Dead upstream,
 masked for removal in ~30 to 60 days. app-portage/udept

 Additionally, it doesn't play well with EAPI's greater than zero.

 The removal bug is Bug #250839.  If upstream comes back alive or someone
 forks and actively maintains, I will unmask or re-add to the tree.
 
 Ouch!  This one hurts!

++

I really hope someone steps up and continues maintaining this great
tool. Before EAPI's greater than zero existed this tool combined many
things I needed for daily use within one single application.

 The main thing I use it for, and therefore the question I have about any 
 useful substitute, is quickly getting a changelog when portage won't spit 
 one out.  In particular, when there's a USE flag change in an existing 
 package, or a downgrade, emerge --log won't output anything, because it's 
 not an upgrade.  However, I find the info in such logs often useful!
 
 Of course I can check the package category and type in the whole long 
 path to the changelog and edit/head/view it by hand, but a quick dep -j 
 pkg is a lot faster and very useful!
 
 While I'm at it, is there anything useful to display metadata.xml?  In 
 particular, the long descriptions and use flags can be useful.  With 
 use.desc and especially the local version thereof going deprecated, and 
 with additional info about global flags sometimes in the metadata...

Regarding metadata.xml there is (besides querying Willikins on IRC)
emeta. Take a look at bug 248278 [1].

[1] http://bugs.gentoo.org/show_bug.cgi?id=248278




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Last Rites: app-portage/udept

2008-12-15 Thread Daniel Pielmeier
Douglas Anderson schrieb am 16.12.2008 01:28:
 On Tue, Dec 16, 2008 at 9:06 AM, Daniel Pielmeier
 daniel.pielme...@googlemail.com wrote:
 Duncan schrieb am 16.12.2008 00:47:
 While I'm at it, is there anything useful to display metadata.xml?  In
 particular, the long descriptions and use flags can be useful.  With
 use.desc and especially the local version thereof going deprecated, and
 with additional info about global flags sometimes in the metadata...
 Regarding metadata.xml there is (besides querying Willikins on IRC)
 emeta. Take a look at bug 248278 [1].

 [1] http://bugs.gentoo.org/show_bug.cgi?id=248278

 
 emeta will likely become `equery meta' in the next release of
 gentoolkit, but feel free to use it from the overlay for now.
 
 Regarding equery, there's a changes option that is just waiting to
 be written. Considering udept's changleog function is about 30 lines,
 it should be trivial to do. If people are interested, I can handle
 that. It's something I would like to have, also.
 
 I hope to have the upgraded gentoolkit available for testing within a few 
 weeks.

Good to hear!

Besides that, is there anything similar to dep --pruneworld.

It happens to me sometimes that I forget --oneshot and packages are
added to the world file that are not intended to be there. So this
option gives an overview over packages in world that have no reverse
dependencies and thus are probably not needed. There might still be some
packages without reverse dependencies in the world file that are
intended to be there because the user wants it there, but being
presented with a list of possible unneeded packages it is more easy to
determine which are intended to be there and which are not.

For checking the reverse dependencies of single packages there is of
course emerge -pv --depclean atom, but it is a tedious job to this
for every entry in the world file. I hacked something together which
runs the above command for every entry in world but this is very slow
and dep is much faster doing this check.

Regards,

Daniel



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Last Rites: app-portage/udept

2008-12-15 Thread Daniel Pielmeier
2008/12/16 Daniel Pielmeier daniel.pielme...@googlemail.com:

Hm, looks like I have mixed up something here. The pruneworld option
looks for packages that _have reverse dependencies_ and thus are
probably unneeded and not the other way round


 Besides that, is there anything similar to dep --pruneworld.

 It happens to me sometimes that I forget --oneshot and packages are
 added to the world file that are not intended to be there.


So this option gives an overview over packages in world that have
reverse dependencies and thus are probably not needed. There might
still be some packages with reverse dependencies in the world file
that are intended to be there because the user wants it there, but
being presented with a list of possible unneeded packages it is more
easy to determine which are intended to be there and which are not.


 For checking the reverse dependencies of single packages there is of
 course emerge -pv --depclean atom, but it is a tedious job to this
 for every entry in the world file. I hacked something together which
 runs the above command for every entry in world but this is very slow
 and dep is much faster doing this check.


-- 
Regards,
Daniel



Re: [gentoo-dev] A tool helps to diff and override config files

2008-12-04 Thread Daniel Pielmeier
2008/12/4 Song Ma [EMAIL PROTECTED]:
 Hi,

 With Gentoo if the user runs emerge --update --newuse --deep world, the
 config file under /etc may be updated and get the new config file named as
 ._cfg_, for example,  ._cfg_ntp.conf. Normally I will
 compare this newly updated config file with my existing one, then decide if
 I am going to override the existing one with new one or discard the new one
 since I must keep my existing setting. It is not very efficient to do these
 actions with command lines such as diff, cp or mv one by one. I wrote
 a tool with text menu to help Gentoo user compare and copy new the new
 config file conveniently. Does anyone have interest about it? What should I
 do if I want to make it open source and maintain it for Gentoo users?

 A screen shot for the tool use:



Why reinventing the wheel?

What about using existing tools with much more functionality like
etc-update, dispatch-conf, cfg-update or etc-proposals?

-- 
Regards,
Daniel



Re: [gentoo-dev] To ELISA, PIGMENT, PIGMENT-PYTHON dev's

2008-11-10 Thread Daniel Pielmeier
2008/11/10 Mateusz Mierzwinski (me.matheos.org) [EMAIL PROTECTED]:
 I just want to install latest media-tv/Elisa (0.5.17 i think) (This is
 Linux MC) but guess what? There is no Elisa in portage (there was,
 because I was checking the forums and even found some Wiki about that -
 that was deleted because of administrator that don't do backups). Same
 thing with media-libs/pigment and dev-python/pigment-python - black
 hole. So what to do, when Python on Gentoo don't have that module (or
 name it as You like)? Is there some back steps in portage? Maybe some
 dev gone for lunch or something?

snip
 Do I need to write it by myself?

This packages have never been in the tree. Take a look at bug #159086.
Also this overlay [2] may be of help.

[1] http://bugs.gentoo.org/159086
[2] http://overlays.gentoo.org/dev/dang/browser

-- 
Regards,
Daniel



Re: [gentoo-dev] zeroconf/avahi USE flag

2008-11-05 Thread Daniel Pielmeier
2008/11/4 Doug Goldstein [EMAIL PROTECTED]:
 bonjour is Apple specific branding for zeroconf. This is another case
 that needs to be changed.

I just came up with this as nobody mentioned it before :-)

 zeroconf/avahi/howl/bonjour/mdnsresponder all need to be condensed.

++ one flag for all implementations.

-- 
Regards,
Daniel



Re: [gentoo-dev] zeroconf/avahi USE flag

2008-11-04 Thread Daniel Pielmeier
Doug Goldstein schrieb am 04.11.2008 18:11:
 Hey all,
 
 A few ebuilds treat things differently with regard to this situation and
 it really needs to get rectified.
 
 net-misc/ntp
 zeroconf? ( || ( net-dns/avahi net-misc/mDNSResponder ) )
 
 net-print/cups
 zeroconf? ( !avahi? ( net-misc/mDNSResponder ) )
 avahi? ( net-dns/avahi )
 
 kde-base/kdelibs
 !avahi? ( !bindist? ( net-misc/mDNSResponder !kde-misc/kdnssd-avahi ) )
 avahi? ( kde-misc/kdnssd-avahi )
 
 
 To name a few... the above will cause blockers for people depending on
 their merge order if they have the following in their USE flags.
 
 USE=zeroconf -avahi
 
 
 Maybe we should clean the whole thing up and do like net-misc/ntp does
 it. Thoughts?
 
 

There is also a bonjour use flag which should be considered.

pidgin-2.5.2.ebuild:bonjour? ( net-dns/avahi )
bonjour use flag pulls in net-dns/avahi

squeezecenter-7.2.1.ebuild: bonjour? ( net-misc/mDNSResponder )
bonjour use flag pulls in net-misc/mDNSResponder

vlc-0.9.5.ebuild:   $(use_enable avahi bonjour)
avahi use flag enables bonjour support in vlc. Maybe the avahi flag
should be replaced with zeroconf here too.

Regards,

Daniel



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Bug wrangling

2008-09-08 Thread Daniel Pielmeier

Joe Peterson schrieb am 08.09.2008 22:22:


Sorry if this answer can be found elsewhere, but if one has a proxy maintainer
(i.e. not a Gentoo dev) for a package, can/should this person be added to
metadata.xml?  Is there a special tag for this?  I can certainly see this
being helpful (so that person automatically gets on the cc list at least).

Thanks, Joe



I maintain two packages [1,2] as proxy and I am listed in metadata.xml 
with the normal maintainer tag. There are also other packages where 
proxy maintainers are listed this way in metadata.xml. Don't know if 
there is an extra tag for proxy maintainers though.


[1] 
http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/ttcut/metadata.xml?view=markup
[2] 
http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/channeleditor/metadata.xml?view=markup


Regards,

Daniel



Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo

2008-03-20 Thread Daniel Pielmeier
2008/3/20, Doug Goldstein [EMAIL PROTECTED]:
 Roy Marples wrote:
  On Thursday 20 March 2008 06:59:24 Josh Saddler wrote:
 
  I'll be working on the migration guide with Cardoe (and possibly Roy, if
  we can tag-team him into submission). As much of a pain as migration
  will be, we'll definitely need a howto. Fun, fun.
 
 
  I already provide documentation with commands in example config files and 
  man
  pages that cover nearly every aspect on OpenRC and all it's commands.
 
  The nice thing about not being a Gentoo dev means I don't feel the urge to
  write a migration how to. However, here's a really good primer.
 
  1) Install OpenRC
  2) Review all updated files in /etc/conf.d/ and /etc/rc.conf [1] [2]
  3) If using a volume such as LVM, you'll find an appropriate init script
  in /etc/init.d that you need to add to the boot runlevel.
  4) Carry on as normal [3]
 
  Thanks
 
  Roy
 
  [1] The case of variable names has been changed from UPPER to lower. This is
  for a few reasons (removes confusion vs environment vars, looks nicer).
  However, *existing* UPPER case vars should still work.
  [2] Paludis users will need to ensure that the init scripts checkfs and
  checkroot are removed. I don't care whose bug this is, but neither side
  wants to fix it.
  [3] A reboot is currently needed as for some reason state data isn't 
  migrated
  from baselayout-1. This is probably due to OpenRC being split from 
  baselayout
  and the code is pretty much the same here. Maybe some plucky Gentoo ebuild
  dev can step up and fix it.
 
 You missed the whole /etc/modules.autoload.d/* - /etc/conf.d/modules
 but I already discussed that with Josh for the guide. ;)
 --
 gentoo-dev@lists.gentoo.org mailing list



Maybe the XSESSION variable disappearing from /etc/rc.conf and the
changed settings in /etc/conf.d/clock are worth consideration too!

Regards,

Daniel
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] When does gnome-2.22 come in portage?

2008-03-13 Thread Daniel Pielmeier
2008/3/13, Shaochun Wang [EMAIL PROTECTED]:
 Gnome 2.22 was out recently. When does it come in portage?

When the gentoo-devs add it!
They are aware of the newly released gnome, so be patient!

Regards,

Daniel
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-20 Thread Daniel Pielmeier
2007/12/18, Joe Peterson [EMAIL PROTECTED]:
 Santiago M. Mola wrote:
  One example was mentioned in this thread before: You cannot use
  find -name '*.ebuild' anymore.
 
 
  So people could use a bit more elaborated expression to find them.
  Things like this shouldn't be a reason for not applying
  EAPI/GLEPs/PM-behaviour changes. If this GLEP is approved, it would be
  fine to publish a quick guide of recipes to migrate scripts which rely
  on the old naming convention and that should be enough.
 
  IMO, keeping us away from improvements to Gentoo because they break
  backwards compatibility with third party scripts is a no-go. Of
  course, this kind of changes can't happen once a month, but they can
  happen from time to time.

 I don't think this is about strictly maintaining backwards
 compatability.  You are right that we should not let this impede
 progress.  My objection is that the proposed scheme does not appear to
 make the system more elegant, but rather it creates complexity,
 potential errors (mismatches in representions of EAPI), and introduces a
 rather unorthodox and complicated file extension pattern.

 I also do not see why there are not other more elegant, transparent, and
 automatic ways to determine EAPI without sourcing.  I put forth an idea,
 and I understand the objections to it, but I'm just brainstorming, and
 there *must* be other ways that retain portage's elegance and simplicity.

 -Joe
 --
 [EMAIL PROTECTED] mailing list



Just another brainstorming attempt. Is it possible to use one single
file per eapi which lists all ebuilds using a specific eapi like
package.eapi-name and is stored in the profiles. Or even one single
file which lists the ebuild and its eapi.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Patch make_desktop_entry to produce entries that validate better

2007-11-17 Thread Daniel Pielmeier

Petteri Räty schrieb:

Petteri Räty kirjoitti:

Any objections to the attached patch:

[EMAIL PROTECTED] ~ $ desktop-file-validate
/usr/share/applications/jedit-jedit.desktop
/usr/share/applications/jedit-jedit.desktop: warning: key Encoding in
group Desktop Entry is deprecated
/usr/share/applications/jedit-jedit.desktop: warning: value  for key
Path in group Desktop Entry does not look like an absolute path

Regards,
Petteri



Hmm. Wrong patch attached.


There are two other bugs (#197891, #181999) which are related to changes
regarding the freedesktop specs. One for the Encoding key depreciation
which you can see above too and one for the Icon key which should not
specify a suffix if the value does not use the full path to the icon.
These could be taken into consideration when desktop-file-utils-0.14 is
stable on all archs.

I have attached an updated patch.

Regards,

Daniel



--- eutils.eclass   2007-11-18 02:06:50.0 +0100
+++ eutils.eclass   2007-11-18 02:32:44.0 +0100
@@ -741,7 +741,7 @@
 
local exec=${1}
local name=${2:-${PN}}
-   local icon=${3:-${PN}.png}
+   local icon=${3:-${PN}}
local type=${4}
local path=${5}
 
@@ -875,18 +875,18 @@
 
cat -EOF  ${desktop}
[Desktop Entry]
-   Encoding=UTF-8
Version=1.0
Name=${name}
Type=Application
Comment=${DESCRIPTION}
Exec=${exec}
TryExec=${exec%% *}
-   Path=${path}
Icon=${icon}
Categories=${type};
EOF
 
+   [[ ${path} ]]  echo Path=${path}  ${desktop}
+
(
# wrap the env here so that the 'insinto' call
# doesn't corrupt the env of the caller
@@ -938,7 +938,6 @@
 
cat -EOF  ${desktop}
[Desktop Entry]
-   Encoding=UTF-8
Name=${title}
Comment=This session logs you into ${title}
Exec=${command}


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-print/cups: ChangeLog cups-1.3.4-r1.ebuild cups-1.3.4.ebuild

2007-11-10 Thread Daniel Pielmeier
Ciaran McCreesh schrieb:
 On Sat, 10 Nov 2007 13:56:31 +0100
 Denis Dupeyron [EMAIL PROTECTED] wrote:
 On Nov 9, 2007 11:28 AM, Ciaran McCreesh
 [EMAIL PROTECTED] wrote:
 Looks like it's a silly hack
 [...]
 Which is rather perverse
 Whoever it was, whatever it was, nobody deserves to have his/her work
 to be qualified this way. All of us (including you) would benefit of a
 more neutral language. Although not totally offensive, you're walking
 a fine line here. Please make sure this little quirk of yours doesn't
 bite us (that includes you again) anymore.
 
 I'm guessing you're not a native English speaker. Please leave such
 commentaries to those who are, since your misunderstandings are only
 going to cause offence where none previously existed.
 

Gentoo is a worldwide project, so i guess many of the contributors are
not native speakers. See the gentoo-devs all over the world [1] as an
example. Okay english is the common language here, but is it that
difficult to articulate in a way that everybody can understand and not
to use words which could easily be misunderstood.

Lucky you are that your native language is one of the world's most
widely spoken languages. Imagine to express yourself in a language you
are not familiar with!

I hope everybody can understand this, as i am not a _native speaker_ too!

[1] http://www.gentoo.org/proj/en/devrel/roll-call/devmap.xml?
-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Managing users and groups

2007-09-08 Thread Daniel Pielmeier
Hi,

I have recently checked the contents of /etc/{group,passwd,shadow} and
found that there are users and groups which are not needed anymore
because the packages which need them have also been removed. I have
deleted some of them which are unnecessary with userdel and groupdel.

I have experienced that some ebuilds use enewuser and enewgroup to
create users and groups which are needed. Some print a elog notice in
pkg_postinst to inform the user to create them manually.

I think it would be a good idea to either leave it to the user (inform
them via pkg_postinst) to create the groups and users or better create
the needed groups and users in pkg_preinst and remove them at uninstall
in pkg_postrm (edeluser end edelgroup may have to be implemented to
achieve this). In this case the configuration files did not get
cluttered with unneeded entries. To be sure that no group or user is
removed which is still needed some kind of configuration file could be
used to prevent the deletion of shared groups/users. With contents like
group/user X needed by ebuild Y.

While writing this i have found GLEP-27. What is the current status
concerning this?

Regards,

Daniel


-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Managing users and groups

2007-09-08 Thread Daniel Pielmeier
Mike Frysinger schrieb:
 On Saturday 08 September 2007, Daniel Pielmeier wrote:
 While writing this i have found GLEP-27. What is the current status
 concerning this?
 
 presumably you'd search bugzilla and come across 53269
 -mike

I have searched bugzilla, but not for the specific glep. This does not
look like a big issue as there is no progress in this bug at all (sorry
i can not help out there, i am just a user not a programmer as i have
mentioned before).

Why not using something similar to Comment 16 in Bug 8634

USERDEPEND=someuser
GROUPDEPEND=somegroup

A group/user is created when no other ebuild has the dependency and is
removed when the last ebuild has been removed which needs it?

Okay the approach in the glep look much cleaner, but this is maybe more
easier to implement!
-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] [QA] Repoman check for committing ebuilds with stable keywords

2007-08-27 Thread Daniel Pielmeier
Hi!

From time to time i recognize that ebuilds are committed straight to
stable into the gentoo tree, especially for version bumps where no
changes in the ebuild are required. It also happens to me when providing
ebuilds via bugzilla!

So what about adding a repoman check to cover this. If a ebuild is
committed to the tree with stable keywords repoman could give a warning
about stable keywords in IUSE. I know there are cases where it is
necessary to commit an ebuild with stable keywords because of security
issues or others. But better be reminded about this than forgetting it.

I don't know if such a check already exists or is work in progress, i
have just found nothing comparable in repoman --help under QA keywords.

Any thoughts?

Regards,

Daniel
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [QA] Repoman check for committing ebuilds with stable keywords

2007-08-27 Thread Daniel Pielmeier
  http://bugs.gentoo.org/show_bug.cgi?id=110443
 

Thanks!

It looks rather old! Why isn't it implemented?

Regards,

Daniel
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [QA] Repoman check for committing ebuilds with stable keywords

2007-08-27 Thread Daniel Pielmeier
Mike Frysinger schrieb:
 On Monday 27 August 2007, Daniel Pielmeier wrote:
   http://bugs.gentoo.org/show_bug.cgi?id=110443

 It looks rather old! Why isn't it implemented?
 
 i bet if you posted a patch it'd get done quicker
 -mike

I would do so if i had any python skills ;)
For me as a non developer/programmer this seems not to be that
difficult! But as i have no clue how repoman is working, it is probably
more difficult than i think!

Regards,

Daniel
-- 
[EMAIL PROTECTED] mailing list




Re: [gentoo-dev] Last rite x11-misc/login-app

2007-05-02 Thread Daniel Pielmeier
Samuli Suominen schrieb:
 # Samuli Suominen [EMAIL PROTECTED] (2 May 2007)
 # Masked for removal in 30 days. See bug #176150.
 # Use x11-misc/slim instead.
 x11-misc/login-app

Thanks for reacting so fast and adding slim to the tree!

Regards,

Daniel
-- 
[EMAIL PROTECTED] mailing list