Re: [gentoo-dev] Python 3.1: Stabilization and news item
On 03/24/2010 11:47 PM, Joshua Saddler wrote: Even then, it'll likely get installed first, as users will probably learn about p.masking it only *after* they install it. I don't have strong feelings on whether having v3 installed by default is a big problem, but the last bit here probably should be addressed. The current news item only shows up for people with python 3.1 already installed. Would it make sense to have it show up for anybody with any version of python installed? Otherwise it is news after-the-fact. Rich
[gentoo-dev] Re: MinGW for windows - creating dlls
On 03/17/2010 03:38 PM, Mansour Al Akeel wrote: Hello all, I am not sure if this is the best list to ask, but I will ask here since it's related to development and cross compilation. I have setup a 32 bit chroot environment to be able to cross develop for windows. I followed this guide: http://www.gentoo.org/proj/en/base/embedded/cross-development.xml You should be better off using this instead: http://www.nongnu.org/mingw-cross-env
Re: [gentoo-dev] Re: MinGW for windows - creating dlls
On Thursday 25 March 2010 12:57:21 Nikos Chantziaras wrote: On 03/17/2010 03:38 PM, Mansour Al Akeel wrote: I am not sure if this is the best list to ask, but I will ask here since it's related to development and cross compilation. I have setup a 32 bit chroot environment to be able to cross develop for windows. I followed this guide: http://www.gentoo.org/proj/en/base/embedded/cross-development.xml You should be better off using this instead: http://www.nongnu.org/mingw-cross-env mingw + dlls + etc... works just fine under crossdev/Gentoo -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: MinGW for windows - creating dlls
On 03/25/2010 07:43 PM, Mike Frysinger wrote: On Thursday 25 March 2010 12:57:21 Nikos Chantziaras wrote: On 03/17/2010 03:38 PM, Mansour Al Akeel wrote: I am not sure if this is the best list to ask, but I will ask here since it's related to development and cross compilation. I have setup a 32 bit chroot environment to be able to cross develop for windows. I followed this guide: http://www.gentoo.org/proj/en/base/embedded/cross-development.xml You should be better off using this instead: http://www.nongnu.org/mingw-cross-env mingw + dlls + etc... works just fine under crossdev/Gentoo -mike It's just a bit difficult to work with. It needs a lot of effort to set everything up. I recommend mingw-cross-env because it simply works out of the box and you can even compile stuff like Qt and build Windows Qt applications without any effort. 64-bit Windows apps also easy to build. So all things considered, it's the better solution. crossdev of course has other virtues and is universal. It's really just the MS Windows special case that makes mingw-cross-env worth looking at, since it's specialized for just this, while crossdev is a generic solution. Btw, does anyone intent to put an ebuild of mingw-cross-env in Portage? :P
Re: [gentoo-dev] Re: MinGW for windows - creating dlls
On Thursday 25 March 2010 13:53:29 Nikos Chantziaras wrote: On 03/25/2010 07:43 PM, Mike Frysinger wrote: On Thursday 25 March 2010 12:57:21 Nikos Chantziaras wrote: On 03/17/2010 03:38 PM, Mansour Al Akeel wrote: I am not sure if this is the best list to ask, but I will ask here since it's related to development and cross compilation. I have setup a 32 bit chroot environment to be able to cross develop for windows. I followed this guide: http://www.gentoo.org/proj/en/base/embedded/cross-development.xml You should be better off using this instead: http://www.nongnu.org/mingw-cross-env mingw + dlls + etc... works just fine under crossdev/Gentoo It's just a bit difficult to work with. It needs a lot of effort to set everything up. it'll stay that way unless someone improves things. it works for my needs, so i have no vested interest here. 64-bit Windows apps also easy to build. and it's trivial with crossdev too. i build 64bit windows JTAG/USB apps. Btw, does anyone intent to put an ebuild of mingw-cross-env in Portage? :P i only spend time on crossdev. anything else is a waste. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On 2010.03.24 21:12, William Hubbs wrote: On Wed, Mar 24, 2010 at 09:36:52PM +0100, Ben de Groot wrote: On 24 March 2010 21:25, William Hubbs willi...@gentoo.org wrote: If we make it clear in the news item that python-3 cannot be used as the default python, so if users do not want it they should mask it, we have done our job imho. In other words, this is just a matter of informing users. We agree that this is the minimum that should be done. But our Python lead stubbornly refuses to honor this reasonable request. On the other hand, I can see his point as well. The news item makes it very clear that python-3 cannot be the default python and that python-2 needs to be installed. It could be argued that he is just assuming that users are intelligent enough to figure out that they need to mask python-3 if they do not want it on their systems. Basically this is a case of how much hand-holding do we want to do? William The case where Python-3 cannot be used as the default Python is transitory (it may be a long time). Should we advise users of stable to mask it, we will get a lot of pleas for help when Python-3 is required because many users will have forgotten all about package.mask In my view, its better to avoid these future unmasking issues as stable users tend to be very wary of unmasking things and let them have Python-3 unless they are already comfortable with the contents of /etc/ portage ... in which case they are not using stable anyway. -- Regards, Roy Bamford (Neddyseagoon) a member of gentoo-ops forum-mods trustees pgpivXFtPOgsk.pgp Description: PGP signature
Re: [gentoo-dev] Python 3.1: Stabilization and news item
2010-03-25 19:34:24 Roy Bamford napisał(a): On 2010.03.24 21:12, William Hubbs wrote: On Wed, Mar 24, 2010 at 09:36:52PM +0100, Ben de Groot wrote: On 24 March 2010 21:25, William Hubbs willi...@gentoo.org wrote: If we make it clear in the news item that python-3 cannot be used as the default python, so if users do not want it they should mask it, we have done our job imho. In other words, this is just a matter of informing users. We agree that this is the minimum that should be done. But our Python lead stubbornly refuses to honor this reasonable request. On the other hand, I can see his point as well. The news item makes it very clear that python-3 cannot be the default python and that python-2 needs to be installed. It could be argued that he is just assuming that users are intelligent enough to figure out that they need to mask python-3 if they do not want it on their systems. Basically this is a case of how much hand-holding do we want to do? William The case where Python-3 cannot be used as the default Python is transitory (it may be a long time). Gentoo Python Project will soon start supporting setting Python 3 as main active version of Python. Currently about 57% of our packages from dev-python category are prepared. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Packages up for grabs
Hi, I have a bunch of packages that I no longer use and have little to no motivation to maintain. I will be replacing myself with maintainer-needed in their metadata.xml in a few days. If you want to take them, feel free to edit metadata.xml directly -- no need to ask for permission :) app-accessibility/powiedz app-i18n/man-pages-pl app-text/clara net-analyzer/chaosreader net-analyzer/gspoof net-im/ekg net-im/gnugadu net-im/tleenx2 net-libs/libtlen These are all low maintenance packages with no open bugs, the exception being ekg, for which there is an open request for a live ebuild (bug 300017). Thanks, -- Michal Januszewski http://people.gentoo.org/spock
[gentoo-dev] fltk version 1.1 is the one to go for
Hello, I wanted to report that cinepaint (which as of today is not in portage) compiles fine on my gentoo box which has been emerge-synced only yesterday. It uses however not the fltk-2.0 which is emerged by default but the version fltk-1.1.10. On the fltk website they say however that actually 1.1 is the stable version, whereas fltk-2.0 is an experimental version which is not as much maintained as 1.1. By the way, 1.3 is the development version. In case anybody would like to take care of this, I won't be able to do so during the next few weeks. Regards, Gabriel P.S.: I actually only tested the latest cvs version. I will test the latest stable tarball and then see whether cinepaint is fully functional, and will report back any problems I might encounter.
Re: [gentoo-dev] fltk version 1.1 is the one to go for
On 03/25/2010 11:01 PM, li...@gabriel-striewe.de wrote: Hello, I wanted to report that cinepaint (which as of today is not in portage) compiles fine on my gentoo box which has been emerge-synced only yesterday. It uses however not the fltk-2.0 which is emerged by default but the version fltk-1.1.10. On the fltk website they say however that actually 1.1 is the stable version, whereas fltk-2.0 is an experimental version which is not as much maintained as 1.1. By the way, 1.3 is the development version. In case anybody would like to take care of this, I won't be able to do so during the next few weeks. Regards, Gabriel P.S.: I actually only tested the latest cvs version. I will test the latest stable tarball and then see whether cinepaint is fully functional, and will report back any problems I might encounter. http://bugs.gentoo.org/278375 is for cinepaint, not the mailinglist, but thanks anyway. - samuli
[gentoo-portage-dev] Handling merge issues (on the case of prefix)
Hello!
As the prefix branch is not the last case where people may run into
problems with merging due to the conversion from SVN to Git I feel like
writing about it here.
In this mail
- The problem
- Merges in SVN
- Merges in Git
- Consequences
- Dealing with it
- The concept
- Realization
The problem
===
Merges in SVN
-
In SVN people select what commits are merged from where to where
manually: SVN, merge commits 3 to 10 to branch prefix please. What
has been merge is tracked in the mind of the person merging and in log
messages.
Merges in Git
-
In Git there's another place where merges are saved: in the DAG of commits:
- A commit with several children/successors is a branch point
- A commit with several parents is a merge point
When merging one branch into another Git runs the DAG up (into the past)
from both commits until it finds a shared merge or branch point: that's
the point up to where both branches were synced last time. History
after that point is then merged over, nothing before.
Consequences
So Git relies on the existence of merge commits to detect what has been
merged already. Creating all these merge commits is a tough job for a
conversion tool (like svn2git) as it would have to distinguish between
cases where just a few commist have been cherry-picked over and cases
where all previous commits have made it over.
So the portage Git history does not have merge commits at these points
but plain single-parent commits.
Dealing with it
===
The concept
---
So to not get diffs way bigger than needed when merging what we can do
is we can manually (and permanently) teach Git what we know more about
portage's history.
Let's look the case of the prefix branch.
The current head on prefix has this log message:
[head on prefix]
Merged from trunk -r15842:15843
Looking a few commits back (using gitg or git log) on branch master I
find this commit:
[commit f52e83b0982c9c18d96757ab55109d43a9873b3f on master]
install_qa_check: make sure init.d and conf.d files do not have
syntax errors in them #310805
svn path=/main/trunk/; revision=15843
So that's the commit where grobian merged trunk into prefix last time:
perfect.
Realization
---
How do we teach Git that all that stuff has been merged already?
By creating a merge commit with two parents:
1) f52e83b0982c9c18d96757ab55109d43a9873b3f
2) head on prefix
This is how to do it on the shell
# Checkout prefix locally
git checkout -b prefix overlays-gentoo-org/prefix
# Create merge commit manually (_NOT_ something to do usually)
MERGE_COMMIT=$(echo \
'Teach Git that tr...@15843 has been merged into prefix' \
| git commit-tree 'prefix^{tree}' -p prefix -p
f52e83b0982c9c18d96757ab55109d43a9873b3f)
# Inspect result
echo ${MERGE_COMMIT}
# Move prefix head forward to include that commit
git merge ${MERGE_COMMIT}
# Inspect what we have done visually
gitg
That's where we leave the land of dirty hacks and Git's so-called
plumbings. We can can continue merging the few remaining commits from
here as usual.
# Get a feeling for what would be merged
# Should list ~10 commits (instead of ~8000 without the hack before)
git cherry -v prefix overlays-gentoo-org/master
# Merge master into prefix
git merge overlays-gentoo-org/master # Fails with conflicts, fine
git status
git mergetool
git commit
git push overlays-gentoo-org prefix
I hope this mail was helpful to you.
Sebastian
Re: [gentoo-portage-dev] Handling merge issues (on the case of prefix)
Thanks, I've used your procedure to do that to the 2.1.7 branch and it seems to have worked well (git cherry now gives the expected result): http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=797fb70107834d0346e5201b7a9aaa5d36978c81 -- Thanks, Zac
