[gentoo-dev] New project: LXQt
Hi, I'm announcing the LXQt project [1] to replace the old herd as preparation for GLEP 67 implementation. See also the appropriate bug [2]. It seems like there is a consensus about project creation (Ben de Groot, what do you think? You haven't commented on bug). The only issue remaining is do we want to have this project as Qt subproject. What do people from Qt project think? [1] https://wiki.gentoo.org/wiki/Project:LXQt [2] https://bugs.gentoo.org/show_bug.cgi?id=569412 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] LLVM static libs
Hi, On 09/20/2015 11:14 PM, Alexandre Rostovtsev wrote: > On Sun, 2015-09-20 at 22:32 +0200, Jauhien Piatlicki wrote: >> Hi, >> >> the first question is addressed both to llvm-dev and gentoo-dev. The >> second one is Gentoo specific. >> >> Is there any possibility to build LLVM both as static and shared libraries? >> >> What I see currently is that our ebuild makes LLVM to build shared libs >> unconditionally. Is there a possibility (if it is impossible to build >> both lib types) to at least give to user control on what kind of libs he >> will have? > > I don't quite understand why you are asking all of gentoo-dev about this. > I'm asking because there can be some reasons not to have static-libs for LLVM that I do not see and somebody may point me to them. Also from a quick look at LLVM cmake files it seems that it can have either shared or static libs (not both at a time), that's another reason why I'm asking list, may be I'm wrong here and somebody will show me how to proceed here. Another question there were static libs installed by LLVM once, but they stopped to be built now, may be somebody will comment why. Regards, Jauhien signature.asc Description: OpenPGP digital signature
[gentoo-dev] LLVM static libs
Hi, the first question is addressed both to llvm-dev and gentoo-dev. The second one is Gentoo specific. Is there any possibility to build LLVM both as static and shared libraries? What I see currently is that our ebuild makes LLVM to build shared libs unconditionally. Is there a possibility (if it is impossible to build both lib types) to at least give to user control on what kind of libs he will have? -- Jauhien Piatlicki signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] <>-DEPENDS
On 09/07/2015 02:35 PM, Marc Schiffbauer wrote: > Hi, > > > I'd like to propose a new kind of DEPEND syntax: <> > > This would mean "Any version but the one specified" and is usefull when > you have a dependency on another package but a single version of it is > not compatible for example. +1 from me. But how will this affect our already not very fast and correct depsolver? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] dev-rust category
Hi, On 09/07/2015 07:28 AM, Daniel Campbell wrote: > On 09/06/2015 02:00 PM, Jauhien Piatlicki wrote: >> Hi, > >> On 09/05/2015 11:23 PM, Daniel Campbell wrote: >>> On 09/05/2015 01:04 PM, Matthew Thode wrote: > >>>> I think cargo should probably go in dev-util with other rust >>>> libraries and programs going into dev-rust as needed, but >>>> that's just me :D >>> >>> Agreed. dev-util until it grows in size (isn't the >>> recommendation 5-10+ pkgs?), then dev-rust. Despite the package >>> moves being somewhat cumbersome, it makes more sense to do it >>> once it's clear Rust has an ecosystem going rather than catch >>> stragglers in its infancy. >>> > >> Ok, looks quite logical for me. So the next question. I remember >> portage had some problems with moving packages. Would it work if >> I'll move dev-rust/cargo to dev-util/cargo in our overlay now. And >> later when rust infrastructure grows move it in the main tree back >> to dev-rust? Or will it break something? > >> -- Jauhien > > > Now that we're on git, I don't see why a quick `git mv old-cat/foo > new-cat/foo` wouldn't get the job done. Don't quote me on it, but my > guess is it would work fine. Then make sure the profile data gets > updated by updating the relevant file(s). > > If you're keeping it in an overlay until you think it's ready for the > Gentoo repo, you may as well keep it whatever you want since it's not > bound by Gentoo policy. I would start with dev-util, even in tree, and > migrate to dev-rust when it reaches critical mass on packages (I'd say > at least ten). > > I'm speaking not about git, but about portage move [1] (see Moving ebuilds there). This is unrelated to version control. [1] https://devmanual.gentoo.org/ebuild-maintenance/index.html signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] dev-rust category
Hi, On 09/05/2015 11:23 PM, Daniel Campbell wrote: > On 09/05/2015 01:04 PM, Matthew Thode wrote: >> I think cargo should probably go in dev-util with other rust >> libraries and programs going into dev-rust as needed, but that's >> just me :D > > Agreed. dev-util until it grows in size (isn't the recommendation > 5-10+ pkgs?), then dev-rust. Despite the package moves being somewhat > cumbersome, it makes more sense to do it once it's clear Rust has an > ecosystem going rather than catch stragglers in its infancy. > Ok, looks quite logical for me. So the next question. I remember portage had some problems with moving packages. Would it work if I'll move dev-rust/cargo to dev-util/cargo in our overlay now. And later when rust infrastructure grows move it in the main tree back to dev-rust? Or will it break something? -- Jauhien signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] dev-rust category
Hi, I have plans to split ?/cargo-bin [1] package from the dev-lang/rust-bin one. We have already dev-rust/cargo package in the rust overlay[2]. It would be logical to have dev-rust/cargo-bin package then. But there is a problem: it will be the only package in this category in the tree and it is not welcome to have categories with small number of packages. Other rust stuff will appear, but later (with no estimate), as a number of problems with packaging source rust packages should be solved before (afaik upstream also has plans to improve rust packaging). The same about moving source cargo to the tree. So what is better, create dev-util/cargo-bin package and later, when rust infrastructure grows, move it to the dev-rust category or create new category now? [1] https://crates.io/ [2] https://github.com/Heather/gentoo-rust -- Jauhien signature.asc Description: OpenPGP digital signature
[gentoo-dev] Current policy for overlays, was: Moving sci-physics/herwig++ to the main tree
Hi all, I've started to work on moving of sci-physics/herwig++ into the tree after discussion with Andrew (see below). It takes with it a bunch of packages: * sci-physics/rivet * sci-physics/yoda * sci-physics/thepeg * sci-physics/looptools I remember some discussions about ideas to make the tree more for core packages and overlay for specialized stuff. How did we decided finally what is better: having specialized stuff in overlays, or moving it to the tree when it is mature enough? What are pros and cons? On 08/01/2015 04:51 PM, Andrew Savchenko wrote: Hi, On Sat, 01 Aug 2015 14:42:36 +0200 Jauhien Piatlicki wrote: On 08/01/2015 01:51 PM, Andrew Savchenko wrote: do you mind moving herwig++ from the science overlay to the main Gentoo tree? (If you don't have time for this, but don't mind, I can move the package myself.) I do not see the reason for having strictly scientific packages in the main tree (just my opinion), but if you need it there for some purpose, I can move it. I just would like to see exactly what is your reason. My idea is consistency. We already have plenty of generators and related software in the tree: pythia, herwig, clhep, fastjet, hepmc, siscone. It would be nice to see herwig++ joining the family as well. IMO overlays are good for staging or to help non-developers to contribute, but eventually mature software should join the tree. Best regards, Andrew Savchenko signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] more golang updates
Hi, are there any docs about how to package go stuff? As I would like to package client for google drive [1], because net-misc/grive is broken. [1] https://github.com/odeke-em/drive On 07/24/2015 12:53 AM, William Hubbs wrote: All, Here is the improvement I mentioned in the earlier thread. golang-base.eclass contains the base functions that were in golang-build but can be used separately from either golang-vcs or golang-build. golang-vcs and golang-build are also being updated to inherit golang-base. Let me know what you think. William signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC] Rebooting the Installer Project
On 07/21/2015 06:08 PM, Andrew Savchenko wrote: On Tue, 21 Jul 2015 09:10:52 -0500 J.Rutkowski wrote: The problem I have with using Sabayon to ultimately install Gentoo is it takes way too much work than just doing a Gentoo install... You missed my point. I'm interesting not in minimizing total time spent for installation and configuration. I'm interested in fast bootstrapping from here your box to you need to have this work done. Of course proper configuration and fine tuning will require time, but this should be done later, not right away. Calculate Linux [1] is a good idea. It is fully compatible with Gentoo and creates no additional pain with updates, but gives you fully working system at the very beginning. [1] http://www.calculate-linux.org/ -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Celebration subthread: Re: Git Migration: launch plan schedule (2015/Aug/08-09)
That's really really great. Thanks to all who contrinuted. On 07/03/2015 09:02 AM, Duncan wrote: [Let this be the celebratory subthread, so people can post if they feel the need, but others can safely skip if they so desire...] NP-Hardass posted on Thu, 02 Jul 2015 17:42:46 -0400 as excerpted: [Reordered to quote/reply order.] On July 2, 2015 5:39:52 PM EDT, Robin H. Johnson robb...@gentoo.org wrote: The Git migration is moving forward, and I'd like to announce a tentative schedule for that end. https://wiki.gentoo.org/wiki/Project:Infrastructure/Git_migration#Status 2015/08/08 15:00 UTC - Freeze 2015/08/08 19:00 UTC - Git commits open for developers 2015/08/09 01:00 UTC - Rsync live again (with lagged changelog) 2015/08/11 - History repo available to graft 2015/08/12 - rsync mirrors carry up-to-date changelogs again Three cheers! Glad to see it happening. Thank you to everyone who helped to make this happen. I doubt I'm the only one who assigned a well under 50% chance of actually seeing it happen, believing gentoo was ultimately destined to become a Linux historical footnote due to failure to switch to git! I've been on gentoo over a decade, now, and stuck on CVS, I honestly didn't know if it'd last another. Obviously, I'm VERY glad to see the git switch actually scheduled! =:^) Thanks... just isn't a sufficient word to convey my gratitude to all the folks that have been working on this. Seriously. This switch to git puts you up with the gentoo greats such as DRobbins, in my book. Because without it, let's face it, gentoo /was/ slipping ever so slowly into history, and this really does, I believe, give us a chance to turn that around. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
Hi Daniel, On 06/20/2015 05:35 AM, Daniel zlg Campbell wrote: Sorry for not replying sooner; my client didn't seem to reflect folder updates... Are there any urgent bugs right now? I'm moving tomorrow and won't be able to tend to them if so, but I am interested in taking maintainership of it. I'm expecting to have Internet in my new home within a few weeks. There is a version bump bug (547460) and two other bugs. The version bump would be nice to do now (may be I will try to ask somebody to help me with it, as I have no amd64 hardware now). signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rutes: dev-util/ext4_utils, dev-util/libsparse
# Jauhien Piatlicki jauh...@gentoo.org (16 Jun 2015) # Upstream does not provide these as separated packages. # Nobody interested in maintaining them in Gentoo. # A number of open bugs. # Masked for removal in 30 days. dev-util/ext4_utils dev-util/libsparse signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
Hi Daniel, so will you take the maintainership? I will reassign bugs to you then. On 06/06/2015 09:23 PM, Daniel zlg Campbell wrote: On 06/06/2015 09:02 AM, Jauhien Piatlicki wrote: Hi, the list of packages that I'm no longer interested in: media-sound/apulse -- needs version bump dev-util/android-ndk -- needs version bump I will remove myself from maintainers of these packages and, if there is no other maintainers reassign bugs to maintainer-needed. dev-util/ext4_utils dev-util/libsparse Adding of these two packages to the tree were, probably, not very good idea, so if nobody wants to maintain them, it makes sense to remove them. -- Jauhien I can take apulse since I use Skype, which it was originally written for use with. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] A few mgorny/ projects for upstream-grabs
Hi, I will try to work a little bit on flaggie (I also have not very much free time, though), I guess you'll continue to accept pull requests for it? On 06/15/2015 07:54 PM, Michał Górny wrote: Hi, everyone. My time for Gentoo is quite limited right now (you gotta start working for money at some point :)), and the little time I have I'm trying to use for the Gentoo work I consider most important. This sadly means that many of my past tools are earning their share of bitrot and would really use a new contributors, or possibly even full-time upstream maintainers :). Here's a long list of projects along with short description, their state and planned TODO items that I won't have time to implement anytime soon. app-portage/flaggie The package.use ( make.conf) flag management tool. Pretty high priority. status: rather working, has a few bugs, certainly would use some new Portage features TODO: - remove make.conf editing support (it's very complex and broken -- can eat random '$' from the file in some cases), - therefore: edit global flags via '*/*' entries in package.use, - support writing 'FOO_BAR:' format for USE_EXPAND in package.use, - support parsing 'FOO_BAR:' format for USE_EXPAND on command-line (i.e. 'flaggie libfoo VIDEO_CARDS: +radeon -nvidia'), - remove implicit '*' expansion in package names and flag names -- package.use can handle '*', so leave it as is and just expand it when checking if the flags are supported, - possibly clean up package.use writer (or rewrite it since I'm no longer able to figure out how it works exactly :)). signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs
Hi, the list of packages that I'm no longer interested in: media-sound/apulse -- needs version bump dev-util/android-ndk -- needs version bump I will remove myself from maintainers of these packages and, if there is no other maintainers reassign bugs to maintainer-needed. dev-util/ext4_utils dev-util/libsparse Adding of these two packages to the tree were, probably, not very good idea, so if nobody wants to maintain them, it makes sense to remove them. -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model
On 11/20/2014 05:39 AM, hasufell wrote: I see a lot of things to figure out (especially PM-side, tools-side, maybe even PMS, maybe even repository layout, but also documentation and if it makes sense culture-wise), but I don't see a fundamental unsolvable problem here. It would be interesting to see a draft of those proposals. Could you start writing it somewhere on the wiki? Then we can discuss more concrete technical things. Even if it will not result in more distributed model for Gentoo, it could improve our current model of overlays. -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model
On 11/19/2014 03:36 PM, hasufell wrote: On 11/18/2014 02:12 PM, Jauhien Piatlicki wrote: On 11/18/2014 04:19 AM, hero...@gentoo.org wrote: Jauhien Piatlicki jauh...@gentoo.org writes: It would be probably good to have in the tree only the core components and move other stuff to the thematic overlays. Then we can have a clear understanding, how things should be: if something is a part of the core system, it goes to the tree, if something is a scientific packages, it lives in the science overlay, if something is a java stuff it lives in the java overlay, etc. This is a good idea. One difficulty: how to handle inter-overlay dependence? Either the dependency should be expressed by overlay + ebuild, or the dependent ebuild should be moved into the core overlay. I haven't figured out a clean solution yet. Yes, this is a weak point of decentralization. We should think how to solve it. The possible solution is using of dependencies between overlays (one overlay says, it depends on other). We already have such a feature, we only need to add more support for it. Example of such a dependency: %cat /var/lib/layman/melpa-stable/metadata/layout.conf repo-name = melpa-stable masters = gnu-elpa gentoo Dependencies on overlays in ebuilds is bad idea I think, as it only will introduce additional problems. Also think what if you need not a package, but an eclass or whatever else. In addition, one question that emerges is possible circular dependencies between overlays. We need a way to handle this. Sounds like there should be some sort of wiki page/guidelines what to keep in mind when creating an overlay. I guess there are two approaches: * make the overlay as independent and consistent as possible * make the overlay as themed and reusable as possible Example: You want to create a games overlay, do you add libsdl, sdl-mixer etc to it? One way to go about it is probably to make a very strong distinction between actual applications and libraries/modules. So you'd rather have two overlays for the above example: games and games-libs? That sounds reasonable. In the end, I'm not sure if this is actually such a big problem. You can still use random ebuilds from random overlays and commit them straight to your own overlay. A bad idea. Bad because of the same reason why copy-past in your code would be bad. -- Jauhien signature.asc Description: OpenPGP digital signature
[gentoo-dev] [gentoo-project] Re: towards a more distributed model
On 11/18/2014 04:19 AM, hero...@gentoo.org wrote: Jauhien Piatlicki jauh...@gentoo.org writes: It would be probably good to have in the tree only the core components and move other stuff to the thematic overlays. Then we can have a clear understanding, how things should be: if something is a part of the core system, it goes to the tree, if something is a scientific packages, it lives in the science overlay, if something is a java stuff it lives in the java overlay, etc. This is a good idea. One difficulty: how to handle inter-overlay dependence? Either the dependency should be expressed by overlay + ebuild, or the dependent ebuild should be moved into the core overlay. I haven't figured out a clean solution yet. Yes, this is a weak point of decentralization. We should think how to solve it. The possible solution is using of dependencies between overlays (one overlay says, it depends on other). We already have such a feature, we only need to add more support for it. Example of such a dependency: %cat /var/lib/layman/melpa-stable/metadata/layout.conf repo-name = melpa-stable masters = gnu-elpa gentoo Dependencies on overlays in ebuilds is bad idea I think, as it only will introduce additional problems. Also think what if you need not a package, but an eclass or whatever else. In addition, one question that emerges is possible circular dependencies between overlays. We need a way to handle this. -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model
On 11/18/2014 03:02 PM, viv...@gmail.com wrote: Il 18/11/2014 14:12, Jauhien Piatlicki ha scritto: On 11/18/2014 04:19 AM, hero...@gentoo.org wrote: Jauhien Piatlicki jauh...@gentoo.org writes: It would be probably good to have in the tree only the core components and move other stuff to the thematic overlays. Then we can have a clear understanding, how things should be: if something is a part of the core system, it goes to the tree, if something is a scientific packages, it lives in the science overlay, if something is a java stuff it lives in the java overlay, etc. This is a good idea. One difficulty: how to handle inter-overlay dependence? Either the dependency should be expressed by overlay + ebuild, or the dependent ebuild should be moved into the core overlay. I haven't figured out a clean solution yet. Yes, this is a weak point of decentralization. We should think how to solve it. The possible solution is using of dependencies between overlays (one overlay says, it depends on other). We already have such a feature, we only need to add more support for it. Example of such a dependency: %cat /var/lib/layman/melpa-stable/metadata/layout.conf repo-name = melpa-stable masters = gnu-elpa gentoo Dependencies on overlays in ebuilds is bad idea I think, as it only will introduce additional problems. Also think what if you need not a package, but an eclass or whatever else. In addition, one question that emerges is possible circular dependencies between overlays. We need a way to handle this. As much as I dislike the idea to move development to overlays circular dependancies is not a problem because it's a simple _mutual_ dep. there is not really a concept of before and after at most priority for a package. At the moment it is. As `masters` is really not the dependency, but instruction to use eclasses from a given overlay. May be we need to rethink layout.conf a little bit and add real overlay dependencies. But here another question arises: overlays are not specified in PMS and so treated by every PM in a different manner. There master repositories are mentioned, but there is no specification afaik. -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-scm] Testing git gx86 repos (and status update)
Picking random email... 02.10.14 22:48, Michał Górny написав(ла): What is the status here? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: razorqt-base/*
Hi Ben, Have you read comments on Qt overlay commit? Have you check reverse dependencies of packages you are masking? razorqt-base/libqtxdg is used by LXQt. So, please, unmask it. I will move it into lxqt-base category. But until this, please, do not touch it. And, please, make sure you are reading metadata.xml and checking revdeps of packages you are touching. -- Jauhien 08.11.14 06:25, Ben de Groot написав(ла): # Ben de Groot yng...@gentoo.org (7 Nov 2014) # Unmaintained, no longer supported, and starting to throw compilation # errors (bug #513906, bug #528372). Masked for removal in 30 days. # Update to lxqt-base/* packages. razorqt-base/libqtxdg razorqt-base/razorqt-appswitcher razorqt-base/razorqt-autosuspend razorqt-base/razorqt-config razorqt-base/razorqt-data razorqt-base/razorqt-desktop razorqt-base/razorqt-kbshortcuts razorqt-base/razorqt-libs razorqt-base/razorqt-lightdm-greeter razorqt-base/razorqt-meta razorqt-base/razorqt-notifications razorqt-base/razorqt-openssh-askpass razorqt-base/razorqt-panel razorqt-base/razorqt-policykit razorqt-base/razorqt-power razorqt-base/razorqt-runner razorqt-base/razorqt-session signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: razorqt-base/*
I see it was unmasked back already. Thanks. -- Jauhien 08.11.14 12:15, Jauhien Piatlicki написав(ла): Hi Ben, Have you read comments on Qt overlay commit? Have you check reverse dependencies of packages you are masking? razorqt-base/libqtxdg is used by LXQt. So, please, unmask it. I will move it into lxqt-base category. But until this, please, do not touch it. And, please, make sure you are reading metadata.xml and checking revdeps of packages you are touching. -- Jauhien 08.11.14 06:25, Ben de Groot написав(ла): # Ben de Groot yng...@gentoo.org (7 Nov 2014) # Unmaintained, no longer supported, and starting to throw compilation # errors (bug #513906, bug #528372). Masked for removal in 30 days. # Update to lxqt-base/* packages. razorqt-base/libqtxdg razorqt-base/razorqt-appswitcher razorqt-base/razorqt-autosuspend razorqt-base/razorqt-config razorqt-base/razorqt-data razorqt-base/razorqt-desktop razorqt-base/razorqt-kbshortcuts razorqt-base/razorqt-libs razorqt-base/razorqt-lightdm-greeter razorqt-base/razorqt-meta razorqt-base/razorqt-notifications razorqt-base/razorqt-openssh-askpass razorqt-base/razorqt-panel razorqt-base/razorqt-policykit razorqt-base/razorqt-power razorqt-base/razorqt-runner razorqt-base/razorqt-session signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage dependency solving algorithm
08.11.14 22:47, hasufell написав(ла): On 11/08/2014 10:30 PM, Rich Freeman wrote: On Sat, Nov 8, 2014 at 2:48 PM, hasufell hasuf...@gentoo.org wrote: On 11/08/2014 08:32 PM, hasufell wrote: Sorry to chime in like that but if you don't mind, I'd like to ask for a real-life example for badly declared dependencies with a few words why those are bad and how to make them actually better? from dev-haskell/hashtables (note hashtables != hashable): || ( ( =dev-haskell/hashable-1.1:=[profile?] dev-haskell/hashable-1.2:=[profile?] ) ( =dev-haskell/hashable-1.2.1:=[profile?] dev-haskell/hashable-1.3:=[profile?] ) ) Latest stable version of dev-haskell/hashable is 1.2.1.0. On a stable system (arch) the paludis dep-solver will try to match the first group first and realize that there is also a stable version 1.1.2.5 that matches that group. At that point there is a correct solution, but since that involves downgrading a package, it will require user-intervention, because it may not be what the user wants. (this is the easy scenario... if downgrading causes blockers, you get much more interesting output) To be more specific... it is assumed that hashable-1.2.1.0 is already installed. Every time the dep solver runs through those packages without specifying what you want, you will hit the downgrade-problem. I'm missing the problem. The package requires one of two ranges of hashable versions. One of them is already installed. The dependency is satisfied. The one that is installed (1.2.1.0) is *excluded* by the first group, but there is a valid version that fits instead (1.1.2.5). That's the point where the assumptions start about what the depstring means and what the user wants. So the problem is only with intervals? First of all, maintainer would specify higher interval first here and it would solve a problem with possible downgrading. Second, || is rather not for such cases as you've said, so we could ask for a new syntax and solve this problem in the right way in one of the next EAPIs. Are there any other problems in current model apart from intervals? I would really like to see a list of them all. -- Jauhien signature.asc Description: OpenPGP digital signature
[gentoo-dev] Portage dependency solving algorithm (WAS: Regarding my final year thesis)
Hi, On 11/06/2014 02:43 PM, Ciaran McCreesh wrote: If you're going to go the toolkit route, you should be using a CP solver, not a SAT solver. But even then you'd be better off making some changes and not using plain old MAC, so you're back to writing the algorithms yourself. What you need is for someone who understands CP and SAT to write a resolver using algorithms inspired by how CP and SAT solvers work, but not just blindly copying them. Doing this well is at least a full year Masters level project... Yeah, you are right. What I am interested in is an overview of what algorithm we are using now. Do we have any documentation about it? As I really would like to look at some concise document rather than sources. Also may be we need to discuss how can we improve it, as at the moment for me it seems one of the biggest problems with Gentoo. And afaik paludis does not solve it (or am I wrong?) -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage dependency solving algorithm (WAS: Regarding my final year thesis)
On 11/07/2014 07:07 PM, Ciaran McCreesh wrote: On Fri, 07 Nov 2014 10:42:39 +0100 Jauhien Piatlicki jauh...@gentoo.org wrote: Also may be we need to discuss how can we improve it, as at the moment for me it seems one of the biggest problems with Gentoo. And afaik paludis does not solve it (or am I wrong?) Paludis solves it. However, Paludis will only ever produce a correct resolution, which can be a problem since ebuild dependencies are often garbage... Then the same question for you: where can one read about the algorithm Paludis uses? And, again, I have herd (did not try myself) that Paludis is as slow as Portage. -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage dependency solving algorithm
On 11/07/2014 08:08 PM, hasufell wrote: On 11/07/2014 07:54 PM, Matthias Maier wrote: Well, you're not comparing like with like. Paludis with everything turned off does more than Portage with everything turned on. If all you're looking for is the wrong answer as fast as possible, there are easier ways of getting it... The last time I compared the resolver speed of portage and paludis both needed almost the same time. Do you have a speed comparison with a similar feature set of both? (Or, alternatively, the speedup one gains by tuning paludis to be as fast as possible). I think you didn't get the idea: it doesn't make much sense to compare the speed if the correctness differs. Also, I don't understand these discussions. The time dependency resolving takes is marginal compared to the whole update process, no matter what PM you use. When it compiles in background after all dependencies was solved, it needs no user intervention. But when I need to solve some blocks or do some tests during maintaining work, the dependency solving time is what I care about, as I need to wait for it and then investigate the results. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage dependency solving algorithm
On 11/07/2014 08:21 PM, Ciaran McCreesh wrote: The main issue, though, is that getting a good resolution out of crappy data is extremely difficult. There's the Babbage quote: | On two occasions I have been asked, — Pray, Mr. Babbage, if you put | into the machine wrong figures, will the right answers come out? In | one case a member of the Upper, and in the other a member of the | Lower, House put this question. I am not able rightly to apprehend | the kind of confusion of ideas that could provoke such a question. Yet this is *exactly* what a dependency resolver has to do for Gentoo, and it's why dependency resolvers are so complicated. (For comparison, Paludis on Exherbo will run an order of magnitude faster for the same set of installed packages, simply because on Exherbo the input is correct.) What;s wrong with input? PMS itself or how do maintainers write ebuilds? Could you explain? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage dependency solving algorithm
07.11.14 21:44, hasufell написав(ла): On 11/07/2014 08:56 PM, Jauhien Piatlicki wrote: Every time people compare portage to paludis I read stuff like but paludis is slower. That is incomplete information to put it diplomatic. Do you really care so much about speed that you don't mind wrong results? My original question was about Portage being too slow. And Paludis came out just as an alternative. And I would like to see a detailed discussion about what's wrong from the point of view of correctness with: 1. PMS 2. ebuilds in tree 3. Portage dependency solving Was this discussed somewhere? Could you point me there? -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Regarding my final year thesis
Hi, Mathematics you said? That's nice. You can, for example, redesign our portage's dependency solving algorithm, as it is quite slow at the moment. ) I do not know what it does have inside right now, but using SAT solver can be a good idea (there is a successful example already: https://en.opensuse.org/openSUSE:Libzypp_satsolver) -- Regards, Jauhien On 11/06/2014 01:49 PM, Harsh Bhatt wrote: I an Applied Maths student, currently in my final year. In my last 6 months i need to do a thesis something related to Mathematics as i am a Maths student. I have been using gentoo for quite a long time so was thinking to do something related to gentoo. Give me suggestion of what can be done. Anything related to modeling, simulation or Discreet Mathematics would be a better choice. signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] make repoman checks disableable on per repo basis
Hi, 22.09.14 20:38, Zac Medico написав(ла): On 09/22/2014 05:44 AM, Jauhien Piatlicki wrote: Hi, could we have possibility to disable some repoman checks in repo configs? See e.g. https://github.com/gentoo-science/sci/issues/268 -- Jauhien How about if we add a new field to metadata/layout.conf, containing a list of identifiers for repoman checks to disable? it would be nice. Was there any progress on this? -- Jauhien signature.asc Description: OpenPGP digital signature
[gentoo-portage-dev] make repoman checks disableable on per repo basis
Hi, could we have possibility to disable some repoman checks in repo configs? See e.g. https://github.com/gentoo-science/sci/issues/268 -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
Hi, On 09/15/2014 01:37 AM, Kent Fredric wrote: On 15 September 2014 11:25, hasufell hasuf...@gentoo.org wrote: Robin said The Git commit-signing design explicitly signs the entire commit, including blob contents, to avoid this security problem. Is this correct or not? I can verify a commit by hand with only the commit object and gpg, but without any of the trees or parents. https://gist.github.com/kentfredric/8448fe55ffab7d314ecb So signing of git commits does not guarantee enough security (taking that SHA1 is weak and can be broken), right? Could we than just use usual (not thin) manifests? -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
Hi, 14.09.14 14:03, Michał Górny написав(ла): Hi, I'm quite tired of promises and all that perfectionist non-sense which locks us up with CVS for next 10 years of bikeshed. Therefore, I have prepared a plan how to do git migration, and I believe it's doable in less than 2 weeks (plus the testing). Of course, that assumes infra is going to cooperate quickly or someone else is willing to provide the infra for it. as always, nice effort, but I foresee lots of bikeshedding in this thread. ) This means we don't have to wait till someone figures out the perfect way of converting the old CVS repository. You don't need that history most of the time, and you can play with CVS to get it if you really do. In any case, we would likely strip the history anyway to get a small repo to work with. Is it so difficult to convert CVS history? The rsync tree -- We'd also propagate things to rsync. We'd have to populate it with old ChangeLogs, new ChangeLog entries (autogenerated from git) and thick Manifests. So users won't notice much of a change. How will user check the ebuild integrity with thick manifests using rsync? The remaining issue is signing of stuff. We could supposedly sign Manifests but IMO it's a waste of resources considered how poor the signing system is for non-git repos. Again, how will user check the integrity and authenticity if Manifests are unsigned? Also, it would be a good idea to add automatic signature checking to portage for overlays that use signing (or is it already done?). -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
Another question: will it be possible to maintain a copy of tree on github to make contributions for users simpler (similarly to e.g. science overlay)? (Can it somehow be combined with proposed signing mechanism?) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
14.09.14 15:23, Jauhien Piatlicki написав(ла): Another question: will it be possible to maintain a copy of tree on github to make contributions for users simpler (similarly to e.g. science overlay)? (Can it somehow be combined with proposed signing mechanism?) Or well, have our own pull requests review tool. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
14.09.14 15:25, C. Bergström написав(ла): On 09/14/14 08:24 PM, Jauhien Piatlicki wrote: 14.09.14 15:23, Jauhien Piatlicki написав(ла): Another question: will it be possible to maintain a copy of tree on github to make contributions for users simpler (similarly to e.g. science overlay)? (Can it somehow be combined with proposed signing mechanism?) Or well, have our own pull requests review tool. NIH? What would be the benefit of that.. before going down this path.. I think there's some good tools around which may at least serve as a base to (fork) from before starting a ground up project. Sorry to jump in the middle of the conversation, but I know 1st hand how much is involved here. I was not precise. By our own I mean hosted by us, not by github. ) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Early idea: install_qa_check() refactor and 'public API'
Hi,
11.09.14 00:20, Michał Górny написав(ла):
I would like to have install-qa-check.d in three main places:
1. /usr/lib/portage/install-qa-check.d (or alike) for scripts
installed by Portage and other packages,
2. /etc/portage/install-qa-check.d for extra scripts installed
by sysadmin,
3. ${repo}/metadata/install-qa-check.d for repository-specific
QA checks.
The rationale for (3) is quite simple: many of the modern QA checks are
results of policies specific to Gentoo tree and the eclasses in it --
like my recent bash-completion checks (still in review queue). Keeping
them in Portage is cumbersome, and has some code duplication factor.
nice idea, +1 from me.
One question related to (3): am I correct that not only scripts from
${repo}/metadata/install-qa-check.d, but also scripts from the repos that
current repo has in masters from metadata/layout.conf will be runned? It means
that these scripts will be 'inherited' by repos?
--
Regards,
Jauhien
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?
13.09.14 19:31, Peter Stuge написав(ла): Jauhien Piatlicki wrote: Emerging live ebuild usually is quite a risky thing, I don't know. It depends on the culture of the particular repository, and while it is true that many open source repos are utter crap I'm not sure if that is the common case? I like to believe that developers actually think before they commit, but I do admit to also ending up disappointed. One way to change that is IMO to pressure upstream not to put crap in their repo in the first place. That is only detected by people using the upstream repo code, and filing bugs upstream in case of crap. Sure, that's more effort for the community. But the end result is less crappy software. Do you want to help with that? The question is not about crap in the upstream, but about changed dependencies, behavior, whatever else. E.g. we in downstream have some patches, when upstream changes related code (e.g. applying our patches), ebuild fails to build. Everything in live ebuild can change, so it will fail. It can be not crap, but some improvements, but it does not matter for the possibility of building of a given ebuild. -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?
Hi, 13.09.14 22:03, Peter Stuge написав(ла): E.g. we in downstream have some patches, when upstream changes related code (e.g. applying our patches), ebuild fails to build. I consider this a separate issue however. I would actually expect there to be a policy which forbids patches on live ebuilds. Make another live ebuild or maybe an overlay if you want to offer a different set of commits than the upstream repo. In the ideal country of elves. In the real life it can be not possible to build and install software in a given distribution without downstream patches. You can find examples of such live ebuilds in Gentoo tree. Everything in live ebuild can change, so it will fail. It can be not crap, but some improvements, but it does not matter for the possibility of building of a given ebuild. Patches aside I completely agree that a live ebuild is a moving target, but to me that is a good thing, in fact the very essence of open source. Open source is not about instability. It is just about sources being available. No more, no less. ;-) Anyway, summarizing, it is completely impossible to be sure that live ebuild will be buildable for you on a given arch in the next 15 min., even if it was so in the last 15 min. -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?
Hi, 09.09.14 20:36, hasufell написав(ла): Michał Górny: And how can you test a VCS ebuild? You can't assume upstream will be stuck on one commit. I don't see the argument. It sounds like you are saying one day, upstream might stop supporting architecture xy, so better we just omit all of them from KEYWORDS. Err? For example, I know polarssl upstream will support amd64 and x86 for the foreseeable future (cause they told me and I run the live ebuild on both arches). Why would I want empty KEYWORDS, even in the live ebuild? Bugs will be valid and fixed. If an architecture is no longer supported and upstream doesn't accept bugs for it any more, drop it. Same as always. When I accept ~arch I expect that no live ebuilds will be built. I think other gentoo users expect the same. Emerging live ebuild usually is quite a risky thing, so hiding such stuff behind dropped keywords is quite reasonable. -- Jauhien signature.asc Description: OpenPGP digital signature
[gentoo-portage-dev] repoman commit message for git
Hi, can repoman logic be changed a little bit, so it prepends commit message for git repos with package name? Otherwise git log when using repoman looks not informative. Regards, Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] repoman commit message for git
08.09.14 19:04, Zac Medico написав(ла): On 09/08/2014 04:32 AM, Jauhien Piatlicki wrote: Hi, can repoman logic be changed a little bit, so it prepends commit message for git repos with package name? Otherwise git log when using repoman looks not informative. Regards, Jauhien We could add an option for that, rather than make it mandatory, so that the existing behavior remains for flexibility. You could enable the new option by default via REPOMAN_DEFAULT_OPTS in make.conf. We could also add a per-repo setting for repos.conf (and possibly layout.conf in the repository) which you could override via the command line. It would be nice. As currently, when people commit to overlays using repoman, logs look quite unclear. Adding such an option to overlay configuration files is a good idea. -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: adding sys-apps/iproute2 to the @system set
05.09.14 21:21, Wyatt Epp написав(ла): On Fri, Sep 5, 2014 at 2:35 PM, Alex Xu alex_y...@yahoo.ca wrote: no, because it's not necessary to bring up a working system. we don't have wpa_supplicant, and we shouldn't have net-tools now that openrc isn't in @system anymore. Well, your definition of working seems quite a bit narrower than mine! More saliently, I recall having needed to do network-related things from within my stage 3 chroot before, and I'd very much like that to continue being possible. sys-apps/iproute2 is not necessary for this. stage3 already has enough stuff to work with network. Or am I wrong? -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] systemd profiles
Hi, 30.08.14 04:41, Rich Freeman написав(ла): On Fri, Aug 29, 2014 at 7:09 PM, Jauhien Piatlicki jauh...@gentoo.org wrote: Hi all, I have a simple question: why do we have systemd subprofiles only in gnome and kde profiles? Could we add systemd subprofiles also to default/linux/$arch/13.0/ and desktop (and any other profiles where it makes sense)? I'm not sure systemd profiles actually make that much sense these days. To install systemd from a stage3 you basically just need to set USE=systemd and do an emerge -uDN world. We're actually getting close to the point where you would pick an init system the way you pick a kernel or cron implementation during install. -- Rich that's good. Then I have another question: why systemd profile exists at all? As I see as consistent two possibilities: 1. no systemd profiles at all 2. systemd subprofile profile of default exists together with other profiles --- Jauhien signature.asc Description: OpenPGP digital signature
[gentoo-dev] systemd profiles
Hi all, I have a simple question: why do we have systemd subprofiles only in gnome and kde profiles? Could we add systemd subprofiles also to default/linux/$arch/13.0/ and desktop (and any other profiles where it makes sense)? Thanks for answers, Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making an overlay publicly available?
Hi, I was not able to google instructions, but you need to file a bug, something like https://bugs.gentoo.org/show_bug.cgi?id=510028 Ask on gentoo-infra IRC channel for more information. I think we should add instructions to some place on our wiki, where one can easy google them. Regards, Jauhien signature.asc Description: OpenPGP digital signature
[gentoo-dev] New category lxqt-base
Hi all, LXQt 0.7.0 has been released [1]. As it is project different from LXDE and will be supported in parallel with it, it seems like a good idea add a new category lxqt-base. For previous discussion see [2] and [3]. The packages that will go into this category are: compton-conf libqtxdg lxqt-about lxqt-config-randr lxqt-notificationd lxqt-power lxqt-session qt-gtk-engine libfm libsysstat lxqt-appswitcher lxqt-globalkeys lxqt-openssh-askpass lxqt-powermanagement liblxqt lximage-qt lxqt-common lxqt-lightdm-greeter lxqt-panel lxqt-qtplugin obconf-qt liblxqt-mount lxqt-config lxqt-meta lxqt-policykit lxqt-runner pcmanfm-qt If there are no objections I'll proceed with adding new category when ebuilds for 0.7.0 release will be ready (~ in week or two). [1] http://sourceforge.net/p/lxde/mailman/message/32310545/ [2] https://bugs.gentoo.org/show_bug.cgi?id=501606 [3] https://github.com/gentoo/qt/pull/26 Regards, Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Add support for rsync patches
04.02.14 20:53, Donnie Berkholz написав(ла): On 12:48 Tue 28 Jan , Michał Górny wrote: Dnia 2014-01-28, o godz. 11:59:33 Jauhien Piatlicki jpiatli...@gmail.com napisał(a): net-misc/rsync upstream provides a tarball with additional patches that can be useful for some users. I think it would be nice to have them handled automatically by portage using e.g. USE_EXPAND. Of course these patches can be just picked by user an applied using epatch_user, but I think it would be much easier and convenient to do this with just setting a use flag. ...and what do you want from gentoo-dev@? You need someone to file the bug for ya? This is not the level of friendliness that is going to welcome potential new contributors into our community. I'm reading this list for a long rime, so I'm quiet acquainted with this level of friendliness. So do not mind. I've wrote this list because potential changes I want to do include adding of new USE_EXPAND that should be discussed here anyway. And there can be reasons why this have not done, that I'm not aware of, and maintainer of rsync or somebody else could comment here. Anyway I still have not ended with those changes and hence still have not posted a bug. So do not mind once again. ;-) Jauhien signature.asc Description: OpenPGP digital signature
[gentoo-dev] Add support for rsync patches
Hi, net-misc/rsync upstream provides a tarball with additional patches that can be useful for some users. I think it would be nice to have them handled automatically by portage using e.g. USE_EXPAND. Of course these patches can be just picked by user an applied using epatch_user, but I think it would be much easier and convenient to do this with just setting a use flag. Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The Gentoo Qt Project wants your help!
02.03.13 07:54, Ben de Groot написав(ла): app-admin/keepassx app-text/goldendict If these two packages need a maintainer, I could proxy-maintain them. I'm not a developer, but I have some experience with ebuild writing. Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] g-elisp repository helper
21.02.13 16:18, Ulrich Mueller написав(ла): It looks promising. I only wonder why you need to define your own fetch function instead of assigning SRC_URI? This will cause the ebuilds to be live ebuilds and there will be no possibility for the user to verify the integrity of the downloaded package. Or have I missed something? Cheers, Ulrich Thanks. The problem with SRC_URI is that if it is defined, manifests should include hashes of the source files. As g-elisp is aimed to dynamically generate overlays on user's computer it means that during this generation all the sources from elisp repos will be downloaded. It isn't very nice. The integrity of sources could be verified in ebuild, but I have not found any hashes in elpa's repository info. May be I just failed in my googling, so if you know a solution of this problem, I will implement it with great pleasure. Best regards, Jauhien signature.asc Description: OpenPGP digital signature
[gentoo-dev] g-elisp repository helper
Hi all, I do not know whether this list is an appropriate place, so sorry if it is not ) Recently I've wrote some little scripts that implement interface for g-common type repositories of layman[1]. And I would ask those who is interested to test them. I've created two packages: g-common (interacts with layman) and g-elisp (generates ebuilds). g-elisp is aimed to automatically create layman overlays for repositories of elisp packages supported by package.el, so those packages could be installed by portage. To test it you can add an overlay described by this xml-file: https://github.com/jauhien/jauhien-overlay/blob/master/jauhien-overlay.xml and then `emerge g-elisp` After emerging it you will be able to add two layman repositories of type g-common: gnu-elpa and marmalade. g-common and g-elisp are still in the very beta, also I'm a very beginner in python, so I will appreciate any feedback and criticism. Jauhien [1] http://git.overlays.gentoo.org/gitweb/?p=proj/layman.git;a=blob;f=layman/overlays/g_common.py;h=5f0e9bc341028248ccd718eff84d304100180949;hb=HEAD https://github.com/jauhien/g-common https://github.com/jauhien/g-elisp signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] proposal for consistency between {RUBY,PYTHON,PHP}_TARGETS
24.11.12 19:19, Peter Stuge написав(ла): Look at the following: PHP_TARGETS=php5-3 RUBY_TARGETS=ruby19 PYTHON_TARGETS=python2_7 Note the redundancy, which I'm not quite sure why we have at all.. Why not also eliminate the language name in one of the two places; either in the variable name, or in the target name? I think this looks rather pleasant, because it is quite obvious: PHP_TARGETS=5.3 5.4 RUBY_TARGETS=1.9 PYTHON_TARGETS=2.7 But maybe it would be too problematic? What will you do with PYTHON_TARGETS=python2_7 python3_2 pypy1_9 jython2_5 then? Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [warning] the bug queue has 100 bugs
03.11.12 09:04, Ben de Groot написав(ла): On 31 October 2012 23:17, Chris Reffett creff...@gentoo.org wrote: Basically, I would rather the user get too many elog messages than not enough, since I feel that a lot of people skip over them anyway and so the only display once method makes it far too easy for important messages to get lost in the shuffle. Did you ever consider *why* so many users skip over elog messages? Don't you think that could be because most of these messages of useless to them, or they have already seem them many times? I think we need to come up with a better policy regarding elog messages, which would improve the signal to noise ratio. Yes, it would be really great if messages that are not relevant for upgrading of a package will be shown only for the first install. For example, I've just finished upgrading of Gentoo on my notebook and I was spammed with heaps of messages. They are for 10 packages. From them messages for net-misc/dhcpcd, net-misc/tor, sci-physics/root, mail-client/thunderbird, www-client/firefox and sci-libs/scipy are typical and not relevant for update. It means for 6 from 10 packages (Only message for dev-libs/boost is quite original with its red color )) ). It is of course not very important issue, but it is quite annoying. signature.asc Description: OpenPGP digital signature
[gentoo-dev] libxul.so in gentoo
Hi, May be a stupid question, but Both firefox and thunderbird have xul library. Before there was a separate package xulrunner in the tree, but as Mozilla does not provide it as a separate package now (as far as I remember) both firefox and thunderbird use there own libxul.so. It seems this is the same library (Or am I wrong?). So may be it could be splitted into a separate package? (The reason is its compilation takes a lot of time on week machines and compiling it one time would be better than twice). Also as far as I can see xulrunner is splitted into a separate package in Debian and at least Iceweasel uses it. Jauhien signature.asc Description: OpenPGP digital signature
