FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-13-2012, 09:33 PM
Alan McKinnon
 
Default

On Sun, 13 May 2012 17:01:07 -0400
Michael Mol <mikemol@gmail.com> wrote:

> On Sun, May 13, 2012 at 4:53 PM, Alan McKinnon
> <alan.mckinnon@gmail.com> wrote:
> > On Sun, 13 May 2012 14:12:04 -0400
> > Michael Mol <mikemol@gmail.com> wrote:
> >
> >> On Sun, May 13, 2012 at 4:56 AM, Alan McKinnon
> >> <alan.mckinnon@gmail.com> wrote:
> >> > [1] .avi files are notorious for this shit. It's what happens
> >> > when you are Microsoft and you release any old crappy format
> >> > without consulting the other experts out there (who will always
> >> > outnumber you)
> >>
> >> Which better container formats were available at the time AVI was
> >> released (1992)? The only contemporary container format I'm aware
> >> of is RIFF, which came out in 1988. MPEG-1 didn't come out until
> >> 1993, which was the same year the Ogg project started. Real's
> >> stuff didn't come out until 1995. Matroska was announced a decade
> >> later, in 2005.
> >>
> >> Matroska, MP4 and even OGG are nicer container formats, sure, but
> >> they weren't around yet. And even with any of them, it's perfectly
> >> possible to accidentally get A/V desync or stuttering if you don't
> >> mux your streams properly.
> >>
> >> (This post draws heavily on Wikipedia for date information, and
> >> dates may be considered only as accurate as Wikipedia...)
> >>
> >
> > You missed the essence of my post entirely.
>
> Anti-Microsoft snark? I thought I was calling you on it.
>

I said .avi is a crappy format, and it is, that much is obvious to
anyone who understands the simple basics of what a container should do.
It would have been obvious to the .avi developers then. And yet it
somehow made it's way to market and got used extensively

You asked what alternatives were available. That is not a question I
asked. It matters nothing that the public used .avi so much (they had
precious little in the way of choice). So whether they had
alternatives or not is irrelevant.

The entire gist of my post was about how .avi as it stands is crappy
and should never have been released by an entity with the engineering
clout of Microsoft as they don't have the excuse of being one dude in
Mom's basement who didn't know better. They really should have known
better.


--
Alan McKinnnon
alan.mckinnon@gmail.com
 
Old 05-13-2012, 10:03 PM
Michael Mol
 
Default

On Sun, May 13, 2012 at 5:33 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Sun, 13 May 2012 17:01:07 -0400
> Michael Mol <mikemol@gmail.com> wrote:
>
>> On Sun, May 13, 2012 at 4:53 PM, Alan McKinnon
>> <alan.mckinnon@gmail.com> wrote:
>> > On Sun, 13 May 2012 14:12:04 -0400
>> > Michael Mol <mikemol@gmail.com> wrote:
>> >
>> >> On Sun, May 13, 2012 at 4:56 AM, Alan McKinnon
>> >> <alan.mckinnon@gmail.com> wrote:
>> >> > [1] .avi files are notorious for this shit. It's what happens
>> >> > when you are Microsoft and you release any old crappy format
>> >> > without consulting the other experts out there (who will always
>> >> > outnumber you)
>> >>
>> >> Which better container formats were available at the time AVI was
>> >> released (1992)? The only contemporary container format I'm aware
>> >> of is RIFF, which came out in 1988. MPEG-1 didn't come out until
>> >> 1993, which was the same year the Ogg project started. Real's
>> >> stuff didn't come out until 1995. Matroska was announced a decade
>> >> later, in 2005.
>> >>
>> >> Matroska, MP4 and even OGG are nicer container formats, sure, but
>> >> they weren't around yet. And even with any of them, it's perfectly
>> >> possible to accidentally get A/V desync or stuttering if you don't
>> >> mux your streams properly.
>> >>
>> >> (This post draws heavily on Wikipedia for date information, and
>> >> dates may be considered only as accurate as Wikipedia...)
>> >>
>> >
>> > You missed the essence of my post entirely.
>>
>> Anti-Microsoft snark? I thought I was calling you on it.
>>
>
> I said .avi is a crappy format, and it is, that much is obvious to
> anyone who understands the simple basics of what a container should do.

The MPEG group had only been formed four years prior to AVI's release,
and didn't release their first standard until a year later. Meanwhile,
Microsoft needed a video file format that:

1) Was a file format that sat on disk
2) Synchronized audio and video
3) Integrated cleanly with their being-developed operating system (AVI
is very closely related to the Video for Windows API. It's worth
noting that WMF, another Microsoft format from this time, is
essentially a serialized form of their drawing primitives.)
4) Ran smoothly on an 80386 at 33MHz with a 16-bit, 8MHz data bus
between the CPU and persistent storage.

With the exception of perhaps (3), those are the "basics." Consider
that this was released in 1992, and then consider that it had probably
been under development for at least a couple years prior.

I won't disagree that AVI is a crappy format by today's standards, and
that it should be avoided where possible, but what you consider simple
and obvious today was *new* at the time, and so not simple and
obvious.

> It would have been obvious to the .avi developers then. And yet it
> somehow made it's way to market and got used extensively
>
> You asked what alternatives were available. That is not a question I
> asked. It matters nothing that the public used .avi so much (they had
> precious little in the way of choice). So whether they had
> alternatives or not is irrelevant.

It's entirely relevant if you want to consider whether not the
expertise to come up with a 2012-modern format *existed* in the
lead-up time to 1992.

>
> The entire gist of my post was about how .avi as it stands is crappy
> and should never have been released by an entity with the engineering
> clout of Microsoft as they don't have the excuse of being one dude in
> Mom's basement who didn't know better. They really should have known
> better.

Seriously, why? Why do you think that the entire engineering clout of
a company which hadn't yet taken over the desktop market(!) would be
focused on perfecting AVI, one piece of a large,
already-late-to-market product? They had a bunch of difficult things
to pay attention to, such as mixing protected-mode and real-mode
applications on hardware in a task-switching environment, and working
around compatibility for programs whose developers still assumed they
had full run of the system. On a 386.

--
:wq
 
Old 05-13-2012, 11:27 PM
Alan McKinnon
 
Default

On Sun, 13 May 2012 18:03:59 -0400
Michael Mol <mikemol@gmail.com> wrote:

> On Sun, May 13, 2012 at 5:33 PM, Alan McKinnon
> <alan.mckinnon@gmail.com> wrote:
> > On Sun, 13 May 2012 17:01:07 -0400
> > Michael Mol <mikemol@gmail.com> wrote:
> >
> >> On Sun, May 13, 2012 at 4:53 PM, Alan McKinnon
> >> <alan.mckinnon@gmail.com> wrote:
> >> > On Sun, 13 May 2012 14:12:04 -0400
> >> > Michael Mol <mikemol@gmail.com> wrote:
> >> >
> >> >> On Sun, May 13, 2012 at 4:56 AM, Alan McKinnon
> >> >> <alan.mckinnon@gmail.com> wrote:
> >> >> > [1] .avi files are notorious for this shit. It's what happens
> >> >> > when you are Microsoft and you release any old crappy format
> >> >> > without consulting the other experts out there (who will
> >> >> > always outnumber you)
> >> >>
> >> >> Which better container formats were available at the time AVI
> >> >> was released (1992)? The only contemporary container format I'm
> >> >> aware of is RIFF, which came out in 1988. MPEG-1 didn't come
> >> >> out until 1993, which was the same year the Ogg project
> >> >> started. Real's stuff didn't come out until 1995. Matroska was
> >> >> announced a decade later, in 2005.
> >> >>
> >> >> Matroska, MP4 and even OGG are nicer container formats, sure,
> >> >> but they weren't around yet. And even with any of them, it's
> >> >> perfectly possible to accidentally get A/V desync or stuttering
> >> >> if you don't mux your streams properly.
> >> >>
> >> >> (This post draws heavily on Wikipedia for date information, and
> >> >> dates may be considered only as accurate as Wikipedia...)
> >> >>
> >> >
> >> > You missed the essence of my post entirely.
> >>
> >> Anti-Microsoft snark? I thought I was calling you on it.
> >>
> >
> > I said .avi is a crappy format, and it is, that much is obvious to
> > anyone who understands the simple basics of what a container should
> > do.
>
> The MPEG group had only been formed four years prior to AVI's release,
> and didn't release their first standard until a year later. Meanwhile,
> Microsoft needed a video file format that:
>
> 1) Was a file format that sat on disk
> 2) Synchronized audio and video


This is the part they got wrong.

Would you not agree that this is the second-most important feature
required, where the ability to actually play the audio/video at all is
the first?

Getting that wrong is to me akin to building a car and forgetting to
provide it with an adequate means of stopping. There are many other
things that can be forgiven where one would need a predictive crystal
ball, but needing time sync information in the container is just simply
self-evident.




> 3) Integrated cleanly with their being-developed operating system (AVI
> is very closely related to the Video for Windows API. It's worth
> noting that WMF, another Microsoft format from this time, is
> essentially a serialized form of their drawing primitives.)
> 4) Ran smoothly on an 80386 at 33MHz with a 16-bit, 8MHz data bus
> between the CPU and persistent storage.
>
> With the exception of perhaps (3), those are the "basics." Consider
> that this was released in 1992, and then consider that it had probably
> been under development for at least a couple years prior.
>
> I won't disagree that AVI is a crappy format by today's standards, and
> that it should be avoided where possible, but what you consider simple
> and obvious today was *new* at the time, and so not simple and
> obvious.

I'm not talking about today's standards. I'm talking about 1992
standards.

It's not reasonable to expect MS devs to anticipate algorithms that did
not exist then, or hardware that was 10 years away, or even that the
internet would be what it is. I do expect devs to get right aspects of
their software that will be used right at the time it is released.

>
> > It would have been obvious to the .avi developers then. And yet it
> > somehow made it's way to market and got used extensively
> >
> > You asked what alternatives were available. That is not a question I
> > asked. It matters nothing that the public used .avi so much (they
> > had precious little in the way of choice). So whether they had
> > alternatives or not is irrelevant.
>
> It's entirely relevant if you want to consider whether not the
> expertise to come up with a 2012-modern format *existed* in the
> lead-up time to 1992.

Again, I'm not talking about 2012

>
> >
> > The entire gist of my post was about how .avi as it stands is crappy
> > and should never have been released by an entity with the
> > engineering clout of Microsoft as they don't have the excuse of
> > being one dude in Mom's basement who didn't know better. They
> > really should have known better.
>
> Seriously, why? Why do you think that the entire engineering clout of
> a company which hadn't yet taken over the desktop market(!) would be
> focused on perfecting AVI, one piece of a large,
> already-late-to-market product? They had a bunch of difficult things
> to pay attention to, such as mixing protected-mode and real-mode
> applications on hardware in a task-switching environment, and working
> around compatibility for programs whose developers still assumed they
> had full run of the system. On a 386.
>

No, I expect them to get the basics right. Cars and brakes.

--
Alan McKinnnon
alan.mckinnon@gmail.com
 
Old 05-13-2012, 11:54 PM
Michael Mol
 
Default

On Sun, May 13, 2012 at 7:27 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Sun, 13 May 2012 18:03:59 -0400
> Michael Mol <mikemol@gmail.com> wrote:
>
>> On Sun, May 13, 2012 at 5:33 PM, Alan McKinnon
>> <alan.mckinnon@gmail.com> wrote:
>> > On Sun, 13 May 2012 17:01:07 -0400
>> > Michael Mol <mikemol@gmail.com> wrote:
>> >
>> >> On Sun, May 13, 2012 at 4:53 PM, Alan McKinnon
>> >> <alan.mckinnon@gmail.com> wrote:
>> >> > On Sun, 13 May 2012 14:12:04 -0400
>> >> > Michael Mol <mikemol@gmail.com> wrote:
>> >> >
>> >> >> On Sun, May 13, 2012 at 4:56 AM, Alan McKinnon
>> >> >> <alan.mckinnon@gmail.com> wrote:
>> >> >> > [1] .avi files are notorious for this shit. It's what happens
>> >> >> > when you are Microsoft and you release any old crappy format
>> >> >> > without consulting the other experts out there (who will
>> >> >> > always outnumber you)
>> >> >>
>> >> >> Which better container formats were available at the time AVI
>> >> >> was released (1992)? The only contemporary container format I'm
>> >> >> aware of is RIFF, which came out in 1988. MPEG-1 didn't come
>> >> >> out until 1993, which was the same year the Ogg project
>> >> >> started. Real's stuff didn't come out until 1995. Matroska was
>> >> >> announced a decade later, in 2005.
>> >> >>
>> >> >> Matroska, MP4 and even OGG are nicer container formats, sure,
>> >> >> but they weren't around yet. And even with any of them, it's
>> >> >> perfectly possible to accidentally get A/V desync or stuttering
>> >> >> if you don't mux your streams properly.
>> >> >>
>> >> >> (This post draws heavily on Wikipedia for date information, and
>> >> >> dates may be considered only as accurate as Wikipedia...)
>> >> >>
>> >> >
>> >> > You missed the essence of my post entirely.
>> >>
>> >> Anti-Microsoft snark? I thought I was calling you on it.
>> >>
>> >
>> > I said .avi is a crappy format, and it is, that much is obvious to
>> > anyone who understands the simple basics of what a container should
>> > do.
>>
>> The MPEG group had only been formed four years prior to AVI's release,
>> and didn't release their first standard until a year later. Meanwhile,
>> Microsoft needed a video file format that:
>>
>> 1) Was a file format that sat on disk
>> 2) Synchronized audio and video
>
>
> This is the part they got wrong.
>
> Would you not agree that this is the second-most important feature
> required, where the ability to actually play the audio/video at all is
> the first?

You're going to have to go into detail. Last I checked, old versions
of Windows shipped with AVI files for their animations, and those AVI
files played fine. So it _sounds_ like they're able to play video, at
least.

And my largish collection of AMVs and videos I've put together myself
suggest that AVI can play synchronized audio and video.

> Getting that wrong is to me akin to building a car and forgetting to
> provide it with an adequate means of stopping. There are many other
> things that can be forgiven where one would need a predictive crystal
> ball, but needing time sync information in the container is just simply
> self-evident.

Only if you anticipate your audio and video streams deviating from
intended usages. AVI is used for far more things than it was designed
to do. Reading deeper into its history, it sounds like it was embraced
and extended by entities outside of Microsoft to do things it wasn't
designed for in the first place. So expecting it to handle VBR audio
or video with predictive frames is kinda like putting a supercharger
in a Pinto and complaining when it winds up sitting on its own roof.

>
>
>
>
>> 3) Integrated cleanly with their being-developed operating system (AVI
>> is very closely related to the Video for Windows API. It's worth
>> noting that WMF, another Microsoft format from this time, is
>> essentially a serialized form of their drawing primitives.)
>> 4) Ran smoothly on an 80386 at 33MHz with a 16-bit, 8MHz data bus
>> between the CPU and persistent storage.
>>
>> With the exception of perhaps (3), those are the "basics." Consider
>> that this was released in 1992, and then consider that it had probably
>> been under development for at least a couple years prior.
>>
>> I won't disagree that AVI is a crappy format by today's standards, and
>> that it should be avoided where possible, but what you consider simple
>> and obvious today was *new* at the time, and so not simple and
>> obvious.
>
> I'm not talking about today's standards. I'm talking about 1992
> standards.

_Those standards didn't exist._ That's been my key point.

Yes, there was SMPTE, but that's for video recording and production
houses, and that was certainly not a planned usage for AVI.

>
> It's not reasonable to expect MS devs to anticipate algorithms that did
> not exist then, or hardware that was 10 years away, or even that the
> internet would be what it is. I do expect devs to get right aspects of
> their software that will be used right at the time it is released.

The earliest AVI files I'm aware of were sequences of RLE bitmaps, and
the code doing playback knew *exactly* what the framerate was, because
it knew what the video was for. Framerate support was added by
external parties because external parties wanted to extend AVI for
their own purposes. For that matter, AVI was an extension of RIFF.

>
>>
>> > It would have been obvious to the .avi developers then. And yet it
>> > somehow made it's way to market and got used extensively
>> >
>> > You asked what alternatives were available. That is not a question I
>> > asked. It matters nothing that the public used .avi so much (they
>> > had precious little in the way of choice). So whether they had
>> > alternatives or not is irrelevant.
>>
>> It's entirely relevant if you want to consider whether not the
>> expertise to come up with a 2012-modern format *existed* in the
>> lead-up time to 1992.
>
> Again, I'm not talking about 2012

No, but you're talking from the perspective of 2012, with a 20-year hindsight.

>
>>
>> >
>> > The entire gist of my post was about how .avi as it stands is crappy
>> > and should never have been released by an entity with the
>> > engineering clout of Microsoft as they don't have the excuse of
>> > being one dude in Mom's basement who didn't know better. They
>> > really should have known better.
>>
>> Seriously, why? Why do you think that the entire engineering clout of
>> a company which hadn't yet taken over the desktop market(!) would be
>> focused on perfecting AVI, one piece of a large,
>> already-late-to-market product? They had a bunch of difficult things
>> to pay attention to, such as mixing protected-mode and real-mode
>> applications on hardware in a task-switching environment, and working
>> around compatibility for programs whose developers still assumed they
>> had full run of the system. On a 386.
>>
>
> No, I expect them to get the basics right. Cars and brakes.

Pintos and superchargers. AVI does far more than what it was designed
for, and even what you want it to have been designed to do wasn't even
in the forecast in 1992. In 1992, the biggest and most interesting
applications were still conceptual derivatives of VisiCalc. (Actually,
that's probably still true today, but in 1992 there wasn't as big a
base of software developers to work other concepts.)

--
:wq
 
Old 05-14-2012, 02:23 AM
 
Default

I set my screen size to 1280x1024 in my xorg.conf

This worked fine up thru Fedora 11 (I dont currently have running copies
of F12 or F13 to test it there) but it DOES NOT WORK in Fedora14.
In Fedora14 I get 1024x768 with or without the xorg.conf.

Now my actual screen is behind a KVM so that is part of the problem, if I
connect the monitor directly to the computer everything works correctly
and I get a screen size of 1280x1024,

So my question.
Is there some way to FORCE X11 to run at 1280x1024 in Fedora14, independent
of any tests it may make of the screen?

Having something to override this (incorrect) behavior would be REALLY helpful.

I keep several old versions of Fedora around for testing of some software,
so PLEASE dont tell me to just move to the most recent release.

--
Reg.Clemens
reg@dwf.com


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 05-14-2012, 03:12 AM
Tim
 
Default

On Sun, 2012-05-13 at 20:23 -0600, reg@dwf.com wrote:
> Is there some way to FORCE X11 to run at 1280x1024 in Fedora14,
> independent of any tests it may make of the screen?

Have you looked into modeline parameters on the kernel line?

I can't offer a canned solution, since I've not tried this, but have
noticed *that* mentioned before. It may help you find an answer through
Google. The right searchword is half the problem with Googling.

--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686

Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.



--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 05-14-2012, 04:08 AM
JD
 
Default

On 05/13/2012 09:12 PM, Tim wrote:

On Sun, 2012-05-13 at 20:23 -0600, reg@dwf.com wrote:

Is there some way to FORCE X11 to run at 1280x1024 in Fedora14,
independent of any tests it may make of the screen?

Have you looked into modeline parameters on the kernel line?

I can't offer a canned solution, since I've not tried this, but have
noticed *that* mentioned before. It may help you find an answer through
Google. The right searchword is half the problem with Googling.


These are examples of using xrandr. Perhaps this could help:

Forces to use a 1024x768 mode on an output called VGA:
xrandr --newmode "1024x768" 63.50 1024 1072 1176 1328
768 771 775 798 -hsync +vsync

xrandr --addmode VGA 1024x768
xrandr --output VGA --mode 1024x768


Enables panning on a 1600x768 desktop while displaying 1024x768 mode on
an output called VGA:
xrandr --fb 1600x768 --output VGA --mode 1024x768 --panning
1600x0


Have one small 1280x800 LVDS screen showing a small version of a huge
3200x2000 desktop, and have a big VGA screen display the surrounding of the
mouse at normal size:
xrandr --fb 3200x2000 --output LVDS --scale 2.5x2.5 --output VGA --pos
0x0 --panning 3200x2000+0+0/3200x2000+0+0/64/64/64/64


Displays the VGA output in trapezoid shape so that it is keystone
corrected when the projector is slightly above the screen:
xrandr --fb 1024x768 --output VGA --transform
1.24,0.16,-124,0,1.24,0,0,0.000316,1


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 05-14-2012, 04:35 AM
 
Default

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 05-14-2012, 08:07 AM
Arch Website Notification
 
Default

=== Signoff report for [testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 12 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 3 fully signed off packages
* 15 packages missing signoffs
* 0 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)


== New packages in [testing] in last 24 hours (12 total) ==

* cryptsetup-1.4.2-1 (i686)
* isdn4k-utils-3.22_20120509-1 (i686)
* iw-3.4-1 (i686)
* libnl-3.2.9-1 (i686)
* linux-3.3.6-1 (i686)
* cryptsetup-1.4.2-1 (x86_64)
* isdn4k-utils-3.22_20120509-1 (x86_64)
* iw-3.4-1 (x86_64)
* libnl-3.2.9-1 (x86_64)
* linux-3.3.6-1 (x86_64)
* misdnuser-2.0.13_20120513-1 (i686)
* misdnuser-2.0.13_20120513-1 (x86_64)


== Incomplete signoffs for [core] (11 total) ==

* cryptsetup-1.4.2-1 (i686)
0/2 signoffs
* isdn4k-utils-3.22_20120509-1 (i686)
0/2 signoffs
* iw-3.4-1 (i686)
0/2 signoffs
* libnl-3.2.9-1 (i686)
0/2 signoffs
* mdadm-3.2.4-1 (i686)
0/2 signoffs
* xinetd-2.3.15-1 (i686)
0/2 signoffs
* cryptsetup-1.4.2-1 (x86_64)
1/2 signoffs
* isdn4k-utils-3.22_20120509-1 (x86_64)
0/2 signoffs
* iw-3.4-1 (x86_64)
1/2 signoffs
* libnl-3.2.9-1 (x86_64)
1/2 signoffs
* xinetd-2.3.15-1 (x86_64)
0/2 signoffs

== Incomplete signoffs for [extra] (4 total) ==

* misdnuser-2.0.13_20120513-1 (i686)
0/2 signoffs
* xorg-server-1.12.1.901-2 (i686)
0/2 signoffs
* misdnuser-2.0.13_20120513-1 (x86_64)
0/2 signoffs
* xorg-server-1.12.1.901-2 (x86_64)
0/2 signoffs


== Completed signoffs (3 total) ==

* linux-3.3.6-1 (i686)
* linux-3.3.6-1 (x86_64)
* mdadm-3.2.4-1 (x86_64)


== Top five in signoffs in last 24 hours ==

1. thomas - 6 signoffs
2. andyrtr - 3 signoffs
3. foutrelis - 2 signoffs
4. ibiru - 2 signoffs
 
Old 05-14-2012, 08:07 AM
Arch Website Notification
 
Default

=== Signoff report for [community-testing] ===
https://www.archlinux.org/packages/signoffs/

There are currently:
* 0 new packages in last 24 hours
* 0 known bad packages
* 0 packages not accepting signoffs
* 0 fully signed off packages
* 3 packages missing signoffs
* 2 packages older than 14 days

(Note: the word 'package' as used here refers to packages as grouped by
pkgbase, architecture, and repository; e.g., one PKGBUILD produces one
package per architecture, even if it is a split package.)



== Incomplete signoffs for [community] (1 total) ==

* systemd-arch-units-20120412-5 (any)
0/2 signoffs

== Incomplete signoffs for [unknown] (2 total) ==

* mariadb-5.5.23-3 (i686)
1/2 signoffs
* mariadb-5.5.23-3 (x86_64)
1/2 signoffs


== All packages in [community-testing] for more than 14 days (2 total) ==

* mariadb-5.5.23-3 (x86_64), since 2012-04-26
* mariadb-5.5.23-3 (i686), since 2012-04-26


== Top five in signoffs in last 24 hours ==

1. thomas - 6 signoffs
2. andyrtr - 3 signoffs
3. foutrelis - 2 signoffs
4. ibiru - 2 signoffs
 

Thread Tools




All times are GMT. The time now is 07:05 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org