Package Base Details: xorg-server-git

Git Clone URL: https://aur.archlinux.org/xorg-server-git.git (read-only)
Keywords: git x-server xorg xorg-server
Submitter: ilikenwf
Maintainer: yurikoles
Last Packager: yurikoles
Votes: 44
Popularity: 1.41
First Submitted: 2008-08-07 19:05
Last Updated: 2019-09-01 21:01

Pinned Comments

yurikoles commented on 2019-05-29 15:00

PRs are welcome: https://github.com/yurikoles-aur/xorg-server-git

Det commented on 2010-08-29 10:55

Dunno how can you not be able to extract my tarball.. probably a really weird archiving tool you got there - how about just 'tar xvfz xorg-server-git.tar.gz'?

About gitorious/github, I'm not exactly sure what you mean by that. That we'd do changes _there_ and the other one, whoever is the maintainer, would just update the package(s) in the end? Wouldn't that be rather unnecessary thing to do, when 1) the changes would first be posted to gitorious and _then_ here - is the log keeping so important? 2) If the xorg-server git tree changed and the package would need to be updated in order to compile and the maintainer one wouldn't be able to update the package for whatever reason (and didn't know that was gonna happen and thus didn't disown the package) then what(?) - the other person would either need to wait for the maintaining person to update the package or tell a TU in the forums/IRC/mailing list to disown the package so that he could update it himself.

I wouldn't really like to be doing that :S.

Det commented on 2010-08-29 10:53

Dunno how can you not be able to extract my tarball.. :/.

About gitorious/github, I'm not exactly sure what you mean by that. That we'd do changes _there_ and the other one, whoever is the maintainer, would just update the package(s) in the end? Wouldn't that be rather unnecessary thing to do, when 1) the changes would first be posted to gitorious and _then_ here - is the log keeping so important? 2) If the xorg-server git tree changed and the package would need to be updated in order to compile and the maintainer one wouldn't be able to update the package for whatever reason (and didn't know that was gonna happen and thus didn't disown the package) then what(?) - the other person would either need to wait for the maintaining person to update the package or tell a TU in the forums/IRC/mailing list to disown the package so that he could update it himself.

I wouldn't really like to be doing that :S.

Det commented on 2010-08-29 10:12

Dunno how can you not be able to extract my tarball.. :/.

About gitourious/github, you'd need to find another person for that. It's just not my thing...

Anonymous comment on 2010-08-28 10:05

Still the same situation.
Det maybe we can collaborate on them using git I got repo on giorious for this.

Det commented on 2010-08-26 11:50

Nope, you probably just had "xorg-server-git.tar.gz" on your desktop already causing my tarball to be renamed to "xorg-server-git.tar(1).gz" or something like that. When you tried extracting _this_ tarball it resulted in a .tar file with name something like "xorg-server-git (1)" that would of course then need to be renamed to "X.tar" to have it extracted completely.

But you need not to just stop "associating" with this thing and "glib2-newest" when you can just orphan both packages and then we both do changes to each one of them when we think such changes should be done.

E.g. If you are busy enough to not update either of these packages - I can do it for you by adopting -> updating -> disowning.

I used to do that for like 6 months when I started out as a 'package maintainer' (or whatever) but in the whole 6 months period only _1_ person actually updated one of my packages when it was out of date - and just that single time. But maybe 'we' will do better than that.

Det commented on 2010-08-26 11:45

Nope, you probably just had "xorg-server-git.tar.gz" on your desktop already causing my tarball to be renamed to "xorg-server-git.tar(1).gz" or something like that. Extracting _this_ tarball results in a .tar file that would of course need to then be renamed to "xorg-server-git.tar" to extract it completely.

But you need not to just stop "associating" with this thing and "glib2-newest" when you can just orphan it and we both do changes to each one of them when we think such changes should be done.

E.g. If you are busy enough to not update either of these packages - I can do it for you by adopting -> updating -> disowning.

I used to do that for like 6 months when I started out as a 'package maintainer' (or whatever) but in the whole 6 months period only _1_ person actually updated one of my packages when it was out of date - and just that single time. But maybe 'we' will do better than that.

Anonymous comment on 2010-08-26 08:19

@Det: The package you uploaded is broken (I got only xorg-server-git file inside of it) and it's format is bz2 not tar.gz ;)
BTW. Would you like to adopt package when it will be orphaned?

Det commented on 2010-08-24 18:26

Ok, apparently libxres was included with [Testing]'s xorg server 1.9 as a makedependency.

Det commented on 2010-08-22 08:23

Uhh... okay(?), but why exactly are so many people talking about libxres being needed with the build while I myself hadn't never even seen a message about it with either my own package/the official [extra]'s xorg-server (ABS). So what exactly is this option to make libxres needed?

Also as a sidenote when replying to the former post on the comments section here you don't need to actually quote the message because it only fills the space here. At least I don't like it when people do that.

Anonymous comment on 2010-08-21 19:43

>Could you please tell us WHY do you think so?

Hmm, your surprise is reasonable. libxres is needed with options from stock Arch package, which I copy-pasted and forgot about it. :) With your options there is no need for libxres.