Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 42079
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Mamoru KOMACHI (RETIRED) <usata@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Ed Catmur <ed@catmur.co.uk>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 42079 depends on: Show dependency tree
Bug 42079 blocks: 23299
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2004-02-18 15:26 0000
Required by passepartout-0.4.

Current ebuild works fine.

Not sure whether to re-SLOT it into 1.

------- Comment #1 From Mamoru KOMACHI (RETIRED) 2004-02-21 09:36:12 0000 -------
Thanks for reporting. I've committed libxmlpp-1.0.2.ebuild into
Portage tree.  I didn't put 2.5.1 since we don't have gtkmm-2.3.x
branch atm, but added SLOT="1" for future support of both versions.

------- Comment #2 From foser (RETIRED) 2004-02-21 13:56:44 0000 -------
why is this text-markup ?

Anyway, afaik 1.0.X just is the API stable  of the 0.2x dev series, so they should be similar SLOTed : now you have a mix of both 0 & 1, resulting in  portage keeping track of 2 packages while it's one and the same.

Second, 2.3 gtkmm and it's resulting 2.4 series are meant to be in the same SLOT as current gtkmm, so there is no reason to SLOT libxmlpp in the forseeable future to my knowledge.

This needs to be adressed.

PS. Why is there a mirror restriction ? Do check the ebuild completely when bumping for cruft, etc.

------- Comment #3 From Mike Gardiner (RETIRED) 2004-02-22 01:35:26 0000 -------
Vapier, this isn't text-markup, it's a C++ wrapping library around libxml.

Foser, is this gnome-herd material, along with gtkmm, libgnomemm etc c++ bindings in dev-cpp?

0.2x were the development versions that became version 1.0 upon 'official/stable' release, thus they fit in the same slot, I've reverted it to SLOT=0.

As for the nomirror, mholzer, you added it to the 0.2x series? I've removed it from 1.0

------- Comment #4 From foser (RETIRED) 2004-02-22 06:20:50 0000 -------
Gnome could probably take care of it for now.

------- Comment #5 From Mamoru KOMACHI (RETIRED) 2004-02-22 06:58:48 0000 -------
Sorry for the breakage. I was doing bug squash of text-markup this
weekend (because I'm rather inactive for weekdays) and took it and
committed without careful observation. I should have put it back to
bug-wranglers.

As for nomirror restriction, I read klieber's post on gentoo-mirrors
few weeks ago about not mirroring sources distributed by large
mirrors such as sourceforge and kernel sources (because of distfile
mirror's disk space), so I thought it was okay. Aren't gnome mirrors
solid enough not to get mirrored by Gentoo distfiles mirror?

------- Comment #6 From foser (RETIRED) 2004-02-29 10:00:39 0000 -------
usata, i would appreciate it if you could at least fix the outstanding issues
in this bug & add metadata.xml with gnome as maintaining herd.

------- Comment #7 From Mamoru KOMACHI (RETIRED) 2004-03-02 12:11:35 0000 -------
Obz did half of the job for me already.. thanks.
I added metadata.xml and removed RESTRICT line from ebuilds.
(there seems little consensus on putting RESTRICT for mirror://)
Thanks again to gnome herd people for maintaining the package.

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug