Re: [gentoo-dev] Repository stacking and complementary overlays
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: Ideas for a (fast) EAPI=3
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/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] RFC: Deprecating EAPI0
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] EAPI 3's default src_install needs bikeshedding
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] EAPI 3's default src_install needs bikeshedding
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] Project summaries
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] Passing arguments to eqmake3
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] RFC: Project proposal -- maintainer-wanted
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] LibGL.la removal news item for =eselect-opengl-1.1.1-r2 going stable
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
[gentoo-dev] Last rites: media-tv/linuxtv-dvb-firmware
# 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] [RFC][NEW] Utility to find orphaned files
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
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
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
Re: [gentoo-dev] Patch make_desktop_entry to produce entries that validate better
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] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
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] When does gnome-2.22 come in portage?
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] OpenRC baselayout-2 meets Gentoo
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] Bug wrangling
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] zeroconf/avahi USE flag
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] zeroconf/avahi USE flag
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] To ELISA, PIGMENT, PIGMENT-PYTHON dev's
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] A tool helps to diff and override config files
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] Re: Last Rites: app-portage/udept
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
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/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] Re: Last Rites: app-portage/udept
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 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: what happened to /etc/init.d/hal{d,daemon,whatever} script ?
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] Proposal: removing server profile variants from profiles.desc
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] Last rite x11-misc/login-app
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
[gentoo-dev] [QA] Repoman check for committing ebuilds with stable keywords
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
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
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
[gentoo-dev] Managing users and groups
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
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
Re: [gentoo-dev] bash-4.1 for stable
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] New eshowkw
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
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/quassel: metadata.xml ChangeLog quassel-9999.ebuild quassel-0.7.1.ebuild
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] Please move your packages to virtual/jpeg
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
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
Re: [gentoo-dev] Rewrite java-config in C++ or python
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] Re: euscan proof of concept (like debian's uscan)
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
[gentoo-dev] Last rites: app-cdr/backlite
# 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
[gentoo-dev] Last rites: media-sound/puddletag
# 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
Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
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
Re: [gentoo-dev] speeding up usage of portage in e-file / portage file list
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] speeding up usage of portage in e-file / portage file list
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] [PATCH 0/4] Eclass for single-impl Lua ebuilds
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
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] speeding up usage of portage in e-file / portage file list
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] RFC: packages.g.o: new features available
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
[gentoo-dev] Announcement: PFL is looking for a new maintainer
Hello All! I am posting this here (gentoo-dev, gentoo-user) at the request of the upstream maintainer to reach a larger audience. PFL upstream will stop working on the project and is looking for a new maintainer. For those who don't know what PFL is. It is basically a database that allows users to search for packages that provide a file. Say you want to run a command/program, but you don't know which package provides it. This is where PFL can help. The database itself is populated by users. When you install app-app-portage/pfl [1], there's a script that sends a list of installed packages and their contents to the server. A second script is used to query for packages that owe a file. There is also a web interface [2] which provides similar functionality. I believe a similar feature is also available for Ubuntu (maybe other distributions too, not sure if this is Ubuntu specific). If you type a command on the command line that is not available, you get suggestions for packages that contain the program. I now see two possibilities. Either another user takes over the project or Gentoo itself takes over the maintenance. But someone has to do the work and further maintenance. Otherwise the project will be terminated. If you are interested or have something to share, please join the discussion in the forum [3] to keep everything in one central place. Thanks! [1] https://packages.gentoo.org/packages/app-portage/pfl [2] https://portagefilelist.de/ [3] https://forums.gentoo.org/viewtopic-t-1163382.html -- Best Regards Daniel
