Re: [ubuntu-marketing] Making Canonical's/Ubuntu's contributions more visible

[John McCabe-Dansted]

On Thu, Jun 5, 2008 at 7:07 AM, Bryce Harrington <[EMAIL PROTECTED]> wrote:
> 3.  $ sudo apt-get build
>
>Run from within the source tree, this wrappers all the work of
>generating a patch from the current source tree's changes and adding
>it to the package's patch management system (or adding a patch
>management system if one doesn't exist), running debuild, set up a
>pbuilder environment if needed, run pbuilder to produce the
>(unsigned) debs, and place them in the parent directory.

I think debuild already makes a diff.gz. (It would also be nice if,
when doing the share, it would have some way of filtering out the
weird temp files that can appear in a source tree.)

>Would be nice to not have to run it as root, but not sure that
>there's an easy way of running pbuilder as non-root.

There is pbuilder-uml, but that doesn't count as "easy" ;)

Using some from of filesystem virtualisation like Plash may also work,
and it would be nice to be able test the package in a sandbox. A
rather lightweight sandbox would be to let the application run with
Copy-on-write access to the /. This may not suitable for all packages,
but there could be a list of ways that a package could be sandboxed.

> 4.  $ apt-get share [bug id | package-name]
>
>Like you mention, presents user with a list of their outstanding
>patches applicable for the given bug or package (or all in the
>system), prompts for annotation, allows gpg-signing, and uploads to
>the appropriate place.  Maybe a PPA, or maybe sending directly to a
>Launchpad bug ID, with request to add to ubuntu and/or debian.
>
> Of course, the above paints over a huge amount of implementational
> complexity.  Perhaps this could only be achieved for certain well-formed
> packages.

Perhaps when one comes across a non-well-formed package one could fix
it and do an apt-get share :)

-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: [ubuntu-marketing] Making Canonical's/Ubuntu's contributions more visible

[Bryce Harrington]

On Wed, Jun 04, 2008 at 11:11:05PM +0800, John McCabe-Dansted wrote:
> On Tue, May 27, 2008 at 6:20 PM, Bryce Harrington <[EMAIL PROTECTED]> wrote:
> >> It could perhaps make things even easier for developers, but thats
> >> another kettle of fish.
> >
> > I'd be interested in hearing your further thoughts on this.  (I've had
> > my own thoughts on this, but would love to see other's ideas.)
> 
> Well the development aspects of Ubuntu aren't as polished as the
> end-user facing applications. Unlike firefox and OO, pbuilder and
> make-kpkg don't really "just work".
> 
> In principle, developing could be as simple as doing "dev edit
> " finding whatever you wanted to change, perhaps
> changing a constant like MAX_COL from 80 to 160 in your favourite
> editor, doing a "dev test-sandbox", and perhaps a "dev install".
> Perhaps then there could be
> run a simple "dev share" command which would the developer to, at
> their leisure, annotate each of their patches and upload them
> somewhere others could re-use and comment on them.

I think you're onto some good ideas here.

This probably sounds odd, but the thing that "sold" me on Ubuntu/Debian
over gentoo and emerge was of all things 'apt-get source'.  I use that a
gazillion times a month, and I love how easy it makes it to get in and
poke at stuff.

You're definitely right that the steps involved in creating a package
once you've got the source is not as straightforward as it could be for
a newb (I've got it in finger muscle memory now, but the first few weeks
were tough).  It would be awesome if there was a simplified workflow
something like: 

1.  $ apt-get source foo

2.  $ cd foo; #hack hack

Allow the user to edit the code tree directly, no worries about
patch systems, etc.

3.  $ sudo apt-get build

Run from within the source tree, this wrappers all the work of
generating a patch from the current source tree's changes and adding
it to the package's patch management system (or adding a patch
management system if one doesn't exist), running debuild, set up a
pbuilder environment if needed, run pbuilder to produce the
(unsigned) debs, and place them in the parent directory.

Would be nice to not have to run it as root, but not sure that
there's an easy way of running pbuilder as non-root.

4.  $ apt-get share [bug id | package-name]

Like you mention, presents user with a list of their outstanding
patches applicable for the given bug or package (or all in the
system), prompts for annotation, allows gpg-signing, and uploads to
the appropriate place.  Maybe a PPA, or maybe sending directly to a
Launchpad bug ID, with request to add to ubuntu and/or debian.

Of course, the above paints over a huge amount of implementational
complexity.  Perhaps this could only be achieved for certain well-formed
packages. 

Bryce

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: [ubuntu-marketing] Making Canonical's/Ubuntu's contributions more visible

[Markus Hitter]

Am 04.06.2008 um 17:11 schrieb John McCabe-Dansted:
> In principle, developing could be as simple as doing "dev edit
> " finding whatever you wanted to change, perhaps
> changing a constant like MAX_COL from 80 to 160 in your favourite
> editor, doing a "dev test-sandbox", and perhaps a "dev install".  Then
> when the next apt-get update is run it could be smart enough to use
> apt-get source and merge the changes into the new version, unless
> conflicts arise.
>   Often I find that after finally fixing a problem, I've run out of
> time and have to move onto something else. Perhaps then there could be
> run a simple "dev share" command which would the developer to, at
> their leisure, annotate each of their patches and upload them
> somewhere others could re-use and comment on them.  Presumably apport
> should also make note of what patches are in use, and bug reports with
> patches could have a "test this patch in a sandbox" option and ...

Now, _that_ would be a great thing. Instead of trying to find out how  
each package's build system is intended to work, one would go ahead,  
dive into the source and fix actual problems. Wether and how the  
package's development group picks up such patches is another  
question, but having a patch and perhaps a few lines of comments  
should be a real booster for upstream's code quality.


MarKus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/





-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: [ubuntu-marketing] Making Canonical's/Ubuntu's contributions more visible

[John McCabe-Dansted]

On Tue, May 27, 2008 at 6:20 PM, Bryce Harrington <[EMAIL PROTECTED]> wrote:
> On Tue, May 27, 2008 at 06:11:10PM +0800, John McCabe-Dansted wrote:
>> On Tue, May 27, 2008 at 2:18 PM, Markus Hitter <[EMAIL PROTECTED]> wrote:
>> > - Even if it's distribution specific it's still a commitment to the
>> > whole as long as it's open source. Other developers can look there to
>> > get an idea how some tasks were done. Always better than starting
>> > from scratch entirely.
>>
>> To my mind the biggest contribution downstream projects make is saving
>> developers time. My experience suggests that it if you are a developer
>> and you want to spend less time fighting your distro and more time
>> doing actual productive coding, then Ubuntu is one of the better
>> choices.
>
> Interesting...  Could you explain this in more detail?

In a pure waterfall model downstream projects don't give *anything*
back to upstream projects... except a finished project.

There isn't a clear dividing line between users and developers.  The
time I spend trying to get printing to work is time I don't spend
coding. Just because I know how to do a "simple"
 configure ; wget ; wget ; configure ; make ; vim ; make ; make install
doesn't make it a productive use of a weekend. For this reason I like
using a "Just works" distro.

As others have mentioned previously the Ubuntu is also fairly friendly
to new developers.

>> It could perhaps make things even easier for developers, but thats
>> another kettle of fish.
>
> I'd be interested in hearing your further thoughts on this.  (I've had
> my own thoughts on this, but would love to see other's ideas.)

Well the development aspects of Ubuntu aren't as polished as the
end-user facing applications. Unlike firefox and OO, pbuilder and
make-kpkg don't really "just work". Debhelper seems less
"user-developer friendly" than emerge. A developer has to learn a
programming language or two more or less by definition, but in
practice has to also learn autoconf, automake, make, am_edit,
pbuilder, make-kpkg, svn/cvs just to be able scratch their own itch.

In principle, developing could be as simple as doing "dev edit
" finding whatever you wanted to change, perhaps
changing a constant like MAX_COL from 80 to 160 in your favourite
editor, doing a "dev test-sandbox", and perhaps a "dev install".  Then
when the next apt-get update is run it could be smart enough to use
apt-get source and merge the changes into the new version, unless
conflicts arise.
  Often I find that after finally fixing a problem, I've run out of
time and have to move onto something else. Perhaps then there could be
run a simple "dev share" command which would the developer to, at
their leisure, annotate each of their patches and upload them
somewhere others could re-use and comment on them.  Presumably apport
should also make note of what patches are in use, and bug reports with
patches could have a "test this patch in a sandbox" option and ...

I am not necessarily suggesting that it is wise use of resources at
this time to focus on making development tasks more "user friendly",
just that it is conceptually possible and potentially useful.

-- 
John C. McCabe-Dansted
PhD Student
University of Western Australia

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Problem with sm.archive.ubuntu.com

[Sim]

>
> It may take a little while for the DNS update to propagate, but
> sm.archive.ubuntu.com now points to it.archive.ubuntu.com.
>

Dear Cheers,
thanks for your attention.

I have seen new record.

Very very thanks.


#dig sm.archive.ubuntu.com

; <<>> DiG 9.4.2 <<>> sm.archive.ubuntu.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55887
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;sm.archive.ubuntu.com. IN  A

;; ANSWER SECTION:
sm.archive.ubuntu.com.  600 IN  CNAME   it.archive.ubuntu.com.
it.archive.ubuntu.com.  600 IN  CNAME   ubuntu.mirror.garr.it.
ubuntu.mirror.garr.it.  600 IN  A   193.206.139.34
ubuntu.mirror.garr.it.  600 IN  A   193.206.140.37

;; AUTHORITY SECTION:
mirror.garr.it. 17024   IN  NS  server2.garr.net.
mirror.garr.it. 17024   IN  NS  icilhp.cilea.it.

Best regards

---
Sim

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Problem with sm.archive.ubuntu.com

[Chris Jones]

Hi

(fwiw, [EMAIL PROTECTED] is probably a better way to talk to the mirror 
admins, or #ubuntu-mirrors on irc.freenode.net)

Sim wrote:
> we have seen that "sm.archive.ubuntu.com" (San Marino), use GB network

correct, any country which doesn't have a mirror who have agreed to be 
the official country mirror, defaults to archive.ubuntu.com in London.

> Please update dns for sm. with it.archive.ubuntu.com. (for example
> Garr Network) otherwise network connection is really slow

Normally we would want to discuss a change in official country mirror 
with the mirror admins for that site, however, given the location and 
size of San Marino, it doesn't seem like it would put much additional 
stress on the Italian mirror. Thanks for bringing this to our attention.

It may take a little while for the DNS update to propagate, but 
sm.archive.ubuntu.com now points to it.archive.ubuntu.com.

Cheers,
-- 
Chris Jones
   [EMAIL PROTECTED]
www.canonical.com

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Bugs reports about -proposed packages

[(``-_-´´) -- Fernando]

Olá Martin e a todos.

On Tuesday 03 June 2008 11:05:37 Martin Pitt wrote:
> Do we need to make this page more obvious? Anything that I can change on that 
> page to make it more useful for testers?
> 
> Thanks,
> Martin

Maybe place that link, or some short version of it, on Update-Manager, when 
-proposed is enable

-- 
BUGabundo  :o)
(``-_-´´)   http://Ubuntu.BUGabundo.net
Linux user #443786GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net
ps. My emails tend to sound authority and aggressive. I'm sorry in advance. 
I'll try to be more assertive as time goes by...


signature.asc
Description: This is a digitally signed message part.
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Weird downstream Power Manager changes?

[Matthew Paul Thomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dylan McCall wrote on 03/06/08 16:06:
> 
> On Tue, 2008-06-03 at 16:33 +0200, Oliver Grawert wrote:
>...
>> Am Dienstag, den 03.06.2008, 07:21 -0700 schrieb Dylan McCall:
>>> 
>>> Power Management Preferences has been needlessly crippled. The sliders
>>> to control when the computer sleeps and when the display sleeps all have
>>> a lower limit of "21 minutes".
>...
> Aha! Sorry about the double post. Just realized that the minimum is idle
> time + 1 minute, which probably makes sense somewhere. (Except for the 1
> minute part?!). Still, the fact that this basic setting of timers needed
> research to figure out suggests a need for some reorganizing. Firstly,
> idle time should be set in gnome-power-preferences, not just
> gnome-screensaver-preferences, if it has such a widespread impact.
> Furthermore, I think it is problematic that the idle time cannot be set
> differently for when on battery as opposed to when on AC power, again
> because of its tie to screensaver time. Perhaps this would make more
> sense if idle did not automatically trigger the screensaver, instead
> with another timer to handle that.
> 
> Come to think of it, I am also a little confused by what "idle" means
> here. There is "dim display when idle", which seems to have an opinion
> of its own for when idle is, dimming the screen after what seems a few
> seconds of inactivity. It does not wait for the idle time that
> everything else seems to be tethered to.
> 
> This is all assuming "idle time + 1" actually makes sense
> infrastructure-wise. I am assuming here that we somehow need
> gnome-screensaver to trigger these actions. If not, what of use does
> "idle" do, anyway, other than control the controls?
>...

So if you have the Power Management Preferences open, and you want to
set your computer to go to sleep sooner than the screensaver is
currently set to begin, you need to (1) open the Screensaver
Preferences, (2) reduce the "Regard the computer as idle after:" value
to something less than the time you want the computer to go to sleep,
(3) switch back to the Power Management Preferences, and (4) change the
"Put the computer to sleep when inactive for". That's rather silly.

The "Regard the computer as idle after:" slider is an example of a
needless abstraction. I don't need help from a slider to regard my
computer as idle. "You're a lazy, slovenly computer who has never done
anyone any good!" See? Worked perfectly.

Anyway, this is reported upstream:


Cheers
- --
Matthew Paul Thomas
http://mpt.net.nz/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIRmJt6PUxNfU6ecoRAoTaAKCzjhs4VwACXmAXcbnS/aMCb9XrDwCfd+Ey
4cPaIiYgjiJT7GDU0HAzQLM=
=JF/n
-END PGP SIGNATURE-

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Problem with sm.archive.ubuntu.com

[Sim]

Dear Developer,
we have seen that "sm.archive.ubuntu.com" (San Marino), use GB network
(91.189.88.0/21)

San Marino is located inside Italy and the the backbone is italian (
http://en.wikipedia.org/wiki/San_marino )

Please update dns for sm. with it.archive.ubuntu.com. (for example
Garr Network) otherwise network connection is really slow

Waiting for your support,

best regards

---
Sim

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss