Foresight Linux Desktop

oktober 6, 2007

Paul Cutler
silwenae
paul cutler's blog
» More on the waiting game aka Quake Wars

I, like Phoronix, thought the Linux client was days away, but it’s weeks according to a post I saw on Linux-Gaming.net this morning:

I’ve also been making steady progress with the Linux Client, and it’s coming along really well. We’ve been running a closed-beta test for ‘friends and family’ for a little while, and for the past couple of weeks have had a fully functional version of the demo running. The closed-beta testers are now able to play alongside Windows players on the same version, with full Punkbuster support. The major systems including the renderer and audio are working great, and performance has been good on both the NVIDIA and ATI graphics cards.

Alongside my other responsibilities at id, my focus now is on optimization for the Linux Client. If everything goes to plan, we should have the Linux Client ready for release in just a few weeks.

Read TTimo’s full post here.

Darn. Well, I have tons of stuff to do with Foresight right now anyway, but it would have been fun to have some time to play before my new job starts in a couple weeks!

, , ,

oktober 5, 2007

Ken VanDine
kenvandine
ken's blog
» FOSSCamp

As a distro guy, I am always very interested in ways to encourage open source projects to work together. FOSSCamp is designed to do just that. I would encourage anyone in the Boston area, or willing to visit the fine city of Boston to come and hang out for a couple days (Oct 27-28).

I am sure there will be lots of good times, and great topics discussed. I am hoping to talk about desktop technologies, package/systems management, and online desktop possibilities.

oktober 4, 2007

Conary News
conary
Conary News
» Conary 1.2.1 Released

Conary 1.2.1 is a maintenance release.

Build Changes:
  • The addGitSnapshot() source action is now available. (CNY-1965)
  • Cooking derived packages no longer warns about their experimental state. (CNY-2092)
  • loadInstalled does not search the local database for a matching package on checkin, but instead searches the repository. This makes it easier to develop packages that are correct, with the potential of not building on the current machine. (CNY-2027)
Client Changes:
  • The Conary client is now less aggressive in sending keepalive packets with long-running requests. (CNY-2104)
  • Promote and clone callbacks are more verbose. (CNY-2063)
Bug Fixes:
  • Schema migration for the Latest table now correctly handles branches that end in redirects. (CNY-2081)
  • Adding a large number of user maps is now more efficient if the new addServerGlobs method is used. (CNY-2083)
  • Redirects between branches on the same label, which were necessary before Conary 1.2.0, are again handled correctly. (CNY-2103)
  • The 'conary updateall' command again properly handles the --replace-files command-line argument. (CNY-2112)
  • Patches are no longer partially applied when building. Previously, partially applied patches were not reverted and could in rare circumstances cause incorrect patches to appear to be correctly applied. (CNY-2017)
  • A bug which caused Conary to incorrectly determine the flags for python dependencies on 64-bit systems has been fixed. (CNY-2091)
  • Ruby dependencies now function properly in a bootstrap build of the ruby package. (CNY-2109)


Paul Cutler
silwenae
paul cutler's blog
» Foresight Wiki

The Foresight wiki is unavailable for adding content for a few days. All wiki content is still viewable, but you can’t edit or add content until after we perform an upgrade, which will hopefully be completed by the end of the weekend.

Our apologies!

, ,

» Waiting Game: Quake Wars

I picked up a copy of Enemy Territory: Quake Wars.

Now I’m just playing the waiting game for the Linux binary so I can play it.

I think the actual game is more fun.

But I wanted to make a statement by picking up the game during release week - it’s important to me to support commercial game companies who make Linux compatible games.

, , , ,

» links for 2007-10-03

No Tags

oktober 3, 2007

Og Maciel
ogmaciel
Journal Of An Open Sourcee
» Milestones and Events

Quick post to mention a couple of personal milestones and events:

  • Today is my 1-year anniversary at rPath. It also marks 1 year since I stopped doing work with VB.NET/C# and PL/SQL and embarked in a brand new world of Python, and web-by programming… There is not a day that I don’t learn something new!
  • Sept. 29th marked 1 year since I left New Jersey for North Carolina! Besides the advantages of working with such a smart bunch (see above), I now get to spend quality time with my wife and two daughters. I get to see them grow and learn, and that is priceless!
  • October 16th will be my 7th wedding anniversary! Marrying Elizabeth was about the smartest thing I have ever done!
  • I will be attending this year’s FOSSCamp 2007, together with my friend Ken Vandine. Looking forward to seeing Jorge and Jono again!


Paul Cutler
silwenae
paul cutler's blog
» Rolling releases

Over the next month or two, you may hear a lot of news about upcoming releases of various Linux distributions.

But what if you could do things differently? What if you could have a Linux distribution that wasn’t tied to a specific date twice a year to update your packages and your distribution? What if you wanted access to the latest Banshee for example that will be out later this year and not wait until next spring? Why mess around with backports or unstable respositories just to gain access to the latest release of a package that features a bug fix you need?

Try a Linux distribution that features a rolling release. Try Foresight Linux. Yes, we have a “formal” release when GNOME releases every 6 months, but when a package has an update, it’s probably updated before you even notice, and just one conary updateall away from being included in your desktop. The latest packages will give you access to the latest features, and better yet, the latest bug fixes of any given package. With Foresight Linux 2.0 on the horizon, we will be adding a more formal QA process, so don’t let the “but we need months of testing” stop you from updating. Point releases come out every couple months, but mostly to update the downloadable media including install CDs / DVD and live media such as Live CDs or VMWare images. The magic of conary will keep all of your installed packages up to date.

Additionally, if something doesn’t work, Conary is an innovative package manager that features a rollback feature - from the command line type sudo conary rollback 1 and you’ll be right back to where you were before you installed that last package.

There can be better ways of doing things. And a rolling release is a better way.

, , ,

oktober 2, 2007

Ken VanDine
kenvandine
ken's blog
» We can get along

We might represent different distros, but we will always have GNOME in common.

We can get along

Jorge and I at the Ohio Linux Fest after-after party.


Stephanie Watson
stefw
stefw
» Conary Uncorked: Your Father Smelt of Conary Queries!

In my last post, I launched my series of posts called “Conary Uncorked” as a means of introducing people to managing a Linux system based on Conary package management. I want to start by describing how to learn about software installed on a Conary-based system.
* What’s installed on my system?
Use conary query, or conary q for short, to determine what is installed on your system. There are several option combinations you can use to refine the search results. Without any other arguments, though, it returns a list of Conary packages and groups installed on the current system along with their current Conary revision values. Conary packages contain the software installed on your system, and groups are used to manage multiple packages together.
*How can I determine what Conary packages install the “Foo” software?
I run into this issue all the time: I know the name of the software, but I don’t know the name of the Conary packages used to install it. Usually it is only a single package, but some software has been built into multiple packages. What I typically do for this is to grep my query for strings that might be used in the package name:
$> conary q | grep foo
* Is package “foo” installed?
When you know the package name, add an argument to the conary query command to query a specific package. If there are results, Conary displays the revision installed. If the package is not installed, Conary says that it is not found. Here are a couple of examples:
$> conary q openssh
openssh=4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]
$> conary q foo
foo was not found

* Where was package “foo” installed from?
The —full-versions option provides sufficient output to determine what revision of the package is installed as well as where it was installed from. However, it may not always be the easiest thing to read for new Conary users, especially because Conary automatically abbreviates parts of the string. The following query shows OpenSSH from Foresight Linux:
$> conary q—full-versions openssh
openssh=/conary.rpath.com@rpl:devel//1//foresight.rpath.org@fl:1-devel//1/4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]

The —info option reveals several pieces of information about the Conary package, including the specific “Label” used to answer the question of where it was installed from. For OpenSSH, the label shows its repository hostname (foresight.rpath.org) and the release branch from that repository (fl:1):
$> conary q—info openssh
Name : openssh           Build time: Sun Sep 16 22:15:55 2007
Version : 4.7p1–0.1.1–1      Label : foresight.rpath.org@fl:1
Size : 675106
Pinned : False
Flavor : gnome,ipv6,krb,!openssh.smartcard,selinux,tcpwrappers is: x86

After working with Conary for a while, you will likely become familiar with the various parts of a Conary verion string and be better able to read the results of —full-versions. I recommend bookmarking Conary:Version String at wiki.rpath.com for reference.
* What files are managed by the “foo” package?
The —ls and —lsl options return a list of the files on the system that are installed and managed by a particular package. The results show absolute paths so the files are easy to locate on the system. Here’s another example using OpenSSH:
$> conary q —ls openssh
/usr/share/doc/openssh-4.7p1/ChangeLog
/usr/share/doc/openssh-4.7p1/INSTALL
/usr/share/doc/openssh-4.7p1/OVERVIEW
/usr/share/doc/openssh-4.7p1/README… (output truncated)

* Can we do that in reverse? What package manages the ”/usr/share/foo/foobar.sh” file on my system?
Use the —path option to determine the package that manages the file in question. This is very useful and highly recommended before arbitrarily modifying files throughout your system. Here is yet another example related to OpenSSH; notice that the option is before the argument:
$> conary q—path /etc/ssh/moduli
openssh:runtime=4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]

* What’s that colon for? Is “openssh:runtime” different than the “openssh” package?
It is different, but part of the same package. When the package name is followed by a colon and another name, such as “openssh:runtime” and “openssh:doc”, this references a component. When the package is first built, Conary separates out the files into components. Each component represents some logical grouping of files within the package, such as everything needed to run the software or the documentation for how to use the software. This gives the flexibility for other packages to resolve dependencies by bringing in components rather than entire packages. It also gives users the freedom to uninstall components that are just taking up space without removing an entire package. But, enough about how awesome Conary can be… how do I know what components make up an installed package?
Use the —troves option to list all the components that are installed as part of a package. A trove is an installable unit on a Conary-based system or Conary repository. Troves include packages and their individual components as well as Conary groups. The following example shows all the troves that are installed for the OpenSSH package:
$> conary q—troves openssh
openssh=4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]
openssh:doc=4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]
openssh:runtime=4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]

* You mentioned dependencies. How can I be sure things still work if I remove a component from my system?
First, Conary warns you if you are about to remove a component that is used to resolve a dependency elsewhere on the system. Conary keeps track of these dependencies for you. Second, you can use the —deps option to display dependency-related information. You can also use —file-deps to list component dependencies at the file level. Results display what the trove “requires” to resolve its own dependencies and “provides” to resolve other packages’ dependencies. You don’t have to track this information unless you really want to do so; trusting Conary’s warnings is usually enough to prevent mistakes when installing and removing software:
$> conary q—deps openssh
$ conary q—deps openssh
openssh=4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]
(output truncated)...
openssh:runtime=4.7p1–0.1.1–1!openssh.smartcard,!openssh.static_libcrypto]
Provides:
file: /usr/bin/ssh-copy-id
file: /usr/bin/ssh-keygen
trove: openssh:runtime
Requires:
abi: ELF32(SysV x86)
file: /bin/sh
soname: ELF32/libc.so.6(GLIBC_2.0 GLIBC_2.1 GLIBC_2.2 GLIBC_2.3 SysV x86)
soname: ELF32/libcom_err.so.3(SysV x86)
soname: ELF32/libcrypt.so.1(SysV x86)
soname: ELF32/libcrypto.so.5(SysV x86)
soname: ELF32/libgssapi_krb5.so.2(SysV x86)
soname: ELF32/libk5crypto.so.3(SysV x86)... (output truncated)

When you need more information from your Conary queries, reference one of the following resources:
* The conary(1) manual page (run the command man conary)
* The conary query page on the rPath Wiki (http://wiki.rpath.com/wiki/Conary:conary_query)
The next “Conary Uncorked” post goes beyond your current system and queries what software is available for installation from Conary repositories across the Internet.

oktober 1, 2007

Paul Scott-Wilson
pscott
pscott's thoughts » Foresight
» had 2b dun

lolcatz

After reading Jame’s Zodiac I felt compelled to do this as I feel the same way. You’re tech-savvy enough to what to use Foresight on your computer so presumably you have a qwerty/qwertz/dvoark/whatever keyboard. The least you could do is not type like your using your thumbs.</Zodiac>

Original picture by celebdu found with the awesome Creative Commons Flickr search looking for “kitten laptop”.

lulz?


Ken VanDine
kenvandine
ken's blog
» What a great time in Ohio!

This was my first year attending the Ohio Linux Fest, and what a great event. I had a chance to meet lots of cool people and have some great conversations. The .ORG Desktop Corner, which consisted of Foresight, GNOME, Fedora and Ubuntu Ohio Loco, was a real smash. We had the first 4 tables near the entrance, and was so much more crowded than the rest of the show. Linux on the desktop was obviously important to people this year.

Kevin did a great job running the Foresight, with some great help from Ryan, and Michael. We had 250 DVDs to give out, which I think ran out after just a couple hours, and lots of stickers.

On Friday night, Jorge Castro and I were invited to give a talk about GNOME on Saturday (another talk was canceled). Obviously with short notice, we had to do a little cramming to get some slides ready and figure out how we would tag team the talk. Fortunately I think both Jorge and I work best under pressure, and things seem to go off well (besides OOo eating Jorge’s work). I hope all that attended enjoyed it as much as I did.

In the afternoon, Michael and I hosted a Conary BoF. We had a pretty full room, and everyone seemed to “get it”. Lots of great questions, and we spent some time to really talking about the stuff we love. We even ran over by an hour, and nobody seemed anxious to leave… which must be a good sign :)

No question, I will be going back next year!


James Laver
elpenguin
JamesLaver.com
» Unacceptably poor English

How hard is it to type ‘you’, as opposed to ‘u’? Those two letter must be killers. Is it really necessary that you talk as if you were a twelve year old to use foresight? Come on, grow up.

What is further irritating me recently is that when I pick people up on their inability to even try and communicate their point, I’m getting picked up on it. Ask yourselves if you think we should be breeding a situation where users will start asking questions like “I’z got a probz wiv networkmanager, wut shud i du 2 fix it lulz?”, because I anticipate such a situation isn’t far away, with the direction we’re headed in.

There is a saying a friend of mine had in his signature on a forum we both frequent, “friends don’t let friends use bad code”. Friends don’t let friends make themselves appear to have the intelligence of a typical 12 year old either (unless of course they are 12). I think this should be extended beyond friends to everyone seeking help in the channel, because most people, when picked up, apologise and start talking acceptable english, and all is fine. When you get an ass who refuses to do, apart from making my blocklist (and my shitlist), the rest of the channel have to put up with their ridiculous text talk.

Now I can understand speaking poor english if it isn’t your first language, but text talk implies that you’re fluent enough to know better. There isn’t a seriously crippling character limit on irc messages, so don’t save yourself all of a second to make us spend half an hour trying to translate your crappy comments into English.
On the other hand, some of you think I’m an ass for disliking text-talk. Well, so be it. But if you want my help, you can try to talk English. I’m not asking for perfect capitalisation and punctuation, I’m just asking you to try.


Paul Cutler
silwenae
paul cutler's blog
» links for 2007-09-30

No Tags

september 30, 2007

Scott Parkerson
smerp
Snort a Sprocket
» Phony

“I believe the closest Rush [Limbaugh] has ever gotten to combat was watching We Were Soldiers with surround sound.”

— Alex at Army of Dude
regarding Rush’s comment about phony soldiers

(Via Making Light.)

september 29, 2007

Ken VanDine
kenvandine
ken's blog
» Ohio Linux Fest

Michael K Johnson and I just made it into Columbus for Ohio Linux Fest. I am very excited, this is the first show that we will actually have a Foresight booth. Come stop by, we have some DVDs of 1.4 and with any luck will have some stickers to give out.

I will also be giving a talk about rPath built appliances on the Open Source Solutions stage at 11am… so be there or be square!

If I can rally enough interest, we will host a Conary BoF… So look for that or track me down, I will be the guy in the bright green Foresight t-shirt ;-D

september 28, 2007

Mihai Ibanescu
misa
mihai.ibanescu.net
» The long road to Conary 1.2

Conary 1.2 is finally out!

We are very excited, I think this is a great achievement for Conary. It packs three months of work behind the scenes on several new features and a ton of bug fixes, while we were maintaining the former stable Conary 1.1 branch. The release announcement is pretty long, as a result.

Many thanks to the Foresight community, who agreed to try some early releases and provided valuable feedback (not to mention uncovering those minor things that we like to call undiscovered features, for lack of a better term :-) ).


Ken VanDine
kenvandine
ken's blog
» Conary 1.2!

Woot! Conary 1.2 has been released with many new features. Read the announcement for a run down of all new features/improvements. Foresight users will see it in their next update, enjoy!.


Conary News
conary
Conary News
» Conary 1.2.0 Released

Conary 1.2.0 is a new feature release.

Major Changes:

Label multiplicity, in which a trove on the same label appearing on multiple branches was understood as meaning that all the trove can be installed at once, is now generally deprecated. Instead, a newer trove on a different branch that ends with the same label as an older trove will be considered together with and generally preferred to the older trove. Branch affinity, in which Conary keeps packages from the same branch during an update, is therefore replaced with label affinity, in which Conary keeps packages from the same label during an update. Many of the individual changes in this version are parts of implementing this general change in behavior.

Client Changes:

  • Update journal did not have an entry for hard links which were made to targets which already existed on the system, causing system corruption if the journal had to be rolled back. (CNY-1671)
  • The critical update information now includes enough data to re-create the original update job. (CNY-1608)
  • Unknown trove info types in the database are properly stored in extracted trove info. (CNY-2059)
  • Conary's internal diff and patch implementation now support files without trailing newlines. (CNY-1979)
  • The clone and promote commands no longer complain when a buildRequirement is not also being cloned to the new location. (CNY-1844)
  • The cvc promote and clone commands are now more efficient and do not download unnecessary packages. This also makes it possible to clone packages where access to some of the included troves is unavailable at the time of the promote or clone operation. (CNY-1913)
  • A bug which prevented the mirror client from using hidden commits when mirroring to a single target has been fixed. (CNY-1981)
  • Filesets are now cloneable. (CNY-1297)
  • Large files are now compressed on disk instead of in memory when creating rollbacks. (CNY-1896)
  • The Conary client API is now more careful with releasing open file descriptors. (CNY-1834)
  • The "migrate" mode has changed to overwrite changes made to files that are not yet owned by Conary, but already exist on the system, as well managed, non-configuration files that have changed. (CNY-1868)
  • When signals are received during updates, the journal is now rolled back before conary terminates. (CNY-1393)
  • A 'cvc checkout' of multiple projects uses far fewer repository calls now, and uses a single changeset.
  • The 'cvc update' and 'cvc diff' commands now accept a source version argument without a source count. (CNY-1921)
  • Added getTroveLatestByLabel as a client-side call.
  • Label lookups pick the latest version which matches instead of the latest version on each branch.
  • Replaced branch affinity with label affinity.
  • getAllTroveLeavesByLabel() filters results by server names to eliminate spurious results from repositories which host multiple server names. (CNY-1771)
  • The cvc and conary commands now ignore broken pipes on standard output instead of producing a traceback. (CNY-1853)
  • Redirects follow the label of the branch they were built with instead of the branch itself.
  • Building redirects to a branch is now deprecated; redirects should point to labels instead. (CNY-1857)
  • The --replace-files option has been split into --replace-managed-files, --replace-unmanaged-files, --replace-modified-files, and --replace-config-files. The original option is still accepted, and is equivalent to specifying all four of the new options simultaneously (CNY-1270)
  • Dependency resolution now allows updates to go across branches if the branches are on the same label.
  • Added --show-files parameter to "conary config" to display where configuration items came from.
  • Newly installed transient files now silently replace files which are otherwise unowned. (CNY-1841)
  • Conary now rereads entitlements from disk when EntitlementTimeout is received. (CNY-1862)

Server Changes:

  • External entitlement servers can now specify per-entitlement timeouts and automatic retry values (CNY-2060)
  • A bug which triggered an exception while migrating postgresql repositories has been fixed. (CNY-1912)
  • The getNewTroveInfo call works faster for mirror operations. (CNY-2006)
  • An issue that prevented the server from responding with the proper error message when in maintenance mode has been fixed. (CNY-2005)
  • An issue that was affecting cooking performance when looking up path IDs has been fixed. (CNY-1996)
  • Setting "forceSSL" once again requires a HTTPS connection be used when authentication data is passed to an Apache based Conary Repository. (CNY-1880)
  • A bug that caused incorrect values for sourceItemId and clonedFromId to be used when groups and components were committed as part of one changeset has been fixed. (CNY-1903)
  • A bug that caused the Latest table to be rebuilt incorrectly when migrating to schema version 15.0 has been fixed. (CNY-1909)
  • Added EntitlementTimeout exception to notify clients that an entitlement has timed out from the authentication cache (CNY-1862)
  • Added remote_ip to user and entitlement based external authentication checks (CNY-1864)
  • Fixed bug in proxy which prevented remote_ip from being passed to internal repository.

Build Changes:

  • A bug which caused Conary to compute python dependencies incorrectly when using an external version of python (such as when building python itself) has been fixed. (CNY-2087)
  • More paths (/usr/lib/.*-sharp.*/) have been added to :cil components. (CNY-2080)
  • Mono (CIL) files are now placed in :cil components by default. (CNY-1821)
  • Path ID lookups now ignore permission errors; in such a case, a new path ID is computed. (CNY-1911)
  • Conary now handles python files that specify a python interpreter that is not available on the system or in the builddir. It will print a warning and not attempt to compute dependency information for those files. (CNY-2050)
  • The loadSuperClass() and loadInstalled() methods now print out name, version, and flavor of the package that was used when determining which source recipe to load. (CNY-1967)
  • Filesets now accept macros. (CNY-148)
  • crossRequires are now ignored when not cross compiling. (CNY-1950)
  • Malformed .jar files are now ignored when computing Java dependencies. Previously, Conary exited with an error while attempting to process them. (CNY-1983)
  • Conary dependencies are no longer attempted when cross-compiling, and when bootstrapping python, modules are now sought in system python directories as well as in the destdir. (CNY-1986)
  • Python extension modules (.so files) now expose the proper dependencies by providing, for example, itertools (the true name) as well as itertoolsmodule (as it has previously), but requiring the shorter name if it is available on the system. (CNY-1077)
  • Redirects will now be followed in group recipes. Previously, including redirects would result in an error. (CNY-1693)
  • Derived recipes can now be based on troves which have files that have the same content (SHA1) as each other but are members of different link groups (are not intended to be installed as hard links to each other). (CNY-1733)
  • Derived packages now work properly if the troves they are based on contain dangling symlinks. (CNY-1914)
  • Symbolic links that have not changed in a derived package are now correctly ignored by policies that are not interested in unmodified files. (CNY-1879)
  • The build flavor string used for building a trove is now stored as part of that trove's troveInfo field. (CNY-1678)
  • Looking up path IDs now stops when all files have been found, instead of always walking the shadow hierarchy. (CNY-1911)
  • On x86_64 platforms, multilib cooks set only Arch.x86_64. (CNY-1711)
  • The cvc update command can now update multiple directories simultaneously.
  • Java files are now put in a :java component by default. (CNY-527)
  • Python dependencies now include flags designating the major version of python involved, as well as a flag distinguishing the target architecture library directory (normally "lib" or "lib64") to enhance update reliability. When building a bootstrap python or using a different python executable than Conary is running with, Conary will use an external python process to determine python dependencies. (CNY-1517)
  • Ruby dependencies are now generated, and Ruby modules are placed in a :ruby component by default. Flags are included in the dependencies similar to the Python flags, except that they are not conditional. (CNY-612)
  • Conary now ensures that two binary packages with the same source count but different build counts end up with the same build count after cloning. (CNY-1871)

Other Changes:

  • InodeStreams and FileStreams now preserve unknown elements, allowing future additions to those without breaking fileId computation. (CNY-1971)
  • The transport layer is using BoundedStringIO objects for compression, decompression and XMLRPC encoding/decoding, to avoid excessive memory consumption. (CNY-1968)
  • Conary tracebacks now report values for each variable in the local namespace in each frame. (CNY-1922)
  • All select() calls have been replaced with poll() for higher efficiency. (CNY-1933)
  • The showchangeset script now displays information on redirect troves.
  • The logcat script now works for calls which passed lists of entitlements.
  • A bug which prevented the mirror client from using hidden commits when mirroring to a single target has been fixed. (CNY-1981)
  • Repository database migration scripts have been integrated into a common unit.
  • Proxy can now inject entitlements and user authentication on behalf of clients (CNY-1836)

Bug Fixes:

  • When running in threaded mode, don't install signal handlers, since that is not supported. (CNY-2040)
  • URLs returned by prepareChangeSet, getChangeSet, and getFileContents are all based on the URL the client used to call the repository instead of built internally by the repository. (CNY-2034)
  • An issue has been fixed that was preventing the repository server, under certain circumstances, from determining the proper URL. (CNY-2056, CNY-2058)
  • An issue related to Conary proxies running in non-SSL mode, talking to SSL-enabled repository servers has been fixed. (CNY-2067)
  • Related to CNY-2034, Conary proxies now properly compute the return URL. (CNY-2069)
  • The client now properly computes the downloaded file's digest if a size limit was specified. (CNY-2072)
  • A regression from Conary 1.1.94 that caused some local cooks to fail to be installable due to incorrect primary trove information has been fixed (CNY-2078)
  • Bootstrapping python can now find system conary when using the bootstrapped python to determine python dependencies. (CNY-2001)
  • A bug in findTroves when using partial labels, introduced as part of 1.1.90, has been fixed. (CNY-2011)
  • cvc operations no longer trace back when the current working directory can no longer be accessed. (CNY-2014)
  • Redirects to nothing are now displayed when using --trove-flags. (CNY-2025)
  • Stack frames now wrap long lines to make them easier to read. (CNY-2016)
  • Comparison of VersionSequence objects is now more robust. (CNY-2020)
  • Autosourced files added to both a shadow and its parent now merge properly. (CNY-1856)
  • Python extension modules installed at the top level of the Python search path no longer produce a traceback when computing dependencies. (CNY-1995)
  • The clone and promote commands now work when cloning over removed packages. (CNY-1955)
  • searchPath will now provide only the best flavor match when matching against groups with more than one version of a package available. Previously, it would return all matches. (CNY-1881)
  • ccs2tar correctly handles changesets with duplicate contents and hard links. (CNY-1953)
  • An error in the way attributes of ServerProxy classes get marshaled has been fixed. (CNY-1956)
  • The last trove source in a trove source stack is now properly passed flavor information. (CNY-1969)
  • Derived packages properly handle files that were not flavored due to an exception in the upstream packages. (CNY-1954)
  • The transport layer now automatically encodes non-ASCII strings into XMLRPC Binary objects. (CNY-1932)
  • An error that was causing warnings to be printed while cooking groups has been fixed. (CNY-1957)
  • The new OpenPGP parsing code now accepts Version 3 keys and signatures, without verifying them. (CNY-1931)
  • A file descriptor leak in the getFileContents method has been fixed.
  • If ignoreErrors is set for a configuration file, that setting is now honored for contexts as well.
  • Troves with large numbers of identical files now erase faster, thanks to a SQL fix in sqldb.iterFiles. (CNY-1937)
  • Conary now correctly avoids assuming that standard I/O files are objects with fileno() methods. Previously, calling Conary interfaces with non-file objects associated with standard input, output, or error could trace back. (CNY-1946)
  • The --buildreqs option for 'conary q' now functions when multiple build requirements have the same name.
  • An issue related to the flavor preferences list not being properly populated when a group was cooked has been fixed. (CNY-1951)
  • Fix a bug in commit code that made r.macros.buildlabel unusable because you could not commit recipes that used it. (CNY-1752)
  • An internal class, _AbstractPackageRecipe, has been renamed to AbstractPackageRecipe, in order to allow the inclusion of its methods in its subclasses' documentation pages. The old name is still available for compatibility with older modules. (CNY-1848)
  • Multiple entitlements can be stored for a single hostname or glob (previously only the last hostname for a particular hostname/glob would be used). (CNY-1825)
  • Cloning the source component for filesets is now allowed.
  • The includeConfigFile directive now sorts files that are matched by globs.
  • In group recipes, the default settings from r.add() will now override the default settings from an r.addAll(). (CNY-1882)
  • Cloning no longer downloads components that won't be cloned. (CNY-1891)
  • Proxies previously used the wrong getChangeSet() call for old protocol versions. (CNY-1803)

september 27, 2007

Ken VanDine
kenvandine
ken's blog
» Get Involved with Foresight Linux

As Paul mentioned in his blog post, we are having a developer meeting on IRC (#foresight-devel on Freenode) next Wednesday, October 3rd at 1:00 p.m. EST. Anyone interested in giving back a little and helping to make the world a better place, come join us. Not a developer? Don’t worry… we have lots of ways for people to help out, testing, documentation, translations, packaging, sysadmin, etc… lots of ways to get involved and there is no better time than now!

You can find the agenda and more info here. So come join us, #foresight-devel on Freenode.