[gentoo-dev] Packages up for grabs
As discussed at: https://bugs.gentoo.org/show_bug.cgi?id=460780 dev-db/firebird dev-db/flamerobin
Re: [gentoo-dev] Re: maintainer-needed@ packages need you!
On Sunday, September 07, 2014 01:16:57 AM Andrew Savchenko wrote: Hello, On Mon, 01 Sep 2014 07:15:53 +0800 Patrick Lauer wrote: On Sunday 31 August 2014 11:39:22 hasufell wrote: Martin Vaeth: hasufell hasuf...@gentoo.org wrote: On 08/30/2014 02:35 PM, J. Roeleveld wrote: For net-im/skype, Screw skype. Please don't. Not all communication partners are linux users. Tox is multiplatform. We have tox [1] on the way. This is far from being ready, especially for non-specialists. It is not even foreseeable whether the Android client will ever be able to do at least audio. (So far, I was not even able to exchange any messages at all. It may be my mistakes, but if I am not able to do it, how could I expect this from casual computer users?) This has nothing to do with specialists. Tox is configuration-free. And sure, it's pre-alpha as indicated in my previous mail. So it doesn't work, but you feel the need to feel superior by telling everyone else that they are doing it wrong. Can't agree with you here. I just tried tox (utox client) from tox-overlay. Works like charm from the box, the only unusual thing I did is keyword added to package.keywords in order to install live ebuild. I tested text messages, audio and video from double-nat environment (where SIP clients can work only using stune and only some of them). It probably works, provided all your contacts also use it. As long as the vast majority of my contacts use Skype and Yahoo, I will not be able to switch. If Kopete (and other generic IM clients) would add support for tox, then it would be easier. It should be noted that at least in Linux skype is much harder to install and use since it requires pulseaudio and I don't use that sh^W stuff. So skype reqires its own LXC container set up which is doable, but costed me a day (with all tight isolation stuff). And I even had not mentione that installation of skype equals to trojan injection into the system (that's why I used all that LXC and separate X server precautions). If you want to isolate a package, then yes, it is more difficult then just running emerge skype (Which works flawlessly for me). I also had no issues installing pulseaudio. (Apart from having to undo some alsa-settings to default to the normal audio output instead of the HDMI one). Which trojan injection are you talking about? -- Joost
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On 09/05/2014 13:34, William Hubbs wrote: All, there is a bug open requesting that we add sys-apps/iproute2 to the system set [1]. Originally the request was to drop net-tools, but it has become just adding iproute2. If no one objects, I would like to do this sometime in the next 72 hours by adding sys-apps/iproute2 to profiles/default/linux/packages. Thoughts? William [1] https://bugs.gentoo.org/189149 I questioned on the original bug on net-tools vs iproute2, because netstat and ss each support different protocol families, and so compliment each other instead of replace. The same might not hold true for other components of each package. That said, the thread had deviated towards discussion on the makeup of the @system set in general, so let's rename the thread (or at least fork() it). IMHO, I think @system should maintain at least one editor and include some kind of networking diagnostic package. Even on the slower archs like MIPS, building either net-tools or iproute2 isn't asking a whole lot. Faster archs even less so. As far as editor, nano is my preference because it just works for quick edits, but an argument can be made for swapping that out with a minimal vim (which doesn't require ncurses). -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] rfc: adding sys-apps/iproute2 to the @system set
On 09/06/2014 08:41, Patrick Lauer wrote: On Friday 05 September 2014 12:34:11 William Hubbs wrote: All, there is a bug open requesting that we add sys-apps/iproute2 to the system set [1]. Originally the request was to drop net-tools, but it has become just adding iproute2. I wouldn't mind either option - net-tools has been deprecated for a decade, but if we still ship it as default it will be used. It looks like Fedora has been maintaining net-tools on their own now. We might want to switch to pulling from their sources, since I know they've fixed the SCTP bug in netstat -S. The last official net-tools release on SourceForge is 2011, so I don't think that's going to be updated anymore. https://apps.fedoraproject.org/packages/net-tools/overview -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On 09/07/2014 16:01, Rich Freeman wrote: On Sun, Sep 7, 2014 at 3:49 PM, Joshua Kinard ku...@gentoo.org wrote: IMHO, I think @system should maintain at least one editor and include some kind of networking diagnostic package. Why is it important that we not be able to parallel build an editor? Is it such a frequent build-time dependency that we wouldn't want to specify it? It is essential that we make it extra-hard for a user to uninstall their last editor, since it is impossible to install an editor without an editor already present? Re: editor, I was referring to this: On 09/06/2014 09:37, Rich Freeman wrote: There isn't much question that stuff like rsync and nano (via the editor virtual) should be in the stage3 just so that we're not ripping our hair out during installation. However, they really don't need to be part of the system set. How many packages really need to depend on an editor (and I'm talking linking and other technical issues that affect builds - not practical use)? And thus, I was referring only to @system, not a stage3. I think an editor should be in @system, but as much as I like nano, I know the ncurses dependency won't sit well with everyone. If @system is supposed to be a minimal-working system, a minimal vim deserves consideration. But if ncurses is already being dragged in by something else, then stick with nano. As for Parallel builds, do you make make -jX? Or running concurrent emerges in different shells? I wasn't commenting at all on parallel builds. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On Sun, 07 Sep 2014, Joshua Kinard wrote: And thus, I was referring only to @system, not a stage3. I think an editor should be in @system, but as much as I like nano, I know the ncurses dependency won't sit well with everyone. If @system is supposed to be a minimal-working system, a minimal vim deserves consideration. But if ncurses is already being dragged in by something else, then stick with nano. There's neither nano nor any other specific editor in the system set, to start with. There is virtual/editor which I think is the best choice, unless we would decide that no editor is needed at all. Ulrich pgpMX4Uyca61T.pgp Description: PGP signature
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On 09/07/2014 16:45, Ulrich Mueller wrote: On Sun, 07 Sep 2014, Joshua Kinard wrote: And thus, I was referring only to @system, not a stage3. I think an editor should be in @system, but as much as I like nano, I know the ncurses dependency won't sit well with everyone. If @system is supposed to be a minimal-working system, a minimal vim deserves consideration. But if ncurses is already being dragged in by something else, then stick with nano. There's neither nano nor any other specific editor in the system set, to start with. There is virtual/editor which I think is the best choice, unless we would decide that no editor is needed at all. Ulrich The stage2/stage3 catalyst runs I did recently always dragged in nano ncurses. I did very little customization to the build profiles or the specs, so something was favouring nano over other editors. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On Sun, Sep 7, 2014 at 4:33 PM, Joshua Kinard ku...@gentoo.org wrote: And thus, I was referring only to @system, not a stage3. I think an editor should be in @system, but as much as I like nano, I know the ncurses dependency won't sit well with everyone. If @system is supposed to be a minimal-working system, a minimal vim deserves consideration. But if ncurses is already being dragged in by something else, then stick with nano. That's the thing. I don't think that @system should be a minimal-working system. That has been the past attitude towards it, and it causes issues. As for Parallel builds, do you make make -jX? Or running concurrent emerges in different shells? I wasn't commenting at all on parallel builds. I was referring to --jobs. The issue with @system is that you can't build packages in @system in parallel, or their dependencies. Now, I'm not sure if that extends to dependencies of virtual packages - if not then an editor isn't as much of a problem. However, you're still stuck with lots of whining by portage if you unmerge your last editor. I think we really need to reserve that for situations where you're actually likely to break something. You can unmerge and re-merge an editor without any issues at all, and there are probably lots of useful substitutes for editors that aren't in the editor virtual. I'm not suggesting that we rip out editor just now either. It makes more sense to just try to hold the line on @system until we have something better actually implemented (like mix-ins), and then it won't be a big deal if we trim it down further. To cut down on replies - the reason nano is preferred is that it is the first package in the virtual, which is the usual rule. Of course, it was placed there deliberately since it is a simple editor with few dependencies and both the vi and emacs camps can agree that it is lousy. -- Rich
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On 09/07/2014 17:04, Rich Freeman wrote: On Sun, Sep 7, 2014 at 4:33 PM, Joshua Kinard ku...@gentoo.org wrote: And thus, I was referring only to @system, not a stage3. I think an editor should be in @system, but as much as I like nano, I know the ncurses dependency won't sit well with everyone. If @system is supposed to be a minimal-working system, a minimal vim deserves consideration. But if ncurses is already being dragged in by something else, then stick with nano. That's the thing. I don't think that @system should be a minimal-working system. That has been the past attitude towards it, and it causes issues. Well, I was mainly just trying to fork() the thread to discuss the @system issue in general, so the smaller issue of net-tools vs iproute2 could be discussed and the bug resolved appropriately. I looked over the base/packages file and that looks fine to me right now. Couple of commented-out lines can probably be removed, but even on my slow MIPS systems, a full stage1-stage2-stage3 run only takes about 2.5 days, so I really don't have a problem with the current makeup of @system, and adding iproute2 to it isn't going to really change much. As I highlighted in the bug, only comparing netstat and ss (which is far from a comprehensive analysis), they compliment each other instead of replace. netstat supports older protocol families like IPX and AX.25 (some HAMs using Linux still use this), plus it supports showing SCTP sockets via the undocumented -S flag, as well as UDPLite. But, the SCTP support is currently broken, and Fedora's patches should fix it. ss, on the other hand, does not support SCTP, but does support DCCP (the other IANA general-purpose protocol), which netstat doesn't. Undoubtedly, there are other variances between the two packages. Before one replaces the other, we should take a look at what each package offers, find the places where they compliment each other and push whichever one has the active upstream to incorporate the missing features (likely, iproute2 needs to pickup UDPLite and SCTP support), then we can replace one with the other. As for net-tools itself, I'll see if I can get Fedora's patches to apply to it and update it. If not, I dunno whether to import their version as a separate package or as an alternate version (net-tools-2.0?). No point in ignoring it when there's obvious bugs and fixes available, even if they're not from the original upstream. As for Parallel builds, do you make make -jX? Or running concurrent emerges in different shells? I wasn't commenting at all on parallel builds. I was referring to --jobs. The issue with @system is that you can't build packages in @system in parallel, or their dependencies. Now, I'm not sure if that extends to dependencies of virtual packages - if not then an editor isn't as much of a problem. However, you're still stuck with lots of whining by portage if you unmerge your last editor. I think we really need to reserve that for situations where you're actually likely to break something. You can unmerge and re-merge an editor without any issues at all, and there are probably lots of useful substitutes for editors that aren't in the editor virtual. Well, I believe a stage2 in catalyst is just a remerge of @system, and that's only ~12 hours on my Octane, which is perfectly fine for me. So the parallelization isn't a real concern. Stage3 takes ~30hrs, though, so I'd be curious to see if that parallelizes well once I get SMP working on that machine. Then again, those of us who work with slower hardware probably have a much higher level of patience than others. So while the inability to parallelize the @system merge isn't a concern for me, it is for others. I'm not suggesting that we rip out editor just now either. It makes more sense to just try to hold the line on @system until we have something better actually implemented (like mix-ins), and then it won't be a big deal if we trim it down further. The editor is a total non-issue to me. I simply raised it as part of my reply to branch the thread off. I am perfectly fine keeping virtual/editor in @system and letting nano be the primary satisfier. To cut down on replies - the reason nano is preferred is that it is the first package in the virtual, which is the usual rule. Of course, it was placed there deliberately since it is a simple editor with few dependencies and both the vi and emacs camps can agree that it is lousy. The vi and emacs camps agreeing on something? Impossible! -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
[gentoo-dev] Re: maintainer-needed@ packages need you!
J. Roeleveld posted on Sun, 07 Sep 2014 17:51:46 +0200 as excerpted: On Sunday, September 07, 2014 01:16:57 AM Andrew Savchenko wrote: Hello, On Mon, 01 Sep 2014 07:15:53 +0800 Patrick Lauer wrote: On Sunday 31 August 2014 11:39:22 hasufell wrote: Martin Vaeth: hasufell hasuf...@gentoo.org wrote: On 08/30/2014 02:35 PM, J. Roeleveld wrote: For net-im/skype, Screw skype. Please don't. Not all communication partners are linux users. The (in)?famous network effect. A network grows in value based on the number of users it has... Tox is multiplatform [but] pre-alpha [...] FWIW, this subthread was the first I had read of it, tho I saw an article in the press about it since. The early 4chan involvement is interesting. This should be rather less controversial but at the same time potentially far more (semi-)permanently effective than the LOIC stuff. Good for them! =:^) So it doesn't work [...] Can't agree with you here. I just tried tox (utox client) from tox-overlay. Works like charm from the box [...] I tested text messages, audio and video from double-nat environment (where SIP clients can work only using stune and only some of them). It probably works, provided all your contacts also use it. As long as the vast majority of my contacts use Skype and Yahoo, I will not be able to switch. If Kopete (and other generic IM clients) would add support for tox, then it would be easier. That was the point above about not everyone being a Linux user (aka network effect), tho it seemed lost by the point of your parent post even if it was still quoted, so thanks for re-making it. Of course not all users do servantware either and skype's simply not an option for them. FWIW that includes me, no matter what my comm-partners might use. But the network effect remains valid. I simply can't join that network, network effect or not. So I can certainly identify with the screw skype sentiment since that's demonstrably their attitude toward potential users who actually care about their rights. It should be noted that at least in Linux skype is much harder to install and use since it requires pulseaudio and I don't use that sh^W stuff. So skype reqires its own LXC container set up which is doable, but costed me a day (with all tight isolation stuff). And I even had not mentione that installation of skype equals to trojan injection into the system (that's why I used all that LXC and separate X server precautions). If you want to isolate a package, then yes, it is more difficult then just running emerge skype (Which works flawlessly for me). I also had no issues installing pulseaudio. (Apart from having to undo some alsa-settings to default to the normal audio output instead of the HDMI one). Which trojan injection are you talking about? I'd guess the no-warrant-NSA-trojan that skype is pretty much known to have, given the Edward Snowden and etc. revelations, when it *HAD* been claimed to be secure. In theory there's at least shreds of the law that was supposed to protect US citizens left, if only shreds, but there's been no candy-coating the fact that if you don't happen to be a US citizen, they felt no compunction whatsoever. Whatever US citizens may feel about it then, certainly for everyone else in the world it's a trojan, period. That some g-men injected it (or forced MS to) is immaterial, when it wasn't /their/ g-men. (FWIW I'm a US citizen and I'm none-too-happy about the NSA's actions either, but obviously I'm in the minority as Obama got elected after retroactively authorizing otherwise law-breaking actions, etc, and few if any other politicians who voted for that or any of the other shenanigans seem to have been kicked out due to it either, so what can I say?) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Does the scm ebuild masking policy make sense for git?
Right now the general policy is that we don't allow unmasked (hard or via keywords) ebuilds in the tree if they use an scm to fetch their sources. There are a bunch of reasons for this, and for the most part they make sense. I was wondering if this policy still made sense in the case of scm ebuilds that pull a particular git commit. While portage can't check the Manifest, the fact is that git will in this case, and since we're pointed at a content-hashed commit we can ensure that the package never changes. We of course can't mirror it with the current setup (there is no real reason we couldn't mirror git, but this is a different problem). Tying ebuilds to a git commit has pros and cons, but I'm hard-pressed to think of any actual QA issues. That is, something that would make our tree inconsistent, or create a security vulnerability. Am I just not thinking of something? It would probably be most useful for packages that track a backport branch or something along those lines - where upstream does not regularly update their tarballs so we're constant creating patchsets. In this case all we'd have to do is bump the commit ID in the ebuild. -- Rich
Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]
On 09/07/2014 17:57, Joshua Kinard wrote: As for net-tools itself, I'll see if I can get Fedora's patches to apply to it and update it. If not, I dunno whether to import their version as a separate package or as an alternate version (net-tools-2.0?). No point in ignoring it when there's obvious bugs and fixes available, even if they're not from the original upstream. Added net-tools-1.60_p20130513023548-r1.ebuild, please test. Previous: netstat -anSp: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name sctp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 18500/sshd SCTP error in line: 2 Bug ^^ Now: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name sctp0.0.0.0:22 LISTEN 18500/sshd sctp:::22LISTEN 18500/sshd (Yes, the re-written SCTP stats code from Fedora don't display a value when 0 or nothing is connected -- no idea why). IPX addresses are also displayed correctly: Active IPX sockets Proto Recv-Q Send-Q Local AddressForeign AddressState IPX0 0 0100:0540- IPX0 0 0100:0440- IPX0 0 0100:03403E01A8C0:0001:5104 ESTAB Now: Active IPX sockets Proto Recv-Q Send-Q Local AddressForeign AddressState IPX0 0 0001:0540- IPX0 0 0001:0440- IPX0 0 0001:0340C0A8013E:0001:5104 ESTAB If anyone encounters any problems, please let me know. Thanks!, -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] RFC: GLEP 64: Export Package Manager Cached Information. (Was: RFC: GLEP 64: Standardize contents of VDB and establish and API for exporting this information.)
On Saturday 06 September 2014 16:22:46 hasufell wrote: Anthony G. Basile: On 09/06/14 12:12, hasufell wrote: Anthony G. Basile: And when you do ask, is a package that's provided installed, and if so, what's its metadata? When the package is installed, that data should have been cached. Afaik there is nothing cached if you put stuff in package.provided. It's a terrible hack, unless I missed something. I wasn't sure what Ciaran was talking about there. If its hacky, then we certainly don't want to standardize it in the GLEP. Well, you have to to define what tools can expect from provided/installed packages. That means either say you cannot expect anything, because there might or might not be metadata or say you can expect metadata for any provided/installed package in which case package.provided feature has to be removed from portage. Provided means not managed by the package manager and thus returning empty metadata for queries is perfectly fine. I don't see why this feature would need to be removed ...
Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?
On 09/07/2014 09:03 PM, Rich Freeman wrote: Right now the general policy is that we don't allow unmasked (hard or via keywords) ebuilds in the tree if they use an scm to fetch their sources. There are a bunch of reasons for this, and for the most part they make sense. Hard masking is a relic from the days that we didn't just have empty keywords, most of the VCS ebuilds in the tree just have empty keywords now and are not actually hard masked. I'd say if you set ACCEPT_KEYWORDS=** then you get to keep the pieces. I was wondering if this policy still made sense in the case of scm ebuilds that pull a particular git commit. While portage can't check the Manifest, the fact is that git will in this case, and since we're pointed at a content-hashed commit we can ensure that the package never changes. We of course can't mirror it with the current setup (there is no real reason we couldn't mirror git, but this is a different problem). Tying ebuilds to a git commit has pros and cons, but I'm hard-pressed to think of any actual QA issues. That is, something that would make our tree inconsistent, or create a security vulnerability. Just use a snapshot tarball, it's not hard to do, it allows us to mirror the file, checksum the file, and users can reinstall while offline if they have fetched ones. Am I just not thinking of something? It would probably be most useful for packages that track a backport branch or something along those lines - where upstream does not regularly update their tarballs so we're constant creating patchsets. In this case all we'd have to do is bump the commit ID in the ebuild. I make a lot of VCS snapshot tarballs, it's annoying, but the benefits to the users seem to far outweigh the 2-3 minutes of aggravation it takes me to make a tarball. -Zero -- Rich signature.asc Description: OpenPGP digital signature
