Re: missing dependencies
On 8/26/2018 7:52 PM, oskar wrote: > Hello, I just want to report a bug, I have installed slic3r on linux > Mint 19 through apt command, from ubuntu Bionic LTS repository. It did > not install all the recommended dependencies, i had to install them > manually (e.g. could not run slic3r with gui). That's not a bug; Recommends: means it is not required for the package to operate and so do not have to be installed. Ubunutu configures apt to install them by default, but that's a policy choice that Mint very well may not have decided to follow. signature.asc Description: OpenPGP digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: SRU vs Backport
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/13/2013 11:02 AM, Daniel Lintott wrote: > Hi MOTU, > > The following bug [0] was recently fixed though Debian in version > 0.8.6-2 of the GNS3 package. This has has successfully been > imported into Trusty, but the bug was first reported in 13.04 > (Raring), so is still present in 13.10 (Saucy). > > When I took took over maintenance of the GNS3 package, I had to > bump the dependency on dynamips to version 0.8.4. > > So I believe both packages would need to be updated to prevent the > dependency breaking. > > The problem arises that whilst GNS3 0.86-2 fixes a bug making it a > candiate for SRU, dynamips does not and simply imports the new It isn't a candidate for SRU since 13.10 shipped with 0.8.3, so 0.8.6 is a new upstream release. > upstream version, which would be a backport. > > What would be the preferred method to handle this situtation? If you could cherry pick just the change that fixes the bug and apply it to 0.8.3 and it didn't require the new library, then it could be an SRU, otherwise it would have to be a backport. Given that 14.04 is now only a month away, and will shortly be followed by 13.10 going EOL, it begs the question why bother with either? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTJ4kPAAoJEI5FoCIzSKrwz1UH/jaHwNnRAz9+Y5hKlVc0FX+R pZVhjqE8vo+s19GdGxHXDw6Vi0wfryUznweia2O0XpDduV105t3A7BGET2lAEUc5 akYXsJnengkCe7oywQ3n5y3xCF8k+AWGtNAs3lGUl/lQgwCKe9OGgZ7H6yyMKZ9n nCploEti0XRD4lrBJX+BSCaACYykiVdvNuB1rwGhnbcKXqZXZcpb/WqQjwBMGgVF YfHeYpFHlQo/GQxVB7KKRvwD8xjrVyVnL8ycgy3B7mXY1i6lIBHothIplUcz/kkZ NfKQa28s2aDndSFT8IPmigdcnHBV1KM29FY+CpN3zGXkgqsMlJY+lQdaY4kdPZw= =knU9 -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Why p7zip isn't updated about 4 Ubuntu major releases?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/01/2011 02:54 PM, Ettore Atalan wrote: > Hi, > > The "p7zip" package in natty/maverick/lucid/karmic [1] repository > contains p7zip version 9.04, which dates from 2009 [2] and looks like it > was taken from Debian unstable. The latest version is p7zip 9.20.1 from > 2011. > > Why p7zip isn't updated about 4 Ubuntu major releases? Because it wasn't updated in Debian. It looks like it was updated in experimental last month. Should hit unstable soon hopefully and be syned to Ubuntu during Oneiric. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3J63cACgkQJ4UciIs+XuIbGwCfZU03nvJfhwBGABylXpbOoIrR 5GUAoIp7xzyEaqRUP5/ucy3fr8KFLKrA =cf0R -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Greetings from Freeciv upstream
On 2/14/2011 9:46 AM, Marko Lindqvist wrote: > This new need for gtk3 client means we have to cut effort in something > else. Unless some new face(s) take active role in Qt-client development, > it will be almost halted. Speaking of clients, I wonder if you might weigh in on that subject in this bug I came across today: https://bugs.launchpad.net/ubuntu/+source/freeciv/+bug/202327 It notes that while there are 3 different clients, the descriptions do not really indicate what the difference is. Something should probably be done to clear that up, so maybe you can suggest some wording? Personally I always use the gtk client, but the description should probably include reasons why you might want to use the others instead. In particular, I'm not sure why you would want to use the SDL client. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Sponsorship request for defrag package
The defrag package originally written over 20 years ago mostly by Theodore Tso, Remmy Card, and Linus Torvalds. It went unmaintained for many years and finally was removed from Debian and Ubuntu 2 years ago. I have resurrected the package and am looking for sponsorship to review it and upload it to the universe repository. I created a project page for it on launchpad.net/e2defrag, which includes a bzr repository. I have updated the code to work with ext4 and made several optimizations. A build can be found for testing in my ppa:psusi/ppa. If someone could review the packaging, I'm sure there are things that should be fixed before uploading it to universe. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Converting the old defrag package to native ( review wanted )
I am trying to rescue the old defrag package that was dropped from the repos a while back due to it being abandoned by its upstream maintainers for years. I have created a bzr branch in lp and have tried to convert it into a native Ubuntu package. Could someone review it please and let me know if I did it correctly? Basically what I did was change the version from 0.73pjm1-8ubuntu2 to 0.74. I also merged each of the dpatch patches into their own bzr commits, then removed the patches and the dpatch system from the build process. Is this correct? The branch can be found on lp at: https://code.launchpad.net/~e2defrag/e2defrag/trunk -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: [rfc] boot-time async readahead...
Scott James Remnant wrote: > Sync is *always* better than no readahead at all. > Parallel is *sometimes* better than no readahead, but in various cases > is actually _worse_. > When Parallel is not worse then no readahead, it is better than sync. > > Since the out-of-the-box has to work for everyone, I chose sync. You may be able to get the best of both worlds. Take the readahead list sorted in order of access. Split the list in half. Sort each individual half by block address. Now do a sync readahead of the first list, and async readahead of the second. Set the io priority of the async readahead to a very high value so that should a startup process request a block that has not yet been read ahead, it will not cause a seek, but instead will just wait for readahead to get there in the right order. Also it sure would be nice to defrag the disk so the files are placed in the order they are accessed. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Patch systems in packages
Emmet Hikory wrote: > I am not advocating the storage of patches in the diff.gz, as I > believe that this makes the package awkward to extend when Ubuntu > seeks to add patches: I'd much prefer that each package have a patch > system. I understand that for work in Debian, using a VCS in place of > a patch system can be easier, but it's certainly not easier for > derivatives, especially for patches that do not belong back in Debian. Agreed. > Rather I am arguing against the introduction of a patch system in > Ubuntu for packages that maintain patches in the diff.gz in Debian > except in the rare case where there is such a vast separation in the > Ubuntu and Debian packaging that it becomes easier to apply Debian > patches by reviewing debdiffs between Debian packages rather than > either using the merge tools or rebasing packaging off the Debian > package each time. > > 1: https://lists.ubuntu.com/archives/intrepid-changes/2008-August/005755.html Sounds like we are in agreement in principal; we just disagree exactly where to draw the line. I'd rather get the pain of adding the patch system over sooner so it doesn't grow worse when I have to do it later. Also if debian is using a VCS then it becomes fairly easy to pull the patches from their VCS and merge them into our VCS or patch system, rather than trying to do a hand merge between the two .diff.gz files. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Patch systems in packages
Scott Kitterman wrote: >> Has debian policy changed in the last few years? > > No, but in Debian, policy follows practice. It doesn't leadt it. The > current flirtation with various DVCS seems to have pushed things in this > direction. Unfortunately this leaves all the structure in the DVCS and not > in the package. Yes, and that's the down side of using a DVCS, but at least the information that is missing from the source package is available _somewhere_ ( in the vcs ). If you just modify the original sources directly without a patch system, then you don't have the information (detailed description of each patch, delineation between each patch ) _anywhere_. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Patch systems in packages
Stephan Hermann wrote: > Again, we don't have to discuss the pros and cons of a patch system. We > have them, and we should use them, but on Ubuntu, when the original > maintainer in debian doesn't use a patch system, we shouldn't introduce > one but using the way the debian maintainer is using. If the debian maintainer has a patch system, then sure, you should use that one instead of adding another. If they don't have one though, we have just as much reason to add one in ubuntu as they do in debian. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Patch systems in packages
Stefan Potyra wrote:
> This is quite a good example, why I personally believe that patch systems for
> universe packages shouldn't be added: Assuming that a patch is still relevant
> and functional because it applies cleanly (or the other way round) is quite a
> flawed approach. You should in all cases verify that this is the case, no
> matter if you use a patch system or don't use one.
My point was that figuring that out is MUCH easier when you don't have 3
different patches all smashed into one, with little to no documentation.
Since we seem to agree that use of a patch system is good, I don't
see how you can conclude that using them in universe packages isn't.
> And exactly this logic ("it applies, so it must be correct") is something
> I've
> seen quite a bit when sponsoring packages, in particular merges: People are
> easily tempted to take the output of MoM/DaD as granted if it seems to work,
> w.o. looking at the ubuntu delta in particular or if each change is still
> needed.
I don't see how this is related to the use of a patch system or not.
> Finally, for universe packages the number of patches is usually quite low, so
> I don't see any problem with applying these inline when there isn't a patch
> system present yet.
If it is a single trivial change, that's fine, but once you have more
than one change, applying them inline gets them hopelessly tangled and
makes sorting out what's what much, much harder.
> What's more important is that changes are properly documented, especially the
> why and how a change was done, and that the changes are forwarded upstream.
> However this is an educational problem, which can imho not be solved just by
> using a patch system.
Use of a patch system allows for this since each change is split in its
own patch, and accompanied with documentation.
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Patch systems in packages
Emmet Hikory wrote: > Actually, the monolithic patch that the Debian Maintainer > frequently doesn't want to see is the debdiff from the ubuntu version, > rather than the raw diff.gz. This is presented by default on the PTS, > and can be useful for some packages, but is often not the best way to > see the results. When there is a simple patch, this debdiff can be > clean, regardless of how the patch is applied. When a patch system is > introduced in Ubuntu to a package that does not have a patch system in > Debian, this debdiff will be less clean, and if the patch system > chosen in Ubuntu is not one preferred by the Debian Maintainer, it > means that the fix requires more than just applying the patch after > filtering out the changelog and maintainer change. More generally, if > the Debian Maintainer uses e.g. quilt, this debdiff ought contain a > quilt-formatted patch: the same ought be true for packages using > simple-patchsys, dpatch, a custom-hacked patch system in debian/rules, > or changes raw in diff.gz. That's why you don't send the debian maintainer the debdiff. You send him the individual patch(es), and let him worry about applying them using whatever patch system, or lack of one, that he chooses. Even if he looks at the debdiff, picking out the individual patches is trivial, at least with dpatch. > How does this become differently clear? If the package in > question uses a patch system in Debian, then there is no debate. If > the package in question does not use a patch system in Debian, the > introduction of a patch system and attendant repackaging may appear to > be a voluminous change to the Debian changes (and is), while the > actual patch of interest was an upstream patch exclusively. I submit > that changing the choice of patch system (or none) is significantly > more frustrating to a Debian Maintainer than applying a patch > following the practice used in Debian. I agree with that. If you try to send the debdiff to the debian maintainer it will be frustrating to him. This is easily solved though by just sending him the patch instead. While it is good to be concerned about debian, maintaining the package in ubuntu is more important, and doing so requires a reasonable patch management system. It seems you are trying to make it trivially easy for a debian dev to import a trivial patch from an ubuntu derivative at the expense of making maintaining the ubuntu package much more difficult. > All of the above notwithstanding, I do agree with Steve that where > there are a significant number of Ubuntu changes, especially where > many of them are not expected to go to Debian, it makes sense to track > the patches in Ubuntu, rather than in the Debian BTS. In these cases, > I think it's appropriate to use a patch system if present, branch a > VCS if Debian code is in a VCS and no patch system is present, > introduce a patch system matching the Debian Maintainer's apparent > preference, or introduce a new patch system in Ubuntu, with preference > in that order. On the other hand, I don't think this overhead is > necessarily worthwhile for something small for a package well > maintained in Debian and for which the patch is useful to Debian. In I generally agree, but what seems a single, simple, small change at the time can easily grow more complicated quickly, so it's a good idea to start using a VCS or patch system with the first change, so you don't have to add it later. > these trivial (but very common) cases, the work for a later Ubuntu > merger to discover that the patch system and attendant patches are no > longer relevant is of similar volume to that of an Ubuntu merger > presented with a couple of patches in diff.gz that must be detangled, > and yet the volume of work to put the pacakge in this state is > considerably higher, so the total volume of work for Ubuntu is larger. I disagree vehemently with this point. The work of detangling multiple patches is so large as to be nearly insurmountable unless each patch is a simple one or two liner. Even if you can figure out what changes correspond to what entry in the changelog, usually the changelog description is far more terse than the one accompanying the patch, which you can not recover if it is just merged into the main .diff.gz. While adding a patch system makes the diff larger, it is generally pretty standard stuff, and so easy to filter out. Even scanning the debdiff by eye, it is very simple to pick out the one or two dpatch files that were added from the boilerplate code, and easily review or separate them. If it is a single and very simple patch that requires little explanation, then it isn't so bad to leave it in the .diff.gz, but as soon as you start carrying multiple patches, or patches which are somewhat complex, you really need to use a VCS or patch system to track each change independently and with good descriptions, or you will quickly loose all control of what pa
Re: Patch systems in packages
Emmet Hikory wrote: >> upload), or it can be an in-package patch system; but it is important to >> have /some/ mechanism for labelling your changes so that you aren't left >> with a single massive diff. > > Why? Why should the Debian Maintainer care about the monolithic > patch as applied in Ubuntu (perhaps also cluttered by several > changelog entries about merges that have happened, or rebuilds). Is > it not best practice to send those patches relevant to Debian to bugs > in the BTS, as separated patches? If this is done, to whom is it > useful to track the patches independently, so long as the patches > remain easy to maintain? You just answered your own question. The Debian Maintainer does not want to see a monolithic patch that includes all of the debianization and changes already there in the debian package. He just wants the one new patch you have added, broken out on its own. Tracking the patches independently is useful to everyone who wants the patches to remain easy to maintain. > I generally argue against the introduction of patch systems, as 1) > I am very much opposed to working with a package that has both changes > in diff.gz (from the original packaging), and 2) a patch system. Yes, there should be no changes in the .diff.gz outside of debian/ ( at least when not using a proper VCS ). > These are painfully ugly, and the monolithic diff frequently becomes > completely unreadable (was this a change to a previous Debian change, > to an upstream change, or to a combination?); and 2) I have heard a That's exactly WHY all changes to the original sources should be done via a patch system; so that it is immediately clear when you are changing the debian changes, or applying a patch to the upstream source. > number of Debian maintainers complain about the "useless" introduction > of a patch system when they maintain the package in a VCS with no > patch system. That said, in the case where there are no previous > diff.gz changes external to debian/, I think it is best practice to > review other packages with the same Debian Maintainer to attempt to > determine the preferred patch system of that maintainer (which may be > monolithic diff.gz), and follow that practice. In the rare case where > there are no patches external to debian/ in any of the packages > maintained by that Maintainer, the introduction of a patch system > seems the least bad way to do things, but this is very much an > exceptional case, and for most packages we would do well to instead > follow the existing practice (even where that is a monolithic > diff.gz). VCS throws a big wrench it the works since it totally clashes with the debian package system, which essentially is another form of VCS. If you are using a VCS, then you have to stick to the external VCS and not bother with directly messing with the debian source package. If you aren't using an external VCS, then you handle change control the debian way and use a patch system. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Patch systems in packages
Stephan Hermann wrote: > I think the problem is, that many people don't know, that debian > source packages do have this diff.gz handling, which is also a "patch" > system. Not the best one, but actually it works. And that's exactly the problem. You don't WANT patches munged up into the single massive .diff.gz because then it becomes extremely hard to do things like fix them so they apply cleanly to a new upstream, or break them out and send them to upstream to apply, or easily remove them once upstream has accepted the patch. > A debianized source tree (with debian/ already applied) can be changed > outside debian/ dir and those changes are going in the resulting > diff.gz. No orig.tar.gz source is being touched. And then when you drop in a new .orig.tar.gz from upstream, you have dozens of errors applying the .diff.gz and since it's all one monolithic patch, it's much, much harder to sort out. With a patch system the old .diff.gz will always apply cleanly to a new upstream tarball since it only adds files to debian/, and then when you build it tries to apply each patch individually and if one fails, disabling it or fixing it is much simpler when you are dealing with an individual smaller patch with its own documentation. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Patch systems in packages
Reinhard Tartler wrote: > I really wonder who brought up the (wrong) claim that *not* using a > patch system was deprecated in the first place. It isn't deprecated; it's something you were never supposed to do. >> In the first case, if you are going to start patching you need to use >> one of the patch systems to do it. > > I disagree with the necessity with doing that. And I strongly disagree > telling Debian Developers to use one. The last time I read the debian packaging guide it was debian developers telling ME to use a patch system, and not to modify the original upstream files directly. This was reinforced by lintian complaining loudly if you do so, and I had packages rejected for doing this. It certainly makes managing the changes across several versions ( both local and upstream ) much easier. When you add more than one trivial patch without a patch system it becomes impossible to manage them since they get merged into one large patch, so you have a hard time pulling just one back out, or sending it upstream, or fixing it to apply cleanly to a new upstream version. Has debian policy changed in the last few years? -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Patch systems in packages
Reinhard Tartler wrote: >> I think our job as downstreams is to provide patches to Debian, not >> tell them how to maintain their packages. > > Excatly. > > Please note that adding a patch system to a package that previously > didn't adds additional noise in the debdiff. So please, don't. > > (well, perhaps debdiff could be taught somehow to handle patch systems > more sensibly, which would alleviate the issue here) I have to disagree. If you are applying patches you must use a patch system to comply with the debian packaging guidelines ( otherwise you modify the .orig.tar.gz and you shouldn't be doing that ). If you run into a package that does not already have some kind of patch system there are 2 possibilities: 1) The package has never needed to be patched before 2) The package has been patched by directly modifying the original upstream files, which is a big no-no In the second case, the package should be fixed and the upstream debian maintainer notified and asked to repair their broken package as well. In the first case, if you are going to start patching you need to use one of the patch systems to do it. Ideally you would want to coordinate with the debian package maintainer to use whichever patch system he prefers so he will accept the diff adding the patch and the patch system. Practically speaking though, it can take weeks, months, or sometimes years to get a debian developer to pay attention to your patch, so really you just want to go ahead and diverge by adding a patch system, try to get it added to debian, and if the debian maintainer ever manages to add the patch, even if he uses a different patch system, you can just drop the ubuntu changes when merging from debian. Sure, you will have to manually merge debian updates until they accept the patch, but using the patch system in the first place makes this as simple as grabbing the debian package, inserting the patch system again, and copying over the patch file from the last ubuntu package. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: pbuilder twice in a row option
Stefan Potyra wrote: >> If you verify that the clean rule restores the build directory to the >> exact state it was in before building, then the package will build >> cleanly a second time. > > not quite, at leat from a practical POV: > If I run make -f debian/clean, I want the package to be in a state to build > again when runing make -f debian/rules binary. And I don't want the .diff.gz > list any remains of failed attempts to modfify the package. > > from that practial POV I'm not really interested in if a package decides to > remove files on clean that can/will be recreated during build, e.g. > Makefile(s) create from Makefile.am(s). If the clean rule removes such files, then they should not be found in the package to begin with. IOW, the clean rule should be run before building the source package, so a clean following a build should return the working directory to the exact same state. If it doesn't, that may not prevent the package from building a second time ( then again, it might, or might cause it to behave differently when built ), but is still undesirable. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: pbuilder twice in a row option
Scott Kitterman wrote: > I asked for the feature to make it easier to see if a package supports one of > Debian Lenny's release goals: > > http://release.debian.org/lenny/goals.txt > > # double compilation support > Advocate: Martin Zobel-Helas and Luk Claes > Description: All packages should be able to be built twice in a >row. > Bug-User: [EMAIL PROTECTED] > Bug-Tag: qa-doublebuild > Bug-Url: > http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]&tag=qa-doublebuild > State: confirmed It seems to me that this requirement is an error as it requests a specific solution to the problem rather than requesting a solution to the real problem. It appears that the real goal is to have the ability to automatically check that a package properly cleans itself so that it does not cause various problems, just one if which is failure to build twice. This request seems to be trying to treat the symptom instead of the disease. If you verify that the clean rule restores the build directory to the exact state it was in before building, then the package will build cleanly a second time. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: pbuilder twice in a row option
Nicolas Valcarcel wrote: > Hi! > I've just write a --build-twice-in-a-row feature for pbuilder that Rather than try to build twice, shouldn't you just make a copy, build, then run the clean rule and diff with the copy? Even if the package manages to build a second time after cleaning, that doesn't necessarily mean the clean rule is not broken. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Proposing changes to multimedia stack
Reinhard Tartler wrote: > On what basis do you come to this conclusion? Can you provide some > evidence for this? Patent law does not bar you from disclosing or discussing the patented process -- only from practicing it. In other words, it's illegal to run the code, not to read or copy it. Patent law has nothing to do with copying intellectual property; that's copyright law. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Proposing changes to multimedia stack
Stefan Potyra wrote: > Hm... that wouldn't make too much sense to me, allow a patent encumbered > source package but not patent encumbered binary packages *shrug*. Makes sense to me... distributing the binary requires a license from the patent holder... distributing the source code does not. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: I very really need your help
Jumpod Plekhongthu wrote: > > I need to create installer DVD for Ubuntu with my system that confiuare > everything and install all package already, > Could you tell me how to I do it,please. > I want DVD is support both DVD internal and DVD external same as "Ubuntu > CD installer" > > Best Regards,and really thanks for advance > Jumpod Plekhongthu > TDC Celestica Thailand > EXT 2865 Please do not repeatedly post things that are completely off topic for this list. This mailing list is for package maintainers to discuss issues related to packaging; specifically packages in the Universe repository. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: how to get a new version in repositories ?
Ouattara Oumar Aziz (alias wattazoum) wrote: > Hi, > > Thank you to you two for your answer . I'll try to make it on debian and > Ubuntu at the same time . Probably a good idea I'm still waiting for several bug fixes I made to various packages 3-12 months ago ( sitting in the debian BTS ) to be applied to debian. Good thing I uploaded them to Ubuntu at the same time. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Bitchx in Ubuntu Edgy
Gabriel Puliatti wrote: > According to the Debian Policy Manual, Depends is only to be used when: > > # The Depends field should be used if the depended-on package is > required for the depending package to provide a significant amount of > functionality. > > # The Depends field should also be used if the postinst, prerm or > postrm scripts require the package to be present in order to run. > Note, however, that the postrm cannot rely on any non-essential > packages to be present during the purge phase. > > Which the plugin does not fulfill. Therefore, it would be either > Recommends or Suggests, depending on the usefulness and popularity of > the plugin. > I agree, this should not be listed in the depends field. I sometimes get suggests and recommends backwards, but iirc, it is recommends that means "this package will be needed for a typical installation to function as expected". If this plugin is one that is going to be used in a typical installation then the mysql package should be listed as a recommends, if it is more of an optional thing that not many people use, then it should be suggests. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
