[opensuse-factory] Several factory candidate packages
Hi all, I have finally gotten around to getting several packages that have proven useful to me over many years in real-world applications properly set up in their respective OBS development projects. Now I'd like to offer them as candidates for factory. I understand there's a quasi-freeze at this time; if some have to wait until after 12.3 is finished that's fine. These should all be "leaf" packages. [ filesystems / s3backer ] https://build.opensuse.org/package/show?package=s3backer&project=filesystems s3backer is a filesystem that contains a single file backed by the Amazon Simple Storage Service (Amazon S3). As a filesystem, it is quite small and simple: it provides a single normal file having a fixed size. The file is divided up into blocks, and the content of each block is stored in a unique Amazon S3 object. In other words, what s3backer provides is really more like an S3-backed virtual hard disk device, rather than a filesystem. In typical usage, a `normal' filesystem is mounted on top of the file exported by the s3backer filesystem using a loopback mount. [ network:utilities / fonehome ] https://build.opensuse.org/package/show?package=fonehome&project=network%3Autilities fonehome allows remote access to machines behind firewalls using SSH port forwarding. The fonehome client is a daemon that runs on remote client machines that are behind some firewall that you either do not control or do not want to reconfigure, but which does allow normal outgoing TCP connections. The clients use SSH to connect to a fonehome server to which you have direct access. The SSH connections include reverse-forwarded TCP ports which in turn allow you to connect back to the remote machine. This setup is useful in situations where you have several machines deployed in the field and want to maintain access to them from a central operations server. [ network:utilities / qos ] https://build.opensuse.org/package/show?package=qos&project=network%3Autilities The Problem: Bufferbloat (see http://en.wikipedia.org/wiki/Bufferbloat) - Your SSH session turns to molasses when your kid watches YouTube - Your wife complains that "the internet is slow" - You hate the stupid DSL modems supplied by the phone company with their giant packet queues that add unnecessary latency - You have your own Linux router that routes all your traffic or is the only machine you have connected to the Internet and know there must be a better way See http://en.wikipedia.org/wiki/Bufferbloat for details. The Solution: QoS QoS = "Quality of Service" You probably already know about it. Control and proritize traffic. This QoS is new and improved. Previous QoS setups only throttled traffic in the download direction. This one handles both directions using the (poorly documented) Linux ifb interface and tc(8) 'mirred' redirection. [ utilities / csvprintf ] https://build.opensuse.org/package/show?package=csvprintf&project=utilities csvprintf is a simple UNIX command line utility for parsing CSV files. cvsprintf works just like the printf(1) command line utility. You supply a printf(1) format string on the command line and each record in the CSV file is formatted accordingly. Each format specifier in the format string contains a column accessor to specify which CSV column to use, so for example %3$d would format the third column as a decimal value. csvprintf can also convert CSV files into XML documents and back. [ utilities / mtree ] https://build.opensuse.org/package/show?package=mtree&project=utilities This project is a port of FreeBSD's very useful mtree utility to Linux and other operating systems. The mtree utility compares the file hierarchy rooted in the current directory against a specification read from the standard input. Messages are written to the standard output for any files whose characteristics do not match the specifications, or which are missing from either the file hierarchy or the specification. This port of mtree uses the autoconf infrastructure to maintain portability. [ utilities / shp ] https://build.opensuse.org/package/show?package=shp&project=utilities Like PHP, except you write your script in the bash shell scripting language instead of PHP. SHP parses and executes SHP scripts in the manner of PHP, except nested scripts are written in shell scripting language instead of the PHP language. SHP outputs its script file, with nested <?shp ... ?> blocks executed as shell scripts. [ server:monitoring / logwarn ] https://build.opensuse.org/package/show?package=logwarn&project=server%3Amonitoring Logwarn searches for interesting messages in log files, where ``interesting'' is defined by a user-supplied list of positive and negative extended regular expressions. Each log message is compared against each pattern in the order given. If the log message matches a positive pattern before matching a negative pattern then it's printed to standard output. Logwarn keeps track of its position between invocations, so each matching line is only ever output once. It also finds messages in log files that have been rotated (and possibly compressed) since the previous invocation. Logwarn also includes support for log messages that span multiple lines. Logwarn is written in C for efficient execution. A Nagios plugin is also included. Thanks, -Archie -- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Not sure what is the proper procedure/workflow here, so thought I'd ask.
Previously I sent this email...
http://lists.opensuse.org/opensuse-factory/2013-01/msg00168.html
On Sat, Jan 12, 2013 at 11:21 AM, Archie Cobbs
I have finally gotten around to getting several packages that have proven useful to me over many years in real-world applications properly set up in their respective OBS development projects. Now I'd like to offer them as candidates for factory.
I understand there's a quasi-freeze at this time; if some have to wait until after 12.3 is finished that's fine. These should all be "leaf" packages. ...
Several SRs were rejected with this comment:
State of submit-request #149573 was changed by mvyskocil:
review -> declined
Comment: Hi, sorry, there is a factory freeze atm - see http://lists.opensuse.org/opensuse-factory/2013-01/msg00333.html
I know that you've requested package before it, but please be so kind and sent an email again with coolo in CC to get an approval and then reopen the sr. Sorry for the inconvenience.
So this here is me sending the requested email. If these packages can be approved - great. If not, that's fine too. But I also have a question about SR workflow: if there is some package that someone wants to submit to factory and there is a current freeze, are they supposed to NOT submit the SR, wait until the freeze is over, and then submit it? Because it seems like it would make more sense to go ahead and submit the SR and leave it to the recipient to deal with - they can either approve it, or if it cannot be added until after the freeze, then they can just leave it in a pending state until after the freeze (perhaps with a comment to that effect), at which time they can approve it. This is how a queue of issues normally works. In other words, it makes sense to require approval before a package is added to factory during a code freeze, but is it required to get approval even to submit the SR in such a situation? Thanks, -Archie -- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23.01.2013 16:24, Archie Cobbs wrote:
cannot be added until after the freeze, then they can just leave it in a pending state until after the freeze (perhaps with a comment to that effect), at which time they can approve it. This is how a queue of issues normally works.
Yep, for new packages it doesn't really matter in what state they are pending. For updates though a decline makes sense, because there is a disagreement between developer and factory maintainer on how it should be changed, so there it often makes sense to start talking about the issue before doing a SR. I actually had an agreement with the review team not to decline things but review as normal and leave it up to me how to handle the request. But Michal thought the agreement was no longer valid after my "freeze" reminder. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Jan 23, 2013 at 9:31 AM, Stephan Kulow
On 23.01.2013 16:24, Archie Cobbs wrote:
cannot be added until after the freeze, then they can just leave it in a pending state until after the freeze (perhaps with a comment to that effect), at which time they can approve it. This is how a queue of issues normally works.
Yep, for new packages it doesn't really matter in what state they are pending. For updates though a decline makes sense, because there is a disagreement between developer and factory maintainer on how it should be changed, so there it often makes sense to start talking about the issue before doing a SR.
I actually had an agreement with the review team not to decline things but review as normal and leave it up to me how to handle the request. But Michal thought the agreement was no longer valid after my "freeze" reminder.
Thanks... since these are all new I will re-submit them. Do with as you please :) -Archie -- Archie L. Cobbs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Jan 23, 2013 at 04:31:51PM +0100, Stephan Kulow wrote:
On 23.01.2013 16:24, Archie Cobbs wrote:
cannot be added until after the freeze, then they can just leave it in a pending state until after the freeze (perhaps with a comment to that effect), at which time they can approve it. This is how a queue of issues normally works.
Yep, for new packages it doesn't really matter in what state they are pending. For updates though a decline makes sense, because there is a disagreement between developer and factory maintainer on how it should be changed, so there it often makes sense to start talking about the issue before doing a SR.
I actually had an agreement with the review team not to decline things but review as normal and leave it up to me how to handle the request. But Michal thought the agreement was no longer valid after my "freeze" reminder.
Hi coolo, this really surprise me - I am not aware about any such agreement discussed on our ML. So my apologies if I have missed something. I won't decline anything because of a version update then. Regards Mchal Vyskocil
participants (3)
-
Archie Cobbs
-
Michal Vyskocil
-
Stephan Kulow