bashburn-info — BashBurn mailing list

Re: [Bashburn-info] Values misaligned in config menus

[Nick W. <ni...@uk...>]

On Wed, 8 Oct 2008 21:24:29 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:

> On Wednesday, Oct 8th 2008 at 18:51 -0000, quoth Anders Lind?n:
> 
> =>I've noticed that when I use the Swedish translation, the current
> settings =>in the config and advanced menu are not aligned evenly. In
> English and =>German it all looks right but not in Swedish. Anyone
> have a clue on why =>this is?
> 
> I'm not sure why, but I see it too. I only see that the last four
> menu items are messaed up. The rest is ok.
> 
> If I try this:
> 
> #! /bin/bash
> bb_conf_menu_default=$'\205terstll'
> printf "%s\n" "$bb_conf_menu_default"
> 
> It prints out something on two lines.
> 
> So for starters, we should not be coding the line up with embedded
> control characters. We should be using the notation I describe above.
> 
> As for why it displays this way... I suspect it has something to do
> wit hwhether the terminal emulator program we're using (each one of
> different) knows how to handle the characters we try to display. IOW,
> is the character that we want to see part of the character set that
> the program knows how to display? This is just a stab because the
> likelyhood is that Anders is correctly capable of displaying whatver
> that $'\205' really is.

Now, I don't see this at all in X using mrxvt terminal.  All are lined
up perfect.  But if I go to virtual terminal Ctrl+Alt+F2 and try it,
they are mis-aligned by a space.

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] Values misaligned in config menus

[Steven W. O. <st...@sy...>]

On Wednesday, Oct 8th 2008 at 18:51 -0000, quoth Anders Lind?n:

=>I've noticed that when I use the Swedish translation, the current settings 
=>in the config and advanced menu are not aligned evenly. In English and 
=>German it all looks right but not in Swedish. Anyone have a clue on why 
=>this is?

I'm not sure why, but I see it too. I only see that the last four menu 
items are messaed up. The rest is ok.

If I try this:

#! /bin/bash
bb_conf_menu_default=$'\205terstll'
printf "%s\n" "$bb_conf_menu_default"

It prints out something on two lines.

So for starters, we should not be coding the line up with embedded control 
characters. We should be using the notation I describe above.

As for why it displays this way... I suspect it has something to do wit 
hwhether the terminal emulator program we're using (each one of different) 
knows how to handle the characters we try to display. IOW, is the 
character that we want to see part of the character set that the program 
knows how to display? This is just a stab because the likelyhood is that 
Anders is correctly capable of displaying whatver that $'\205' really is.




-- 
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net

[Bashburn-info] Values misaligned in config menus

[Anders L. <and...@gm...>]

I've noticed that when I use the Swedish translation, the current settings 
in the config and advanced menu are not aligned evenly. In English and 
German it all looks right but not in Swedish. Anyone have a clue on why 
this is?
-- 
Anders Lindén
http://bashburn.dose.se

Re: [Bashburn-info] cdrecord OPTIONS dump

[Steven W. O. <st...@sy...>]

On Wednesday, Oct 8th 2008 at 03:20 -0000, quoth Nick Warne:

=>On Tue, 7 Oct 2008 22:48:22 -0400 (EDT)
=>"Steven W. Orr" <st...@sy...> wrote:
=>
=>> 
=>> The reason is that that command writes to stderr and not to stdout.
=>> So, if you want your command to pipe its stderr to grep you have to
=>> say this:
=>> 
=>> cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive 2>&1 | \
=>> 	grep -i Driver
=>> 
=>> which sez in English: "run the command and dup(2) stderr onto stdout
=>> and close stderr. Then take the combined stderr and stdout that is
=>> now on stdout and pipe it to grep."
=>> 
=>> Make sense?
=>
=>Yes, I think we all know about that... but it wasn't something I
=>thought about.
=>
=>Anyway, it still is peculair.  The line below NOW only prints out Driver
=>Options (I guess 20 lines will be enough) but still have to dump
=>to /dev/null.
=>
=>cdrecord dev=/dev/<you_drive> driveropts=help -checkdrive 2>&1
=>> /dev/null | grep -A 20 "Driver options"
=>
=>Please test this line - if it works for all of us, I guess it could be
=>used to only print out drivers options.

That works.

-- 
steveo at syslang dot net TMMP1 http://frambors.syslang.net/
Do you have neighbors who are not frambors? Steven W. Orr

[Bashburn-info] This is a test of the new bashburn list.

[Steven W. O. <st...@sy...>]

Please ignore.

-- 
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net

Re: [Bashburn-info] cdrecord OPTIONS dump

[Nick W. <ni...@uk...>]

On Wed, 08 Oct 2008 11:37:17 +0200
Markus Kollmar <mar...@on...> wrote:
 
> Note, for those who first maybe wondered also about the "missing" 
> redirection char:
> Some mail programms format the ">" before "/dev/null" to a graphical 
> vertical line (they interpret it as reply-statements). Looking the 
> message in source form shows that Nick formated it correct.

Yes, sometimes the 'quoted text' marks bugger up a 'proper' > when in
the reply.  I dunno how to get around it.

I use claws-mail

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] cdrecord OPTIONS dump

[Nick W. <ni...@uk...>]

On Wed, 8 Oct 2008 12:25:36 +0100
Nick Warne <ni...@uk...> wrote:

> On Wed, 08 Oct 2008 11:37:17 +0200
> Markus Kollmar <mar...@on...> wrote:
> 
> > Nick Warne wrote:
> > > On Tue, 7 Oct 2008 22:48:22 -0400 (EDT)
> > > "Steven W. Orr" <st...@sy...> wrote:
> > >
> > >   
> > >> The reason is that that command writes to stderr and not to
> > >> stdout. So, if you want your command to pipe its stderr to grep
> > >> you have to say this:
> > >>
> > >> cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive 2>&1
> > >> | \ grep -i Driver
> > >>
> > >> which sez in English: "run the command and dup(2) stderr onto
> > >> stdout and close stderr. Then take the combined stderr and stdout
> > >> that is now on stdout and pipe it to grep."
> > >>
> > >> Make sense?
> > >>     
> > >
> > > Yes, I think we all know about that... but it wasn't something I
> > > thought about.
> > >
> > > Anyway, it still is peculair.  The line below NOW only prints out
> > > Driver Options (I guess 20 lines will be enough) but still have to
> > > dump to /dev/null.
> > >
> > > cdrecord dev=/dev/<you_drive> driveropts=help -checkdrive 2>&1
> > >   
> > >> /dev/null | grep -A 20 "Driver options"
> > >>     
> > >
> > > Please test this line - if it works for all of us, I guess it
> > > could be used to only print out drivers options.
> > >
> > > Nick
> > >   
> > 
> > Nick, yes this works for me.
> > 
> > Note, for those who first maybe wondered also about the "missing" 
> > redirection char:
> > Some mail programms format the ">" before "/dev/null" to a
> > graphical vertical line (they interpret it as reply-statements).
> > Looking the message in source form shows that Nick formated it
> > correct.
> > 
> > :-)
> > 
> 
> OK, I will commit this to TRUNK.  Also I have appended an extra
> message to lang/German/Swedish/English/configure.lang to
> bb_conf_ch_dropts. This adds a 'Detecting CD Writer...' (using
> bb_text_7).
> 
> The reason I done this is due to me having two drives.  One dumps the
> options to the screen immediately, and the other takes about 3 seconds
> - so I end up looking at a blank screen wondering what is happening.
> This message now tells the user that the drive is being queried.

Now we need a way to report that the drive /dev/ entered is invalid if
no option is produced.  i.e. change to /dev/cdrom999 and then look at
drive options...

Perhaps this could be done in Option 0) setting CD writer menu - get
cdrecord to -checkdrive and if no output or error etc. tell the user.

EXAMPLE:
#: cdrecord dev=/dev/cdrom99 driveropts=help
-checkdrive Cdrecord-ProDVD-ProBD-Clone 2.01.01a38 (i686-pc-linux-gnu)
Copyright (C) 1995-2008 Jörg Schilling scsidev: '/dev/cdrom99'
devname: '/dev/cdrom99'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.
cdrecord: No such file or directory. Cannot open '/dev/cdrom99'. Cannot
open or use SCSI driver. cdrecord: For possible targets try 'cdrecord
-scanbus'. cdrecord: For possible transport specifiers try 'cdrecord
dev=help'.


Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] cdrecord OPTIONS dump

[Nick W. <ni...@uk...>]

On Wed, 08 Oct 2008 11:37:17 +0200
Markus Kollmar <mar...@on...> wrote:

> Nick Warne wrote:
> > On Tue, 7 Oct 2008 22:48:22 -0400 (EDT)
> > "Steven W. Orr" <st...@sy...> wrote:
> >
> >   
> >> The reason is that that command writes to stderr and not to stdout.
> >> So, if you want your command to pipe its stderr to grep you have to
> >> say this:
> >>
> >> cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive 2>&1 | \
> >> 	grep -i Driver
> >>
> >> which sez in English: "run the command and dup(2) stderr onto
> >> stdout and close stderr. Then take the combined stderr and stdout
> >> that is now on stdout and pipe it to grep."
> >>
> >> Make sense?
> >>     
> >
> > Yes, I think we all know about that... but it wasn't something I
> > thought about.
> >
> > Anyway, it still is peculair.  The line below NOW only prints out
> > Driver Options (I guess 20 lines will be enough) but still have to
> > dump to /dev/null.
> >
> > cdrecord dev=/dev/<you_drive> driveropts=help -checkdrive 2>&1
> >   
> >> /dev/null | grep -A 20 "Driver options"
> >>     
> >
> > Please test this line - if it works for all of us, I guess it could
> > be used to only print out drivers options.
> >
> > Nick
> >   
> 
> Nick, yes this works for me.
> 
> Note, for those who first maybe wondered also about the "missing" 
> redirection char:
> Some mail programms format the ">" before "/dev/null" to a graphical 
> vertical line (they interpret it as reply-statements). Looking the 
> message in source form shows that Nick formated it correct.
> 
> :-)
> 

OK, I will commit this to TRUNK.  Also I have appended an extra message
to lang/German/Swedish/English/configure.lang to bb_conf_ch_dropts.
This adds a 'Detecting CD Writer...' (using bb_text_7).

The reason I done this is due to me having two drives.  One dumps the
options to the screen immediately, and the other takes about 3 seconds
- so I end up looking at a blank screen wondering what is happening.
This message now tells the user that the drive is being queried.


Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] cdrecord OPTIONS dump

[Markus K. <mar...@on...>]

Nick Warne wrote:
> On Tue, 7 Oct 2008 22:48:22 -0400 (EDT)
> "Steven W. Orr" <st...@sy...> wrote:
>
>   
>> The reason is that that command writes to stderr and not to stdout.
>> So, if you want your command to pipe its stderr to grep you have to
>> say this:
>>
>> cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive 2>&1 | \
>> 	grep -i Driver
>>
>> which sez in English: "run the command and dup(2) stderr onto stdout
>> and close stderr. Then take the combined stderr and stdout that is
>> now on stdout and pipe it to grep."
>>
>> Make sense?
>>     
>
> Yes, I think we all know about that... but it wasn't something I
> thought about.
>
> Anyway, it still is peculair.  The line below NOW only prints out Driver
> Options (I guess 20 lines will be enough) but still have to dump
> to /dev/null.
>
> cdrecord dev=/dev/<you_drive> driveropts=help -checkdrive 2>&1
>   
>> /dev/null | grep -A 20 "Driver options"
>>     
>
> Please test this line - if it works for all of us, I guess it could be
> used to only print out drivers options.
>
> Nick
>   

Nick, yes this works for me.

Note, for those who first maybe wondered also about the "missing" 
redirection char:
Some mail programms format the ">" before "/dev/null" to a graphical 
vertical line (they interpret it as reply-statements). Looking the 
message in source form shows that Nick formated it correct.

:-)


Markus

Re: [Bashburn-info] cdrecord OPTIONS dump

[Nick W. <ni...@uk...>]

On Tue, 7 Oct 2008 22:48:22 -0400 (EDT)
"Steven W. Orr" <st...@sy...> wrote:

> 
> The reason is that that command writes to stderr and not to stdout.
> So, if you want your command to pipe its stderr to grep you have to
> say this:
> 
> cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive 2>&1 | \
> 	grep -i Driver
> 
> which sez in English: "run the command and dup(2) stderr onto stdout
> and close stderr. Then take the combined stderr and stdout that is
> now on stdout and pipe it to grep."
> 
> Make sense?

Yes, I think we all know about that... but it wasn't something I
thought about.

Anyway, it still is peculair.  The line below NOW only prints out Driver
Options (I guess 20 lines will be enough) but still have to dump
to /dev/null.

cdrecord dev=/dev/<you_drive> driveropts=help -checkdrive 2>&1
> /dev/null | grep -A 20 "Driver options"

Please test this line - if it works for all of us, I guess it could be
used to only print out drivers options.

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] cdrecord OPTIONS dump

[Steven W. O. <st...@sy...>]

On Tuesday, Oct 7th 2008 at 12:50 -0000, quoth Nick Warne:

=>On Mon, 06 Oct 2008 22:52:23 +0200
=>Markus Kollmar <mar...@on...> wrote:
=>
=>> Yes you are right, I think also it is much work to grep the output of 
=>> the burner-option (since it seems not strongly formated and some part
=>> of output goes not to stdout I think.)
=>
=>As an aside on this, I too like Markus couldn't work out why some of
=>the dump goes to STDOUT and some doesn't seem to go anywhere yet still
=>gets printed to terminal.
=>
=>i.e. compare:
=>
=>cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive
=>
=>with:
=>
=>cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive > /dev/null
=>
=>with:
=>
=>cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive | grep -i
=>Driver
=>
=>I dunno how J?rg Schilling has done this.  In the man page quote:
=>
=>"driveropts=option list
=>              Set driver specific options. The options are specified a
=>comma separated list.  To get a  list of valid options use
=>driveropts=help together with the -checkdrive option.  If you like to
=>set driver options without running a typical cdrecord task, you need to
=>use the -setdropts  option in  addition,  otherwise  the command line
=>parser in cdrecord will complain."
=>
=>
=>Command line parser?  So he somehow does some magic?
=>
=>I have never seen this behaviour in any application ever before.
=>
=>Nick

The reason is that that command writes to stderr and not to stdout. So, if 
you want your command to pipe its stderr to grep you have to say this:

cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive 2>&1 | \
	grep -i Driver

which sez in English: "run the command and dup(2) stderr onto stdout and 
close stderr. Then take the combined stderr and stdout that is now on 
stdout and pipe it to grep."

Make sense?

-- 
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net

Re: [Bashburn-info] cdrecord OPTIONS dump

[Anders L. <and...@gm...>]

On Tuesday 07 October 2008 18:50:48 Nick Warne wrote:
> On Mon, 06 Oct 2008 22:52:23 +0200
>
> Markus Kollmar <mar...@on...> wrote:
> > Yes you are right, I think also it is much work to grep the output of
> > the burner-option (since it seems not strongly formated and some 
part
> > of output goes not to stdout I think.)
>
> As an aside on this, I too like Markus couldn't work out why some of
> the dump goes to STDOUT and some doesn't seem to go anywhere 
yet still
> gets printed to terminal.
>
> i.e. compare:
>
> cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive
>
> with:
>
> cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive > 
/dev/null
>
> with:
>
> cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive | grep 
-i
> Driver
>
> I dunno how Jörg Schilling has done this.  In the man page quote:
>
> "driveropts=option list
>               Set driver specific options. The options are specified a
> comma separated list.  To get a  list of valid options use
> driveropts=help together with the -checkdrive option.  If you like to
> set driver options without running a typical cdrecord task, you need 
to
> use the -setdropts  option in  addition,  otherwise  the command 
line
> parser in cdrecord will complain."
>
>
> Command line parser?  So he somehow does some magic?
>
> I have never seen this behaviour in any application ever before.
>
> Nick

Jörg is a strange man. I wouldn't be surprised if he uses black magic.

-- 
Anders Lindén
http://bashburn.dose.se

Re: [Bashburn-info] 3.0 Beta 1

[Nick W. <ni...@uk...>]

On Tue, 7 Oct 2008 19:00:11 +0200
Anders Lindén <and...@gm...> wrote:

> (We can all be happy about that we're not designing control software 
> for a nuclear plant. It's just a CD/DVD burner app after all :-) )

Melt down!  Burn baby, burn :-)

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] 3.0 Beta 1

[Anders L. <and...@gm...>]

On Tuesday 07 October 2008 18:54:48 you wrote:

> OK, but what I meant was that TRUCK (as it is) is tested upto NOW.  
So
> I thought that would become the beta1/2 or whatever.
>
> But anyway, we are there :-)
>
> Nick

Yes, that was the way it was supposed to work :-)
Oh well, we all learn from our mistakes (I'll try to, I promise).

From now on when trunk has been tested and deemed stable, I'll do a 
simple 'svn copy https://svn.inf.sgsp.edu.pl/svn/bashburn/trunk 
https://svn.inf.sgsp.edu.pl/svn/bashburn/releases/<version> -m 
"Release <version> is a go" and create a release package from the 
created directory. Hopefully this should work and we can avoid any 
crazyness like now.

(We can all be happy about that we're not designing control software 
for a nuclear plant. It's just a CD/DVD burner app after all :-) )

-- 
Anders Lindén
http://bashburn.dose.se

Re: [Bashburn-info] 3.0 Beta 1

[Nick W. <ni...@uk...>]

On Tue, 7 Oct 2008 18:45:38 +0200
Anders Lindén <and...@gm...> wrote:

> On Tuesday 07 October 2008 18:28:45 you wrote:
> > On Tue, 07 Oct 2008 15:44:31 +0200
> >
> > Markus Kollmar <mar...@on...> wrote:
> > > Anders Lindén wrote:
> > > > On Tuesday 07 October 2008 15:11:50 you wrote:
> > > >> Anders, we have a small problem with Beta 1!
> > > >>
> > > >> I have done yesterday some changes in the trunk (also the
> > > >
> > > > mentioned
> > > >
> > > >> swedish language updating).
> > > >> Now I saw you have not moved all files for the release 3.0 from
> > > >
> > > > 'trunk'
> > > >
> > > >> to 'release' shortly before you created the release-package.
> > > >
> > > > Ouch! Which files are we talking about? I could add the missing
> > > > files and do a quick re-release.
> > >
> > > Anders, I think that is not the best idea (it are some files like
> > > "BashBurn.sh" and lang. files - and maybe I think Nick and maybe
> > > others also did improvements since then).
> > > So in such cases we should always take the whole thing to avoid
> > > dependency-problems - if we can be shure nothing is broken - 
> and i
> > > think in this short time the trunk is relatively usable.
> > >
> > > >> I should had tell you this - so you thought that there was no 
> major
> > > >> changes in the trunk since you created the release branch.
> > > >> In my humble opinion I think it would be good if we use 
> following
> > > >> process to make a release and to avoid such things in future:
> > > >>
> > > >>
> > > >> 1. Like you did - tell others per mailing list shortly before
> > > >> release whether it is ok to create a release for the main
> > > >> developers, and tell the short time period in which the 
> creation
> > > >> is planned.
> > > >>
> > > >> 2. Then lock the trunk branch (via "svn lock") and move ALL 
> files
> > > >
> > > > from
> > > >
> > > >> trunk to release.
> > > >>
> > > >> 3. Create package from release tree.
> > > >>
> > > >> 4. Unlock trunk branch.
> > > >>
> > > >>
> > > >> Is this a way?
> > > >
> > > > Sounds like a good idea to me.
> >
> > Also what I meant was all changes go to TRUNK.  Then and if tested 
> etc.
> > export that particular fix to RELEASE.
> >
> > As it is, I think the whole trunk can be cp'ed to RELEASE (i.e.
> > trash RELEASE tree and start from this working version).
> >
> > Then all new development starts again on TRUNK.
> >
> > Nick
> 
> I don't think we really have to nuke the release tree for each
> release, just create a new sub directory under it. One mistake we
> might have done with this release is that we just called it 3.0, even
> for beta releases. I think in the future we should create
> releases/3.1-beta1, beta2 and so on and then simply create release
> packages from those directories. 
> 
> Nothing new from trunk will go into those. What should be allowed to 
> change in release is just release specific things like editing the 
> installation script (Like I did with 3.0-beta1) or changing the
> version number.
> 
> What I think we should do now is to rename releases/3.0 to 
> releases/3.0-beta1. After we get some bug reports and/or fix some 
> things ourselves in trunk and we feel things are done, I'll create a 
> releases/3.0-final (Or beta2 should we think it's necessary) from
> trunk and leave the beta1 directory alone. 

OK, but what I meant was that TRUCK (as it is) is tested upto NOW.  So
I thought that would become the beta1/2 or whatever.

But anyway, we are there :-)

Nick
-- 
Free Software Foundation Associate Member 5508

[Bashburn-info] cdrecord OPTIONS dump

[Nick W. <ni...@uk...>]

On Mon, 06 Oct 2008 22:52:23 +0200
Markus Kollmar <mar...@on...> wrote:

> Yes you are right, I think also it is much work to grep the output of 
> the burner-option (since it seems not strongly formated and some part
> of output goes not to stdout I think.)

As an aside on this, I too like Markus couldn't work out why some of
the dump goes to STDOUT and some doesn't seem to go anywhere yet still
gets printed to terminal.

i.e. compare:

cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive

with:

cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive > /dev/null

with:

cdrecord dev=/dev/<your_drive> driveropts=help -checkdrive | grep -i
Driver

I dunno how Jörg Schilling has done this.  In the man page quote:

"driveropts=option list
              Set driver specific options. The options are specified a
comma separated list.  To get a  list of valid options use
driveropts=help together with the -checkdrive option.  If you like to
set driver options without running a typical cdrecord task, you need to
use the -setdropts  option in  addition,  otherwise  the command line
parser in cdrecord will complain."


Command line parser?  So he somehow does some magic?

I have never seen this behaviour in any application ever before.

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] 3.0 Beta 1

[Anders L. <and...@gm...>]

On Tuesday 07 October 2008 18:28:45 you wrote:
> On Tue, 07 Oct 2008 15:44:31 +0200
>
> Markus Kollmar <mar...@on...> wrote:
> > Anders Lindén wrote:
> > > On Tuesday 07 October 2008 15:11:50 you wrote:
> > >> Anders, we have a small problem with Beta 1!
> > >>
> > >> I have done yesterday some changes in the trunk (also the
> > >
> > > mentioned
> > >
> > >> swedish language updating).
> > >> Now I saw you have not moved all files for the release 3.0 from
> > >
> > > 'trunk'
> > >
> > >> to 'release' shortly before you created the release-package.
> > >
> > > Ouch! Which files are we talking about? I could add the missing
> > > files and do a quick re-release.
> >
> > Anders, I think that is not the best idea (it are some files like
> > "BashBurn.sh" and lang. files - and maybe I think Nick and maybe
> > others also did improvements since then).
> > So in such cases we should always take the whole thing to avoid
> > dependency-problems - if we can be shure nothing is broken - 
and i
> > think in this short time the trunk is relatively usable.
> >
> > >> I should had tell you this - so you thought that there was no 
major
> > >> changes in the trunk since you created the release branch.
> > >> In my humble opinion I think it would be good if we use 
following
> > >> process to make a release and to avoid such things in future:
> > >>
> > >>
> > >> 1. Like you did - tell others per mailing list shortly before
> > >> release whether it is ok to create a release for the main
> > >> developers, and tell the short time period in which the 
creation
> > >> is planned.
> > >>
> > >> 2. Then lock the trunk branch (via "svn lock") and move ALL 
files
> > >
> > > from
> > >
> > >> trunk to release.
> > >>
> > >> 3. Create package from release tree.
> > >>
> > >> 4. Unlock trunk branch.
> > >>
> > >>
> > >> Is this a way?
> > >
> > > Sounds like a good idea to me.
>
> Also what I meant was all changes go to TRUNK.  Then and if tested 
etc.
> export that particular fix to RELEASE.
>
> As it is, I think the whole trunk can be cp'ed to RELEASE (i.e. trash
> RELEASE tree and start from this working version).
>
> Then all new development starts again on TRUNK.
>
> Nick

I don't think we really have to nuke the release tree for each release, 
just create a new sub directory under it. One mistake we might have 
done with this release is that we just called it 3.0, even for beta 
releases. I think in the future we should create releases/3.1-beta1, 
beta2 and so on and then simply create release packages from those 
directories. 

Nothing new from trunk will go into those. What should be allowed to 
change in release is just release specific things like editing the 
installation script (Like I did with 3.0-beta1) or changing the version 
number.

What I think we should do now is to rename releases/3.0 to 
releases/3.0-beta1. After we get some bug reports and/or fix some 
things ourselves in trunk and we feel things are done, I'll create a 
releases/3.0-final (Or beta2 should we think it's necessary) from trunk 
and leave the beta1 directory alone. 

-- 
Anders Lindén
http://bashburn.dose.se

Re: [Bashburn-info] 3.0 Beta 1

[Nick W. <ni...@uk...>]

On Tue, 07 Oct 2008 15:44:31 +0200
Markus Kollmar <mar...@on...> wrote:

> Anders Lindén wrote:
> > On Tuesday 07 October 2008 15:11:50 you wrote:
> >   
> >> Anders, we have a small problem with Beta 1!
> >>
> >> I have done yesterday some changes in the trunk (also the 
> >>     
> > mentioned
> >   
> >> swedish language updating).
> >> Now I saw you have not moved all files for the release 3.0 from 
> >>     
> > 'trunk'
> >   
> >> to 'release' shortly before you created the release-package.
> >>
> >>     
> >
> > Ouch! Which files are we talking about? I could add the missing
> > files and do a quick re-release.
> >
> >   
> 
> Anders, I think that is not the best idea (it are some files like 
> "BashBurn.sh" and lang. files - and maybe I think Nick and maybe
> others also did improvements since then).
> So in such cases we should always take the whole thing to avoid 
> dependency-problems - if we can be shure nothing is broken - and i
> think in this short time the trunk is relatively usable.
> 
> 
> >> I should had tell you this - so you thought that there was no major
> >> changes in the trunk since you created the release branch.
> >> In my humble opinion I think it would be good if we use following
> >> process to make a release and to avoid such things in future:
> >>
> >>
> >> 1. Like you did - tell others per mailing list shortly before
> >> release whether it is ok to create a release for the main
> >> developers, and tell the short time period in which the creation
> >> is planned.
> >>
> >> 2. Then lock the trunk branch (via "svn lock") and move ALL files 
> >>     
> > from
> >   
> >> trunk to release.
> >>
> >> 3. Create package from release tree.
> >>
> >> 4. Unlock trunk branch.
> >>
> >>
> >> Is this a way?
> >>     
> >
> > Sounds like a good idea to me. 

Also what I meant was all changes go to TRUNK.  Then and if tested etc.
export that particular fix to RELEASE.

As it is, I think the whole trunk can be cp'ed to RELEASE (i.e. trash
RELEASE tree and start from this working version).

Then all new development starts again on TRUNK.

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] 3.0 Beta 1

[Markus K. <mar...@on...>]

Anders Lindén wrote:
> On Tuesday 07 October 2008 15:11:50 you wrote:
>   
>> Anders, we have a small problem with Beta 1!
>>
>> I have done yesterday some changes in the trunk (also the 
>>     
> mentioned
>   
>> swedish language updating).
>> Now I saw you have not moved all files for the release 3.0 from 
>>     
> 'trunk'
>   
>> to 'release' shortly before you created the release-package.
>>
>>     
>
> Ouch! Which files are we talking about? I could add the missing files 
> and do a quick re-release.
>
>   

Anders, I think that is not the best idea (it are some files like 
"BashBurn.sh" and lang. files - and maybe I think Nick and maybe others 
also did improvements since then).
So in such cases we should always take the whole thing to avoid 
dependency-problems - if we can be shure nothing is broken - and i think 
in this short time the trunk is relatively usable.


>> I should had tell you this - so you thought that there was no major
>> changes in the trunk since you created the release branch.
>> In my humble opinion I think it would be good if we use following
>> process to make a release and to avoid such things in future:
>>
>>
>> 1. Like you did - tell others per mailing list shortly before release
>> whether it is ok to create a release for the main developers, and tell
>> the short time period in which the creation is planned.
>>
>> 2. Then lock the trunk branch (via "svn lock") and move ALL files 
>>     
> from
>   
>> trunk to release.
>>
>> 3. Create package from release tree.
>>
>> 4. Unlock trunk branch.
>>
>>
>> Is this a way?
>>     
>
> Sounds like a good idea to me. 
>
>
>   
ok :-)


Markus

Re: [Bashburn-info] 3.0 Beta 1

[Anders L. <and...@gm...>]

On Tuesday 07 October 2008 15:23:28 you wrote:
> On Tue, 07 Oct 2008 15:11:50 +0200
>
> Markus Kollmar <mar...@on...> wrote:
> > Anders Lindén wrote:
> > > On Tuesday 07 October 2008 02:10:43 you wrote:
> > >> Anders Lindén schrieb:
> > >>> So guys, I'm thinking I'll release 3.0 beta1 tonight or 
tomorrow.
> > >>> If anyone feels that's a bad idea let me know, otherwise I'll 
do
> > >>> it. I'll include the English, Swedish and German translation
> > >>> because as
> > >
> > > far as I
> > >
> > >>> know those are the ones updated.
> > >>> We've tested this thing pretty good so I feel good releasing 
a
> > >
> > > beta to
> > >
> > >>> hunt down any hard to find bugs that might still be there.
> > >>
> > >> Ok, Anders. Big marking as beta I think would be ok. So we 
could
> > >
> > > get
> > >
> > >> more people for testing - and since there is a "rule" to release
> > >> often in open source development, this may also a point.
> > >>
> > >> Ahh - Anders you can look to the Swedish translation. I have 
added
> > >
> > > the
> > >
> > >> variable
> > >>
> > >> bb_main_menu=MAIN
> > >>
> > >> in file "BashBurn.lang" for main-menue header text printing.
> > >
> > > Translate it
> > >
> > >> to swedish if necessary.
> > >>
> > >>
> > >>
> > >> By the way - did you removed the link to the svn web-interface 
on
> > >
> > > the
> > >
> > >> bashburn website? I cna't find it anymore. I think it would be
> > >> nice to
> > >
> > > have
> > >
> > >> it there, or don' t think so?
> > >>
> > >> Markus
> > >
> > > Alright Markus, I'll add and translate that.
> > > No I haven't removed that link from the web page. It's located
> > > under downloads -> webSVN
> >
> > Anders, we have a small problem with Beta 1!
> >
> > I have done yesterday some changes in the trunk (also the 
mentioned
> > swedish language updating).
> > Now I saw you have not moved all files for the release 3.0 from
> > 'trunk' to 'release' shortly before you created the release-
package.
> >
> > I should had tell you this - so you thought that there was no major
> > changes in the trunk since you created the release branch.
> > In my humble opinion I think it would be good if we use following
> > process to make a release and to avoid such things in future:
> >
> >
> > 1. Like you did - tell others per mailing list shortly before release
> > whether it is ok to create a release for the main developers, and
> > tell the short time period in which the creation is planned.
> >
> > 2. Then lock the trunk branch (via "svn lock") and move ALL files
> > from trunk to release.
> >
> > 3. Create package from release tree.
> >
> > 4. Unlock trunk branch.
> >
> >
> > Is this a way?
> > However, Anders now we can maybe in near future release beta 
2.
> > Hehe - before we got installed beta 1, it is already outdated.
> > If we would be a company we could make much money and users 
would be
> > impressed about the dynamic of improvements.  ;-)
>
> Also I see somebody is only updating RELEASE tree?  I thought 
TRUNK
> would be moved to RELEASE for beta 1?
>
> Nick

That was me just doing a quick little fix for beta 1. I forgot to update 
the installation script to not try to install the translations that were 
not included. 

I agree we should release a beta 2 soon. I should have checked more 
carefully that the latest trunk was copied to release. Sorry about that.

-- 
Anders Lindén
http://bashburn.dose.se

Re: [Bashburn-info] 3.0 Beta 1

[Nick W. <ni...@uk...>]

On Tue, 7 Oct 2008 14:23:28 +0100
Nick Warne <ni...@uk...> wrote:

> On Tue, 07 Oct 2008 15:11:50 +0200
> Markus Kollmar <mar...@on...> wrote:
> 
> > Anders Lindén wrote:
> > > On Tuesday 07 October 2008 02:10:43 you wrote:
> > >   
> > >> Anders Lindén schrieb:
> > >>     
> > >>> So guys, I'm thinking I'll release 3.0 beta1 tonight or
> > >>> tomorrow. If anyone feels that's a bad idea let me know,
> > >>> otherwise I'll do it. I'll include the English, Swedish and
> > >>> German translation because as 
> > > far as I
> > >   
> > >>> know those are the ones updated.
> > >>> We've tested this thing pretty good so I feel good releasing a 
> > >>>       
> > > beta to
> > >   
> > >>> hunt down any hard to find bugs that might still be there.
> > >>>       
> > >> Ok, Anders. Big marking as beta I think would be ok. So we could 
> > >>     
> > > get
> > >   
> > >> more people for testing - and since there is a "rule" to release
> > >> often in open source development, this may also a point.
> > >>
> > >> Ahh - Anders you can look to the Swedish translation. I have
> > >> added 
> > > the
> > >   
> > >> variable
> > >>
> > >> bb_main_menu=MAIN
> > >>
> > >> in file "BashBurn.lang" for main-menue header text printing. 
> > >>     
> > > Translate it
> > >   
> > >> to swedish if necessary.
> > >>
> > >>
> > >>
> > >> By the way - did you removed the link to the svn web-interface
> > >> on 
> > > the
> > >   
> > >> bashburn website? I cna't find it anymore. I think it would be
> > >> nice to 
> > > have
> > >   
> > >> it there, or don' t think so?
> > >>
> > >> Markus
> > >>     
> > >
> > > Alright Markus, I'll add and translate that.
> > > No I haven't removed that link from the web page. It's located
> > > under downloads -> webSVN
> > >
> > >   
> > 
> > Anders, we have a small problem with Beta 1!
> > 
> > I have done yesterday some changes in the trunk (also the mentioned 
> > swedish language updating).
> > Now I saw you have not moved all files for the release 3.0 from
> > 'trunk' to 'release' shortly before you created the release-package.
> > 
> > I should had tell you this - so you thought that there was no major 
> > changes in the trunk since you created the release branch.
> > In my humble opinion I think it would be good if we use following 
> > process to make a release and to avoid such things in future:
> > 
> > 
> > 1. Like you did - tell others per mailing list shortly before
> > release whether it is ok to create a release for the main
> > developers, and tell the short time period in which the creation is
> > planned.
> > 
> > 2. Then lock the trunk branch (via "svn lock") and move ALL files
> > from trunk to release.
> > 
> > 3. Create package from release tree.
> > 
> > 4. Unlock trunk branch.
> > 
> > 
> > Is this a way?
> > However, Anders now we can maybe in near future release beta 2.
> > Hehe - before we got installed beta 1, it is already outdated.
> > If we would be a company we could make much money and users would
> > be impressed about the dynamic of improvements.  ;-)
> 
> Also I see somebody is only updating RELEASE tree?  I thought TRUNK
> would be moved to RELEASE for beta 1?

Forgot - reason is there are a ton of fixes in TRUNK that are not in
RELEASE tree...

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] 3.0 Beta 1

[Nick W. <ni...@uk...>]

On Tue, 07 Oct 2008 15:11:50 +0200
Markus Kollmar <mar...@on...> wrote:

> Anders Lindén wrote:
> > On Tuesday 07 October 2008 02:10:43 you wrote:
> >   
> >> Anders Lindén schrieb:
> >>     
> >>> So guys, I'm thinking I'll release 3.0 beta1 tonight or tomorrow.
> >>> If anyone feels that's a bad idea let me know, otherwise I'll do
> >>> it. I'll include the English, Swedish and German translation
> >>> because as 
> > far as I
> >   
> >>> know those are the ones updated.
> >>> We've tested this thing pretty good so I feel good releasing a 
> >>>       
> > beta to
> >   
> >>> hunt down any hard to find bugs that might still be there.
> >>>       
> >> Ok, Anders. Big marking as beta I think would be ok. So we could 
> >>     
> > get
> >   
> >> more people for testing - and since there is a "rule" to release
> >> often in open source development, this may also a point.
> >>
> >> Ahh - Anders you can look to the Swedish translation. I have added 
> >>     
> > the
> >   
> >> variable
> >>
> >> bb_main_menu=MAIN
> >>
> >> in file "BashBurn.lang" for main-menue header text printing. 
> >>     
> > Translate it
> >   
> >> to swedish if necessary.
> >>
> >>
> >>
> >> By the way - did you removed the link to the svn web-interface on 
> >>     
> > the
> >   
> >> bashburn website? I cna't find it anymore. I think it would be
> >> nice to 
> > have
> >   
> >> it there, or don' t think so?
> >>
> >> Markus
> >>     
> >
> > Alright Markus, I'll add and translate that.
> > No I haven't removed that link from the web page. It's located
> > under downloads -> webSVN
> >
> >   
> 
> Anders, we have a small problem with Beta 1!
> 
> I have done yesterday some changes in the trunk (also the mentioned 
> swedish language updating).
> Now I saw you have not moved all files for the release 3.0 from
> 'trunk' to 'release' shortly before you created the release-package.
> 
> I should had tell you this - so you thought that there was no major 
> changes in the trunk since you created the release branch.
> In my humble opinion I think it would be good if we use following 
> process to make a release and to avoid such things in future:
> 
> 
> 1. Like you did - tell others per mailing list shortly before release 
> whether it is ok to create a release for the main developers, and
> tell the short time period in which the creation is planned.
> 
> 2. Then lock the trunk branch (via "svn lock") and move ALL files
> from trunk to release.
> 
> 3. Create package from release tree.
> 
> 4. Unlock trunk branch.
> 
> 
> Is this a way?
> However, Anders now we can maybe in near future release beta 2.
> Hehe - before we got installed beta 1, it is already outdated.
> If we would be a company we could make much money and users would be 
> impressed about the dynamic of improvements.  ;-)

Also I see somebody is only updating RELEASE tree?  I thought TRUNK
would be moved to RELEASE for beta 1?

Nick
-- 
Free Software Foundation Associate Member 5508

[Bashburn-info] Mailing list AWOL

[Nick W. <ni...@uk...>]

This list seems to be not working again...

Nick
-- 
Free Software Foundation Associate Member 5508

Re: [Bashburn-info] 3.0 Beta 1

[Markus K. <mar...@on...>]

Anders Lindén wrote:
> On Tuesday 07 October 2008 02:10:43 you wrote:
>   
>> Anders Lindén schrieb:
>>     
>>> So guys, I'm thinking I'll release 3.0 beta1 tonight or tomorrow. If
>>> anyone feels that's a bad idea let me know, otherwise I'll do it. I'll
>>> include the English, Swedish and German translation because as 
>>>       
> far as I
>   
>>> know those are the ones updated.
>>> We've tested this thing pretty good so I feel good releasing a 
>>>       
> beta to
>   
>>> hunt down any hard to find bugs that might still be there.
>>>       
>> Ok, Anders. Big marking as beta I think would be ok. So we could 
>>     
> get
>   
>> more people for testing - and since there is a "rule" to release often
>> in open source development, this may also a point.
>>
>> Ahh - Anders you can look to the Swedish translation. I have added 
>>     
> the
>   
>> variable
>>
>> bb_main_menu=MAIN
>>
>> in file "BashBurn.lang" for main-menue header text printing. 
>>     
> Translate it
>   
>> to swedish if necessary.
>>
>>
>>
>> By the way - did you removed the link to the svn web-interface on 
>>     
> the
>   
>> bashburn website? I cna't find it anymore. I think it would be nice to 
>>     
> have
>   
>> it there, or don' t think so?
>>
>> Markus
>>     
>
> Alright Markus, I'll add and translate that.
> No I haven't removed that link from the web page. It's located under 
> downloads -> webSVN
>
>   

Anders, we have a small problem with Beta 1!

I have done yesterday some changes in the trunk (also the mentioned 
swedish language updating).
Now I saw you have not moved all files for the release 3.0 from 'trunk' 
to 'release' shortly before you created the release-package.

I should had tell you this - so you thought that there was no major 
changes in the trunk since you created the release branch.
In my humble opinion I think it would be good if we use following 
process to make a release and to avoid such things in future:


1. Like you did - tell others per mailing list shortly before release 
whether it is ok to create a release for the main developers, and tell 
the short time period in which the creation is planned.

2. Then lock the trunk branch (via "svn lock") and move ALL files from 
trunk to release.

3. Create package from release tree.

4. Unlock trunk branch.


Is this a way?
However, Anders now we can maybe in near future release beta 2.
Hehe - before we got installed beta 1, it is already outdated.
If we would be a company we could make much money and users would be 
impressed about the dynamic of improvements.  ;-)


Markus

Re: [Bashburn-info] Mailing list AWOL

[Anders L. <and...@gm...>]

On Tuesday 07 October 2008 14:50:41 Steven W. Orr wrote:
> On Tuesday, Oct 7th 2008 at 05:07 -0000, quoth Nick Warne:
>
> =>
> =>This list seems to be not working again...
> =>
> =>Nick
> =>--
> =>Free Software Foundation Associate Member 5508
> =>
>
> If you want to crank up bas...@sy... it's available.

How do we import the subscribers (And if possible messages) from the 
sourceforge mailing list to the syslang one?
-- 
Anders Lindén
http://bashburn.dose.se