headers
Christoph Wickert | 1 Apr 2009 01:24
Gravatar

Re: opensync downgrade to 0.22

Am Dienstag, den 31.03.2009, 15:43 -0700 schrieb Adam Williamson:
> On Tue, 2009-03-31 at 18:32 -0400, Tom "spot" Callaway wrote:
> > On 03/31/2009 06:17 PM, Christoph Wickert wrote:
> > > Am Dienstag, den 31.03.2009, 14:53 -0700 schrieb Alex Lancaster:
> > >> Is anybody actively working on porting these broken deps in rawhide to
> > >> the newly downgraded opensync?
> > >>
> > >> Broken deps for i386
> > >> ----------------------------------------------------------
> > >> 	libopensync-plugin-kdepim-0.36-2.fc11.i586 requires libopensync.so.1
> > >> 	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
> > >> 	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libopensync.so.1
> > >> 	libopensync-plugin-vformat-0.36-2.fc11.i586 requires libopensync.so.1
> > > 
> > > Felix has downgraded libsyncml today and asked me to rebuild
> > > libopensync-plugin-syncml because I'm a proven packager. Kevin already
> > > downgraded the plugin from 0.38 to 0.36, so I just requeued his build.
> > > No joy, it still fails with the same error and it's not due to libsyncml
> > > now. See https://koji.fedoraproject.org/koji/taskinfo?taskID=1268785
> > > 
> > > Can anybody look into this, I'm not really familiar with it and have to
> > > admit that I'm a little confused after all the recent changes and
> > > downgrades. Downgrade a release further to 0.35?
> > 
> > Yes. Probably all the way back to 0.22.

I was afraid of that, but you are correct. After talking to Kevin I
downgraded, but the package still does not build because it does not
find the new libsoup in rawhide, see
https://koji.fedoraproject.org/koji/taskinfo?taskID=1268891
(Continue reading)

Permalink | Reply | 3 comments |
headers
Martin Ebourne | 1 Apr 2009 01:35
Picon

Re: Radeon Test Day: Wednesday April 1st (yes, really)

On Mon, 30 Mar 2009 12:24:38 -0700, Adam Williamson wrote:
> Be it hereby announced that this Wednesday, the first of the glorious
> month of April (ignore Eliot, he was a douche), shall be the Test Day
> for the radeon video driver. Which is used, as you may already have
> deduced, for ATI Radeon (and FireGL) video cards. All of 'em.
> 
> http://fedoraproject.org/wiki/Test_Day:Radeon_2009-04-01

Is there anything specific to test the vsync/tear free video that has 
recently been added to radeon - and which hardware it is expected to work 
on?

Cheers,
Martin

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply | 0 comments |
headers
Martin Ebourne | 1 Apr 2009 01:35
Picon

Re: Radeon Test Day: Wednesday April 1st (yes, really)

On Mon, 30 Mar 2009 12:24:38 -0700, Adam Williamson wrote:
> Be it hereby announced that this Wednesday, the first of the glorious
> month of April (ignore Eliot, he was a douche), shall be the Test Day
> for the radeon video driver. Which is used, as you may already have
> deduced, for ATI Radeon (and FireGL) video cards. All of 'em.
> 
> http://fedoraproject.org/wiki/Test_Day:Radeon_2009-04-01

Is there anything specific to test the vsync/tear free video that has 
recently been added to radeon - and which hardware it is expected to work 
on?

Cheers,
Martin

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply | 2 comments |
headers
Pete Zaitcev | 1 Apr 2009 01:40
Picon
Favicon

Re: question about git workflow

On Tue, 31 Mar 2009 18:42:02 +0200, Christoph Höger <choeger <at> cs.tu-berlin.de> wrote:

> I am getting used to using git while working with upstream projects. So
> when I try to make a patch available upstream, I encounter the following
> problem: I want to make small commits during my work but of course send
> the result as a single patch via git format-patch. So what's best:

I just go the caveman way and do
git diff origin master > ../x.diff

> And the final question: When I got to the point of sending one single
> patch and upstream merges it, how can I resync with upstream without
> having to clone again? 

Sure, I always do  git pull.  If a conflict occurs, I do this
 - Edit conflicts so the code looks good (using git status to remind
   what's left, and then vi, /, >>> Enter ).
 - make check  # just see how I'm doing
 - git commit -a
   This thing posts this scary message "oh you're committing a MERGE,
   the sky is falling!" inside the commit template. Just do :wq
   and let it commit
In my experience, git merges pretty well. However, I need to watch
out for an occasional double-patch when upstream rearranges chunks.
In C, all functions look the same with 3-line context.

-- Pete

--

-- 
fedora-devel-list mailing list
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pete Zaitcev | 1 Apr 2009 01:47
Picon
Favicon

Re: question about git workflow

On Tue, 31 Mar 2009 12:52:42 -0400, Behdad Esfahbod <behdad <at> behdad.org> wrote:

> > I am getting used to using git while working with upstream projects. So
> > when I try to make a patch available upstream, I encounter the following
> > problem: I want to make small commits during my work but of course send
> > the result as a single patch via git format-patch.

> "git-diff from..to" can do that.  But srsly, why not send a patch series? 
> That's the beauty of git.

That only works if your temporary commits make sense. Otherwise
it's a garbage history which cannot be bisected. But I usually commit
things before lunch. Git has many beauties, one is that commits cost
you nothing. Also, free backups.

> > And the final question: When I got to the point of sending one single
> > patch and upstream merges it, how can I resync with upstream without
> > having to clone again?
> 
> git-rebase typically.

Woa, a cannon against sparrows. Although, if you're a big enthusiast
of branches... But I just clone and pull all the time instead.

-- Pete

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Nicholson | 1 Apr 2009 01:51
Picon

Re: question about git workflow

On Tue, Mar 31, 2009 at 4:40 PM, Pete Zaitcev <zaitcev <at> redhat.com> wrote:
> On Tue, 31 Mar 2009 18:42:02 +0200, Christoph Höger <choeger <at> cs.tu-berlin.de> wrote:
>
>> And the final question: When I got to the point of sending one single
>> patch and upstream merges it, how can I resync with upstream without
>> having to clone again?
>
> Sure, I always do  git pull.  If a conflict occurs, I do this
>  - Edit conflicts so the code looks good (using git status to remind
>   what's left, and then vi, /, >>> Enter ).
>  - make check  # just see how I'm doing
>  - git commit -a
>   This thing posts this scary message "oh you're committing a MERGE,
>   the sky is falling!" inside the commit template. Just do :wq
>   and let it commit
> In my experience, git merges pretty well. However, I need to watch
> out for an occasional double-patch when upstream rearranges chunks.
> In C, all functions look the same with 3-line context.

FYI, newer git added a --rebase switch to pull. So, you can do "git
pull --rebase origin", and it will just rebase whatever local commits
you have on top. Of course, you may still have conflicts, and that's
not a good idea if your repo is public.

--
Dan

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Woehlke | 1 Apr 2009 03:03
Picon
Gravatar

Re: F11: xorg decision to disable Ctrl-Alt-Backspace

Adam Jackson wrote:
> So let's list the cases that zap would actually recover from:
> 
> 1: stuck grabs
> 2: focus reverts to None and your window manager is dead
> 3: X driver that's decided to stop rendering (or stop rendering
> correctly)
4: "log out"... didn't. :-)

There's no data loss since I'm trying to make X shut down anyway. (And, 
guess what? VT switching *doesn't work* with NVIDIA's so-called 
"drivers". It'll be wonderful to have nouveau learn how to support 
triple-head across two boards.)

While I do have access to other machines from which I could ssh in, 
there's a huge convenience difference between giving the three-finger 
salute and getting immediately back to work, and powering up another 
box, logging in, finding X, killing it, going back down the hall to my 
machine, finding out it didn't work, trying again...

(I've not filed bugs any of the many occasions this has happened because 
I'm using trunk KDE; I tend not to bother filing bugs against stuff that 
has a high probability of having been fixed before I even noticed it, 
and might well be due to a bad build on my end.)

In the grand scheme of things, I log out so infrequently it's not a huge 
deal, but I still think disabling c-a-bs is the wrong decision.

--

-- 
Matthew
(Continue reading)

Permalink | Reply | 0 comments |
headers
Itamar Reis Peixoto | 1 Apr 2009 03:28
Picon

Re: Orphan package: reiserfs-utils

I will take it and let it's live for more time (probably until next merge review).

I am still have some machines running with reiserfs



On Tue, Mar 31, 2009 at 7:14 PM, Jason L Tibbitts III <tibbs <at> math.uh.edu> wrote:
Jeff Garzik has indicated in the merge review ticket
(https://bugzilla.redhat.com/show_bug.cgi?id=226367) that he has had
no interest in maintaining reiserfs-utils for some time and so I have
orphaned it for him.  If someone wishes to maintain this package,
please feel free to pick it up but keep in mind that the merge review
linked above needs doing (which should be quite easy) and, though I'm
sure it's obvious to anyone who cares, that the package needs
updating.

 - J<

--
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list



--
------------

Itamar Reis Peixoto

e-mail/msn: itamar <at> ispbrasil.com.br
sip: itamar <at> ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599


--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply | 0 comments |
headers
Bruno Wolff III | 1 Apr 2009 06:45
Picon

Re: F11: xorg decision to disable Ctrl-Alt-Backspace

On Tue, Mar 31, 2009 at 16:00:17 -0400,
  Matthew Saltzman <mjs <at> clemson.edu> wrote:
> On Tue, 2009-03-31 at 19:43 +0200, Kevin Kofler wrote:
> > Matthew Saltzman wrote:
> > > OK (I'm trying to picture it, and I keep seeing Rose Mary Woods
> > > demonstrating how she "accidentally" created the infamous 18-minute gap
> > > in the Watergate tapes), but it's still "unlikely" if you are typing,
> > > much more so than any Ctrl-Alt-≤whatever> key combo.
> > 
> > I accidentally hit it with my foot.
> 
> Did you move the machine after that, or do you now tie your feet to the
> chair posts?

After accidentally hitting the switch on a powerstrip, I taped an angle
bracket over it so I couldn't do that again.

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply | 0 comments |
headers
Bruno Wolff III | 1 Apr 2009 06:52
Picon

Re: koji / kernel feedback...

On Tue, Mar 31, 2009 at 09:13:27 -0600,
  "Nathanael D. Noblet" <nathanael <at> gnat.ca> wrote:
> Recently I started using some kernels built directly from Koji to test  
> out some hardware issues. So now I am mostly happily running 2.6.29-10  
> from a koji build. I'd like to provide feedback if its wanted on the  
> issues it has fixed for me, as well as some regressions I've noticed.  
> I'm not sure it warrants a bug as much as, installed and X now works, Y  
> doesn't, and a bug in Z resurfaced...
>
> Is this a karma thing, or a bug thing, or just put it on the list thing?

I don't think you can do karma unless it gets pushed to bodhi, which doesn't
happen for rawhide. So I think bugzilla is the only reasonable option.
(You can try the devel list, but that's pretty hut or miss whether the people
that might want to see your feedback will see it.)

--

-- 
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Permalink | Reply | 0 comments |

Gmane