[Bug 313952] [NEW] Boa Constructor Inspector Window unusable on 64-bit Hardy
Public bug reported: Inspector unusable - OverflowError - 0.6.1 on Linux 64 bit Clicking on any numerical property in the inspector to change it results in the attached error. The Inspector's property field never opens ; the value it contained before clicking is set to null/void/nothing, but reverts to the original value after dismissing the designer and opening it again. Any subsequent click in the value field for the property after the initial click raises the same error as in the attached file, unless the Designer was closed and then opened again. It becomes therefore impossible to modify any numerical value using the Inspector. This does not happen with the value fields with boolean or list (e.g. (O,1) ) types. Removing ',max=sys.maxint, min=-sys.maxint)' from line 133 in PropEdit/InspectorEditorControls stops this behaviour. The bug happens with wx2.6 as well as wx2.8, but not on a 32-bit OS. Not being a true Python programmer, I have no idea what other impact removing the line quoted above may have. Yet, found no other way to be able to use the Inspector so far. The attached log may refer to a different version of python-wxgtk than my actual 'working' version (the v2.8 debian package from wxpython.org) ; please note that the traceback was identical in all other aspects throughout testing. ** Affects: boa-constructor (Ubuntu) Importance: Undecided Status: New -- Boa Constructor Inspector Window unusable on 64-bit Hardy https://bugs.launchpad.net/bugs/313952 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 313960] [NEW] Please update dnsmasq hardy packages to version 2.46
Public bug reported: Binary package hint: dnsmasq Hello, Dnsmasq has added support for CNAME directives in the config file starting with version 2.46. This version is not available in Hardy, while I believe a LTS release should deserve this improvement. All alternatives require (to my knowledge) heavier configuration and / or demand more on resources. Switching to bind in order to use CNAME or compiling dnsmasq2.46 from source should be considered nontrivial/discourage for the average/beginning user. How about relasing a package for v2.46 in backports ? Regards, Dr. Moe ** Affects: dnsmasq (Ubuntu) Importance: Undecided Status: New -- Please update dnsmasq hardy packages to version 2.46 https://bugs.launchpad.net/bugs/313960 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 313952] Re: Boa Constructor Inspector Window unusable on 64-bit Hardy
** Attachment added: "log.txt" http://launchpadlibrarian.net/20910543/log.txt -- Boa Constructor Inspector Window unusable on 64-bit Hardy https://bugs.launchpad.net/bugs/313952 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 313955] [NEW] Improper translation support for Boa Constructor in Hardy
Public bug reported: Binary package hint: boa-constructor Hello, As I was troubleshooting a different issue with Boa Constructor's Inspector window, I eventually ended up installing from upstream source (awkward, I know...). To my surprise, as soon as the source version was installed, all GUI strings were properly translated to French, as opposed to roughly 30% of them with the Hardy package. The UI language had been set through Boa's prefs for days, but the setting was only taken into account with the original source. Same issue on 32-bit and 64-bit versions. Regards, Dr. moe ** Affects: boa-constructor (Ubuntu) Importance: Undecided Status: New -- Improper translation support for Boa Constructor in Hardy https://bugs.launchpad.net/bugs/313955 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 313956] [NEW] Boa Constructor won't use python-wxgtk v2.8
Public bug reported: Binary package hint: boa-constructor Hello, The Hardy package for Boa depends on version 2.6 of the wxpython libs. Installing version 2.8 of these libs (which is available in Hardy) makes no difference to Boa. The command line switch for starting Boa with a distinct wx version seems not to be supported. Regards, Dr. Moe ** Affects: boa-constructor (Ubuntu) Importance: Undecided Status: New -- Boa Constructor won't use python-wxgtk v2.8 https://bugs.launchpad.net/bugs/313956 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 85014] Re: Fail to enter rc1.d by putting 1 in bootparam in edgy
Hi all, can't believe Scott James Remnant once wrote "This should be fixed upstream" (in telinit ! ). Well, it still works for any other distro, and I bet you'd get a good laugh from the upstream folks if they came across this, which they may have since this issue came up a VERY long time ago. This is really one too many, and our operations are now giving up on Ubuntu. Glad we found out before we became too involved to go back. Let's keep serious : there is no way we or anyone just a little UNIX-savvy will invest time and effort into troubleshooting normal UNIX behavior just because someone preposterously believed they could change it, without even attempting to preserve existing standard functionality. Even if it only lasted for a minute, this would be but a sad joke, so keep up with your good proprietary fun, but for heaven's sake, stop claiming that Ubuntu or any operating system using upstart as it is now would comply with LSB. This is all we have to say. Le jeudi 29 janvier 2009 à 06:58 +, Scott James Remnant a écrit : > ** Changed in: upstart >Target: None => 0.5-later > -- Fail to enter rc1.d by putting 1 in bootparam in edgy https://bugs.launchpad.net/bugs/85014 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 313960] Re: Please update dnsmasq hardy packages to version 2.46
Hi Thierry, Thanks for forwarding. Looking forward to the backporters' response. _Yet_, can you tell me if v2.46 stands a chance of making it to the regular LTS repos ? I must stress again that this would be an important improvement for LTS. To summarize: - if any dnsmasq user wants / needs to use a cname directive, v2.46 is required. - the question was asked several times in the past in every ubuntu forum whose language I can read (many times, that is...) - beginners won't backport - more experienced users may find it a waste of time to backport, and their work may not benefit to the community (I just backported, clumsily, and would not submit this work for anybody else's use unless someone officially in charge would take the time to validate / improve this backport). - anyone not directly involved in Ubuntu will not want to backport every single daemon in order to stick to the LTS release (I have backported 3 different servers last month, and this is not my idea of a Xmas holiday ;-). - LBNL who'd want the hassle of installing and configuring bind solely in order to declare a CNAME (or any number of them)? (or any other DNS server 4 that matter...) I probably should not have mentioned the backports repo in my previous message ; getting v2.46 there would surely be better than not at all on Hardy, _nonetheless_ the whole point should be to give _regular_ Hardy a simple DNS server with every function anyone would expect which works _out_of_the_box. So please let me know if inclusion in the main Hardy repos could be considered at all (there may be something I missed here...) Regards, Dr. Moe Le lundi 05 janvier 2009 à 19:37 +, Thierry Carrez a écrit : > Redirecting to hardy-backports... Please see > https://help.ubuntu.com/community/UbuntuBackports for more information > on the backport process. > > ** Also affects: hardy-backports >Importance: Undecided >Status: New > > ** Changed in: dnsmasq (Ubuntu) >Status: New => Invalid > -- Please update dnsmasq hardy packages to version 2.46 https://bugs.launchpad.net/bugs/313960 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 313960] Re: Please update dnsmasq hardy packages to version 2.46
Hello Mathias and Team, After carefully reading the page you mention, I still fail to understand why dnsmasq 2.46 should not make its way to Hardy LTS at all. Since : - It IS also a security upgrade (should be raised above hardy's current version according to upstream's site). - No regression was introduced, as other distros have acknowledged, as your competitors' package listings show. The only 'valid' reason mentioned on this policy page would be : "bugs that (a) are Fix Released in the current development release and (b) have been nominated but not approved for stable releases"... although it remains unclear what exact policy applies in these cases. Moreover, this update would seem to qualify as a MicroException, in Ubuntu's own terms, provided the packagers actually can communicate with one another, which seems to be very much the case. All in all, what a disappointing answer! Not even a remote chance, either now or later! It makes it look like Ubuntu LTS is not even striving for production-ready status and that this claim as well as that of "Long Term" is but a slogan. Moreover, such a brisk invalidation of an otherwise valid report without even bothering to examine or answer the other arguments we gave regarding the benefits this update could bring to Ubuntu gives your company a bad name. Not to mention referring us to your policy page, since software quality and marketing have little to do with one another. It had been a hard time convincing several of our customers to switch to Ubuntu, and there will be no way for me or anyone else to talk them into accepting quick and dirty handmade non-supported backports like the one I made for this daemon and am currently using. Alas, the management's conclusions will likely highly resemble mine above: not production-ready, not an LTS release but for the name. (Please note this is not the first issue of this kind we've come across, only the first one reported, and that it used to seem - from testing previous releases since the not-production-ready-either dapper drake - that Ubuntu's maintainers were among the most reactive). Still hoping at the very least for an officially supported backport... And at best for more sensible consideration, i.e. a detailed answer to the reasons we formerly gave for this request, which ideally would match Ubuntu's claims to quality. Meanwhile (if so) I remain terribly sorry for this lack of concern towards quality and human consideration. Regards, Dr. Moe "In a democratic community, nagging may seem an appropriate response to contempt." Rvd. J. Barley Le mardi 06 janvier 2009 à 15:44 +, Mathias Gug a écrit : > On Mon, Jan 05, 2009 at 09:45:38PM -, dr.moe wrote: > > _Yet_, can you tell me if v2.46 stands a chance of making it to the > > regular LTS repos ? > > > > So please let me know if inclusion in the main Hardy repos could be > > considered at all (there may be something I missed here...) > > > > I don't think so. Criteria for making Stable Release Updates are > outlined on the following wiki page: > > https://wiki.ubuntu.com/StableReleaseUpdates > > -- > Mathias Gug > Ubuntu Developer http://www.ubuntu.com > Hi Thierry, Thanks for forwarding. Looking forward to the backporters' response. _Yet_, can you tell me if v2.46 stands a chance of making it to the regular LTS repos ? I must stress again that this would be an important improvement for LTS. To summarize: - if any dnsmasq user wants / needs to use a cname directive, v2.46 is required. - the question was asked several times in the past in every ubuntu forum whose language I can read (many times, that is...) - beginners won't backport - more experienced users may find it a waste of time to backport, and their work may not benefit to the community (I just backported, clumsily, and would not submit this work for anybody else's use unless someone officially in charge would take the time to validate / improve this backport). - anyone not directly involved in Ubuntu will not want to backport every single daemon in order to stick to the LTS release (I have backported 3 different servers last month, and this is not my idea of a Xmas holiday ;-). - LBNL who'd want the hassle of installing and configuring bind solely in order to declare a CNAME (or any number of them)? (or any other DNS server 4 that matter...) I probably should not have mentioned the backports repo in my previous message ; getting v2.46 there would surely be better than not at all on Hardy, _nonetheless_ the whole point should be to give _regular_ Hardy a simple DNS server with every function anyone would expect which works _out_of_the_box. So please let me know if inclusion in the main Hardy repos could be considered at all (there may be something I missed here.
Re: [Bug 313960] Re: Please update dnsmasq hardy packages to version 2.46
Hello Thierry and Team, Thanks for taking a little more time to explain. Nonetheless, perhaps the most important point is still missing from your answer. Please see below. Le dimanche 18 janvier 2009 à 17:28 +, Thierry Carrez a écrit : > > It makes it look like Ubuntu LTS is not even striving for > > production-ready status and that this claim as well as that of "Long > > Term" is but a slogan. > > You seem to imply that quality and production-ready standards imply > providing updates that add functionality to an already released product. Well, definitely not, please read on. > That is really not the case. Agreed. > The idea is rather to try to fix existing > bugs while ensuring the largest stability for the current users of the > stable release. Introducing, "for human consideration" Part of Ubuntu's motto. ;-) > , new > functionality into a stable release is wrong: you face the risk of a > regression which is the part of my former posts you seem to insist on missing. I may indeed not be aware of such a regression, but : - there is no report of this alleged regression, wherever. - Ubuntu packagers would know, if I'm correct, since packages for dnsmasq 2.46 were built for both Intrepid and Jaunty, and the maintainers also patched the Hardy version as soon as a security flaw was discovered. So why not give the actual technical reason? Please do. > (even if very unlikely) for the majority of users to please a > minority of them. I fail to understand what minority you are referring to. Provided that a post would represent a number of users (on top of the poster himself), please add up the many posts I mentioned before and do the math ; while this may not be the majority, we are definitely not talking about just a few. Trying to make such a point also misses on the issue of the targeted audience. Some customers will simply not use Bind, or any other "easier" DNS server than dnsmasq. Hence, there is probably no such thing as a general DNS server users' target audience, and figures should be evaluated accordingly. As a real-world example, we actually had to switch two production servers to Slackware because the site manager would more easily trust both the security advisories he can find on the web and their need for CNAME functionality than the package we backported (sadly); following this (and other issues) , we have ceased to recommend Hardy as a solution for security-conscious sites that cannot dedicate more resources to IT management; although setting up the Slackware "model server" was some task, it has already proved not to lead to such dead ends, thus allowing us to revert our remote maintenance time budget to normal. Please note that this had quite an impact in terms of Ubuntu's image for most of this company's employees. > That's what upgrading is for : getting new > functionality and bleeding-edge releases of software. In upgrading to a _stable_ release? If "recent" was the word, we'd be using Intrepid or Jaunty, and not the self proclaimed production server that came out before we started our projects. We would not use the production-ready-LTS argument on our customers either. Also, referring to _new_ functionality here feels odd ; CNAMEs may be new to dnsmasq (making the product indeed ready for adoption in different environments), they are not to DNS. Once again, we are not discussing just some gizmo, but essential DNS functionality, no matter how recently it may have been introduced in dnsmasq. We do understand the _fear_ of regression due to this function's novelty _in_dnsqmasq_, but again there have been no reports of such a regression, no matter where we look. > RHEL for example > apparently still ships dnsmasq-2.39... Slackware, ArchLinux, Debian's Lenny (currently "frozen") and OpenSuse to name just a few all ship 2.46, which is even available in the commercial version of the latter. Besides, the comparison with RHEL seems inappropriate, since it is a commercial product, and neither ourselves or our customers are part of their partners ; it seems that companies like Ubuntu claim to offer the same quality (a production-ready server OS) for free. > > That said we understand the need to provide new functionality for users > of the stable release and that's what the Backports project proposes. And we all have yet to receive an answer from them... and by now it would seem that more time was spent on either end discussing whether the update is worthwhile than would be required to at least build the package, if not test its integration within hardy for this hypothetical (AFAIK) regression. Finally, our operations are now fine here, some without Ubuntu, some with our own backport, but we are still expecting a technical, fact-based explanation to marking this bug as invalid. Your next answer will help in determining whether it is still worthwhile looking into Ubuntu's evolutions and support or if we should build up on different solutions. > Thanks again for y
[Bug 319406] Re: runlevel not passed to init scripts
Hello, Up This should actually be phrased as upstart MUST support various runlevels. Went the same path as Marco Ciampa, and achieved the same results. In the current offer, upstart only has support dor the built-in recovery mode plus ONE runlevel. This is a nonstandard behaviour which causes perplexity to many. While looking for a solution, I came across several apparent dead ends where others may stop. Choice of any runlevel among several is a standard feature which cannot be given up or made harder to set up. Regards, Dr. Moe -- runlevel not passed to init scripts https://bugs.launchpad.net/bugs/319406 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 85014] Re: Fail to enter rc1.d by putting 1 in bootparam in edgy
Le mardi 10 février 2009 à 14:30 +, Scott James Remnant a écrit : > On Thu, 2009-02-05 at 17:33 +0000, dr.moe wrote: > > > can't believe Scott James Remnant once wrote "This should be fixed > > upstream" (in telinit ! ). > > > Scott James Remnant (me) _is_ upstream for telinit. And so ? How does this account for anything else ? (On a side note, the former message was addressing the team, obviously) Your answer perplexed us for a second, and then gave us all a good laugh. As our final communication with Canonical; we decided to google around for S.J.R. so as to better explain why all further messages from this individual and company will now be piped to /dev/null here. Referring to S.J.R.'s comments on this bug and to http://www.fosdem.org/2009/interview/scott+james+remnant: Scott James Remnant believes "hat sometimes you've just got to ditch the past and start over from scratch" ; yet, the same once admitted that his product "only handles -s/single/S being on the command line, because that's all I knew about at the time". Hence, S.J.R. believes he can singlehandedly change something he hardly understands (preposterous, did we write ?) and that he among all people doesn't have to pay attention to the recommendations of his elders. Sadly, S.J.R appears to show enough charisma / pretention to have convinced others to turn Ubuntu's users (and now Fedora's) into his beta-testers ; which we definitely refuse to be, especially as we were using what Canonical claims to be a production-ready server (no, we're not testing this kind of product, guess why ?). We shall give upstart a high salute when it becomes ready ; for now, the program being almost years behind its own schedule, still not including basic functionaliity based on the claim that it will turn better someday (ever heard M$ representatives explain that it doesn't matter if their product is buggy because they will be releasing a new version ?), and S.J.R. having the extra nerve to postpone fixing certain flaws which are so apparent that they have been reported over a dozen times, we are simply waving goodbye (ditching as you'd say) any distro which uses upstart in its present state. Finally, we are glad to report that we have tired enough of mindless one-line answers from Canonical team members who prefer to brag about who they believe they are instead of trying to understand what may be wrong with their work to extend our decision of ditching ubuntu to redirecting any e-mail from Canonical / Ubuntu / related / etc. to the black hole where they belong. Heck, we've wasted enough time tracking down discrepancies and unexpected behaviors to bugs usually introduced by Ubuntu's packaging or projects not to have to bear with these high ideas of yourselves when all you should be doing is fixing those mistakes. Although our policy never was to ignore anybody (as Robert Silverberg once wrote : "Ignorance cannot be forgiven, it can only be cured"), we have spent enough valuable time reminding Ubuntu associates of their responsibilities and received enough of these answers made of contempt which amount to "Do you know who you're talking to ?", this latest answer from S.J.R . being the winner in this category. There is no point whatsoever in engaging a conversation with people who know better no matter what to the extent that they won't bother replying to arguments, and prefer to rely on the opinion they have on themselves. Maybe S.J.R. should have read the message on the t-shirts labeled "F*** Ubuntu" differently and come back to a bit decent humility, if he ever had any ; too bad S.J.R. was baffled to find out that other people believed in thinking ahead and working together, that the same people where just not ready to blindly follow S.J.R wherever he'd want to go; maybe those t-shirts should have used a different name than Ubuntu. We have nothing else to say on this matter. Dr. Moe > > Scott > -- > Scott James Remnant > sc...@canonical.com > -- Fail to enter rc1.d by putting 1 in bootparam in edgy https://bugs.launchpad.net/bugs/85014 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 313956] Re: Boa Constructor won't use python-wxgtk v2.8
Hi Luca, Thanks for making this clear. Sorry for not replying to your question sooner, I got overbooked. Regards, Dr. Moe Le samedi 11 avril 2009 à 14:08 +, Luca Falavigna a écrit : > Actually, boa-constrcuctor depends on python-wxgtk v2.6 since it has not > been tested with 2.8, so it's better using 2.6 for now. > > ** Changed in: boa-constructor (Ubuntu) >Status: Incomplete => Invalid > -- Boa Constructor won't use python-wxgtk v2.8 https://bugs.launchpad.net/bugs/313956 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 313952] Re: Boa Constructor Inspector Window unusable on 64-bit Hardy
Hi Luca, Thanks for this, will test asap :) Regards, Dr. Moe Le samedi 11 avril 2009 à 16:18 +, Luca Falavigna a écrit : > Fixed in boa-constructor 0.6.1-6, just uploaded in Debian. > > ** Changed in: boa-constructor (Ubuntu) >Importance: Undecided => Medium > > ** Changed in: boa-constructor (Ubuntu) >Status: New => Fix Committed > -- Boa Constructor Inspector Window unusable on 64-bit Hardy https://bugs.launchpad.net/bugs/313952 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 74825] Re: Unreferenced function freezes tar.gz export
** Description changed:
Hello,
The tar.gz export option does not work on my installed version of gcfilms
(gcfilms/dapper uptodate 6.0-1) unless line 93 in
/usr/share/gcfilms/lib/GCExport/GCExportTarGz.pm
is commented out (on my machine, the line reads :
#$movie->{image} = $self->restorePicture;
- after adding the comment mark).
+ after adding the comment mark ; 'sub restorePicture' is of course nowhere to
be found).
Commenting out this line stops the export operation from freezing, but the
resulting file cannot be imported into a win32 version of the program (tried
with v.6.2, will double check with matching version 6.0 if I can find a windoze
archive ; importing back into same prog on same machine on Linux works fine).
+ UPDATE : import works properly with version 6.4 for windoze, so I guess this
was fixed upstream.
Regards,
Dr. Moe
--
Unreferenced function freezes tar.gz export
https://launchpad.net/bugs/74825
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 74825] Unreferenced function freezes tar.gz export
Public bug reported:
Hello,
The tar.gz export option does not work on my installed version of gcfilms
(gcfilms/dapper uptodate 6.0-1) unless line 93 in
/usr/share/gcfilms/lib/GCExport/GCExportTarGz.pm
is commented out (on my machine, the line reads :
#$movie->{image} = $self->restorePicture;
after adding the comment mark).
Commenting out this line stops the export operation from freezing, but the
resulting file cannot be imported into a win32 version of the program (tried
with v.6.2, will double check with matching version 6.0 if I can find a windoze
archive ; importing back into same prog on same machine on Linux works fine).
Regards,
Dr. Moe
** Affects: gcfilms (Ubuntu)
Importance: Undecided
Status: Unconfirmed
** Description changed:
Hello,
The tar.gz export option does not work on my installed version of gcfilms
(gcfilms/dapper uptodate 6.0-1) unless line 93 in
/usr/share/gcfilms/lib/GCExport/GCExportTarGz.pm
is commented out (on my machine, the line reads :
#$movie->{image} = $self->restorePicture;
after adding the comment mark).
- This stops the export operation from freezing, but the resulting file cannot
be imported into a win32 version of the program (tried with v.6.2, will double
check with matching version 6.0 if I can find a windoze archive).
+ Commenting out this line stops the export operation from freezing, but the
resulting file cannot be imported into a win32 version of the program (tried
with v.6.2, will double check with matching version 6.0 if I can find a windoze
archive ; importing back into same prog on same machine on Linux works fine).
Regards,
Dr. Moe
--
Unreferenced function freezes tar.gz export
https://launchpad.net/bugs/74825
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
